Search

What are you looking for?

Search our services, use cases and practical insights.

Enter at least 2 characters

Popular starting points

Agents and automation

What is the Model Context Protocol (MCP)?

MCP provides a common language for integrations around AI applications. It can make connections more consistent, but it does not replace permissions, domain validation or secure operations.

The short answer

The Model Context Protocol is an open protocol through which an AI application can discover and use tools, data resources and templates exposed by an MCP server in a standard way.

In brief

  • MCP standardises the connection between an AI application as client and capabilities exposed by a server.
  • An MCP server can offer tools, readable resources and reusable prompt templates.
  • The protocol can make integrations more portable, but says nothing about a server's domain quality or trustworthiness.
  • Authentication, least privilege, approvals, logging and protection against manipulated content are still required.

Which roles exist in MCP?

The host is the application in which a person works with AI. Inside it, an MCP client manages a connection to one or more MCP servers. A server describes its capabilities in a standard format and performs permitted calls or returns resources.

The language model does not communicate directly and without control with every business system. The host application decides which servers are connected, which capabilities are shown to the model and how a proposed call is validated.

  1. Step 1

    A person states the task

    The authenticated person works in the host. Control point: identity, role and visible purpose are established.

  2. Step 2

    The host plans a permitted call

    The application decides which servers and capabilities the model may see. Control point: policies and approval thresholds are enforced outside the model.

  3. Step 3

    The MCP client opens the connection

    The client sends the structured call to one approved server. Control point: authentication and destination are verified, and the access token must be issued for exactly that server or target resource.

  4. Step 4

    The MCP server validates and translates

    The server validates parameters and enforces authorisation before calling the target system. Control point: schema, tenant, fields and action are bounded on the server.

  5. Step 5

    The target system returns or executes

    The business system remains the final authority. Results, errors and approval status return through server and client, with relevant steps recorded.

What can an MCP server expose?

Tools are callable functions, such as a product search or creation of a ticket draft. Resources provide readable content such as a configuration or document. Prompts are server-provided templates for recurring interactions. An integration does not have to expose all three types.

  • Tools for clearly described queries or actions
  • Resources for addressable, readable information
  • Prompt templates for reusable work patterns
  • Capability discovery so clients understand what is supported

What value can MCP provide to a company?

Without a common standard, the same data source is often integrated separately for several assistants and agents. MCP can make technical exposure consistent and reduce coupling between one model application and one tool.

The value still depends on a maintained product and operating model. An MCP server needs versioning, ownership, stable schemas, support and clear commitments. For one tightly embedded interface, a direct API may remain simpler.

  1. Step 1

    Assess reuse

    Will several clients need the same capability, or is this a one-off integration?

  2. Step 2

    Define the contract

    Specify inputs, outputs, failures, versions and server limits.

  3. Step 3

    Assign ownership

    Name owners for data, tool, access and operation.

  4. Step 4

    Test clients

    Verify how different applications handle permissions, failures and change.

Which security questions does MCP not solve automatically?

A standardised call can still be over-privileged or wrong for the business context. Server descriptions and returned content cross a trust boundary and must not override system rules or silently create new rights.

  • Connect only reviewed servers and explicitly approved capabilities
  • Bind authorisation to authenticated identities and individual calls
  • Secure token forwarding, dynamic client registration and redirects
  • Confirm sensitive actions and log all calls for traceability
  • Retest schema and server changes before production use
Example from day-to-day business

Example: a shared product catalogue MCP server

A company exposes approved product catalogue search through a read-only MCP tool. A service copilot and an internal sales assistant can use the same server. Clients pass the authenticated user identity; the server filters product range and fields by role and market. Price changes are not part of this server and remain in a separate, tightly controlled process.

What to remember

Use MCP as an integration standard, not as evidence of trust. Every server, tool and access path still needs a clear purpose, an owner and technically enforced boundaries.

Sources and further reading

These primary sources provide further detail on definitions, technical foundations or responsible use.

Content reviewed

Would you like to apply this to your situation?

Together, we clarify what makes sense for your process, data and systems – in plain language and without unnecessary complexity.

Discuss Your Project