Skip to content

MCP servers

The Model Context Protocol (MCP) is how an AI model discovers and calls tools — a database query, an internal API, a file store, a ticketing system. An MCP server exposes those tools over a standard protocol so any MCP-capable client can use them.

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. That matters, because an MCP server is usually the component with the most access — it is the thing holding the database credential the model is not allowed to see.

Why host your own

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

Shape of a deployment

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 pattern is the important half. An MCP server should reach exactly the systems its tools need and nothing else — see Networking for the policy shape.

Treat tool inputs as untrusted

Arguments to a tool call are model output, and model output can be steered by whatever the model has read. Validate and constrain arguments server-side; never interpolate them into a shell command or an unparameterised query.

Scaffold status

This is a placeholder. Reference manifests and the supported transport list are written here once confirmed against the platform.