MCP · Infrastructure · AI agents

Using an MCP server to operate infrastructure

How an MCP server lets AI agents discover and call infrastructure operations, which setup to choose, and the security checks to make before your first write.

By: Escanor team
Published: 6 October 2026
Reading time: 6 min read

On this page

An MCP server for infrastructure exposes operations on your cloud, deploy platform, databases and monitoring as tools that an AI agent can discover and call through the Model Context Protocol. The agent asks the server which tools exist, reads each tool's input schema, and calls one with arguments. The server runs the operation with credentials the agent does not hold and returns the result. Done well, that gives a coding agent one consistent way to check a deploy, read logs or restart a service, under rules you control.

This guide covers how the protocol works, the three common ways to set it up, a walkthrough with Escanor's server, and the checks to make before an agent touches production.

How MCP works, briefly

MCP is an open protocol. Messages are JSON-RPC, and the specification defines three things a server can offer:

Primitive	Controlled by	Example
Prompts	The user	A slash command that starts a runbook
Resources	The client application	A file or log excerpt attached as context
Tools	The model	An API call that redeploys a service

Infrastructure work is mostly tools. A client discovers them with tools/list and runs one with tools/call. Each tool has a name, a description and an inputSchema written in JSON Schema (MCP tools).

The spec defines two standard transports (transports):

stdio. The client starts the server as a local subprocess and talks over standard input and output. Credentials usually come from the local environment.
Streamable HTTP. The server runs as an independent process, often remote, behind one HTTP endpoint.

For HTTP servers, the spec's authorization section is based on OAuth 2.1. Servers publish OAuth Protected Resource Metadata (RFC 9728) so clients can find the authorization server, and a server must only accept tokens issued for it.

Three ways to connect agents to infrastructure

Setup	How it works	Good for	Watch out for
One local server per provider	Run a stdio server for each cloud or tool on the developer's machine.	Single developers, quick experiments, providers with an official local server.	Each server needs its own credentials on that machine, and every laptop becomes a place keys live.
Vendor-hosted remote servers	Connect to each provider's own HTTP MCP server.	Teams that use few providers, each with a maintained remote server.	Separate sign-in, scopes and audit for every provider.
A gateway in front of many providers	One remote server routes calls to many connected integrations.	Teams with many providers who want one place for keys, approvals and logs.	The gateway becomes a high-value system; check how it stores credentials and what it logs.

These are not exclusive. Plenty of teams run a local filesystem or database server for development and a remote server for production systems. Choose the setup per environment.

The tool-count problem

Large providers expose a lot of operations. If a server registered one MCP tool per cloud API call, the agent would have to choose among thousands of tool definitions before doing anything.

Two common answers are to expose a small, hand-picked set of tools, or to expose a search tool and an invoke tool so the agent looks up the operation it needs. The first is easier to reason about. The second covers more ground but puts more weight on the agent reading each schema correctly.

Escanor uses the second approach. Its server exposes five tools:

Tool	Does
`escanor_list_providers`	Lists the providers the server knows.
`escanor_connection_status`	Shows which providers your workspace has connected.
`escanor_list_tools`	Searches one provider's operations, with paging.
`escanor_usage_stats`	Reports usage and rate limits.
`escanor_invoke`	Runs one operation by its ID.

Walkthrough: from connection to first action

These steps use Escanor's server. The pattern (discover, read the schema, invoke a read, then consider a write) applies to any infrastructure MCP server.

1. Connect the client

Open MCP in the Escanor dashboard. It creates a key and shows the exact command or configuration for your client, already filled in. Claude Code takes a one-line terminal command. Cursor and VS Code take a JSON configuration. ChatGPT connects as a custom connector through sign-in, with no key to copy. Any client that supports remote MCP servers can use the server address with an Authorization: Bearer <key> header. The full list is in the MCP docs.

The key is shown once. Name it after the agent or machine that uses it.

2. Check what the agent can see

Ask the agent: "List the tools you can use from Escanor." It should name the five tools above. Then ask it to call escanor_connection_status. A provider you have not connected shows as not connected, and calls to it return not_connected.

3. Find an operation

The agent searches one provider at a time. These are tool arguments sent through the MCP client, not REST requests:

{"provider":"github","query":"repository","limit":20,"offset":0}

limit defaults to 100 and is clamped between 1 and 500. Results include each operation's input_schema. If the first page does not contain the operation, advance offset.

4. Run a read

escanor_invoke takes the exact discovered tool_id and an arguments object that matches the schema:

{"tool_id":"<discovered-provider.operation>","arguments":{}}

Start with something you can verify by eye, such as listing recent deployments for a staging project, then compare the answer with the provider's own dashboard.

5. Consider a write

Destructive operations require confirm=true in their arguments. A refusal that mentions confirmation is deliberate, so the agent should not retry it automatically. Remember that the agent can set that flag itself. Put a human approval in front of invocations in your client as well, as described in How to give AI coding agents safe production access.

Security checks before production

The MCP specification lists requirements for servers and recommendations for clients. Use them as a checklist when you choose or build a server.

Human in the loop. The spec says there "SHOULD always be a human in the loop with the ability to deny tool invocations", and that clients should show tool inputs before calling the server (tools).
Server-side controls. Servers must validate inputs, enforce access controls, rate limit invocations and sanitise outputs (same page).
Untrusted annotations. Tool annotations describe behaviour, but clients must treat them as untrusted unless the server is trusted. A tool marked read-only by an unknown server is not proof that it is.
Origin checks and binding. Streamable HTTP servers must validate the Origin header, and local servers should bind to 127.0.0.1 rather than every interface, to block DNS rebinding.
No token passthrough. A server must not accept tokens issued for another service or forward a client's token to a downstream API (security best practices).
Minimal scopes. The same document recommends starting with a minimal scope set and elevating only when a privileged operation is attempted.

On Escanor, discovery requires mcp:read and invocation requires mcp:invoke. Read-only tokens and limited write budgets are available, and each call runs with your workspace's stored provider credential, bound for that call only. See Permissions and approvals.

Reading errors correctly

MCP separates protocol errors, such as an unknown tool, from tool execution errors, which come back as a result with isError: true. A working transport can still return a failed operation, so an agent must read the result, not only the status.

Escanor result	Meaning	Next step
`not_connected`	The provider is not connected for this workspace.	Connect it in Integrations; do not paste a credential into the prompt.
`provider_not_found`	The provider name is wrong.	Call `escanor_list_providers` first.
`insufficient_scope`	The token lacks a scope the call needs, such as `mcp:invoke`.	Review the token's grants.
`read_only_token`	A read-only token tried a write.	Expected; use a different token only if the write is intended.
`unauthorized`	The MCP key is invalid or revoked.	Check or replace the key.
`rate_limit_exceeded`	Too many calls.	Wait, then check `escanor_usage_stats`.

For any failed write, check the provider's state before retrying. Repeating a write that partly succeeded can duplicate the change.

Which providers work today

Some providers run on your workspace's stored connection as soon as you connect them, including GitHub, GitLab, Vercel, Netlify, DigitalOcean, Terraform, Neon, Supabase, Sentry, PagerDuty, Slack and Stripe. Others, including AWS, GCP, Azure, Kubernetes and several databases, appear in the catalog but need additional configuration before a workspace has usable access. The current split is in MCP providers, and escanor_list_providers returns the live list.

When MCP is the wrong tool

MCP suits work where an agent has to decide what to look at next: investigating an incident, checking why a deploy failed, preparing a fix. For a job that runs the same steps on a schedule, such as a nightly backup or a fixed deploy pipeline, a script or CI job is easier to test and review than an agent choosing tools at run time.

To try the setup above, start from the Escanor MCP page or the MCP docs. For how it fits incident work, see AI incident response, and for plan limits see pricing.