Protocols of Action: MCP, Skills, and the Boundary Around Capability

In the repository’s tools-and-protocols path, the central question changes from “can an application call a tool?” to “can a capability and its procedure remain understandable across hosts, requests, and trust boundaries?” This chapter follows two related but different artifacts: MCP as a protocol boundary for capabilities, and Agent Skills as a package boundary for procedures. The distinction helps the reader decide what is being shared, who owns authority, and what evidence is still missing.

A private function definition can work inside one application because the application already knows the tool, its schema, and the code that executes it. A shared ecosystem loses that implicit context. A client may discover a server at runtime. Different requests may carry different identities or capabilities. A host may know how to invoke a procedure but not be authorized to perform every operation the procedure describes. Interoperability therefore requires explicit lifecycle stages rather than ambient assumptions.

MCP makes a capability request self-describing

The repository’s MCP fundamentals lesson treats the protocol as a boundary around callable capabilities. Tools, resources, and prompts are not simply names placed into a model’s context. They are exposed through typed JSON-RPC interactions that a client can discover and invoke. The protocol carries the information needed to interpret the current request, route it, authorize it, and return either a typed result or an error.

The lesson’s current target is MCP revision 2026-07-28, a dated detail that belongs to this repository snapshot rather than to an eternal definition of MCP. In that model, the protocol core is stateless. A server should interpret a request from the metadata and arguments in that request, not from what an earlier request declared, what a particular process happens to remember, or what a transport connection implies.

This does not mean that an MCP-backed application has no state. It means protocol state is not hidden in a connection. If an operation needs continuity, the continuity must be represented explicitly—for example, through an opaque handle or a durable task record owned by the server. A later request can then present that reference and be checked under the current identity and policy. The distinction is important because process memory can outlive one user, one permission set, or one assumption about the client.

Consider two requests arriving at the same server. The first client may be allowed to read a resource; the second may be allowed to update one. If the server infers authority from the previous request or from the fact that both requests share a worker, it has confused transport continuity with authorization. A request-scoped protocol makes the boundary visible: parse the current envelope, inspect its declared metadata and arguments, apply current policy, invoke the matching handler, and return a result tied to the current request.

The repository’s focused MCP path turns this model into evidence requirements. A learner is expected to observe independent requests, discovery results, version failures, security checks, and conformance behavior. That is more informative than a single successful SDK call because it tests the transitions where interoperability actually breaks: version mismatch, inconsistent metadata, missing authority, malformed arguments, or a proxy that changes the wire shape.