What is MCP?

What are the parts?

The model never connects to anything itself. It emits a request to use a tool; the host performs it and returns the result as text the model can read.

What does a tool definition look like?

{
  "name": "search_orders",
  "description": "Find orders by customer email",
  "inputSchema": {
    "type": "object",
    "properties": { "email": { "type": "string" } },
    "required": ["email"]
  }
}

The description is not documentation for you — it is the instruction the model reads when deciding whether this tool fits the request. A vague description produces a tool that is called at the wrong moments.

Why does a standard matter here?

Before it, every assistant needed a bespoke integration for every service: N assistants times M services. A shared protocol turns that into N plus M. Write one server for your service and any compliant host can use it.

What are the security implications?

• A tool runs with whatever credentials the server holds, not the model's — so scope those credentials narrowly.
• Content returned by a tool is untrusted input. Text inside a fetched page or database row can attempt to instruct the model.
• Write actions deserve confirmation. Reading a row and deleting a table should not feel the same to the person supervising.
• Log what was called and with what arguments, or you cannot audit a surprising outcome afterwards.

The interesting failure is not a tool that breaks. It is a tool that works perfectly on the wrong record because the model misread the request.

Where does MCP show up in an AI-assisted build?

Mostly in the tooling around your project rather than in the app you ship: giving your editor or assistant access to a database, a documentation set, a design tool, or your own service. Your deployed application rarely speaks MCP itself — it calls ordinary APIs.