The Problem With Writing Every Tool Yourself

Unit 8 covered function calling by writing custom Python functions and their schemas by hand. This works well for a tool specific to your own application, but a huge number of tools an application might want — reading a calendar, searching a company's Slack history, querying a shared project-management system — are things someone else has already built an integration for, and reimplementing each one from scratch as a custom function would mean rebuilding the same authentication, pagination, and API-wrapping work every other developer wanting the same integration has already had to do. The Model Context Protocol (MCP) exists to standardize this: rather than every application writing its own bespoke schema and implementation for "search my company's Notion workspace," an MCP server exposes a standard interface that any MCP-compatible client can connect to, and any tool built against that standard interface works the same way regardless of which application is calling it.

What a Remote MCP Server Actually Is

An MCP server is a service — running somewhere on the internet, hosted by whoever built the integration — that exposes a set of tools following the Model Context Protocol's standard format. A "remote" MCP server, in the context of this lesson, is one your request connects to over the network at request time, as opposed to a tool implemented directly in your own application code. Connecting a model-calling request to a remote MCP server gives the model access to whatever tools that server exposes, without you having to implement those tools yourself — you are, in effect, borrowing someone else's already-built and already-maintained integration.

response = client.responses.create(
    model="gpt-5.6-terra",
    input="What are the open issues assigned to me in the 'backend' project?",
    tools=[
        {
            "type": "mcp",
            "server_label": "project-tracker",
            "server_url": "https://mcp.example-project-tool.com/sse",
            "authorization": "Bearer YOUR_ACCESS_TOKEN",
        }
    ],
)

print(response.output_text)

Note: The exact tool type identifier (mcp here), the required fields for connecting to a remote server (server_label, server_url, authentication mechanism), and the specifics of how authorization tokens are supplied can vary significantly by SDK version and by the specific MCP server being connected to. Confirm the current interface, and the specific connection details for whatever MCP server you're integrating with, against the current documentation for both before relying on these specifics in production code.

Here, the request never defines parameters schemas or writes any implementation at all, in sharp contrast to every custom function example in Unit 8 — the remote server at server_url is what defines which tools are available and implements them, and the model discovers and uses those tools directly through the connection, the same way it would use a locally defined {"type": "function"} tool, just with the implementation living on someone else's server instead of in your own code.

Connectors: Pre-Built MCP Integrations

A "connector" is a term commonly used for a specific, pre-built remote MCP server integration for a well-known service — a connector for a project-management tool, a connector for a shared document platform, a connector for a team chat tool. Rather than building an MCP server from scratch to integrate with a popular service, using an existing, maintained connector for that service is almost always the right choice, for the same reason using a well-maintained library beats hand-rolling equivalent functionality: someone else has already handled the authentication flow, the API's quirks, and the ongoing maintenance as that service's own API evolves.

tools = [
    {
        "type": "mcp",
        "server_label": "team-chat",
        "server_url": "https://mcp.example-chat-tool.com/sse",
        "authorization": f"Bearer {chat_tool_access_token}",
    },
    {
        "type": "mcp",
        "server_label": "shared-docs",
        "server_url": "https://mcp.example-docs-tool.com/sse",
        "authorization": f"Bearer {docs_tool_access_token}",
    },
]

response = client.responses.create(
    model="gpt-5.6-terra",
    input="Summarize the discussion in the #launch-planning channel and check if there's a related planning doc.",
    tools=tools,
)

Registering two connectors at once here — one for team chat, one for shared documents — mirrors Unit 8, Lesson 4's guidance on registering multiple tools: the model chooses which connector's tools are relevant to which part of a combined request, based on each server's exposed tool descriptions, exactly as it would choose among several custom function tools. The practical difference is entirely in where the implementation lives and who maintains it, not in how the model reasons about when to use each one.

Approval and Trust: A Different Risk Profile Than Custom Functions

Unit 8, Lesson 5 covered treating function-call arguments as untrusted input and validating them inside functions you control. A remote MCP server introduces a related but distinct concern: you are not just trusting the model's arguments, you are trusting a third party's server to correctly and safely implement whatever tools it claims to expose, and to handle your authorization credentials responsibly. This is a meaningfully different trust boundary than a custom function you wrote and can fully audit yourself.

response = client.responses.create(
    model="gpt-5.6-terra",
    input="Send a message to the #general channel announcing the release.",
    tools=[{
        "type": "mcp",
        "server_label": "team-chat",
        "server_url": "https://mcp.example-chat-tool.com/sse",
        "authorization": f"Bearer {chat_tool_access_token}",
        "require_approval": "always",
    }],
)

for item in response.output:
    if item.type == "mcp_approval_request":
        print(f"Approval requested for: {item.name} with arguments {item.arguments}")
        # A real application would surface this to a human before proceeding,
        # rather than approving automatically.

Note: The exact mechanism for requiring and handling approval (require_approval, the mcp_approval_request item shape, and how an approval or denial is actually submitted back) can vary by SDK version. Confirm the current interface against your installed SDK version's documentation.

Setting an explicit approval requirement for a consequential action (sending a real message to a real channel, in this example) mirrors Unit 8, Lesson 5's confirmation-step pattern for irreversible custom-function actions, applied here to a remote server's tool instead of your own function — and arguably matters even more for a remote MCP server, since you have less direct visibility into and control over exactly what that tool's implementation does than you would for a function you wrote yourself. Treating every remote MCP tool with real side effects as requiring the same deliberate, human-reviewed confirmation Unit 8, Lesson 5 argued for is a reasonable default, tightened or relaxed based on how much you trust the specific server and how reversible its actions actually are.

Combining Remote MCP Tools With Custom Functions and Built-In Tools

A single request can mix all three categories this course has now covered — custom functions (Unit 8), platform-native built-in tools (web search, file search, Code Interpreter, earlier in this unit), and remote MCP connectors (this lesson) — letting the model draw on whichever source is appropriate for each part of a request.

def get_internal_ticket_status(ticket_id: str) -> dict:
    return {"ticket_id": ticket_id, "status": "in_progress"}

tools = [
    {"type": "web_search"},
    {
        "type": "function",
        "name": "get_internal_ticket_status",
        "description": "Look up the status of an internal support ticket by its ID.",
        "parameters": {
            "type": "object",
            "properties": {"ticket_id": {"type": "string"}},
            "required": ["ticket_id"],
            "additionalProperties": False,
        },
    },
    {
        "type": "mcp",
        "server_label": "team-chat",
        "server_url": "https://mcp.example-chat-tool.com/sse",
        "authorization": f"Bearer {chat_tool_access_token}",
    },
]

response = client.responses.create(
    model="gpt-5.6-terra",
    input="What's the status of ticket TCK-4471, is there any related discussion in Slack, and what's the latest on the vendor's public status page?",
    tools=tools,
)

This single request routes three sub-questions to three entirely different sources — an internal custom function for the ticket status, a remote MCP connector for the Slack discussion, and web search for the vendor's public status — with the model deciding the correct source for each based purely on each tool's description, exactly as Unit 8, Lesson 4 described for choosing among several custom functions, now extended across all three tool categories at once.

When to Reach for a Remote MCP Server Versus a Custom Function

The choice between building a custom function (Unit 8) and connecting to an existing remote MCP server for the same capability comes down to a straightforward question: does a maintained integration for this specific service already exist? If a well-maintained connector exists for the exact service you need (a popular project-management tool, a popular documentation platform), using it is almost always less work and lower-maintenance than building an equivalent custom function yourself, since you inherit the connector's ongoing maintenance as the underlying service's API evolves. If no such integration exists — because the system is entirely internal and proprietary, or simply because no one has built a connector for it yet — a custom function (Unit 8) remains the right tool, since it is the only option that gives you both full implementation control and no dependency on a third party's server being available and correctly maintained.

Restricting Which Tools a Server Exposes

A single remote MCP server often exposes many tools — a project-tracker connector might expose tools for reading issues, creating issues, closing issues, and deleting entire projects, even though a specific application only ever needs the first of those. Restricting which of a server's tools are actually made available to the model, rather than exposing everything the server offers by default, applies the same least-privilege reasoning Unit 8, Lesson 5 introduced for custom functions to a connector you did not write yourself.

response = client.responses.create(
    model="gpt-5.6-terra",
    input="What are the open issues in the 'backend' project?",
    tools=[{
        "type": "mcp",
        "server_label": "project-tracker",
        "server_url": "https://mcp.example-project-tool.com/sse",
        "authorization": f"Bearer {project_tool_access_token}",
        "allowed_tools": ["list_issues", "get_issue"],
    }],
)

Note: The exact field name and mechanism for restricting a connected server's exposed tools (allowed_tools here) can vary by SDK version and by server. Confirm the current interface against your installed SDK version's documentation.

Explicitly listing allowed_tools as ["list_issues", "get_issue"] means the model cannot request delete_project or create_issue through this connection at all, even if the underlying server technically supports them — the restriction is enforced before the model ever sees those tools as options, which is a stronger guarantee than hoping the model simply chooses not to call a destructive tool it could otherwise see and request. For any read-only use case like this one, restricting to only the read-only tools a server exposes is a direct, low-effort way to eliminate an entire category of risk rather than relying on approval steps alone to catch a problem after the fact.

Common Mistakes

Granting a remote MCP connector broad access without an explicit approval step for consequential actions, extending less scrutiny to a third party's tool implementation than Unit 8, Lesson 5 argued for even your own custom functions.

Building a custom function from scratch for a capability a maintained connector already covers, taking on unnecessary implementation and maintenance burden for an integration someone else already built and keeps current.

Treating a remote MCP server's output as equally trustworthy as a custom function you wrote and audited yourself, when a third-party server's implementation is not something you can fully verify or control.

Forgetting that authorization credentials passed to a remote MCP server carry the same sensitivity as any other credential, and should be scoped and stored with the same care as an API key used anywhere else in an application.

Best Practices

Prefer an existing, maintained connector over a custom function whenever one exists for the service you need, to avoid duplicating already-solved integration and maintenance work.

Require explicit approval for any remote MCP tool with real, consequential side effects, treating this at least as seriously as Unit 8, Lesson 5's guidance for custom functions with real side effects.

Scope authorization tokens narrowly to only the access a given integration actually needs, following the same least-privilege principle Unit 8, Lesson 5 applied to custom function capabilities.

Combine custom functions, platform built-in tools, and remote MCP connectors deliberately within one tools list when an application genuinely needs capabilities from all three categories, relying on clear, distinct tool descriptions to let the model route each part of a request correctly.