What Is an MCP Server? How MCP and MCP UI Work in 2026

On 1 April 2025, Invariant Labs published a tool called add. It took two numbers and returned their sum. Its description also carried a block marked IMPORTANT, invisible in the client’s interface, telling the model to read ~/.cursor/mcp.json and ~/.ssh/id_rsa and pass both files out through a spare parameter. The model obeyed. The user saw arithmetic.

That demonstration is the most useful introduction to MCP servers I know, because it shows both halves at once. The protocol worked exactly as designed: an AI client discovered a tool, read its description and called it. The trust model was the part nobody had built yet.

What an MCP server is

An MCP server is a program that exposes tools, data and prompts to AI applications through the Model Context Protocol (MCP). The official documentation defines MCP as “an open-source standard for connecting AI applications to external systems.” An AI client such as Claude, ChatGPT, Visual Studio Code or Cursor connects to the server, asks what it offers, and calls those capabilities on the user’s behalf.

Anthropic announced MCP on 25 November 2024 with six pre-built servers: Google Drive, Slack, GitHub, Git, Postgres and Puppeteer. OpenAI adopted it in March 2025. Google DeepMind followed in April. In December 2025 Anthropic donated the protocol to the Agentic AI Foundation, a directed fund under the Linux Foundation co-founded by Anthropic, Block and OpenAI.

The problem it solves is multiplication. Before MCP, every AI application that wanted to reach GitHub wrote its own GitHub connector, and every vendor that wanted to be reachable wrote one per AI application. Ten models and ten tools meant up to a hundred integrations. MCP turns the hundred into twenty: each client implements the protocol once, each system exposes one server.

Think of it as the shipping container of AI integrations. Before containers, every port loaded every cargo by hand, with its own cranes and its own crew. The container standardized the box, so any ship, crane and truck could move any cargo. It did not standardize what went inside the box, and it never inspected the contents. MCP is the same bargain. Hold on to the second half; it comes back in the security section.

How an MCP server works

The current specification, version 2026-07-28, uses JSON-RPC 2.0 messages between three roles. Its own description is three lines long: hosts are “LLM applications that initiate connections”, clients are “connectors within the host application”, and servers are “services that provide context and capabilities.”

Host, client, server

The host is the application you type into: Claude Desktop, an IDE, your own agent. Inside it, one client runs per server connection. The server sits on the far side and talks to the real system, whether that is a Postgres database, the GitHub API or a folder on your disk. The host decides what the model sees and what the user must approve. The server decides what the underlying system will do.

1. Host Claude Desktop · an IDE · your own agent

   shows the model tools, asks the user for consent

2. Client one per server connection

   speaks JSON-RPC over stdio or Streamable HTTP

3. MCP server tools · resources · prompts

   describes what it offers and runs the calls

4. Underlying system database · SaaS API · local files

   does the work

Tools, resources and prompts

A server can offer three kinds of things:

• Tools are functions the model can execute: create_issue, query_orders, send_email. Each has a name, a description and a JSON Schema for its inputs.
• Resources are context and data for the user or the model to read: a file, a database schema, a record.
• Prompts are templated messages and workflows the user can pick, such as “summarize this pull request”.

Tools get most of the attention because they act. That is also why they carry most of the risk.

A tool call, step by step

The 2026-07-28 revision made MCP stateless. There is no initialize handshake any more; every request carries its protocol version and the client’s capabilities in a _meta field, and servers must implement a server/discover method so a client can ask up front what they support. A single tool call now runs like this:

1. User asks: create a ticket for this bug

2. Step 1

   Discover

   • Client may call server/discover for versions and capabilities
3. Step 2

   List tools

   • tools/list returns names, descriptions and input schemas
4. Step 3

   Model picks a tool

   • The host passes the tool definitions to the model
5. Step 4

   User consent

   • The spec says hosts must get explicit consent before invoking any tool
6. Step 5

   Call

   • tools/call with arguments, protocol version in _meta

7. Missing input? Server returns input_required; client retries with answers

   Step 6

   Result

8. Result goes back to the model as context

Step 6 is new in this revision. A server that needs more information no longer sends its own request back to the client. It returns a result marked input_required, the client gathers the answer, and the client retries the original call. The spec calls this the Multi Round-Trip Request pattern.

Transports: stdio and Streamable HTTP

The spec defines two standard transports:

• stdio: the client launches the server as a subprocess and exchanges newline-delimited JSON-RPC over standard input and output. This is how most local servers run, and it means the server runs on your machine with your privileges.
• Streamable HTTP: each message is an HTTP POST to a single endpoint, and replies come back as a JSON object or a request-scoped event stream. This is how remote, hosted servers run.

The older HTTP+SSE transport is formally deprecated. The 2026-07-28 revision also removed protocol-level sessions and the Mcp-Session-Id header; a server that needs state across calls now mints its own handle and receives it back as an ordinary tool argument.

Authorization

Authorization in MCP is optional, and it only applies to HTTP. Over stdio, the spec says servers should take credentials from the environment instead. Over HTTP, a protected MCP server acts as an OAuth 2.1 resource server. It must publish OAuth Protected Resource Metadata (RFC 9728) so clients can find its authorization server. Clients must name the exact server a token is for (RFC 8707 resource indicators). Servers must reject any token not issued for them, and the security guidance names “token passthrough”, forwarding a client’s token unmodified to a downstream API, as explicitly forbidden.

That last rule matters more than it looks. A server that relays whatever token it receives turns into a proxy for whoever holds one.

What MCP UI adds: servers that return an interface

Text answers stop working the moment a user needs to compare forty rows, adjust a form with twelve fields or approve a batch of changes one by one. “MCP UI” is the name people search for the fix: a server returns an interactive interface that renders inside the AI client, next to the conversation.

The status is precise, and worth getting right. The idea started as MCP-UI, a community project. OpenAI built a similar mechanism into its Apps SDK. The MCP project proposed a shared standard on 21 November 2025 in partnership with both, and on 26 January 2026 published MCP Apps as “the first official MCP extension”. MCP-UI’s site now says it “is now standardized into MCP Apps”, and its packages implement that spec and act as a “community playground for future enhancements.”

So MCP UI today means MCP Apps. It is official, and it is an extension, not core protocol. Extensions are opt-in: both client and server must support them, and the docs say plainly that “host support varies by client.” The MCP Apps documentation lists Claude, Claude Desktop, VS Code GitHub Copilot, Microsoft 365 Copilot, Goose, Postman, MCPJam and Archestra.AI as supporting hosts. A server whose tools return UI still has to work for a client that shows only text.

Mechanically, it reuses MCP’s own pieces:

1. A tool’s description includes a _meta.ui.resourceUri pointing at a ui:// resource.
2. The host fetches that resource, an HTML page with its scripts, and can preload it before the tool is called.
3. The host renders it in a sandboxed iframe that cannot read the parent page, its cookies or its storage.
4. The app and the host talk over postMessage in a JSON-RPC dialect of MCP. The app can request tool calls, and the host decides which ones it allows.

The cost is real. You are now shipping a web front end inside someone else’s application, with a content security policy you must declare, rendering rules you do not control, and a text fallback for every host that ignores it. The win is that approval work stops being a chat transcript. The documentation’s own list of good fits ends with “approving expense reports, reviewing code changes, or triaging issues”, which is the honest center of it: MCP UI is best at decisions, not decoration.

A read-only Tajo example

Tajo’s Alto MCP surface includes query_contacts, which searches contacts stored in the connected workspace. Ask for one existing contact by email and inspect its returned ID, email consent state and last-seen time. The separate get_contact_topic_status tool reads that contact’s topic subscriptions.

These are workspace reads. They do not fetch a fresh provider snapshot, start a sync, send a message or establish that every vendor connector is live. Missing or stale workspace data needs investigation at its source. An empty result is not proof that the person does not exist in Brevo.

Use the Tajo MCP documentation to connect a supported client and inspect the tools it actually exposes to your authorized workspace. An interactive panel can make that review easier when the host supports MCP Apps; the text result must still explain the outcome.

A tool call is not a durable sync

A recurring sync additionally needs a schedule, stable record identity, saved progress, retry decisions and a record of completed writes. Those belong to the application executing the work. MCP standardizes access to tools; it does not supply those business rules merely because a tool was listed.

After a timeout, a read can usually be repeated. A send or payment may already have happened. Preserve its execution record and reconcile the outcome before another attempt. A model’s confidence does not authorize the action or make the repeat safe.

For the destination side of a concrete contact path, see the Brevo API guide. For when computed fields deserve their own maintained sync, see reverse ETL.

The security bill comes with the protocol

The objection deserves to be stated in full: “MCP hands a probabilistic model a list of functions that can delete data and send email, then trusts text written by strangers to describe them. That is not an integration standard. It is a supply-chain attack with a spec.” Most of that is correct. The spec agrees with the premise. Its security section says tools “represent arbitrary code execution and must be treated with appropriate caution,” that tool descriptions “should be considered untrusted, unless obtained from a trusted server,” and that MCP “cannot enforce these security principles at the protocol level.”

Here is the record so far:

• Tool poisoning. Invariant Labs’ April 2025 disclosure, the add tool above. The same post described rug pulls, where a server changes a tool’s description after you approved it, and shadowing, where one malicious server rewrites the model’s behavior toward a trusted one.
• Local server compromise. In July 2025 JFrog disclosed CVE-2025-6514 in mcp-remote versions 0.0.5 to 0.1.15, which let a malicious server run commands on the user’s machine. The same summer, CVE-2025-49596 hit Anthropic’s own MCP Inspector, which shipped without authentication by default.
• Scope inflation. The official security best practices name the pattern: tokens granted files:* or admin:* up front because a server listed every scope and the client requested them all.
• Official concern. In May 2026 the US National Security Agency said MCP’s “rapid proliferation has outpaced the development of its security model.”

Where the objection goes wrong is the conclusion. The fix was never to stop connecting models to systems; teams were already doing that with raw API keys pasted into prompts and scripts, with no audit trail at all. The fix is to treat an MCP server like any other privileged dependency:

• Install servers only from sources you would trust with the same credentials outside MCP.
• Prefer remote servers with OAuth and narrow scopes over local binaries holding long-lived keys.
• Require human approval for every write, and log who approved what.
• Pin server versions, and re-review when a tool’s description changes.
• Expose task-shaped tools, not a full API; a model cannot misuse a delete endpoint that was never exposed.

The protocol standardized the box. Inspecting the cargo is still your job.

Build an MCP server or use an existing one

Public directories such as mcp.so catalog community-built servers, and many SaaS vendors publish their own. Brevo, for example, ships an MCP server that is also split into individual servers, so an agent can be given contacts without campaigns. The decision is less about effort than about who should own the shape of the tools.

Which MCP server should your agent use?

1. The vendor publishes a server that covers the task

   Use the vendor's server

   It tracks the API and the vendor maintains it.

2. One system, but you need fewer or safer actions

   Use it, scoped down

   Grant minimal scopes and expose only the tool groups the agent needs.

3. Internal data or a system with no server

   Build a small server

   A few task-shaped tools over your own API, with your own auth.

4. The task spans two or more systems

   Build or adopt a governed layer

   One set of tools, consent rules and audit history across all of them.

Building a basic server is the easy part. With an official SDK, a working stdio server with one tool is an afternoon’s work. The cost lands later: OAuth for the HTTP version, deprecations (the 2026-07-28 revision deprecated Roots, Sampling and Logging, and Dynamic Client Registration), and the ongoing job of writing tool descriptions a model reads correctly. Wrapping an API one endpoint per tool is the most common mistake. Every tool description is text the model has to read and weigh, so a short list of task-shaped tools beats the whole API surface.

MCP, APIs, integrations and iPaaS

MCP does not replace APIs. Nearly every MCP server is a wrapper around one. The API is still where the work happens, with its own rate limits, data model and quirks. MCP changes who can call it: a model, at runtime, choosing the call from a description instead of a developer hard-coding it in advance.

That distinction draws a clean line against the other two things it gets confused with:

• Integrations and iPaaS (the main platforms are compared here) move data on a schedule or a trigger, deterministically, whether or not anyone is in a chat. A nightly sync of 40,000 orders into a CRM should not depend on a model deciding to make 40,000 tool calls.
• Reverse ETL pushes modeled data from a warehouse back into operational tools. What reverse ETL is and when it fits is its own topic, and it is a pipeline, not a conversation.
• MCP is for the moments a person or an agent needs to ask, inspect or act across those systems, on demand.

The mistake runs in both directions. Teams build MCP servers to do bulk sync, and they get slow, expensive, non-repeatable pipelines. Other teams build careful integrations and then hand their AI assistant a raw API key to query them, and they get an ungoverned side door.

For a supported integration, the durable job and the tools used to inspect it should share an explicit permission boundary. Verify the connector, allowed actions and recorded outcomes for the particular workflow. The integration documentation distinguishes setup guidance from paths that still need production evidence. MCP may expose separate approved tools; listing them does not prove that a recurring sync or every required control is active.

In 22 months MCP went from six reference servers to a Linux Foundation project that Claude, ChatGPT, VS Code and Cursor all speak. Connecting a model to a system is now the cheap part. Deciding what it is allowed to do there is the work.