What Is MCP Server? | TMA Glossary

An MCP server is a program that exposes tools, data, and prompts to AI applications through the Model Context Protocol. It wraps a system you care about, such as a database, a ticketing tool, or an internal API, in a standard interface that any MCP-capable app can call.

Think of it as an adapter. The AI app speaks MCP. Your system speaks whatever it speaks. The server translates.

What a server offers

Under the 2025-11-25 spec, a server can expose three kinds of features:

Tools. Functions the model can run.
Resources. Context and data for the user or the model to read.
Prompts. Templated messages and workflows for the user.

Most servers I see in practice are tool servers. A tool has a name, a human-readable description, and an input schema written in JSON Schema. A client finds tools with tools/list and runs one with tools/call, as described in the tools section of the spec.

The description matters more than people expect. The model reads it to decide when to use the tool. A vague description produces wrong calls. A tool named search that searches only closed tickets will get misused.

How a client reaches it

The spec’s transports page defines two standard options:

stdio. The client launches the server as a local subprocess and talks over standard input and output. The spec says the server must not write anything to stdout that is not a valid MCP message. It may write logs to stderr. A stray print statement in a stdio server is a classic bug that breaks the connection.
Streamable HTTP. The server runs as an independent process that handles multiple client connections over HTTP POST and GET, with optional Server-Sent Events for streaming. This is the option for remote and shared servers. It replaced the older HTTP+SSE transport.

Local stdio servers suit a single user on their own machine. Remote HTTP servers suit teams, and they need real authentication.

Security duties

The spec gives servers a short list of musts. Servers must validate all tool inputs, implement access controls, rate limit tool calls, and sanitize tool outputs. Clients should confirm sensitive operations with the user, validate results before passing them to the model, set timeouts, and log tool usage for audit.

Treat a server like any service that can reach your data:

Least privilege. Give the server credentials that can do only what its tools need. A read-only reporting tool should hold a read-only database role.
Per-user identity. Pass the real user’s identity through where you can, rather than one shared admin key. See AI agent permissions and least privilege.
Narrow tools. Prefer get_invoice_status(invoice_id) over run_sql(query).
Treat outputs as untrusted. Text returned by a tool goes back into the model’s context. If it came from a web page or a customer record, it can carry a prompt injection.
Vet third-party servers. A community server is code you run with your credentials. Read it first.

The spec also warns that tool descriptions should be considered untrusted unless they come from a trusted server. A malicious server can hide instructions in a description.

A short example

Say an operations team wants an assistant to check shipment status. They write one server with two tools: lookup_shipment(tracking_id) and list_delayed_shipments(date). Both call an internal API with a read-only service account. Neither tool can change an order. The assistant can answer “which shipments are late today?” and the team never exposes the full order database.

Common mistakes

One giant tool. Generic query or shell tools hand the model a blank check.
Logging to stdout. On stdio servers, this corrupts the protocol stream.
Shared admin credentials. Every user inherits the server’s full reach.
Missing rate limits. A looping agent can hammer a backend.
No audit trail. You cannot answer “what did the agent call and why?”
Trusting it because it is open source. Open code still needs review.

Before you launch one

A short checklist I would run:

Every tool has a clear name, a precise description, and a strict input schema.
Destructive tools are separate from read tools, so you can grant them separately.
Credentials are scoped to the least access needed and can be rotated.
Inputs are validated on the server, not trusted from the model.
Outputs are trimmed to what the model needs, with secrets removed.
Calls are rate limited and logged with the caller’s identity.
Someone owns the server and its updates.

Then test it with a client, using a deliberately bad request, such as a malformed ID or an oversized input, and confirm it fails safely.

The Model Context Protocol defines the standard. Tool calling is the model-side behavior that triggers server tools. For how MCP compares with plain API wiring, see MCP vs API integration and what is MCP. For a wider control list, see the enterprise AI security checklist.