The Three Laws of MCP (Asimov Can Rest Easy)
Asimov's Three Laws of Robotics encoded a philosophy about how robots should relate to humans. They weren't just rules, they were a framework for reasoning about harm, autonomy, and control. The laws conflicted with each other by design, forcing a hierarchy.
MCP's three primitives, Tools, Resources, and Prompts, encode a similar philosophy. They're not just API categories. They're a framework for reasoning about how AI should interact with the world: what it can change, what it can only read, and what humans explicitly invoke.
Get them right, and your MCP server is intuitive, safe, and composable. Get them wrong, and you'll wonder why the AI keeps calling the wrong thing at the wrong time.
The Three Laws
Law 1 (Tools): The AI may act, but only through declared, validated interfaces.
Law 2 (Resources): The AI may observe, but only read, never modify.
Law 3 (Prompts): Humans may invoke structured workflows; the AI executes but does not initiate.
Simple rules. Complex implications.
Law 1: Tools (The AI Acts)
A Tool is the mechanism through which an AI model takes action in the world. Call an API. Write a file. Insert a database record. Send a message.
The crucial design principle here is model-invoked. When you define a Tool, you're telling the AI: "When you judge that this action is appropriate, you may perform it." The model decides. You define the action and its parameters.
This is both powerful and slightly terrifying if you think about it too long.
The validation part of Law 1 matters enormously. Tools have JSON Schema-defined parameters. The SDK validates incoming tool calls against the schema before your handler runs. But JSON Schema validates structure, not semantics. A run_sql tool that validates that query is a string doesn't prevent the model from running DROP TABLE users. That's why:
- Tool scope should be as narrow as possible
- High-risk tools should have the risk encoded in their names
- Your handler must perform semantic validation the schema can't express
- Destructive tools should ideally require host-level user confirmation
When I see a manage_everything MCP tool that accepts raw SQL, I see a liability. When I see search_orders, update_order_status, and cancel_order, I see three safe, auditable tools.
The counterintuitive guidance: More, smaller tools are better than fewer, broader ones. The AI can reason about specific tools more accurately than Swiss-army-knife tools.
Law 2: Resources (The AI Observes)
A Resource is data the AI can read. Files. Database records. API responses. Log streams. The AI doesn't modify Resources, it consumes them as context.
The safety property is clear: if the AI can only read a Resource, it cannot corrupt your data by accident. A hallucinating model with access to a filesystem Resource can read the wrong file. A hallucinating model with a filesystem write Tool can delete it.
The design principle that most developers miss: Resources shouldn't just be "the read-only version of a Tool." They should be identified by stable URIs that the application (not the model) can decide to attach to context.
This is a subtle but important difference. A Tool is called when the model thinks it's a good idea. A Resource can be pre-fetched by the host application before the conversation even starts. Claude Desktop can attach a resource to every conversation in a project. A Cursor workspace can always have the relevant codebase resources available.
This means Resources enable ambient context, the AI always knows about certain data, not just when it explicitly decides to look.
The test for Resources vs. Tools: "Does this operation have side effects?" If yes → Tool. If no → Resource. It's almost always that simple.
Corollary: if you find yourself building a get_user Tool, it should probably be a users://{userId} Resource. Save the Tools for update_user.
Law 3: Prompts (Humans Invoke, AI Executes)
Prompts are the most frequently misunderstood primitive. They're not instructions the AI sends to itself. They're instruction templates that humans explicitly invoke from the host UI.
Think of them as slash commands with arguments:
/code-review language=java focus=security/standup-summary team=backend/explain-error log-level=error component=payment-service
The human chooses to invoke a Prompt. The Prompt expands into a carefully crafted conversation structure, system messages, context, initial user message, designed to produce high-quality, consistent AI output for that specific task.
Why this matters: Without Prompts, every developer on your team writes their code review instruction differently. "Review this code" produces mediocre results. "You are an expert Java security engineer. Review the following code for SQL injection vulnerabilities, insecure deserialization, missing input validation, and authentication gaps. For each issue, cite the CWE, provide a severity rating, and show the corrected code." produces good results. But who writes that every time?
Prompts let you write the expert instruction once and distribute it to everyone through their AI tool.
The Asimov parallel: Law 3 is the one about human control. Tools can run autonomously. Resources can be ambient. But Prompts are explicitly human-initiated. The AI doesn't invoke a Prompt, humans do. This preserves human agency for high-level workflow initiation while letting the AI operate autonomously at the execution level.
When the Laws Conflict
Asimov's genius was in the conflicts between his laws. The MCP primitives have their own tensions:
"Should I make this a Tool or a Resource?"
The primary question is side effects. But there's a secondary question: control. If you want the model to autonomously decide when to fetch data, you need a Tool (the model decides). If you want the host application to control what data is available to the model, you want a Resource (the application decides).
"Is this a Resource or a Prompt?"
Resources provide data. Prompts provide instructions. A resource with product documentation is data. A prompt that says "review this product documentation for inconsistencies and suggest improvements" is an instruction template. Often you use both together: the Prompt includes an embedded Resource reference.
"Do I need a Tool if I already have a Prompt for this?"
Yes. A Prompt for "search for customers" that the user invokes is different from a Tool for search_customers that the AI invokes autonomously mid-conversation. They serve different use cases and you might want both.
The Framework in Practice
Here's how I think through a new capability when building an MCP server:
- Does it write, modify, or have side effects? → Tool (with careful scope definition)
- Does it read stable, addressable data? → Resource (with a meaningful URI)
- Is it a recurring, high-quality workflow? → Prompt (that wraps Tools and Resources)
- Could it be both a Tool and a Resource? → Yes, and that's fine. Implement both.
The laws give you a framework. They don't make every decision for you. But they prevent the most common mistakes: read-only operations implemented as Tools (losing the composability benefit of Resources), and write operations implemented as Resources (breaking the safety contract).
The Philosophical Point
I started with Asimov because the analogy runs deeper than it seems.
Asimov's laws were about the relationship between robots and humans, about who has agency and who has authority. Law 1 (don't harm humans) prioritises human safety. Law 2 (obey humans) prioritises human authority. Law 3 (protect yourself) enables robot agency within those bounds.
MCP's three primitives encode a similar relationship between AI and the systems it operates in:
- Tools encode that the AI can act, but only through declared, safe interfaces
- Resources encode that the AI can know, but only through read-only access to data
- Prompts encode that humans can direct, and the AI will follow high-quality structured guidance
These aren't just implementation details. They're a philosophy of how AI should be integrated into production systems: capable but bounded, powerful but controlled, autonomous but within declared limits.
Asimov's laws failed in the stories because real situations are too complex for simple rules. MCP's three primitives work because they're not about ethics, they're about a clean architectural separation of concerns. And that, as we've known for decades, is where software elegance lives.
Want to build servers that implement these three primitives correctly?
Start with MCP Fundamentals for the theory, or jump straight to Building MCP Servers in Java if you learn better by doing.