What is an MCP server?

An MCP server (Model Context Protocol server) is a program that exposes an app's actions to an AI agent as tools. It publishes a list of tools with names, descriptions, and input schemas. The agent reads that list, picks a tool, and calls it to act on the real app.

The protocol is the reason it matters. MCP is an open standard, so any MCP-capable agent can use any MCP server without custom integration code. A Gmail server written once works in Claude, Cursor, OpenClaw, or any other client that speaks MCP.

Key takeaways

• An MCP server turns an app's API into tools a language model can read and call.
• Three roles do the work: the host is the app you use, the client is the connector inside it, and the server exposes the tools.
• A server offers three things: tools (actions), resources (data to read), and prompts (templates).
• It is not the same as an API. The API is for programmers, the MCP server is packaged for a model.
• It is not the same as RAG. RAG retrieves text for context, MCP performs actions and reads live data.
• You do not have to run one. Hosted servers connect with a browser login.

How do the host, client, and server fit together?

MCP defines three roles, and keeping them straight answers most beginner questions.

The host holds the conversation and the model. The client is the plumbing that carries MCP messages. The server holds the connection to the app and knows how to act on it. When people say "connect an MCP server", they mean adding a client to a host and pointing it at a server.

The MCP architecture documentation is the reference for these roles, checked on 16 September 2026.

The host runs the client, and each server plugs into it. A hosted server such as ClawLink carries many apps behind one plug.

What can an MCP server expose?

Three kinds of capability.

• Tools are the actions. Send an email, create an issue, run a query. Tools are what most people mean when they talk about an MCP server.
• Resources are data the agent can read, such as a file, a document, or a database record, addressed by a URI.
• Prompts are reusable templates the server offers, so a host can present a ready-made workflow instead of a blank prompt.

Most hosted connections, including every app in the ClawLink catalog, focus on tools, because tools are what let an agent act.

How does an MCP server work?

When an agent connects, the server advertises its tools. Each tool has a name, a plain-language description, and a schema describing the inputs it accepts. The model reads those descriptions to choose a tool, then sends a call with structured arguments. The server executes the action against the app, usually through the app's API, and returns a result the agent folds back into the conversation.

MCP servers can run locally alongside the agent, or be hosted remotely and reached over HTTP. The protocol is the same either way, which is the point.

A real MCP handshake with @useclawlink/mcp on 16 September 2026: initialize, then tools/list.

What does connecting Gmail to OpenClaw look like?

Here is what happens end to end when someone connects Gmail to OpenClaw through a hosted MCP server, then asks it to send an email.

1. Connect. The user clicks Connect Gmail once. This runs an OAuth flow against Google, and the resulting token is stored server side rather than on the user's machine. See OAuth for AI agents for what that token grants.
2. Discover. OpenClaw asks the server for the current tool catalog. The server returns Gmail's tools, including gmail_send_email, gmail_fetch_emails, and gmail_create_email_draft, each with a description and an input schema.
3. Call. The user types "email Sarah the Q3 numbers." The model matches this to gmail_send_email, fills in the recipient, subject, and body as structured arguments, and sends the call.
4. Execute. The server receives the call, attaches the stored Gmail token, and makes the actual Gmail API request. Google sends the email.
5. Respond. The server returns a result, including the sent message id, and OpenClaw reports back in plain language.

Every step after the initial connect repeats automatically, on every message, for as long as the connection stays valid. That is the value of the protocol.

Is an MCP server just an API?

No, though it wraps one. This is the most common confusion, and the difference is the audience.

An MCP server wraps the same endpoints into tools with descriptions a model can read and schemas it can fill in reliably. That packaging is what makes tool calling dependable.

MCP server vs RAG: which do I need?

They solve different problems and usually work together.

RAG (retrieval-augmented generation) finds relevant text and puts it in the model's context. It answers "what does our documentation say?"

MCP connects the model to systems and lets it act. It answers "what is in this inbox right now?" and "send this reply."

RAG is read-only and static. MCP can read live data and change things. If your question is about a corpus of documents, RAG is the fit. If your question is about a live account, or you need the agent to do something, you need a connection. A common pattern uses both: RAG supplies background, MCP supplies the action.

Do you have to run your own MCP server?

No. Running one yourself means installing it, putting API keys or OAuth credentials in config files, and keeping it updated, per app. A hosted app connector runs the servers and holds the credentials for you, so connecting an app is a browser login rather than a setup project.

ClawLink takes the hosted approach: 1,100+ apps exposed to your agent as MCP tools, with hosted OAuth and nothing to run yourself. See the full integration catalog or a concrete example such as the Gmail MCP integration.

What are the limitations of MCP?

• Auth covers the connection, not the app credential. MCP's authorization specification defines how a client signs in to an HTTP MCP server, using OAuth 2.1 (checked 16 September 2026). It does not cover the server's own credential for the upstream app, such as the Gmail token behind a Gmail server, or how that token is stored and refreshed. That part is left to the implementer, and self-hosted servers often get it wrong.
• Server quality varies. Community servers range from maintained to abandoned. Check how recently a server was updated and how much of an app it covers.
• Tool lists cost context. Every tool's description consumes context window. Large servers with hundreds of tools can crowd out the conversation, which is why hosts increasingly load tools on demand.
• The model still chooses. A server cannot force a correct tool choice. Bad arguments remain the most common failure we see, described in MCP tool call failed.
• The ecosystem is young. Breaking changes and renamed tools happen.

Is it safe to connect an MCP server?

The risk depends on who holds the credential. A self-hosted server keeps the token on your machine. A hosted server keeps it on the vendor's infrastructure, so the vendor becomes part of your trust boundary. Either way:

• Approve access on the provider's own consent screen, and read the scopes.
• Revoke from the provider's security settings when you stop using it.
• Treat content the agent reads from an app as data, not instructions, because email and documents can carry prompt injection.
• Prefer a connection with an audit trail for accounts that matter.

What changed in this review

This page was rewritten on 16 September 2026. It added the host, client, and server role table, the API-versus-MCP comparison, the MCP-versus-RAG section, the limitations and safety sections, and the expanded FAQ. The definition and the worked Gmail example are unchanged.

FAQ

Keep reading