Propagate tool description to ToolCallItem

[k1eran]

I have read the docs searched for related issues where I found #2228 and PR #2242 (tool_origin)

Description of feature

Propagate a tool's human-readable description onto ToolCallItem.

The SDK already has access to descriptions via FunctionTool.description and MCP tool metadata (tools advertised by the MCP server), but ToolCallItem doesn't currently expose that description.

I'm building an app that streams tool progress events to a client. Today I can show the tool name and arguments, but I can't easily show a description of what the tool does. Without this, apps using the agents-sdk end up maintaining an external registry that maps tool names to descriptions.

This feature would enable richer streaming UIs and better user-facing observability of agent behaviour without apps duplicating tool metadata outside the SDK.

Proposed API

Add description: str | None = None field to ToolCallItem:

@dataclass
class ToolCallItem(RunItemBase[Any]):
  raw_item: ToolCallItemTypes
  type: Literal["tool_call_item"] = "tool_call_item"
  description: str | None = None

Expected behavior / acceptance criteria

• ToolCallItem.description is populated for both FunctionTool calls and MCP tool calls (when metadata is available).
• ToolCallItem.description is present in both streaming events and non-streaming runs.
• ToolCallItem.description is included in to_input_item() output so it survives serialization, and round-trips through persisted runs

If no description is available, the field remains None

Backwards compatibility

• New optional field with None default.

Notes / related work

• Enable to access MCP server name via its converted function tool object #2228 / PR feat: #2228 Add tool origin tracking to ToolCallItem and ToolCallOutputItem #2242 adds tool_origin for provenance tracking (which server/agent). This proposal adds description for user-facing content (what the tool does).
• These are complementary and touch the same areas (items.py, _run_impl.py, run.py).

I've tested this by patching the SDK locally. I'm planning to open a PR this week implementing this; happy to coordinate with PR #2242 since it touches the same areas.