An MCP server is a program that exposes tools, resources, and prompts to AI applications through the Model Context Protocol (MCP).

It is an adapter between an AI client and a system such as GitHub, a database, a project board, a local filesystem, or an internal API. Instead of building a custom integration for every AI product, you implement one protocol interface that compatible clients can discover and use.

What an MCP server exposes

MCP defines three primary server capabilities:

Tools are operations the model can invoke, such as creating an issue, querying a database, or running a deployment check.
Resources are addressable data the application can read, such as a document, schema, repository file, or system status.
Prompts are reusable interaction templates a user can select or a client can present.

Not every server needs all three. A read-only documentation server may expose resources only. An operational integration may expose tools and resources.

How a request works

At a high level:

An MCP client connects to the server.
Client and server negotiate protocol capabilities.
The client discovers available tools, resources, and prompts.
The AI application decides when one of those capabilities is relevant.
The client sends a structured request.
The server validates authorization and input, calls the underlying system, and returns structured output.
The application gives that result back to the model or user.

The official MCP architecture guide describes the host, client, and server roles in detail.

Local and remote MCP servers

A local server commonly runs as a child process and communicates over standard input and output. It is a good fit for developer tools that need controlled access to local files or commands.

A remote server runs behind an HTTP endpoint. It is a better fit for shared organizational services, but it requires production-grade authentication, authorization, transport security, rate limits, and tenant isolation.

Transport location does not determine trust. A local server can still expose dangerous operations, and a remote server can be safe when its scopes and policies are narrow.

What an MCP server is not

An MCP server is not necessarily an AI agent. It normally exposes deterministic capabilities; the host application and model decide how to use them.

It is not a general API replacement. Existing business APIs remain useful. MCP can wrap them with discovery metadata and schemas that AI clients understand.

It is not an authorization system. Your server must still authenticate callers, enforce permissions, validate inputs, protect secrets, and record sensitive activity.

A minimal design checklist

Before publishing a server, define:

the exact user workflows it enables;
the smallest set of tools and data those workflows need;
read versus write behavior for every operation;
input and output schemas with actionable errors;
authentication and per-user authorization;
confirmation rules for destructive or costly actions;
timeouts, retries, rate limits, and idempotency;
logging that excludes secrets and sensitive payloads;
tests against both valid and adversarial inputs.

The MCP server specification is the source of truth for server features and protocol behavior.

Example: a project delivery server

An MCP server for software delivery might offer:

a resource containing the approved specification;
a tool to claim an implementation task;
a tool to record test evidence;
a tool to request human approval;
a tool to submit work for independent validation.

Okto Pulse exposes structured delivery work through MCP, while Okto Nexus exposes coordination, messaging, ownership, and handoffs.

Frequently asked questions

Does MCP choose which tool to call?

No. The host application and its model decide which exposed capability to use. The server executes and validates the request.

Can an MCP server run locally?

Yes. Local process transport is common for developer tooling. Remote HTTP servers are useful when teams need a shared service.

Should I expose my entire API through MCP?

Usually not. Start with a few high-value workflows and least-privilege operations. A smaller interface is easier for models to choose correctly and easier for teams to secure.