Scrapeless Wiki

What Is Model Context Protocol? – Definition and How It Works

Informational P1 what is model context protocol
Overlaps a live page. A published page already targets this keyword: https://www.scrapeless.com/en/blog/what-is-mcp. Publishing both risks cannibalisation — decide before this goes live.

Learn what the Model Context Protocol is, how servers expose tools and resources, how it differs from plain function calling, and where it fits in an AI stack.

The Model Context Protocol (MCP) is an open standard for connecting AI applications to external tools and data. It exists to solve an integration problem: without it, every AI client has to write bespoke glue for every service it wants to reach.

1. What Is MCP?

MCP is a client–server protocol that standardises how an AI application discovers and calls external capabilities.

  • Key idea: one protocol between any client and any tool provider, instead of N Ă— M custom integrations.
  • Mechanism: an MCP server exposes tools, resources and prompts; an MCP client inside the AI application connects and consumes them.
  • Goal: write an integration once and have every compatible client use it.

The analogy people reach for is a device driver interface, or USB: the host does not need to know how each peripheral works internally, only how to speak the common protocol.

2. What a Server Exposes

An MCP server can offer three kinds of thing, and the distinction matters:

Primitive What it is Controlled by
Tools Actions the model can invoke — search, query, create, fetch The model chooses
Resources Data the client can read — files, records, documents The application chooses
Prompts Reusable templated workflows The user chooses

Tools are the most visible primitive, and the one people usually mean when they say "MCP server". The three-way split is deliberate: not everything a server offers should be something the model decides to invoke on its own.

3. How a Session Works

  1. The client connects to the server and they negotiate capabilities.
  2. The client asks what the server offers, and receives tool definitions with JSON Schema parameters.
  3. Those definitions are presented to the model.
  4. The model decides a tool is needed and emits a call with arguments.
  5. The client forwards the call to the server, which executes it.
  6. The result returns to the model, which continues with it in context.

Transport is typically stdio for a local server or HTTP with Server-Sent Events for a remote one. Messages are JSON-RPC.

4. MCP vs. Plain Function Calling

They are related but not interchangeable — MCP is built on top of the model's tool-calling ability.

  • Function calling is a model capability: given schemas, the model emits a structured request to invoke one. The schemas are hardcoded in your application.
  • MCP is a transport and discovery standard: the schemas arrive at runtime from a server the application connects to, and the same server works with any compliant client.

Put simply, function calling answers "how does a model ask for a tool?". MCP answers "where do the tools come from, and who else can use them?". An MCP client still uses function calling underneath.

The practical consequence is reuse. A function-calling integration lives inside one application. An MCP server is a standalone process that any MCP-capable client can attach to without modification.

5. Why It Matters

Integration cost collapses. Ten clients and ten services need a hundred bespoke integrations, or twenty MCP implementations.

Capabilities are discovered, not compiled in. A client learns what a server can do when it connects, so adding a tool does not require shipping a new client.

Servers are separate processes. They run with their own credentials and their own permissions, which is a cleaner security boundary than embedding every integration in the AI application.

Vendor independence. Because the protocol is open, an MCP server is not tied to one model provider.

6. Real-World Examples

  • A database server exposing a read-only query tool, so an assistant can answer questions about live data without a custom backend.
  • A web scraping server exposing scrape_url and search, giving any client live web access through one integration.
  • A filesystem server exposing a directory as resources, so a coding assistant can read a project without the files being pasted into a prompt.
  • An internal API wrapped as a server, letting several different AI clients reach it with one implementation and one audited credential path.
  • A ticketing server exposing issue creation as a tool and issue templates as prompts — the same service using two different primitives correctly.

7. Practical Cautions

  • Tool descriptions are prompt input. The model reads them, so vague descriptions produce wrong calls. Treat them as documentation written for a model.
  • Server content is untrusted. Tool descriptions and results arrive from outside your application. A server can attempt prompt injection through either, so do not grant tools authority based on what a server claims about itself.
  • Too many tools degrade selection. Attaching a dozen servers with a hundred tools makes choosing correctly harder, not easier.
  • Every tool is a permission. A server running with broad credentials gives the model that reach. Scope it deliberately.

8. Summary

MCP is an open client–server protocol that lets AI applications discover and use external tools, resources and prompts through one standard interface, replacing bespoke per-service integrations.

It builds on function calling rather than competing with it: the model still emits tool calls, but the definitions arrive at runtime from a server that any compliant client can reuse. The gain is integration economics and a cleaner process and credential boundary — with the accompanying obligation to treat every connected server as untrusted input, because its tool descriptions and results both reach the model.