張文鈿：淺談模型上下文協定MCP應用開發

1. In one sentence

MCP standardises how a large model gets hold of tools and data, so that a tool vendor writes a server once and every MCP-supporting client (Claude, Cursor, ChatWise and so on) can use it — but the speaker was equally frank that remote deployment and authentication were both still very immature as of that May.

2. The session

The speaker, 張文鈿, known online as ihower, has been building web software since 2002, specialising in full-stack Ruby on Rails; in 2018 he founded 愛好資訊科技有限公司 (aihao.tw), and since 2023 has gone all in on AI engineering, running the "AI Engineer" newsletter and his signature course, the LLM application development workshop (checking afterwards, the company and newsletter names follow his own introduction at ihower.tw/blog/about). He has also published the complete slides and a written article for this session on his own blog (article, slide PDF), which is the most direct external corroboration for these notes.

Why MCP is needed

• The definition of an LLM-based agent: an AI component that uses a large model to make decisions, deciding on steps according to a goal and calling tools repeatedly until the task is done. His analogy: "the large model itself is like a genius locked in a room" — it cannot learn or act on the world by itself, and needs external tools to reach live information and operate a computer.
• Technically, an agent is just "an LLM using tools in a loop": the program maintains instructions / tools / messages, calls the model each round, executes any tool the model asks for and puts the result back into messages, and stops when the model no longer asks for a tool and simply replies. At the API level, that tool call is what is known as function calling.
• He noted that function calling has existed since the year before last, but back then a conversation might involve one or two tool calls; more recently, models like OpenAI's o3 can chain hundreds of tool calls (speaker's own account, no external source — his phrasing was "according to what they say").
• The core claim: "raw model intelligence is not an intelligent software system". Intelligence is only the foundation stone; turning it into a genuinely useful system needs two more things — tool integration (so the model can actually act, query, remember and respond) and the right context (dynamically supplying what the task needs). That whole practice of dynamic management is "context engineering".
• MCP (Model Context Protocol) is the standardised protocol Anthropic open-sourced at the end of last year, defining how models obtain context, covering three primitives: Tools, Resources and Prompts. Official spec site: modelcontextprotocol.io.

How MCP divides the work: client app and server

• The common scenario: making it easier for an app to install third-party tool extensions. Client apps include local GUI applications and editors such as Claude Desktop, ChatWise, Cursor and Windsurf; cloud services such as Claude Web and Dify; and agent programs you write yourself (official client list: modelcontextprotocol.io/clients).
• The key property: MCP is centred on scenarios and use cases rather than on a single function, so installing one MCP server usually installs a whole bundle of tools at once. For example, the Slack MCP server installs eight functions in one go: slack_list_channels, slack_post_message, slack_reply_to_thread, slack_add_reaction, slack_get_channel_history, slack_get_thread_replies, slack_get_users, slack_get_user_profile.
• Before MCP: for each external vendor (Slack, GitHub and so on) you had to write your own function schema and implementation — entirely the app developer's responsibility.
• After MCP, at startup: the MCP client asks the server for available tools at app startup via the standard operation list_tools(), gets the function schemas back and inserts them into the agent definition.
• After MCP, at runtime: the model picks a tool from the function schema and the client executes it via the standard operation call_tool(function_name). Responsibility therefore splits: the MCP server becomes the tool vendor's responsibility, schema and implementation included.
• What standardisation buys you: for app developers, connecting to any MCP server is easy; for tool vendors, write the server once and every MCP client can use it; for users, the app gains arbitrary extensibility; for enterprises, a clean split between the team responsible for the agent and the team responsible for tools. He cited a16z's observation that the MCP ecosystem has grown very fast since late last year (a16z article).

The three kinds of context an MCP server provides

• Tools: functions offered to the model, in practice running on function calling. With the official Python SDK, one function plus an @mcp.tool() decorator is enough to make an MCP server (python-sdk).
• Resources: data offered to the client app, behaving rather like an HTTP GET so the app can request data itself; what it is for depends entirely on how the client app is designed (Claude Desktop, for instance, presents a menu whose selection is inserted into the prompt). He specifically addressed "why not just serve data through a tool": Tools are designed for the model, Resources are designed for the client app, and they differ in purpose and in how they are integrated.
• Prompts: pre-designed high-quality prompt templates the client app can choose from, for complex tasks or high-quality questioning (data analysis, summarisation and so on). The interface is entirely up to the client app: Claude's app uses a dropdown and pops up a form for the parameters; Zed IDE lets you pick a template mid-conversation with a // shortcut.
• His practical verdict was blunt: "in practice only Tools are really useful; I find the other two so-so, and it mostly comes down to how the client app uses them." He also stressed that "the spirit of MCP is not only supplying context to the model, but designing a standard protocol for the whole client application".

Transport: three implementations

Messages between MCP client and server are defined in JSON-RPC (schema.ts), and there are currently three implementations:

• ① Local stdio: at app startup the MCP server is run as a child process per the configuration and talks to the main program over standard input and output. This is how the vast majority of MCP servers work today; it uses few system resources and avoids worrying about an HTTP server occupying a port, but it requires the local environment to be able to run that program (usually JavaScript or Python), which is why non-developers so often fail to install one.
• ② Remote HTTP+SSE (the 2024-11-05 spec): the MCP server is a standalone HTTP server holding a persistent connection, with two endpoints — an SSE endpoint (receiving server events) and an HTTP POST endpoint (sending messages). A persistent connection places heavier demands on backend deployment and on the server itself.
• ③ Remote Streamable HTTP (the 2025-03-26 spec, replacing SSE): can be stateless or stateful, needs no persistent connection, and has a single endpoint (usually /mcp), deciding how to respond based on the client's HTTP header (Accept: application/json or text/event-stream). The official recommendation is to migrate toward this new standard.
• Debugging tool: MCP Inspector (GitHub), a generic client app. Run npx @modelcontextprotocol/inspector, fill in the server's launch command (for example npx @modelcontextprotocol/server-everything), press Connect, and you can inspect the available tools, resources and prompts.

Recommended MCP servers and client development

• Official examples: everything, filesystem (restricted to specified directories), fetch, slack.
• His recommendations: DesktopCommanderMCP, sequential-thinking; for browsers, playwright-mcp and browserbase (SaaS); for search, tavily-mcp (SaaS) and firecrawl-mcp-server (SaaS); for code execution environments, e2b (SaaS) and pydantic run-python (free).
• For client development he recommends the official Python SDK, and the Gemini API documentation also has function-calling-with-MCP examples. His personal recommendation is the OpenAI Agents SDK, where declaring an agent with an mcp_servers=[...] parameter expands the tools automatically — a style he called "excellent". His two demo programs: managing a directory with the filesystem MCP server, and searching with tavily plus filesystem and saving to a CSV (example1, example2).

Potholes in remote MCP

He used the phrase "potholes I fell into" for this whole block, and his tone was noticeably more cautious than when introducing MCP concepts:

• MCP is only a protocol, which does not mean broad availability: the vast majority of MCP servers today are still local stdio versions, and if a third-party tool needs authorisation you have to get the vendor's API key yourself and put it in a config file before anything works.
• The minority of vendors who did build remote MCP servers mostly built only the SSE version, not the newer Streamable HTTP.
• Client support is inconsistent too: the local Claude Desktop does not support remote; Claude on the web supports installing SSE remote MCP servers (Max Plan required) but seems not to support Streamable HTTP yet; amusingly, once you configure a remote MCP server on the web version it syncs automatically to the local Claude app (he said he was not sure how that was designed either).
• OpenAI's Responses API had added support for remote MCP servers the night before he went on stage (documentation).
• The Python SDK only got Streamable HTTP server support done in early May (v1.8.0, release page).
• If your client does not support remote but the server is remote, you can route around it with Cloudflare's local proxy MCP server: the npm package mcp-remote, together with Cloudflare's guide.

Authentication for remote MCP: a mess

His words: "remote auth right now is a mess."

• The simplest approach, an HTTP bearer header, is supported by MCP Inspector, but the Python SDK had not implemented it server-side at the time (issue #431).
• The spec has supported OAuth 2 since the 2025-03-26 version (changelog).
• Claude on the web supports SSE plus OAuth but seems not to support Streamable HTTP; other clients (ChatWise, say) support SSE and Streamable HTTP but not OAuth.
• Python SDK: server-side OAuth only landed in mid-May (PR #255, with a simple-auth example), and client-side only in late May (PR #751).
• MCP Inspector 0.12 had a bug that broke OAuth, so you had to downgrade to 0.11 to run SSE-based OAuth; Streamable HTTP with OAuth still had a bug at the time and would not redirect for authorisation (issue #390). Version 0.13, released the day before he spoke, finally fixed these.
• OpenAI's Responses API can pass an HTTP auth header through for you, but will not run a full OAuth flow.
• The OAuth 2 spec itself was still changing at the time (PR #338), and he cited a blog post summarising the situation: The updated MCP OAuth spec is a mess.

Sampling, Roots and multi-agent composition

• Sampling: an MCP server can ask the client to run an LLM inference on its behalf — the server sends a sampling/createMessage request, the client can let the user review or edit the prompt (a human review gate), runs the inference and returns the result, and the server continues its tool flow. There are two motivations: the MCP server itself need not have any model capability and can reuse the client's; and for security and privacy — a company installs an MCP server but does not want it calling out to somebody else's large model, and Sampling lets it reuse the model the company already installed. He admitted very few apps or libraries actually implement this yet.
• Filled in afterwards: alongside Sampling, the MCP spec defines another client-side primitive called Roots — letting the client declare to the server which filesystem boundaries are operable (a set of file:// URIs). The server can request roots/list for that list and gets notified when it changes; the purpose is to limit which directories the server can reach, for example a project or workspace selector. (Roots was not covered in this session; it is added here from the official spec, roots spec page.)
• A recap of agents-as-tools: you can wrap an agent as a function and use it as another agent's tool (supported by the OpenAI Agents SDK, documentation).
• Agents-as-tools plus MCP: agents B and C can be wrapped as MCP servers and installed on agent A, letting A communicate with B and C remotely — he named this directly as "what Google's A2A (Agent2Agent) Protocol is doing", with A2A being one special case of using MCP.
• Composing further: agent B can be agent A's MCP server and simultaneously an MCP client of agents X and Y; add Sampling and the LLM inference needs of that whole chain can be handled by agent A's model.
• Demo: he showed a "talk to ihower" MCP server live, written with FastMCP plus the OpenAI Agents SDK, wrapping a talk_to_ihower(query, previous_response_id) function in @mcp.tool(), internally running an agent on gpt-4.1-mini with the persona of "張文鈿 Wen-Tien Chang (ihower)", launched with mcp.run(transport="sse"). That remote MCP server lives at mcp.aihao.tw/sse and can be installed straight into Claude or ChatWise, so your own agent can interview the "ihower clone". If your client does not support remote (Claude Desktop, say), the Cloudflare mcp-remote proxy mentioned earlier gets you there.

Industry pace: two announcements from those very days

He made a point of the speed of change in this area: OpenAI's Responses API had added remote MCP server support the night before he spoke, and Anthropic's API "MCP connector" had been announced less than a day before (documentation). His phrasing: "this world really is unbelievably competitive." Once OpenAI added that support, official models could call MCP servers directly without routing back through the developer's own app — a clear efficiency gain.

Security

• Installing too many MCP servers and tools causes tool name collisions and degrades LLM performance; he mentioned two directions for a fix: design a "tool for searching tools", or progressive disclosure (rather than handing the LLM every tool at once, adjust dynamically to the state of the task).
• Three categories of security risk: code execution attacks (most MCP servers run locally over stdio, so installing from an unknown source may execute malicious code), naming attacks (impersonating a legitimate tool with a near-identical name to win trust and get executed), and MCP tool poisoning (hiding prompt injection inside a tool description).
• Further reading, supplied by the speaker: MCP: Flash in the Pan or Future Standard?, Everything Wrong with MCP, The "S" in MCP Stands for Security, Deep Dive MCP and A2A Attack Vectors for AI Agents.

Roadmap: registry and server discovery

• MCP Registry: the project is preparing a unified metadata service, aiming at server discoverability, an API letting future agents discover and install tools dynamically, trust and security mechanisms (who built this server, was it officially published, reducing the risk of installing a malicious one), and version tracking (which version of a server are you on). Several unofficial equivalents already exist: mcp.so, mcp.composio.dev, smithery.ai, glama.ai/mcp/servers.
• Server discovery: the project is standardising a .well-known/mcp file for first-party servers. For example, you tell an agent "manage my shopify.com store", the agent checks whether shopify.com has a .well-known/mcp.json; if it does, the agent discovers Shopify's official MCP server, installs it automatically, and then knows how to manage the store — the concrete mechanism for agents discovering and installing MCP servers by themselves.

Recommended learning resources

He closed by recommending two: the short course MCP: Build Rich-Context AI Apps with Anthropic, a collaboration between DeepLearning.AI and Anthropic, and Anthropic's full workshop video Building Agents with Model Context Protocol, presented by Mahesh Murag.

3. Figures and cases

• The Slack MCP server installs eight functions at once (slack_list_channels and so on — see above).
• o3-class OpenAI models are claimed to chain hundreds of tool calls (speaker's own account, no external source).
• Python SDK timeline: Streamable HTTP server support in early May (v1.8.0); server-side OAuth completed mid-May (PR #255); client-side OAuth completed late May (PR #751).
• MCP Inspector: version 0.12 had an OAuth bug requiring a downgrade to 0.11 to run SSE-based OAuth; version 0.13, released the day before he spoke, fixed them.
• Industry pace: the MCP-related support in OpenAI's Responses API and Anthropic's API were announced less than a day apart.
• Demo case: the talk_to_ihower MCP server packages "talking to ihower" as an installable tool, demonstrating the agent-as-MCP-server composition in practice.

4. Lines worth keeping

• "The large model itself is like a genius locked in a room, unable to learn or act on the world by itself."
• "The spirit of MCP is not only supplying context to the model, but designing a standard protocol for the whole client application."
• "Remote auth right now is a mess."
• "This world really is unbelievably competitive."

5. Tools and terms mentioned

MCP (Model Context Protocol), MCP server / client, Tools / Resources / Prompts, stdio, HTTP+SSE, Streamable HTTP, JSON-RPC, MCP Inspector, Python SDK, OpenAI Agents SDK, Gemini API, Claude Desktop / Claude Web, ChatWise, Cursor, Windsurf, Dify, Slack MCP server, filesystem / fetch / everything MCP servers, DesktopCommanderMCP, sequential-thinking MCP, playwright-mcp, browserbase, tavily-mcp, firecrawl-mcp-server, e2b, pydantic run-python, OAuth 2.0, Sampling, Roots, agents as tools, Google A2A (Agent2Agent) Protocol, MCP Registry, .well-known/mcp, context engineering.

6. Wider observations

The single most useful thing here is that "before / after MCP" diagram of where responsibility sits: moving the tool schema and implementation entirely off the app developer and onto the tool vendor. It sounds simple, but it is what makes an arrangement like "each department inside an enterprise maintains its own MCP server, and the AI team just installs them" workable at all — no wonder he says enterprise adoption has moved so fast.

That said, he spent nearly half the session on the potholes in remote MCP and OAuth, which is a realistic footnote on how mature this ecosystem is: a specification existing does not mean the whole path (stdio → SSE → Streamable HTTP, plus authentication) is clear. A single minor version of MCP Inspector fixing a batch of OAuth bugs, Anthropic and OpenAI adding remote support less than a day apart — at that rhythm, doing production-grade remote MCP integration today still means tracking each SDK's release cadence closely, rather than building it once and leaving it.

The agent-as-MCP-server plus Sampling section carries the furthest: stacking a multi-agent architecture on top of MCP essentially rederives what A2A is doing, which suggests MCP is not just a "tool protocol" but something more like a general-purpose transport layer for building agent networks. If MCP Registry and .well-known/mcp actually get built, letting agents discover, verify and install tools themselves should completely change today's hand-rolled approach of every client maintaining its own list of MCP servers.

7. Sources