Skip to content

MCP servers

The Model Context Protocol (MCP) is a standard way for an AI application to use a tool that runs somewhere else. One side asks, the other side answers, and the two sides can be written by different people who never speak to each other.

It exists because the alternative does not scale. Every AI application used to ship its own connector for every system it touched — one for the ticket tracker, one for the database, one for the internal API — and none of them worked anywhere else. With MCP, a tool is written once as a server, and every client that speaks the protocol can use it.

The three parts

Part What it is Examples
Host The AI application a person is actually using an agent, an IDE, a chat app
Client The connection inside the host — one client per server it talks to —
Server The program that offers the actions and runs them a ticket tool, a query tool

The model is not in that list, and that is the point. The model reads text and writes text. Every connection is opened by the host, and every action is run by the server.

How a tool call works

Two things happen, always in this order. First the host asks the server what it has; then the model picks one of the answers.

sequenceDiagram
    autonumber
    participant H as Host application
    participant S as MCP server
    participant X as Internal system

    H->>S: which tools do you have?
    S-->>H: a name, a description and an argument schema for each
    Note over H: the host shows that list to the model,<br/>the model picks one and fills in the arguments
    H->>S: run this tool, with these arguments
    S->>X: authenticated request
    X-->>S: data
    S-->>H: the result, as text

The schema in step 2 is what makes this work without human wiring. It states the arguments the tool takes and their types, so the model can produce a valid call for a tool it has never seen, and the server can reject one that is malformed.

What a server can offer

A server declares which of these it supports when a client connects. Tools alone is a complete server; the other two are optional.

Offering What it is Who chooses to use it
Tools Actions the server will run — a query, a write, an API call the model
Resources Data the server will hand over — a file, a record, a page the host
Prompts Ready-made instructions for a task the server supports the person

Why host your own

An MCP server usually holds more access than anything else in the stack, because it holds the credentials the model is not allowed to see.

Reason Detail
Data stays put Tools run next to the systems they touch, inside your network
Credentials stay server-side The model gets tool results, never the secret
Policy is enforceable NetworkPolicy decides exactly what the server can reach
Auditable Tool calls are requests to a workload you own and can log

What an MCP server deployment contains

On GRN.CLOUD an MCP server is an ordinary workload: a Deployment, a Service, a route, and whatever RBAC and NetworkPolicy you put around it.

flowchart LR
    AGENT["Agent / LLM client"] -->|MCP| SRV["MCP server<br/>Deployment + Service"]
    SRV --> DB[("Internal database")]
    SRV --> API["Internal API"]
    SRV -.->|blocked by NetworkPolicy| INTERNET(["Public internet"])

The default-deny egress policy is the part that matters most here. An MCP server should reach exactly the systems its tools need and nothing else. See Networking for the policy shape.

Tool arguments are written by the model, not by your application

A model can be steered by whatever it has read — a document, a web page, a ticket comment. So treat every argument as input from a stranger. Check it server-side against a list of what the tool may act on, use parameterised queries, and never paste an argument into a shell command or build SQL by joining strings.