theLLMs

Last checked: 2026-05-28

Scope: Global. MCP specification v2025-11-25 checked on 2026-05-28; this page is operational guidance, not a protocol endorsement.

AI draft model: gemma4:26b

AI review model: deepseek-r1:32b

Key terms:

>_ large language model (LLM) >_ context window >_ prompt >_ system prompt >_ JSON mode >_ function calling / tool use
Hero image for MCP explained: tools, resources, prompts and the current hype gap

MCP explained: tools, resources, prompts and the current hype gap

MCP gives teams a standard way to let models discover and call tools, read resources, and use prompt templates — all over JSON-RPC. The hype gap appears when people assume a protocol automatically solves integration, safety or product design problems that still need to be handled explicitly. A standard interface is helpful. A standard interface is not the same as a complete product.

TL;DR

Understand MCP as a transport and description layer for model-connected capabilities. Then check permissions, stability and operational control before you assume it is production-ready. If you only need one model calling one known API, a custom function-calling wrapper is probably simpler than running an MCP server — and easier to debug when things go wrong.

What this means: tools, resources and prompts — concretely

MCP organises what a model can do into three primitives. Here is what each looks like on the wire.

Tools

A tool is a function the model can invoke. The server advertises tools via tools/list, and the client calls them via tools/call. Each tool has a name, description, and JSON Schema input definition.

Minimal tool definition (what the server returns in tools/list):

{
  "name": "read_file",
  "description": "Read the contents of a file at a given path",
  "inputSchema": {
  "type": "object",
  "properties": {
  "path": {
  "type": "string",
  "description": "Absolute path to the file"
  }
  },
  "required": ["path"]
  }
}

The model sees the name, description and schema — it does not execute the call directly. The model proposes arguments ({"path": "/home/user/config.json"}), the client sends a tools/call request, and the server returns the result.

Spec ref: Tool interface (§tools/list), CallToolRequest (§tools/call) — MCP specification v2025-11-25.

Resources

A resource is data the server can serve — a file, a database row, an API response. Resources are identified by URI. The server advertises them via resources/list, and the client reads them via resources/read.

Resource URI examples:

  • file:///home/user/project/config.json — file system content
  • postgres://orders/recent?limit=10 — database query result
  • https://api.example.com/v2/accounts/1234 — external API data

The model can request these resources without knowing how to fetch them directly. The server handles the actual retrieval.

Spec ref: Resource interface (§resources/list, §resources/read) — MCP specification v2025-11-25.

Prompts

A prompt in MCP is a reusable template the server advertises, not an instruction the model executes. The client fetches the template and fills in arguments before sending the completed prompt to the model.

Example prompt template:

Summarise the following ${document_type} for a ${audience} audience.
Key points to cover: ${focus_areas}

Prompts are useful for standardising common interactions — summarisation, code review, data extraction — across different models and clients without hardcoding instructions in each integration.

Spec ref: Prompt interface (§prompts/list, §prompts/get) — MCP specification v2025-11-25.

Where the hype gap lives

MCP marketing often implies “connect any model to any tool, securely.” The spec itself is more careful, but the gap between promise and reality shows up in three places:

Auth and permissions are not in the spec

MCP v2025-11-25 does not define an authentication or authorisation layer. The spec assumes the transport handles auth (e.g., mTLS for SSE, or OS-level permissions for stdio). If you run an MCP server that wraps a database, the server itself must enforce read-only vs. read-write access — MCP does not do it for you.

Tool descriptions are untrusted input

The model decides what to call based on the tool’s description field. A poorly written description can cause the model to misuse a tool, skip it, or call it with wrong arguments. The protocol does not validate or enforce description quality.

Stability is server-dependent

MCP server quality varies from “reference implementation” to “weekend project.” The protocol standardises the interface, not the implementation. A server that advertises tools/list correctly can still crash on tools/call, return inconsistent results, or leak data through error messages.

Real MCP servers worth studying

The reference servers maintained by the Model Context Protocol organisation on GitHub are open-source and show real tool definitions:

filesystem: exposes read_file, write_file, list_directory, search_files and similar — useful for coding agents but dangerous without approval gates.

github: exposes tools for PR review, issue management, file operations on repos — a good example of wrapping an external API behind MCP.

postgres: exposes database schema and query tools — demonstrates resource URIs (postgres://...) and read-only vs. write tool patterns.

brave-search: wraps the Brave Search API — shows how to expose an external SaaS API as MCP tools.

These are learning resources, not production endorsements. Study them for patterns, not for copy-paste deployment.

Practical decision check

Before adopting MCP, answer:

  • Do you need a standard interface for multiple tools, or just one API wrapper? If you have one API and one model, a custom function-calling integration is less overhead than running an MCP server.
  • Who enforces permissions? MCP does not. Your server or middleware must.
  • What happens when the MCP server goes down? Does your product degrade gracefully, or does the model lose access to critical tools silently?
  • Are you comfortable debugging JSON-RPC? When something breaks, the error is likely in the transport layer, not your application code.
  • Have you tested tool descriptions with the models you actually use? A description that works well with Claude may confuse GPT-4o or Llama.

Methodology

  • Data checked: 2026-05-28
  • Sources consulted: MCP specification v2025-11-25 (schema and protocol docs), Anthropic MCP documentation, OpenAI function calling documentation, OWASP Top 10 for LLM Applications, reference MCP server implementations (server-filesystem, server-github, server-postgres, server-brave-search)
  • Assumptions: MCP implementations continue to evolve; the examples above reflect the v2025-11-25 spec. Tool description quality varies by server — the reference servers above represent best-practice examples. This is integration guidance, not a blanket recommendation for or against MCP.
  • Limitations: This article does not benchmark MCP server performance, does not compare MCP against specific alternatives (LangChain tools, direct function calling), and does not provide legal or compliance advice. Auth, rate-limiting and audit-logging recommendations draw from OWASP Top 10 for LLM Applications, not from MCP specification requirements.
  • Jurisdiction: Global. No jurisdiction-specific regulatory content.

Source list

Trust Stack

  • Last checked: 2026-05-28
  • Corrections: Contact us to report errors

Change log

  • 2026-05-28: Full editorial review against 16-gate checklist. Repaired garbled URL fragments, added 3 Editor’s Note aside cards, slugified all H2/H3 IDs, added missing Trust Stack section with corrections policy and affiliation, standardised Methodology to canonical format, fixed Source List with access dates, removed workflow leak reference, standardised Change Log format.
  • 2026-05-25: Added concrete tool/resource/prompt examples with JSON structures, real MCP server names, expanded scenarios, “what would change the advice” section, inline spec citations, fixed related-guide links to production routes, and rewrote source-use descriptions.
  • 2026-05-24: First published.