feat: server-side MCP connector as a built-in tool

chatlas already speaks MCP client-side (register_mcp_tools_http_stream_async() and friends): chatlas runs the MCP client, executes tool calls locally, and round-trips results. All three first-class providers now also offer a server-side MCP connector: you hand the provider a remote MCP server URL and the provider's infrastructure does tool discovery and invocation itself — no local MCP client, no async session to keep alive, works from restricted environments.

That makes it a natural next ToolBuiltIn after code execution:

chat.register_tool(tool_mcp(url="https://mcp.example.com", name="example"))

Provider mapping

Design questions

• Naming and docs positioning relative to the existing client-side register_mcp_tools_* functions — users will need a clear mental model of "chatlas executes the MCP tools" vs. "the provider executes the MCP tools" (and the privacy/latency trade-offs of each).
• Approval flow: OpenAI's require_approval emits mcp_approval_request items that the client must answer. Can this map onto chatlas's existing tool-approval machinery (on_tool_request / ToolRejectError), or does it need its own surface?
• Auth: how to pass tokens without persisting them in serialized turns.
• Content modeling: what mcp_list_tools / mcp_call events look like as chatlas Content (probably new request/response content types in PROVIDER_ANNOTATION_TYPES, like search/fetch).
• Anthropic's connector is not ZDR-eligible; worth a docs note.

Start by tracing the existing register_mcp_tools_* client-side entry points and the ToolBuiltIn implementation pattern, then inspect on_tool_request, ToolRejectError, and PROVIDER_ANNOTATION_TYPES. Compare the OpenAI, Anthropic, and Google connector contracts and determine how approval, authentication, and MCP events should fit chatlas. Done requires an agreed design, provider coverage, content modeling, tests, and documentation.