MCP

MCP Is the USB-C Port for AI Agents

By 为你学会写情书 · Jul 11, 2026

Read original on juejin.cn ↗ Google Translate ↗ Alt translation

Tool fragmentation is the bottleneck that keeps LLM agents from graduating beyond demos. MCP gives teams a single integration surface for any language, any runtime, and any deployment target, which turns tool-building from a per-agent engineering project into a one-time server definition.

Summary

Anthropic's Model Context Protocol defines a client-server standard where AI hosts discover available tools at runtime instead of relying on hardcoded integrations. An MCP Server packages tools, resources, and prompt templates behind a unified interface, communicating over stdio for local processes or HTTP for remote services. The result is a plug-and-play ecosystem where adding a new capability means spinning up a server process, not rewriting glue code.

A full walkthrough builds a Node.js MCP Server that exposes a user-query tool, registers a documentation resource, and connects via standard I/O. The same server then plugs into a LangChain agent loop, showing how dynamic tool discovery feeds directly into an LLM's reasoning cycle without any static tool list.

The protocol's cross-language, cross-process design means a Python service, a Rust CLI, and a cloud API can all present the same interface to an AI host. This collapses the integration tax that has kept most AI tools siloed inside individual applications.

Takeaways

— An MCP Server exposes three capabilities: Tools (executable functions), Resources (context data), and Prompts (reusable interaction templates).

— Dynamic discovery means the AI host asks the server what it can do at startup; no tool list is hardcoded in the agent.

— Communication uses stdio for local subprocess calls and Streamable HTTP for remote servers, covering both development and production deployments.

— Registering a tool requires a name, a natural-language description, a Zod schema for parameters, and an async callback that returns content.

— LangChain's MCP Adapters let any agent call getTools() to pull a live tool list and bindTools() to inject it into the model's context.

— The agent loop pattern—reason, call tool, inject ToolMessage, reason again—stays identical whether tools are hardcoded or discovered via MCP.

Conclusions

MCP shifts tool integration from a compile-time concern to a runtime concern, which means agent capabilities can change without a redeploy.

The protocol's real power isn't technical novelty but social coordination: it gives every service provider a single target interface to implement, the same way USB-C gave hardware makers one port to build for.

Cross-language support is table stakes for any protocol that wants to be universal, and MCP's stdio transport achieves this trivially because every language can read and write to standard I/O.

The '80% of apps will disappear' prediction follows directly from MCP's architecture: if every backend service speaks MCP, the AI host becomes the only frontend anyone needs.

Concepts & terms

Dynamic Tool Discovery

Instead of hardcoding a list of available tools, the AI host sends an initialize request to the MCP Server at startup and receives back the names, descriptions, and parameter schemas of every registered tool. The host then matches user prompts to tools at runtime.

MCP Server

A lightweight process that packages tools, resources, and prompt templates behind a standard protocol. It can be written in any language and communicates with the AI host over stdio or HTTP.

ToolMessage

In LangChain and similar frameworks, a message type that carries the result of a tool execution back into the LLM's context window, allowing the model to incorporate external data into its next reasoning step.

Source: juejin.cn ↗ Google Translate ↗ Backup ↗