OpenAI's Python agent toolkit can now read external tool annotations and format function execution errors using shared, run-wide rules. Developers connecting external tools can manage error messages centrally. History compaction is deferred for tasks awaiting human approval.

1. Tool annotations are references, not permissions

Released on October 15, 2026, 0.24.0 exposes server-provided annotations when converting MCP server tools into function tools. MCP is a protocol for connecting agents to external tools. These annotations serve as hints for understanding tools.

Developers can read this information through FunctionTool.mcp_annotations. The value is returned as a copy, so changing it does not affect the original.

Non-MCP tools and tools without annotations return None. Hints omitted by the server remain absent. Developers needing defaults must apply the default rules of the MCP version they use.

The release notes say to treat this information as untrusted hints. It grants no execution approval and is excluded from model-facing tool definitions and serialized tool provenance. A description is not an access pass.

2. Set function error messages across a run

RunConfig.tool_error_formatter is a run-wide callback: a custom function invoked to generate tool error messages. This path now also handles execution exceptions from function tools registered using a decorator.

The error kind kind="tool_exception" has been added. If an existing handler treats every non-rejection error as a missing tool, it could incorrectly report that a function was not found when its execution actually failed.

Update existing callbacks to handle the new kind explicitly or return None for it to use the default message. Default behavior without a custom handler remains unchanged.

The optional error field carries exception information. Developers must deliberately sanitize details before including them in model-facing messages. Receiving exception information does not mean it is safe to disclose.

An explicitly specified per-tool handler takes precedence over the run-wide setting. An explicitly specified None or default handler retains this precedence.

Failures in factory-created MCP tools and agents wrapped with Agent.as_tool retain separate behavior. Timeouts, cancellations, and schema-based programmatic invocations are not merged into the new shared handling path.

3. Defer history compaction while approval is pending

Automatic compaction reduces conversation history for easier management. This fix defers it when approval requests are pending. It changes the processing order so history cleanup does not run ahead of unfinished approval steps.

History held while awaiting approval is now preserved through run resumption. The release page's review report says history saving is deferred until output safety checks. Preservation does not mean unconditional saving before those checks.

4. Check error kinds and saved runs before adoption

If an existing handler identifies missing tools solely by whether an error is a rejection, it may report execution failures as missing tools in the new version. Centralized error messaging first requires distinguishing missing tools from execution failures.

Update timing also matters when using saved runs. The release review report says some older configurations containing agents with identical names cannot be loaded in the new version. Finish those tasks with the SDK and original agent code used when saving them.

The release notes provide no runnable code examples.

Adoption depends less on the number of new features than on whether existing error classifications distinguish new inputs and which version is needed to finish saved tasks.