← Back to blog

What Is MCP and When Do You Actually Need Model Context Protocol?

MCP connects AI applications to data and tools. Learn how it works, how it differs from an API, and when the extra protocol is worth using.

Published: 4 min read

MCP, or Model Context Protocol, is an open standard for connecting AI applications to external data and tools. It gives compatible clients a shared way to discover capabilities and use them instead of building a custom integration for every application–data-source pair.

The popular “USB-C for AI” analogy is useful, but too comfortable. A common connector does not solve permissions, tool quality, or the risk of a model choosing the wrong action.

What is MCP?

Anthropic introduced Model Context Protocol in November 2024. The current MCP documentation defines it as an open standard connecting AI applications to external systems such as files, databases, search engines, calculators, and workflows.

A typical setup has three parts:

  • the host, which is the user-facing AI application,
  • a client, which maintains a connection to one MCP server,
  • the server, which exposes data, prompts, or tools through the protocol.

A server might expose a documentation search, a CRM lookup, or an operation that creates a task. The client discovers those capabilities and makes their definitions available to the model. When the model selects a tool, the host still controls the actual call.

MCP versus a regular API

MCP does not replace an API. It often sits on top of one.

If your product already has a POST /tasks endpoint, an MCP server can present it as a create_task tool with documented parameters. The API still performs the operation. MCP standardises how an AI application discovers and invokes it.

Without MCP, every AI client may need its own integration layer. With MCP, one server can work with multiple compatible clients. That becomes valuable when:

  • the same internal system should be available to several AI applications,
  • capabilities change and need to be discovered dynamically,
  • you want a shared format for tools and resources,
  • portability between clients matters.

For one closed application with three stable functions, direct function calling may be easier to maintain. Adding a protocol is not a product goal by itself.

What can an MCP server expose?

Tools

Tools are operations the model may select, such as search_orders, create_issue, or run_test. Each tool has a name, description, and input schema.

Resources

Resources provide context: a file, document, record, or query result. They let a client read data without pretending that every retrieval is a separate business action.

Prompts and workflows

A server can publish reusable procedures or prompt templates. This is helpful when operational knowledge should live close to the integration rather than be copied into every client.

MCP is not your security model

The protocol makes a connection easier. It does not decide whether the model should have access.

Before connecting a server, separate four concerns:

  1. Identity: Which user is the client acting for?
  2. Authorization: Which records and operations can that user access?
  3. Consent: Which actions require confirmation before execution?
  4. Audit: Can you reconstruct what was called and what happened?

An MCP tool named delete_customer does not become safe because its JSON schema is correct. It still needs a narrow permission boundary, confirmation, and preferably a reversible path.

Prompt injection is another boundary. A retrieved document can contain text that tries to steer the model into calling a tool. External content must remain data, not gain the authority of a system instruction.

When does MCP help?

MCP is a good fit when an integration needs to outlive a prototype and serve more than one client. It is particularly useful when a company wants a controlled catalogue of capabilities that several agents can share.

Imagine a team with documentation in one system, projects in another, and analytics in a third. Instead of building a separate plugin for every assistant, the team publishes MCP servers with a small, deliberate set of operations. Different clients use the same contracts, while authorization still follows the signed-in user.

MCP will not fix an unclear API, stale data, or a missing permission model. It can only expose those problems through a newer interface.

A low-risk starting point

Start with one read-only operation, such as documentation search.

Then:

  1. define a narrow input schema,
  2. return a small, unambiguous result,
  3. log every call,
  4. test it against realistic questions,
  5. add write operations later, behind a separate approval gate.

The tool description is part of the model interface. If two operations sound almost identical, the agent may confuse them too. The guide to designing agent tools and APIs covers that interface in more detail.

MCP gives an agent a path to data and actions. The agent environment determines how far it can travel.

Sources