What is an MCP server?

Before MCP, every AI application had to write its own connector for every system it wanted to reach, and each connector described its functions in a slightly different way. An MCP server turns that around: the owner of a system writes one server, and every host that speaks the protocol can discover and use it. That is why so many vendors now publish servers for their own products.

It also changes where risk sits. An MCP server that can write to a database or send email gives a model the power to do those things. The protocol documentation says tools may require user consent before they run, and suggests approval dialogs, pre-approved safe operations and activity logs. Deciding which servers a team may connect, and what each one may do, is now a security question as much as a developer one.

The protocol has three roles. The host is the AI application, such as an IDE or a desktop assistant. For each server it connects to, the host creates a client that holds a dedicated connection. The server is the program that provides context. Messages between client and server use JSON-RPC 2.0, and the current documentation describes requests that each carry the protocol version and the client's capabilities, plus a discovery request a client can send to learn what a server supports.

A server offers three kinds of building block. Tools are functions the model can choose to call, each described by a name and a JSON Schema for its inputs; the client finds them with tools/list and runs one with tools/call. Resources are read-only data addressed by URI, such as a file or a database schema, which the application decides how to use. Prompts are reusable templates that a user invokes explicitly, often as a slash command.

Servers run in two ways. A local server is started by the host on the same machine and talks over standard input and output; it runs with your user's permissions. A remote server runs elsewhere and talks over Streamable HTTP, which supports bearer tokens and API keys, and the protocol recommends OAuth for obtaining tokens. The same messages flow over either transport.

A data team writes an MCP server for its reporting database. It exposes one tool, run_query, whose schema accepts a SQL string, and one resource, the schema of the reporting tables. The server connects with a database role that can only read, and it rejects any statement that is not a SELECT.

An analyst asks their assistant how many orders were refunded last month. The host lists the server's tools, the model reads the schema resource, writes a query and calls run_query. The host shows the query and asks the analyst to approve it before it runs, the server returns rows, and the model writes the answer. The read-only role is the control that matters: even if the model is tricked by text inside the data, the server cannot change anything.

In Swfte you can deploy MCP servers from templates into a workspace, and each deployment answers tools/list. Calls go through a gateway that requires an API key scoped to that MCP server and checks it belongs to the workspace. Each call is logged with the workspace, the server, the JSON-RPC method, the status code and the latency. Cortex can also connect to external MCP servers, with an approval gate on destructive tools.

The limits are stated on the MCP gateway page. Access is decided per server, not per tool: per-tool allow and deny rules are designed for, not shipped. The gateway log does not record the calling person, the tool arguments or the result, and per-user OAuth identity inheritance is not built. For hardening any MCP server, with or without Swfte, use the security guide.

• MCP gateway: what is built and what is not
• How to secure MCP servers
• Cortex

Definitions on this page were read on the sources below on 7 October 2026. Where sources define the term differently, the page says so. The full glossary lists more terms.