Enable to access MCP server name via its converted function tool object

[habema]

Problem:
When MCP tools are converted to FunctionTool via MCPUtil.to_function_tool(), the server name is only in the on_invoke_tool closure. When ToolCallItem/ToolCallOutputItem are created from API responses, they lose which
MCP server the tool came from. With multiple MCP servers, you can't tell which server handled a call.

Given that there could be multiple MCPs, and each MCP's tools could change frequently, tracking MCP server labels externally by tool name is not feasible. This also has implications on StreamEvent by extension.

Proposed solution:
Add a general metadata field to RunItemBase:

@dataclass
class RunItemBase(Generic[T], abc.ABC):
    agent: Agent[Any]
    raw_item: T
    
    metadata: dict[str, Any] = field(default_factory=dict)
    """SDK-level metadata for tracking and debugging. This metadata is NOT sent to the agent.
    
    Examples:
    - For MCP tools: {"mcp_server_name": "git_server"}
    - For handoffs: {"handoff_source": "agent_a"}
    - For debugging: {"execution_time_ms": 123}
    """

The solution to this specific problem:

1. Store MCP server name as a private attribute on FunctionTool when converting MCP tools
2. When creating ToolCallItem/ToolCallOutputItem, populate metadata from the tool if available
3. Access metadata via item.metadata.get('mcp_server_name') when needed

Additional Benefits: The solution is very general-purpose, it supports any future metadata needs, not just MCP, as in the examples in the code snippet.

I'd love to know what you think before implementing this. While this may not be a breaking change, it introduces a new feature at the very core of the SDK, and could have other implications I'm not aware of.

[habema]

@seratch @ihower Your opinions would be appreciated

[seratch]

Hi @habema, first off, please avoid immediately mentioning maintainers here. As you know, I have been actively responding to issues in this repo. While it may sometimes take time, every issue and PR is acknowledged. Also, @ihower is not a core maintainer, so please refrain from mentioning him unless he is actively participating in a discussion.

Regarding this suggestion, I would prefer to avoid adding a general-purpose metadata dict property to the root type. On the other hand, I do see some needs to attach specific information, such as mcp_server_name: str | None, origin: ToolOrigin (just a quick idea, this could be a new type), or similar fields to function tool objects.

That said, we'll be out of the office during the winter holidays and after that, I need to focus on other major changes for 0.7 release. So, it's totally fine to continue discussing potential ideas here, but I won't actively work on it in the short term. I'd appreciate your understanding.

[habema]

Apologies for the pings. I also understand this wouldn't be a priority in the meantime given the upcoming release and holidays.

My first thought was creating a field (like mcp_server_name: str | None) to FunctionTool, or to ToolCallItem and ToolCallOutputItem, but I wasn't too sure if that fix was too targeted to this issue, and lacks extendability.

[ihower]

@habema No worries at all, and thanks for thinking of asking for my opinion. I’m not part of the core team, just a regular contributor. I do actively follow and reply to issues that I personally find interesting, so there’s no need to explicitly mention me.

Regarding this issue itself, at the moment I haven’t personally run into a concrete need to attach a metadata dict to RunItemBase. So I don’t have a strong opinion in favor of adding it there at this time.