Building an MCP Server from Scratch: Making AI Agents Controllable and Extensible

AI is getting better and better at writing code, but have you ever encountered situations where it "overreaches," calls tools it shouldn't, or loses control in complex tasks? According to an instructor who led an MCP-focused session at a technical seminar (with related content on both Bilibili and YouTube), MCP is precisely the key mechanism designed to solve these problems.

What Exactly Is MCP, and Why Does It Matter

MCP (Model Context Protocol) can be understood as a standardized interface between AI agents and external tools and data sources. It is not a specific product but a protocol layer that lets models "know what tools are available, how to call them, and where the boundaries of invocation lie."

The instructor emphasized in the seminar that understanding MCP cannot stop at the conceptual level—you need to clarify three things: what it is, how it connects with agents, and how to choose among the many ready-made solutions. Only by connecting these questions do you form a complete understanding of MCP.

From an engineering perspective, the value of MCP lies in turning "what AI can do" into a declarable, constrainable, and auditable configuration. Without this layer of protocol, models either have limited capabilities or produce unpredictable behavior in open-ended invocation.

Model Context Protocol (MCP) is a protocol standard proposed and open-sourced by Anthropic in late 2024, using JSON-RPC 2.0 as its message format and defining the communication specification between clients (agents/host applications) and servers (tool providers). The core abstractions of MCP include three types of primitives: Tools (functions callable by the model), Resources (readable data sources such as files and databases), and Prompts (reusable prompt templates). Servers declare and expose capabilities to clients through methods like tools/list and tools/call, while the client is responsible for injecting tool descriptions into the model context. Because the protocol is decoupled from any specific model, the same MCP server can be reused by Claude and other agent frameworks that support the protocol—this is also why it is called a "standardized interface." Understanding the division of responsibilities among these three primitives is the foundation for judging whether an MCP server design is reasonable.

How MCP Connects with Agents

The seminar made the interface mechanism between MCP and agents one of its key topics. Simply put, the agent is responsible for deciding "whether to use a tool and which one," while the MCP server is responsible for "how exactly this tool is executed, how parameters are validated, and how results are returned." The division of labor is clear: the agent does not need to understand the underlying implementation of each tool, and the MCP server does not need to understand the agent's reasoning process.

The direct benefit of this layering is controllability. The instructor mentioned that one of the core questions the seminar focused on was "how to ensure AI doesn't do too many foolish things and remains controllable." By making tool capabilities explicit through MCP, developers can set boundaries at the protocol layer rather than relying on the model's self-discipline.

At the integration level, MCP adopts a typical client-server architecture and supports two transport methods: stdio transport based on standard input/output (suitable for local processes, such as an IDE plugin launching a local tool server) and SSE/Streamable HTTP transport based on HTTP (suitable for remote shared services). The agent framework acts as an MCP client, exchanging protocol version and capability declarations through an initialize handshake at startup, then fetching the tool list and converting it into function signatures the model can understand. After the model returns a tool invocation intent, the client is responsible for actually issuing the tools/call request, handling timeouts and exceptions, and then feeding the results back into the conversation context. This flow means that permission boundaries, parameter validation, and error handling all occur on the server side, while the client only forwards and schedules—this is the technical root of why the layered design enables controllability.

Selection: What MCP Options Are Available on the Market

The seminar specifically discussed existing MCP solutions on the market and how to choose the right MCP for specific scenarios. Selection requires considering not only feature coverage but also compatibility with existing agent frameworks, maintenance activity, and the granularity of permission control.

The instructor did not give a one-size-fits-all "best choice" but instead treated selection as an engineering problem that requires judgment based on actual project circumstances. This is quite pragmatic—the MCP ecosystem is still evolving rapidly, and copying others' solutions is often less effective than understanding the selection logic itself.

Building Your Own MCP Server

The most valuable part of the seminar was "how to build your own MCP from scratch." Building your own MCP means you have full control over the granularity of tool exposure and invocation rules, which is especially important for teams that require strict permission management.

Key decisions in the build process include: which capabilities to expose, how to validate input, how to handle error returns, and how to let the agent gracefully degrade when a call fails. These details determine whether an MCP server is merely "usable" or "good to use." The instructor taught self-built MCP as a standalone segment, indicating that the barrier to entry is not high, but you need to understand the design intent of the protocol.

The engineering barrier to building your own MCP server is indeed low: the official SDKs come in two flavors—Python (the mcp package) and TypeScript (@modelcontextprotocol/sdk). Developers only need to define the tool's name, description, and input parameter JSON Schema using decorators or schemas, implement the corresponding handler functions, and mount them via stdio or HTTP transport. What really requires deliberation is the wording of tool descriptions—the model relies entirely on the description field to decide when to call, and vague descriptions lead to false or missed calls. In addition, when input validation fails, you should return structured error information rather than throwing exceptions, so the model can correct parameters and retry accordingly. It is recommended to initially make tools fine-grained with single responsibilities, pair them with a permission strategy that separates read-only and write operations, and then iterate and converge based on actual call logs.

Placing It in the Broader Context of AI-Assisted Development

It is worth mentioning that the same seminar series also covered software development topics in the AI era—how to use tools like Claude, Codex, and GitHub Copilot to improve efficiency. According to the instructor, these talks complement the MCP theme: the toolchain determines development efficiency, while MCP determines the boundaries of AI behavior. Together they form the complete picture of "AI-assisted development."

For teams integrating AI agents into production environments, MCP is not optional—it is infrastructure. Understand the protocol first, then evaluate ready-made solutions, and finally build your own as needed. This path is more reliable than blindly piling up tools.