What Is MCP? — geekcode.vip

If you want Claude to retrieve information from web pages, try mcp-web-content-pick, a local, privacy-conscious server built for that job.

From an island to a bridge

Imagine a remarkably knowledgeable friend locked in a room with no windows. They can reason about almost anything, but cannot check today’s weather, use a calculator, read a local file, or control a device. You can pass notes under the door, but that is all.

That captures an important limitation of a language model. A model can work with the text in its context, yet it cannot automatically read a current system of record or perform an action outside that context. We need a controlled, repeatable way to connect model applications with the outside world. That is the role of the Model Context Protocol (MCP).

MCP in one sentence

MCP is an open protocol for connecting an AI application to external capabilities through a common interface. If an LLM is the brain, MCP is a standardized socket: different capability “plugs” can connect without every application inventing a new adapter.

The three ideas most people meet first are:

Resources provide information a model application can read, such as a document, a schema, or a customer record.
Tools perform a defined operation, such as querying a service or creating a draft.
Prompts offer reusable interaction templates for a specific workflow.

Another analogy is a city. Resources are its libraries and data centers. Tools are its specialist services. Prompts are well-tested scripts that make common interactions easier to begin.

Why a protocol is useful

Before a shared protocol, every LLM integration tends to grow its own custom interface. The result looks like a room full of chargers with incompatible plugs:

interfaces are fragmented;
the same integration work is repeated;
adding a capability requires bespoke application work;
security controls are inconsistent and easy to overlook.

With a common protocol, a host can discover what a server offers, a server can expose focused capabilities, and the two can work together through a known contract. That does not make integrations automatically safe or simple, but it gives them a shared starting point—much as HTTP gave the web a shared foundation.

A small mental model: a calculator server

An MCP server declares the capabilities it is willing to expose. A minimal server might offer:

an add tool with two numeric inputs;
a math://constants resource containing values such as π and e.

The host can then discover the server, learn those names and their input shapes, and invoke the tool or read the resource when it is appropriate for the user’s request. The model is not handed unrestricted access to “the computer”; it is given a narrow, describable capability.

In TypeScript-like pseudocode, the shape is deliberately simple:

server.tool("add", { a: number, b: number }, async ({ a, b }) => ({
  content: [{ type: "text", text: String(a + b) }],
}));

server.resource("constants", "math://constants", async (uri) => ({
  contents: [{ uri: uri.href, text: JSON.stringify({ PI: Math.PI, E: Math.E }) }],
}));

The exact SDK API evolves, so use the current official documentation when implementing a server. The architecture is the durable part: define a small contract, validate input, perform one controlled operation, and return a result the host can place in context.

Resources, tools, and prompts in a real feature

Consider a weather assistant:

A resource can expose the current conditions for a city.
A tool can retrieve a multi-day forecast using validated city and days inputs.
A prompt can produce a standard request such as “Give clothing and activity advice based on the weather in this city.”

The same division works for more serious systems. A database-oriented server might expose its schema as a resource and offer a read-only query tool. A file-oriented server might allow reading from an approved directory and a separately authorized write tool. The point is not to expose every possible operation. The point is to expose the smallest useful set.

What happens during a request?

The interaction is easier to understand if you picture a restaurant:

The host application establishes a connection with an MCP server.
It discovers the server’s available resources, tools, and prompts—the menu.
It selects a capability and sends a request with arguments.
The server validates the request, talks to its underlying system, and returns a result.
The host brings that result into the model’s context and presents the next response or asks for confirmation.

MCP can run locally over standard input/output or remotely over supported web transports. The choice depends on where the host and server run, what network access is appropriate, and how authentication should work. Local transports are often a good fit for personal tools; remote services require more deliberate identity, authorization, and observability.

Advanced uses: databases and files

Database access is a natural example because models are useful at turning a question into an investigation. An MCP server can make the schema readable and provide a query capability. It should not, however, accept arbitrary destructive SQL just because a user asked a question in natural language.

A safer design is to:

expose only the schema and views needed for the task;
use a read-only database role;
allowlist operations or generate parameterized queries;
enforce row, time, and result-size limits;
log every request with the effective identity.

File access needs the same discipline. Resolve paths against an allowed root, reject traversal outside that root, constrain file types and sizes, and make writes separate, explicit, and reviewable. “The model only follows instructions” is not a security boundary—especially when files and web pages may contain hostile text.

Security and privacy: capabilities are doors

Connecting a model to external systems is powerful precisely because it can do more than produce text. Treat every capability as a door that needs a lock.

Useful controls

Access control: expose only resources and tools a given user or service is allowed to use.
Input validation: use a type system and strict limits for fields, enum values, and ranges.
Sandboxing and isolation: run risky work in a constrained environment, not in the host’s full trust zone.
Audit logs: record capability calls, parameters appropriate for logging, identities, and outcomes.
Rate limits and budgets: prevent loops, abuse, and accidental cost explosions.

For consequential actions—payments, emails, deleting data, permission changes—use a confirmation step. Let the AI prepare an action and show its impact; let an authorized person approve the final call. A clear error message for the user and a detailed internal audit record are usually better than exposing raw system errors.

Where MCP fits

MCP is useful wherever a model needs a bounded way to read information or call an operation:

company knowledge bases and internal policies;
personal assistants for calendars, email, and files;
developer tools that search repositories and API documentation;
data-analysis workflows that query approved datasets;
IoT and device-control scenarios with strict authorization.

It is not a reason to connect every system to every model. Start with one real workflow, define a narrow capability, make the failure mode safe, and instrument what happens. A small server that does one thing reliably is more valuable than a broad server nobody can trust.

Conclusion

MCP is not just another API wrapper. It provides a shared language for making AI applications useful beyond the chat box while keeping the connection explicit and controllable. As the ecosystem grows, the winning integrations will not be the ones with the largest tool list. They will be the ones that make the right capability available, to the right identity, with limits that are easy to understand and audit.

Further reading: