Skip to main content
Imagine you need the assistant to check which pull requests are still open in a private repository. The model can generate the correct API call, but it can’t execute it because the repo is private. Or an agent may draft help-desk tickets but leaves you to copy them into the ticketing system and press “Create”. The model understands the task but lacks direct access to the systems where the work must occur. The Model Context Protocol (MCP) fills that gap. MCP connects hosts, clients, and servers so models can securely discover and invoke external capabilities without hardcoding every integration.
MCP standardizes discovery, schema-driven tooling, and execution so applications (hosts) can present capabilities to models without embedding credentials or API-specific logic. Use MCP when you need models to interact with live services while keeping authentication and API handling centralized on dedicated servers.

​
What MCP solves

  • Eliminates the N×M adapter problem by providing a consistent interface: many hosts can use many services without pairwise integrations.
  • Lets hosts discover capabilities via MCP servers instead of embedding knowledge of every external API.
  • Centralizes authentication, error handling, and API changes inside MCP servers maintained by service providers or trusted vendors.

​
Core components and responsibilities

​
Where MCP servers run

  • Locally: started on a developer machine (executable, Docker, Podman). Clients and servers can communicate over stdio or local transports.
  • Shared or remote: deployed as a container, VM, or cloud endpoint that a team can reach over HTTP.
  • Transport-agnostic: MCP semantics are the same regardless of transport (stdio, HTTP, gRPC, etc.), so deployment method does not change behavior.

​
Typical conversation flow (high-level)

  1. User asks a question (e.g., “What open pull requests do I have?”).
  2. The MCP client requests available capabilities from the MCP server (“list tools”).
  3. The server returns tool descriptions (schemas); the host includes these alongside the user query and forwards them to the model.
  4. The model inspects the available tools, selects the appropriate one, and issues a tool request (tool name + inputs).
  5. The client forwards the tool request to the MCP server.
  6. The server executes the requested function by calling the external API and returns the result.
  7. The host feeds the result back to the model, which produces the final answer for the user.

​
Functions, schemas, and resources

  • Functions: Actionable capabilities (e.g., list_pull_requests, create_issue, search_code).
    • Schema: A machine-readable description (what the function does and the inputs it accepts). The model uses schemas to decide if and how to call a tool.
    • Implementation: Server-side code that calls the external API and handles authentication, retries, and errors.
  • Resources: Readable artifacts the server exposes (documents, repo content, documentation snippets) without granting write capability.
Example: a function has a JSON schema describing fields and types; the server implements that schema and maps inputs to the external API.

​
Why use MCP rather than calling external APIs directly?

  • Direct integration requires the host or model to learn and maintain each API schema and authentication flow.
  • MCP servers encapsulate API knowledge, manage auth, handle errors, and keep schemas up to date — reducing maintenance and speeding integration.
  • MCP lets vendors provide officially maintained servers so hosts can rely on accurate, audited behavior instead of custom adapters.

​
Examples

  • A GitHub MCP server translates MCP requests into the GitHub REST API and keeps authentication and rate-limit handling on the server side. See GitHub REST API documentation: https://docs.github.com/en/rest
  • A Terraform MCP server can fetch provider and module documentation from the Terraform Registry for read-only help or, if connected, interact with protected Terraform Enterprise workspaces.

​
Security considerations

An MCP server is code with access to external services and potentially elevated permissions. Treat MCP servers like plugins or browser extensions:
  • Vet servers before installation and prefer official or audited implementations.
  • Use strong authentication (e.g., OAuth) to identify and authorize calls.
  • Apply least privilege to server credentials and expose only the minimal set of tools required.
  • Require human approval for destructive or risky write actions.
  • Treat tool outputs as untrusted text — they may contain prompt-injection attempts or unexpected content.

​
Best practices

  • Limit server credentials and scope to least privilege.
  • Expose only necessary tools; avoid broad write permissions by default.
  • Require explicit user confirmation for destructive actions.
  • Log and audit all MCP requests and responses.
  • Prefer official or well-audited MCP servers from service providers.
  • Keep schemas and implementation up to date to prevent mismatches between the model’s expectations and server behavior.

​
Quick reference

​
Summary

MCP standardizes discovery, schemas, and execution so models can safely and conveniently interact with external services without each host requiring bespoke adapters. Hosts use an MCP client to discover tools from MCP servers; servers hold credentials, map MCP requests to external APIs, and return structured results. This division reduces friction, centralizes security and API updates, and makes it practical for models to take live actions and fetch live data while protecting accounts and organization boundaries.

Watch Video