What Is MCP? A Plain-English Guide to Model Context Protocol

Model Context Protocol (MCP) is an open protocol for connecting an AI application to external data and actions through a consistent interface. Think of it as a connector contract, not a model that suddenly owns every business system. The model may propose a tool call; the application and connected server still control what runs and under whose authority.

This guide addresses one technical question: how an AI application discovers and uses a connected capability. If you are choosing an implementation partner in Armenia, start with the AI specialist guide. For a wider process design, see AI automation.

A definition without the marketing

An MCP host is the AI application. It manages a client connection to each server that exposes capabilities. The server can expose tools (callable functions), resources (contextual data) and prompts (reusable interaction templates), as described in the official specification. The client discovers these capabilities and exchanges structured messages with the server.

MCP does not train the model, grant permissions or prove the model's answer is correct. An ordinary API still performs the business operation behind an adapter. MCP standardizes the discovery and invocation layer for AI applications. If one deterministic workflow needs one known API call, a direct integration may be simpler.

How it works: the MCP-CONNECT-6 map

This original MCP-CONNECT-6 map is a design example, not a customer deployment or benchmark.

The trust boundary sits between a model proposal and execution. A tool description helps the model select a call; it does not authorize that call. A server is not trustworthy just because it speaks MCP. Writes need user authorization, a narrow scope, argument validation and a denial path. The tool calling article examines this execution boundary in more detail.

The three server primitives

• A tool is a callable function, such as crm.findCustomer or calendar.createDraft. Its name and input schema describe the interface, not the access policy.
• A resource supplies a document or other context. It may contain mistaken or malicious instructions; treat its text as data rather than system authority.
• A prompt is a reusable task template selected by the user or application. It helps repeat a workflow but grants no additional permission.

MCP standardizes how a capability is presented and called. Ownership, data rights and correctness remain application responsibilities.

One example from question to CRM draft

An employee asks: “What support terms apply to customer X, and prepare a task draft for the account manager.” The organization stores contracts in a knowledge base and customers in a CRM. Its adapter exposes a permitted contract fragment as a resource and crm.createTaskDraft as a tool.

1. The host binds the employee's identity and organization. The document search filters access before sending any fragment to the model.
2. The model drafts an answer citing a versioned contract excerpt. Any instructions found inside the contract remain untrusted document text.
3. The model proposes a task draft with customerId, summary and sourceRef. The host presents or routes the exact proposal under the employee's permitted workflow.
4. The server validates arguments, record ownership and the permission to create a draft. An ambiguous API result is reconciled against the destination before a retry.

The intended outcome is a sourced answer and, if permitted, a CRM draft. This is a synthetic design example, not a client case or a guarantee about any MCP client. A production host and adapter must implement the controls. Human approval boundaries become relevant before sending a message or changing commercial terms.

// Illustrative control order, not production MCP SDK code.
const proposal = { tool: "crm.createTaskDraft", customerId, summary, sourceRef };
if (!policy.allows(actor, proposal.tool, customerId)) return "deny";
if (!source.isCurrent(sourceRef)) return "refresh_source";
const receipt = await gateway.executeOnce(proposal, requestId);
return receipt.effectKnown ? receipt : "reconcile";

When it fits

Limits and a first pilot

A locally installed server may run as a process on a user's machine; a remote server adds network authorization and operational concerns. Record the server's owner, package provenance, exposed capabilities and revocation path. Give the adapter the least scope the task needs. A tool response is not proof that a CRM change happened.

Test an unauthorized user, another tenant's record, injected document text, malformed arguments, expired approval, a timeout after a write and a changed tool list. Inspect the destination state, not only the model's answer. The official MCP security guidance covers relevant authorization and trust issues.

Start with one read-only resource and one safe draft action. Define who can use each, how to revoke access, what to log and how to reconcile an unknown result. Prompt engineering helps specify answer format; AI automation puts the call into a governed process. To assess a concrete scenario, describe your workflow: system, user, data and one allowed action.