MCP server

What it is

In the Model Context Protocol, the server is the side that does the work. It declares what it can do, answers tools/list with a set of MCP tools, and runs each tools/call it receives. Most servers front a single system: a code host, a CRM, a file store, an accounting package.

A server runs in one of two places. A local server is launched by the client as a subprocess and talks over stdio; it usually serves one client and reads its credentials from the environment. A remote MCP server runs on the internet, talks Streamable HTTP, and typically serves many clients.

Why it matters

The server is where control can actually be enforced. The model only proposes a call; the server decides whether to run it. The MCP specification puts four duties on servers that offer tools: they must validate all tool inputs, implement proper access controls, rate limit tool invocations and sanitise tool outputs.

How it works

1. The client connects and the server states its protocol version and capabilities.
2. The server lists its tools, each with a name, a description and an input schema.
3. For each call, the server checks the caller, validates the arguments, calls the underlying API with its own credential, and returns content or a tool error the model can act on.

Example

An accounting MCP server might offer list_invoices, get_invoice and create_invoice. A model asked "which invoices are overdue?" calls list_invoices with a status filter and summarises the result.

Common pitfalls

• Secrets in configuration files. Local servers often read API tokens from environment variables or config. The OWASP MCP cheat sheet says never to store OAuth tokens in plaintext in MCP config files.
• One server per system. Ten systems means ten servers, ten credentials, ten permission models and ten logs, none of which agree.
• Token passthrough. The specification forbids a server from accepting a token not issued for it and forwarding it downstream; the server must use its own, separately issued credential for the upstream API.
• Too many tools. A server that maps every endpoint to a tool can push a model past what it can choose between. See tool overload.

How actionlake handles it

For every system you connect, actionlake is a single MCP server, which makes it an MCP gateway. Each system is described by a signed service file (a connector) that declares its actions, authentication and limits; the server refuses an unsigned or altered file. There are 1,000+ connectors and 289,000+ actions (counted 24 October 2026), and the tool list stays at eight however many you add. If a system is missing, your agent can draft a connector from the vendor's documentation, test it and sign it; only actions that passed a live test should be relied on. Browse the connectors or see how the platform works.