What is MCP? A shared protocol for connecting AI agents to apps

Watch where the request goes.

Choose an example and a route. The whole connection stays visible: request arrows lead to the service, and result arrows lead back. Switch to the direct route and watch the MCP server disappear. The responses are written illustrations. The tool names and connections are examples, not commands to copy or a claim that a particular Gmail integration exists.

A common way to connect.

MCP means Model Context Protocol. An AI application can use it to discover and use capabilities exposed by an MCP server. A server here is a program; it can run on your computer or elsewhere. The application contains an MCP client that handles the connection.

For this example, the server offers a calendar lookup tool. It receives a request, calls the calendar service, and returns the result. A different server might work with local files, a database, or command-line software. MCP does not require every server to wrap a web API.

The advantage is a shared connection protocol. A compatible application may use the same server without somebody rebuilding that integration for each app. The application still needs to support the relevant features, configure the connection, and obtain access.

Tools are the part we are following here. MCP also has resources for context and prompts for reusable interaction templates. Those are protocol concepts; an MCP prompt is not automatically the same package as an Agent Skill. MCP architecture

Gmail still has its own front door for software.

Google’s Gmail API lets authorised programs work with mailboxes and mail. A calendar reminder app or a traditional automation can use an API without an agent being involved. Gmail API overview

A Gmail MCP integration could expose tools such as searching messages and use the Gmail API underneath. The AI app talks to the MCP server; the server talks to Gmail. Both interfaces can be part of the same request.

If you see a product labelled ‘Gmail MCP’, check who provides it and which actions it exposes. The label alone does not tell us that Google built it, that it supports every Gmail action, or that it has access to your account.

Writing a reply in the conversation, saving it as a Gmail draft, and sending it require different capabilities. The first generates text; the other two change the mailbox. An integration may support only some of these actions.

The same action can have a different route.

An API is an interface for programs. A CLI, or command-line interface, lets someone use software by typing commands. A tool is an action the agent can request. Those words describe different aspects of the setup.

In the command route above, the agent asks a shell tool to run a command-line program. That program contacts the service. In the direct route, the tool’s implementation calls the API without MCP. The reader can get the same calendar events through either route.

A CLI can be used through a tool, so the choice depends on the service and the application. I would check which interfaces are available and which route the application can use reliably.

A connection can fail in more than one place.

‘No matching emails’ is a successful search with an empty result. ‘Access denied’ means the search could not read the account. A missing server is different again. Those results call for different next steps, and the agent should preserve that distinction when it answers.

If a lookup fails, I would check that the expected tool is available, that the connection works, and that the account grants the required access. Rewriting the shopping or scheduling skill will not repair an expired connection.

If the agent needs a repeatable procedure for using that information, a skill can hold those instructions.