When should a server expose a tool, a resource, or a prompt?

2026-07-28 core · deterministic JSON-RPC fixtures

Atlas Release Evidence Server. Read-only evidence, deterministic scoring, and an explicit evaluation Task across replicas and protocol eras.

01 · Smallest useful mechanism

Choose primitives from semantics, not UI convenience.

The primitives have different discovery, invocation, trust, caching, and consent implications. A broad “do everything” tool erases those useful distinctions.

Use tools for operations, resources for addressable context, and prompts for reusable user-invoked templates.

02 · Experiment

Test the prediction

Deterministic protocol fixture

This workbench uses inspectable JSON-RPC fixtures and injected failures. It does not make live calls or execute external effects.

Protocol workbench · atlas-primitives-v1

Choose the cleanest representation for release evidence, risk scoring, and a review workflow.

Injected failure

The evidence changes while a generic tool also has deployment credentials.

Choose the implementation

One universal release toolRead evidence, score risk, and deploy from one free-form command.Represent everything as resourcesEncode actions as special URIs.Split by semanticsVersioned resource, deterministic tool, and user-invoked prompt.

The trace has not run.

Commit to an implementation, then inject the failure and inspect the actual state transitions.

03 · Implementation brief

Build it, break it, prove the outcome.

Implement: Create a primitive inventory with mutability, provenance, schema, size, freshness, and approval.
Break it on purpose: Add a broad free-form tool, a cross-tenant URI, an oversized resource, and a misleading read-only annotation.
Completion evidence: The design splits responsibilities, bounds data, rejects traversal, and applies policy independently of annotations.

Your learning artifact

Write the argument you would defend

Stored only in this browser. No account required; course reset does not delete it.

Your response

04 · Check your understanding

Which primitive best represents a versioned, addressable release report?

Primary sources · verified 2026-08-02

What the fixture does not prove

Poor primitive design inflates model context, makes approval unintelligible, hides data provenance, and increases the blast radius of mistakes or injection.

Common mistake: Everything should be a tool because models already understand function calling. Read-only addressable content and reusable prompt templates have distinct contracts that improve provenance and user control.

Transfer exercise: Model release notes, a risk calculation, and a review checklist using the narrowest appropriate primitives.

Model Context Protocol — 2026-07-28 specificationThe authoritative modern MCP protocol: stateless requests, per-request metadata, capabilities, and server features.MCP — ToolsNormative tool discovery and invocation contract, input and output schemas, errors, annotations, and safety requirements.MCP — Extensions overviewOfficial opt-in extension framework and current extensions, including Tasks, MCP Apps, and Skills over MCP.

Optional referenceDeep dive / reference chapterOpen the complete essay, diagrams, mathematics, exercises, glossary, and sources when you want more depth.on demand

Next: Primitive contracts travel over a transport; the next lesson shows why framing and deployment topology affect correctness and security.