Model Context Protocol (MCP): what it is
MCP is an open standard that lets an AI app talk to tools, data (“resources”), and prompts through a clean client–server protocol. Very small example: you run a Weather MCP server that exposes a tool get_weather(city). Your chat app (the client) discovers that tool, the model chooses to call it, the server executes it, and the model uses the result to answer the user.
How MCP + a model work together
Your app hosts or connects to the model and embeds an MCP client. On startup the client connects to one or more MCP servers, performs an initialization handshake (initialize) to negotiate capabilities and lists tools/list, prompts/list and resources/list.
When the user asks something, you send the user messages and the discovered tool schemas to the model. If the model decides a tool is needed, it proposes a tool call; your app then runs that tool via the MCP server and feeds the tool result as a typed content array back to the model to finish the reply (repeat as needed for multiple tool calls).
Exact call flow & I/O (who calls what)
These steps run in sequence—Discovery → Planning → Execution → Finalization—during a single interaction; the client may repeat the Execution + Finalization pair as needed (e.g., multiple tool calls) until the model finishes.
Initialization. Client → MCP server: initialize (negotiate capabilities such as tools/resources/prompts and notifications).
Discovery. Client → MCP server: tools/list.
Server → Client: a tool list (each tool has a name and JSON Schema input). Similarly, clients may call prompts/list and resources/list to discover prompts and resources
Planning. Client → Model: user messages + tool schemas.
Model → Client: either text, or a tool call proposal (name + JSON args).
Execution. Client → MCP server: tools/call { name, arguments }.
Server → Client: structured content (text/json/image/resource). a typed content array (e.g., text/image/JSON and resource references) When server-side catalogs change, servers may send notifications (e.g., tools list changed) and clients can re-list as needed.
Finalization. Client → Model: send the tool result.
Model → Client: final answer for the user. (Repeat tool call loop if needed.)
Server setup you actually run
Use a ready to run MCP server or build one quickly with official SDKs. Popular reference servers include Filesystem, Fetch, and Git, which you can start with a single command (e.g., npx @modelcontextprotocol/server-filesystem … or uvx mcp-server-git).
npx: A Node.js helper that runs an npm package without you installing it globally.
If you have your own API like example.com/get_today_work/{date}, register a custom tool such as get_today_work in your MCP server. The server will automatically expose the standard methods (tools/list, tools/call) and route calls to your code or REST API.
Through tools/list, the MCP server publishes a catalog of your registered tools (e.g., get_today_work) with names, descriptions, and JSON Schema argument specs; the client forwards these schemas to the model. When the model proposes a tool call, the client invokes tools/call on the MCP server with the tool name and args; the server runs your handler (which can call https://example.com/get_today_work/{date} or other backends), returns structured content (text/JSON/resources) to the client, and the client feeds that result back to the model to finish the reply.
Naming rules & request format (FAQ)
Do I invent my own discovery method? No. Use the standard MCP methods (tools/list, tools/call). Your tool names (e.g., get_today_work) are custom, but the protocol methods are fixed.
What do I send the model? Follow your model provider’s tools/function calling request shape (e.g., “messages” + a tools array, optional tool_choice). Arbitrary top level JSON keys won’t be treated as tools unless they match the provider’s schema.
“One API” orchestration option
If you prefer a single API call that runs the whole loop (model → tools → model) for you, deploy an agent server. LangGraph Server exposes a “run” endpoint that manages the iterative tool calling loop and streaming for you. On OpenAI, the Agents/Responses stack supports tool use with provider defined request shapes and can automate parts of the loop; for custom tools you still register them per the API’s tool schema.
No comments:
Post a Comment