Extensions — 2026-07-28

The clauses of the official extensions attached to 2026-07-28 — 149 in all, 60 judged from a recorded trace and 89 excluded with the reason below. An extension is optional by definition, so its clauses never change a report’s verdict or exit status: a report lists them under extensions, each extension with a verdict of its own, the way the official suite runs an extension’s scenarios under not_scored: extension (ADR-0023). Each entry quotes the extension’s own specification and links to where its repository publishes it.

io.modelcontextprotocol/tasks

TASK-001

MUST NOT · binds the server

A server MUST NOT return CreateTaskResult to a client that did not include the extension capability on its request, regardless of prior declarations.

specification/2026-07-28/tasks#capability-negotiation

Judged by tasks.create-requires-declaration.

TASK-002

MUST · binds the client

A client that has negotiated this extension MUST be prepared to handle either CallToolResult or CreateTaskResult in response to any supported request it issues.

specification/2026-07-28/tasks#capability-negotiation

Excluded. Being prepared is a property of the client’s code. What a recording could show — a client that receives a CreateTaskResult and never polls the task — is also how a client conforms when its user abandons the call or the capture ends first, so the wire cannot tell an unprepared client from either.

TASK-003

MUST · binds the client

A client that receives CreateTaskResult in response to an unsupported request type MUST interpret this as an invalid response to the request.

specification/2026-07-28/tasks#capability-negotiation

Excluded. How a client interprets a response is internal: the protocol defines no message for rejecting an invalid response, so a client that treated the task result as invalid and one that accepted it can send exactly the same thing next.

TASK-004

MUST · binds the server

If a server is unable to service a request to a client that does not declare this extension capability without returning CreateTaskResult, the server MUST return an error with the code -32021 (Missing Required Client Capability), indicating the required extension in the error response

specification/2026-07-28/tasks#capability-negotiation

Excluded. Its antecedent — that the server cannot serve this request without creating a task — is the server’s own judgment, which no message states: a server that can serve the call answers it normally, so a non-declaring client’s call answered with a result conforms whichever way the server could have gone. The -32021 error itself, when sent, is the core clause BASE-035 judges (meta.missing-capability-error).

TASK-005

SHOULD · binds the client and server

This specification may be extended to support tasks over other request types in the future; implementations SHOULD be designed to accommodate additional request types in future revisions of this specification.

specification/2026-07-28/tasks#supported-methods

Excluded. A design property: what an implementation is ready to accept from a later revision is in its code, not in anything it sends today.

TASK-006

MUST · binds the server

Servers MUST set resultType to "task" when returning a CreateTaskResult so that clients can distinguish it from a standard result.

specification/2026-07-28/tasks#polymorphic-results

Judged by tasks.create-result-discriminator.

TASK-007

MUST NOT · binds the server

Servers MUST NOT set resultType to "task" on result types other than CreateTaskResult.

specification/2026-07-28/tasks#polymorphic-results

Judged by tasks.task-result-type-only-on-create.

TASK-008

MUST NOT · binds the server

failed: The request failed due to a JSON-RPC error during execution. The task will include the error field with the JSON-RPC error details. This status MUST NOT be used for non-JSON-RPC errors.

specification/2026-07-28/tasks#task-status

Judged by tasks.failed-not-tool-result.

TASK-009

MUST NOT · binds the server

A server MUST NOT return CreateTaskResult until the task is durably created — that is, until a tasks/get for the returned taskId would resolve.

specification/2026-07-28/tasks#task-creation

Excluded. Durable creation shows only as its failure — a tasks/get for the returned id that does not resolve — and that answer is also the conforming one once the task’s TTL has elapsed (the page: “It is compliant behavior for a server to return an error stating the task cannot be found if it has purged an expired task”). Telling the two apart needs the time between creation and poll, and checks never consult an event’s ts.

TASK-010

MUST · binds the server

In eventually-consistent environments, the server MUST wait for consistency before responding.

specification/2026-07-28/tasks#task-creation

Excluded. How the server’s storage reaches consistency is internal; its one observable consequence is TASK-009’s, excluded for the reason recorded there.

TASK-011

SHOULD · binds the server

Server implementations that use multi round-trip requests in conjunction with task creation (for example, a tool that requires elicitation over InputRequiredResult before creating a task) SHOULD resolve all MRTR exchanges synchronously before responding with a CreateTaskResult.

specification/2026-07-28/tasks#task-creation

Excluded. Every input-required round of the original request necessarily precedes the CreateTaskResult that ends it, so every recording of a server running such rounds shows them resolved first; how else the server could have resolved them is not a message.

TASK-012

SHOULD · binds the client

Clients SHOULD respect the pollIntervalMs provided in responses when determining polling frequency.

specification/2026-07-28/tasks#task-polling

Excluded. Polling frequency is the time between requests, and checks never consult an event’s ts: it is optional, informational, and stamped by the recorder’s clock rather than the client’s.

TASK-013

SHOULD · binds the client

Clients SHOULD continue polling until the task reaches a terminal status or until invoking tasks/cancel.

specification/2026-07-28/tasks#task-polling

Excluded. A recording ends when its capture stops: a task with no terminal status in the trace shows a capture that ended as often as a client that stopped, and nothing on the wire tells the two apart.

TASK-014

SHOULD · binds the client

Clients SHOULD persist task IDs to durable storage so that polling can resume after a crash or restart.

specification/2026-07-28/tasks#task-polling

Excluded. Durable storage is the client’s own, and it shows only across a crash or restart, which a recording of one session does not span.

TASK-015

MUST · binds the server

Upon receiving a tasks/get request, the server MUST check the status of the task and respond accordingly: If the status is working, the server MUST return a a Task object with status working.; If the status is input_required, the server MUST return a Task object with status input_required and an inputRequests field defined in Multi Round-Trip Requests.; If the status is completed, the server MUST return a Task object with status completed and a result field containing the final result of the task.; If the status is cancelled, the server MUST return a Task object with status cancelled.; If the status is failed, the server MUST return a Task object with status failed and the error that occurred during execution.

specification/2026-07-28/tasks#response

Judged by tasks.task-fields, tasks.input-required-carries-requests, tasks.completed-carries-result, tasks.failed-carries-error.

TASK-016

MUST · binds the server

The inputRequests field MUST contain all outstanding requests from the server to the client that need to be fulfilled before the task can proceed.

specification/2026-07-28/tasks#response

Excluded. Which requests are outstanding is the server’s own state: a tasks/get that lists fewer requests than the task is waiting on looks exactly like one that lists them all.

TASK-017

MUST · binds the server

The resultType field MUST be set to "complete" on this object as it is the standard result shape for the tasks/get request.

specification/2026-07-28/tasks#response

Judged by tasks.results-complete.

TASK-018

SHOULD · binds the client

When a client observes a tasks/get response (or notifications/tasks notification) with status: "input_required", the client SHOULD fulfill the outstanding requests in inputRequests by sending one or more tasks/update requests with corresponding inputResponses.

specification/2026-07-28/tasks#task-update-requests

Excluded. Fulfilling an input request needs its user or model to answer, and the recording may end before they do: an unanswered input_required task shows a capture that stopped as often as a client that did not respond.

TASK-019

SHOULD · binds the client

After sending a tasks/update, the client SHOULD continue observing the task’s status via polling (tasks/get) or notifications (notifications/tasks) until it reaches a terminal state.

specification/2026-07-28/tasks#task-update-requests

Excluded. A recording ends when its capture stops: a task with no terminal status in the trace shows a capture that ended as often as a client that stopped, and nothing on the wire tells the two apart.

TASK-020

MUST · binds the client

Clients MUST treat each entry in inputRequests as they would the equivalent standalone server-to-client request — for example, an elicitation request surfaced via inputRequests is subject to the same trust model and user-facing behavior as a direct elicitation/create request.

specification/2026-07-28/tasks#task-update-requests

Excluded. Binds how the host presents and trusts a request a task carries — consent and user interface, which strategy rule 2 keeps out: none of it is a message to the server.

TASK-021

SHOULD · binds the client

Clients SHOULD deduplicate inputRequests keys across consecutive polls to avoid presenting the same request to the user or model more than once.

specification/2026-07-28/tasks#task-update-requests

Excluded. Deduplication here is presentation: receiving the same key on the next poll is the documented snapshot behaviour, and whether the user saw the request twice is user interface. Answering one key twice, which a recording does show, is TASK-026.

TASK-022

MUST · binds the server

Each request key in inputRequests MUST be unique over the lifetime of a single task.

specification/2026-07-28/tasks#task-update-requests

Judged by tasks.input-request-keys-stable.

TASK-023

MUST NOT · binds the server

A server MUST NOT reuse a key for a subsequent server-to-client request after a response for that key has been delivered, and MUST NOT use the same key to refer to two distinct requests over a task’s lifetime.

specification/2026-07-28/tasks#task-update-requests

Judged by tasks.input-request-keys-stable.

TASK-024

MUST · binds the server

On success, the server MUST acknowledge the request with an empty result.

specification/2026-07-28/tasks#response-1

Judged by tasks.ack-empty.

TASK-025

SHOULD · binds the server

Servers SHOULD return a JSON-RPC error if the taskId does not correspond to a known task.

specification/2026-07-28/tasks#response-1

Excluded. Whether a taskId is known is the server’s own state: a task created before the recording began, or one already purged after its TTL (“It is compliant behavior for a server to return an error stating the task cannot be found if it has purged an expired task”), is indistinguishable in a trace from one that never existed, so no answer to an unfamiliar id convicts the server.

TASK-026

SHOULD · binds the client

Clients SHOULD track inputRequests keys to avoid responding to requests more than once.

specification/2026-07-28/tasks#response-1

Judged by tasks.update-answers-once.

TASK-027

SHOULD · binds the server

A server SHOULD ignore any inputResponses responses mapped to a key that is not currently outstanding for the task — including keys that were never issued, keys that have already been answered, and keys whose corresponding request has been superseded.

specification/2026-07-28/tasks#response-1

Excluded. Which keys are outstanding is the server’s own state (TASK-016), and an ignored response leaves no trace of having been ignored: the acknowledgement is the same either way.

TASK-028

MUST · binds the server

The resultType field MUST be set to "complete" on UpdateTaskResult as it is the standard result shape for the tasks/update request.

specification/2026-07-28/tasks#response-1

Judged by tasks.results-complete.

TASK-029

MUST NOT · binds the client

The notifications/cancelled notification MUST NOT be used for task cancellation.

specification/2026-07-28/tasks#task-cancellation

Judged by tasks.no-cancelled-notification.

TASK-030

MUST · binds the server

On success, the server MUST acknowledge the request with an empty result.

specification/2026-07-28/tasks#response-2

Judged by tasks.ack-empty.

TASK-031

SHOULD · binds the server

Servers SHOULD return a JSON-RPC error if the taskId does not correspond to a known task.

specification/2026-07-28/tasks#response-2

Excluded. Whether a taskId is known is the server’s own state: a task created before the recording began, or one already purged after its TTL (“It is compliant behavior for a server to return an error stating the task cannot be found if it has purged an expired task”), is indistinguishable in a trace from one that never existed, so no answer to an unfamiliar id convicts the server.

TASK-032

MUST · binds the server

The resultType field MUST be set to "complete" on CancelTaskResult as it is the standard result shape for the tasks/cancel request.

specification/2026-07-28/tasks#response-2

Judged by tasks.results-complete.

TASK-033

MUST · binds the server

If a client requests task status notifications but does not declare the io.modelcontextprotocol/tasks extension capability, the server MUST return a JSON-RPC error specifying the missing capabilities

specification/2026-07-28/tasks#task-status-notifications

Judged by tasks.listen-requires-declaration.

TASK-034

MUST NOT · binds the server

notifications/progress and notifications/message notifications MUST NOT be sent on the subscriptions/listen stream for a task, and are not supported on tasks in general in this specification.

specification/2026-07-28/tasks#task-status-notifications

Judged by tasks.no-progress-on-task-stream.

TASK-035

MUST · binds the client

When tasks/get, tasks/update, or tasks/cancel is sent over the Streamable HTTP transport, the client MUST set the Mcp-Name header to the value of params.taskId.

specification/2026-07-28/tasks#streamable-http-routing-headers

Judged by tasks.mcp-name-header.

TASK-036

MUST · binds the server

Servers MUST return standard JSON-RPC errors for the following protocol error cases: Invalid or nonexistent taskId: -32602 (Invalid params); Servers MUST return this error for tasks/get.

specification/2026-07-28/tasks#protocol-errors

Excluded. Whether a taskId is known is the server’s own state: a task created before the recording began, or one already purged after its TTL (“It is compliant behavior for a server to return an error stating the task cannot be found if it has purged an expired task”), is indistinguishable in a trace from one that never existed, so no answer to an unfamiliar id convicts the server.

TASK-037

SHOULD · binds the server

Servers SHOULD return this error for tasks/update and tasks/cancel.

specification/2026-07-28/tasks#protocol-errors

Excluded. Whether a taskId is known is the server’s own state: a task created before the recording began, or one already purged after its TTL (“It is compliant behavior for a server to return an error stating the task cannot be found if it has purged an expired task”), is indistinguishable in a trace from one that never existed, so no answer to an unfamiliar id convicts the server.

TASK-038

MUST · binds the server

Missing required client capabilities: -32021 (Missing Required Client Capability); Servers MUST return this error for non-declaring clients requesting task notifications on subscriptions/listen.

specification/2026-07-28/tasks#protocol-errors

Judged by tasks.listen-requires-declaration.

TASK-039

MUST · binds the server

Servers MUST return this error for non-declaring clients issuing tasks/get, tasks/update, and tasks/cancel requests.

specification/2026-07-28/tasks#protocol-errors

Judged by tasks.methods-require-declaration.

TASK-040

SHOULD · binds the server

Servers SHOULD provide informative error messages to describe the cause of errors.

specification/2026-07-28/tasks#protocol-errors

Excluded. Informativeness is a judgment about prose; any non-empty message passes a mechanical test of it, so a check would only ever restate the core clause that error messages exist.

TASK-041

SHOULD · binds the server

The tasks/get response SHOULD include a statusMessage field with diagnostic information about the failure

specification/2026-07-28/tasks#task-execution-errors

Judged by tasks.failed-status-message.

TASK-042

MUST · binds the server

and MUST include the error field with the JSON-RPC error.

specification/2026-07-28/tasks#task-execution-errors

Judged by tasks.failed-carries-error.

TASK-043

MUST NOT · binds the server

The failed status MUST NOT be used to represent non-JSON-RPC errors, such as a tool result that completed with isError: true.

specification/2026-07-28/tasks#task-execution-errors

Judged by tasks.failed-not-tool-result.

TASK-044

MUST · binds the server

Errors within the context of a protocol method result MUST use the completed status with the error details in the result field.

specification/2026-07-28/tasks#task-execution-errors

Judged by tasks.failed-not-tool-result, tasks.completed-carries-result.

TASK-045

MUST · binds the server

If the underlying request resulted in a JSON-RPC error, the task uses failed status and the error field MUST contain that JSON-RPC error.

specification/2026-07-28/tasks#task-execution-errors

Judged by tasks.failed-carries-error.

TASK-046

MUST · binds the server

If the request completed with a result (even if isError: true for tool results), the task uses completed status and the result field MUST contain that result.

specification/2026-07-28/tasks#task-execution-errors

Judged by tasks.completed-carries-result.

TASK-047

MUST · binds the server

Servers MUST generate them with sufficient entropy that a third party cannot enumerate or guess them.

specification/2026-07-28/tasks#security-considerations

Excluded. Entropy is a property of the generator, not of one identifier: a recording holds a handful of ids, and an unguessable one and a predictable one can be spelled alike.

TASK-048

MUST · binds the server

Servers MUST perform authentication and authorization checks on each task-related request to ensure that the client has permission to access a task.

specification/2026-07-28/tasks#security-considerations

Excluded. Authorization is decided inside the server against a credential no recording carries: Authorization is never recorded (ADR-0022, fact 1).

TASK-049

MUST · binds the client

Hosts MUST apply the same trust model to these payloads as they would to standard elicitation/sampling requests.

specification/2026-07-28/tasks#security-considerations

Excluded. Binds how the host presents and trusts a request a task carries — consent and user interface, which strategy rule 2 keeps out: none of it is a message to the server.

io.modelcontextprotocol/skills

SKILL-001

MUST · binds the client

Every request MUST include the required request metadata in params._meta.

specification/stable/skills.mdx

Excluded. Restates the core rule the revision’s own registry judges on every request (BASE-030, meta.required-request-fields). Judged there once, it is not judged again here, where a request missing its metadata would read as a skills defect in a session that never touched the extension.

SKILL-002

MUST · binds the server

A server that declares this extension MUST implement skills/list and skills/get.

specification/stable/skills.mdx

Judged by skills.list-implemented, skills.get-implemented.

SKILL-003

MUST · binds the server

A server that additionally declares directoryRead: true MUST implement resources/directory/read.

specification/stable/skills.mdx

Judged by skills.directory-read-implemented.

SKILL-004

MUST NOT · binds the client

Clients MUST NOT call resources/directory/read against a server that has not declared directoryRead: true.

specification/stable/skills.mdx

Judged by skills.directory-read-declared.

SKILL-005

MUST · binds the server

A server declaring this extension therefore MUST also declare the resources capability.

specification/stable/skills.mdx

Judged by skills.declares-resources.

SKILL-006

MUST · binds the server

A skill served over MCP MUST conform to the Agent Skills specification.

specification/stable/skills.mdx

Excluded. The umbrella over the format rules this page goes on to state: those it states with their own keyword are entered and judged one by one (SKILL-007, SKILL-008, SKILL-013). The rest of the Agent Skills specification is another document, outside this registry’s page set.

SKILL-007

MUST · binds the server

Every skill MUST contain a SKILL.md file at its root.

specification/stable/skills.mdx

Judged by skills.entry-uri-is-skill-md.

SKILL-008

MUST · binds the server

SKILL.md MUST begin with YAML frontmatter containing at minimum the name and description fields as defined by the Agent Skills specification.

specification/stable/skills.mdx

Judged by skills.skill-md-frontmatter.

SKILL-009

MUST · binds the client

In the event that the Agent Skills specification changes in a backwards incompatible way, clients MUST honor any backwards compatibility mechanisms provided by the Agent Skills specification

specification/stable/skills.mdx

Excluded. Binds a client’s response to a future incompatible revision of another specification; no such revision exists, and what a client honours of one is in its code, not in what it sends.

SKILL-010

SHOULD · binds the client

and SHOULD continue to support the Agent Skills specification as it existed prior to any incompatible change.

specification/stable/skills.mdx

Excluded. As SKILL-009: support for a format revision is a property of client code.

SKILL-011

SHOULD · binds the server

Servers SHOULD use the skill:// URI scheme

specification/stable/skills.mdx

Judged by skills.skill-scheme.

SKILL-012

MUST · binds the server

The final segment of <skill-path> MUST equal the skill’s name as declared in its SKILL.md frontmatter.

specification/stable/skills.mdx

Judged by skills.final-segment-is-name.

SKILL-013

MUST · binds the server

The final segment, being the skill name, MUST satisfy the Agent Skills specification’s naming rules.

specification/stable/skills.mdx

Judged by skills.name-follows-naming-rules.

SKILL-014

SHOULD · binds the server

The first segment occupies the URI authority component and SHOULD be a valid reg-name per RFC 3986.

specification/stable/skills.mdx

Judged by skills.authority-reg-name.

SKILL-015

SHOULD · binds the server

Any other prefix segments SHOULD be valid URI path segments.

specification/stable/skills.mdx

Judged by skills.prefix-segments.

SKILL-016

MUST NOT · binds the client

The authority component carries no special semantics under this extension, and clients MUST NOT attempt DNS or network resolution of it.

specification/stable/skills.mdx

Excluded. Name resolution happens off the MCP connection: a recording of the session carries none of the client’s DNS queries or other network traffic.

SKILL-017

MUST NOT · binds the client

A host MUST NOT conclude that a resource is a skill merely because its URI carries a particular scheme.

specification/stable/skills.mdx

Excluded. What a host concludes about a resource is internal. The only act on the wire it could lead to — reading the resource — is permitted whether or not the host takes it for a skill (the page: reading is transport, not a load).

SKILL-018

SHOULD · binds the server

mimeType SHOULD be text/markdown.

specification/stable/skills.mdx

Judged by skills.skill-md-mime-type.

SKILL-019

SHOULD · binds the server

name SHOULD be set from the name field of the SKILL.md YAML frontmatter.

specification/stable/skills.mdx

Judged by skills.skill-md-resource-name.

SKILL-020

SHOULD · binds the server

description SHOULD be set from the description field of the SKILL.md YAML frontmatter.

specification/stable/skills.mdx

Judged by skills.skill-md-resource-description.

SKILL-021

SHOULD · binds the client and server

When _meta keys are used for skill resources, implementations SHOULD use the io.modelcontextprotocol.skills/ reverse-domain prefix.

specification/stable/skills.mdx

Excluded. Binds the keys that expose frontmatter fields, and nothing on the wire says which _meta keys do: a key under another prefix on a skill resource may carry any other metadata, which the base protocol permits.

SKILL-022

MUST NOT · binds the client

A nested SKILL.md read this way is ordinary markdown, and hosts MUST NOT act on its frontmatter.

specification/stable/skills.mdx

Excluded. Binds what the host lets the model execute and which permissions it grants, decided inside the host; a tool the model then runs on the host is not an MCP message to this server.

SKILL-023

MUST · binds the client

Hosts MUST preserve both halves wherever a skill is recorded or addressed, including the registry, persisted approvals, the cache, and any tool or path through which the model reaches the skill.

specification/stable/skills.mdx

Excluded. Binds the host’s own records — its skill registry, persisted approvals and cache — which never cross the MCP connection; and a recording holds one session with one server, so the server identity that would tell two same-URI skills apart is never in question within it.

SKILL-024

MUST NOT · binds the client

Hosts MUST NOT key any of these on the uri alone.

specification/stable/skills.mdx

Excluded. Binds the host’s own records — its skill registry, persisted approvals and cache — which never cross the MCP connection; and a recording holds one session with one server, so the server identity that would tell two same-URI skills apart is never in question within it.

SKILL-025

MUST · binds the client

Any path at which a host materializes skill content, whether a cache directory or a virtual mount, MUST encode the server identity as well as the uri, so that same-URI skills from different servers land at distinct paths and the originating server is recoverable from the path.

specification/stable/skills.mdx

Excluded. Binds the host’s own records — its skill registry, persisted approvals and cache — which never cross the MCP connection; and a recording holds one session with one server, so the server identity that would tell two same-URI skills apart is never in question within it.

SKILL-026

MUST · binds the server

The frontmatter object MUST be identical in content to the frontmatter of the SKILL.md it describes.

specification/stable/skills.mdx

Judged by skills.frontmatter-identical.

SKILL-027

MUST · binds the server

The final <skill-path> segment of the entry’s uri MUST equal frontmatter.name, per Resource Mapping.

specification/stable/skills.mdx

Judged by skills.final-segment-is-name.

SKILL-028

SHOULD · binds the client and server

Implementations SHOULD ignore keys under this prefix that they do not recognize.

specification/stable/skills.mdx

Excluded. Ignoring a metadata key leaves nothing on the wire.

SKILL-029

SHOULD · binds the server

Within a server’s listing, names SHOULD be unique, but they are not guaranteed to be.

specification/stable/skills.mdx

Judged by skills.listing-names-unique.

SKILL-030

MUST NOT · binds the client

Hosts MUST NOT assume name uniqueness.

specification/stable/skills.mdx

Excluded. Binds how the host resolves skill names against other servers and its own filesystem skills: a recording holds one session with one server and none of the host’s other origins, and name resolution produces no message.

SKILL-031

MUST · binds the client

When two entries in one listing collide on name, hosts MUST disambiguate them (for example by their distinguishing path segments) rather than silently discarding or preferring one.

specification/stable/skills.mdx

Excluded. Binds how the host resolves skill names against other servers and its own filesystem skills: a recording holds one session with one server and none of the host’s other origins, and name resolution produces no message.

SKILL-032

MUST · binds the client

When skills from different origins collide on name, hosts MUST resolve the name within a per-origin namespace, identifying servers by a host-assigned label.

specification/stable/skills.mdx

Excluded. Binds how the host resolves skill names against other servers and its own filesystem skills: a recording holds one session with one server and none of the host’s other origins, and name resolution produces no message.

SKILL-033

MUST NOT · binds the client

An MCP-served skill MUST NOT silently shadow, or be silently substituted for, a same-named skill from any other origin, whether another server or the host’s own filesystem skills.

specification/stable/skills.mdx

Excluded. Binds how the host resolves skill names against other servers and its own filesystem skills: a recording holds one session with one server and none of the host’s other origins, and name resolution produces no message.

SKILL-034

MUST · binds the server

resources is REQUIRED on every skill entry and takes one of two forms: an array of SkillResource objects enumerating the skill’s files (SKILL.md and every supporting file), or the string "dynamic".

specification/stable/skills.mdx

Judged by skills.entry-resources-form.

SKILL-035

MUST · binds the server

When resources is an array, it MUST be complete. It lists every file of the skill, each exactly once, including an entry whose uri equals the skill’s top-level uri.

specification/stable/skills.mdx

Judged by skills.manifest-lists-skill-md.

SKILL-036

MUST · binds the server

Each uri MUST be the skill’s SKILL.md or a file within the skill’s directory.

specification/stable/skills.mdx

Judged by skills.manifest-within-skill.

SKILL-037

MUST · binds the server

Each entry MUST carry size, the length in bytes of the file’s raw content (the same bytes the digest covers).

specification/stable/skills.mdx

Judged by skills.manifest-entry-size.

SKILL-038

MUST · binds the server

When a skill’s content is generated dynamically, such that stable digests cannot be published, the server MUST set resources to the string "dynamic" instead of an array.

specification/stable/skills.mdx

Excluded. Its antecedent — content generated so that stable digests cannot be published — is the server’s own knowledge. An array of digests and the string "dynamic" are both valid forms, and SKILL-034 judges that one of them is present.

SKILL-039

MUST NOT · binds the client

An entry with no resources at all, or with any value other than an array or "dynamic", is invalid, and hosts MUST NOT load it.

specification/stable/skills.mdx

Excluded. Loading is the host placing content in the model’s context, which no message marks: a resources/read of the skill’s SKILL.md is transport, not a load (the page says so), so a read after an invalid entry convicts nothing. The server’s half — an entry without a valid resources — is SKILL-034.

SKILL-040

SHOULD · binds the server

Hosts MAY decline to load such skills, and server authors SHOULD expect that some hosts will.

specification/stable/skills.mdx

Excluded. An expectation held by a server’s author is not behaviour.

SKILL-041

MUST · binds the client

Hosts MUST support skills up to and including these limits

specification/stable/skills.mdx

Excluded. The capacity of the host: a recording shows what was served and read, not what the host could have accepted.

SKILL-042

SHOULD NOT · binds the server

Servers SHOULD NOT serve a skill that exceeds either limit.

specification/stable/skills.mdx

Judged by skills.within-limits.

SKILL-043

SHOULD · binds the client

A host that declines a skill on this basis SHOULD tell the user why rather than fail silently on a later read.

specification/stable/skills.mdx

Excluded. Binds what the host shows its user, which strategy rule 2 keeps out: none of it is a message.

SKILL-044

MUST · binds the server

A server declaring this extension MUST implement the skills/list method, which returns entries for the skills it serves.

specification/stable/skills.mdx

Judged by skills.list-implemented.

SKILL-045

MUST · binds the server

The resultType field MUST be set to "complete" on ListSkillsResult, as it is the standard result shape for the skills/list request.

specification/stable/skills.mdx

Judged by skills.list-result-complete.

SKILL-046

MUST NOT · binds the client

Hosts MUST NOT treat an empty or partial listing as proof that a server has no skills, and MUST support loading a skill given only its URI

specification/stable/skills.mdx

Excluded. How a host reasons from a listing, and whether it can load a skill by URI alone, are host capabilities; a session in which it never does either is conforming, and one in which it does looks like any skills/get.

SKILL-047

MUST · binds the server

ListSkillsResult extends CacheableResult, so ttlMs and cacheScope are REQUIRED, as they are on tools/list and resources/list, and carry the same semantics.

specification/stable/skills.mdx

Judged by skills.list-cacheable.

SKILL-048

MUST · binds the server

A server declaring this extension MUST implement the skills/get method, which returns the entry for a single skill named by the URI of its SKILL.md.

specification/stable/skills.mdx

Judged by skills.get-implemented.

SKILL-049

MUST · binds the server

The resultType field MUST be set to "complete" on GetSkillResult, as it is the standard result shape for the skills/get request.

specification/stable/skills.mdx

Judged by skills.get-result-complete.

SKILL-050

MUST · binds the client

params.uri MUST be the URI of a skill’s SKILL.md.

specification/stable/skills.mdx

Judged by skills.get-uri-names-skill-md.

SKILL-051

MUST · binds the server

If the URI does not identify a skill the server serves, the server MUST return error -32602 (Invalid params), the same code resources/read uses for unknown resources.

specification/stable/skills.mdx

Judged by skills.get-unknown-invalid-params.

SKILL-052

MUST · binds the server

A server MUST answer for every skill it serves, whether or not that skill appears in its skills/list result.

specification/stable/skills.mdx

Excluded. What a server serves is its own state at the moment of the call: a skill listed earlier and refused later may have been withdrawn in between, which the page allows (an entry is a point-in-time snapshot), so a refusal convicts nothing.

SKILL-053

MUST · binds the server

GetSkillResult extends CacheableResult, so ttlMs and cacheScope are REQUIRED, as they are on resources/read, and carry the same semantics.

specification/stable/skills.mdx

Judged by skills.get-cacheable.

SKILL-054

MUST NOT · binds the client

Hosts MUST NOT treat a resources/read of a SKILL.md that arrives by any other route as a load.

specification/stable/skills.mdx

Excluded. Whether a host treats a read as a load is internal: the page itself says a read is transport and a load is the host placing content in the model’s context, which no message marks.

SKILL-055

SHOULD · binds the client

Content obtained that way is ordinary resource content, and a host that returns it to the model SHOULD do so as it would any other resource read, not as a loaded skill.

specification/stable/skills.mdx

Excluded. Binds how the host treats skill content inside the model’s context — its trust, its provenance tags, its authority, how it is presented — which strategy rule 2 keeps out: none of it is a message to the server.

SKILL-056

MUST · binds the client

When a host retrieves a file listed in a skill’s resources, it MUST verify the content against that entry’s digest and size.

specification/stable/skills.mdx

Excluded. Verification runs inside the host: comparing bytes against a digest, a size or the entry’s frontmatter produces no message, and the page itself says its only wire trace is the skills/get or skills/list refresh after a failure, which looks like any other call.

SKILL-057

MUST NOT · binds the client

In all cases, hosts MUST NOT use the unverified content.

specification/stable/skills.mdx

Excluded. Verification runs inside the host: comparing bytes against a digest, a size or the entry’s frontmatter produces no message, and the page itself says its only wire trace is the skills/get or skills/list refresh after a failure, which looks like any other call.

SKILL-058

MUST · binds the client

While acting on a skill, a host MUST resolve reads of the skill’s files only to URIs listed in the held entry’s resources.

specification/stable/skills.mdx

Excluded. Binds reads made while the host is acting on a skill, and the acting window is host state: the same resources/read is permitted outside it (a generic resource read, a resource browser), and nothing on the wire marks which one a read was.

SKILL-059

MUST · binds the client

A host MUST treat a read of an unlisted file within the skill as a verification failure equivalent to a digest mismatch.

specification/stable/skills.mdx

Excluded. Verification runs inside the host: comparing bytes against a digest, a size or the entry’s frontmatter produces no message, and the page itself says its only wire trace is the skills/get or skills/list refresh after a failure, which looks like any other call.

SKILL-060

MUST · binds the client

After fetching a SKILL.md for which the host holds an entry (digest-verified when the entry’s resources is an array, unverifiable when it is "dynamic"), hosts MUST parse its YAML frontmatter and compare it field-by-field against the entry’s frontmatter.

specification/stable/skills.mdx

Excluded. Verification runs inside the host: comparing bytes against a digest, a size or the entry’s frontmatter produces no message, and the page itself says its only wire trace is the skills/get or skills/list refresh after a failure, which looks like any other call.

SKILL-061

MUST · binds the client

Any discrepancy MUST be treated as a verification failure equivalent to a digest mismatch, and the skill MUST NOT be loaded.

specification/stable/skills.mdx

Excluded. Verification runs inside the host: comparing bytes against a digest, a size or the entry’s frontmatter produces no message, and the page itself says its only wire trace is the skills/get or skills/list refresh after a failure, which looks like any other call.

SKILL-062

MUST NOT · binds the client

Hosts MUST NOT retrieve a skill’s files ahead of need, whether on connection, on listing, or at approval.

specification/stable/skills.mdx

Excluded. Need is the model’s or the user’s request to load or read, which no recording carries: a read right after a listing is prefetching or a load the user asked for, and the wire is the same. The official suite judges this clause in a scripted scenario in which nothing asked for a load (sep-2640-client-no-prefetch), which a recording of an ordinary session cannot reproduce.

SKILL-063

SHOULD · binds the client

Hosts SHOULD cache what they do retrieve.

specification/stable/skills.mdx

Excluded. Binds the host’s disk cache — where it lives, who may write it, how its bytes are checked and when they are removed — none of which crosses the MCP connection.

SKILL-064

MUST NOT · binds the client

Hosts MUST NOT treat a digest match as a security boundary.

specification/stable/skills.mdx

Excluded. A security policy inside the host; trusting or distrusting content produces no message.

SKILL-065

MUST · binds the server

The resultType field MUST be set to "complete" on ReadResourceDirectoryResult, as it is the standard result shape for the resources/directory/read request.

specification/stable/skills.mdx

Judged by skills.directory-result-complete.

SKILL-066

MUST · binds the server

If the URI does not exist, or exists but is not a directory resource, the server MUST return error -32602 (Invalid params).

specification/stable/skills.mdx

Judged by skills.directory-read-invalid-params.

SKILL-100

MUST · binds the server

ReadResourceDirectoryResult extends CacheableResult, so ttlMs and cacheScope are REQUIRED, as they are on resources/list, and carry the same semantics.

specification/stable/skills.mdx

Judged by skills.directory-cacheable.

SKILL-067

MUST · binds the server

A server that declares directoryRead MUST support the method for every directory within the skill namespaces it serves as individual files.

specification/stable/skills.mdx

Judged by skills.directory-read-every-directory.

SKILL-068

MUST NOT · binds the client

While acting on the skill under the held entry, the host MUST NOT read the newly listed child (an unlisted file is a verification failure) and MUST NOT surface it to the model as a file of the skill.

specification/stable/skills.mdx

Excluded. Binds reads made while the host is acting on a skill, and the acting window is host state: the same resources/read is permitted outside it (a generic resource read, a resource browser), and nothing on the wire marks which one a read was.

SKILL-069

SHOULD · binds the client

Hosts SHOULD present this sequence as a skill that has changed and needs re-approval, rather than as a read error.

specification/stable/skills.mdx

Excluded. Binds what the host shows its user, which strategy rule 2 keeps out: none of it is a message.

SKILL-070

MUST NOT · binds the client

Hosts MUST NOT treat the directory result as extending the manifest.

specification/stable/skills.mdx

Excluded. Binds reads made while the host is acting on a skill, and the acting window is host state: the same resources/read is permitted outside it (a generic resource read, a resource browser), and nothing on the wire marks which one a read was.

SKILL-071

MUST · binds the server

Servers MUST return standard JSON-RPC errors for the following protocol error cases: skills/get with a uri that does not identify a skill the server serves: -32602 (Invalid params).; resources/directory/read with a uri that does not exist or is not a directory resource: -32602 (Invalid params).; resources/read of a skill file the server does not serve: -32602 (Invalid params), per the base Resources specification.; Internal errors: -32603 (Internal error).

specification/stable/skills.mdx

Judged by skills.get-unknown-invalid-params, skills.directory-read-invalid-params.

SKILL-072

SHOULD · binds the server

Servers SHOULD provide informative error messages to describe the cause of errors.

specification/stable/skills.mdx

Excluded. Informativeness is a judgment about prose; any non-empty message passes a mechanical test of it.

SKILL-073

MUST · binds the client

Hosts MUST treat MCP-served skill content as untrusted model input, subject to the same prompt-injection defenses applied to any server-provided text.

specification/stable/skills.mdx

Excluded. Binds how the host treats skill content inside the model’s context — its trust, its provenance tags, its authority, how it is presented — which strategy rule 2 keeps out: none of it is a message to the server.

SKILL-074

MUST · binds the client

Hosts MUST treat MCP-served skills as a higher-risk surface than remote tool invocation.

specification/stable/skills.mdx

Excluded. Binds how the host treats skill content inside the model’s context — its trust, its provenance tags, its authority, how it is presented — which strategy rule 2 keeps out: none of it is a message to the server.

SKILL-075

MUST · binds the client

Hosts MUST tag MCP-served skill content with its originating server identity at the point it enters model context.

specification/stable/skills.mdx

Excluded. Binds how the host treats skill content inside the model’s context — its trust, its provenance tags, its authority, how it is presented — which strategy rule 2 keeps out: none of it is a message to the server.

SKILL-076

MUST NOT · binds the client

Hosts MUST NOT present an MCP-served skill to the model as indistinguishable from a local filesystem skill.

specification/stable/skills.mdx

Excluded. Binds how the host treats skill content inside the model’s context — its trust, its provenance tags, its authority, how it is presented — which strategy rule 2 keeps out: none of it is a message to the server.

SKILL-077

MUST NOT · binds the client

Hosts MUST NOT allow MCP-served skill content to cause host-side code execution without explicit per-skill user approval.

specification/stable/skills.mdx

Excluded. Binds what the host lets the model execute and which permissions it grants, decided inside the host; a tool the model then runs on the host is not an MCP message to this server.

SKILL-078

MUST · binds the client

Hosts MUST ignore or approval-gate (a).

specification/stable/skills.mdx

Excluded. Binds what the host lets the model execute and which permissions it grants, decided inside the host; a tool the model then runs on the host is not an MCP message to this server.

SKILL-079

MUST · binds the client

Hosts MUST apply the same approval gate to code-execution tool calls issued while the model is acting on an MCP-served skill.

specification/stable/skills.mdx

Excluded. Binds what the host lets the model execute and which permissions it grants, decided inside the host; a tool the model then runs on the host is not an MCP message to this server.

SKILL-080

MUST · binds the client

Hosts MUST bind such reads to the skill’s originating server.

specification/stable/skills.mdx

Excluded. Concerns reads across two servers, or the labels the host gives them: a recording holds one session with one server, so neither the second server nor the host’s labels are in it.

SKILL-081

MUST NOT · binds the client

A skill served by server A MUST NOT cause a resources/read against server B.

specification/stable/skills.mdx

Excluded. Concerns reads across two servers, or the labels the host gives them: a recording holds one session with one server, so neither the second server nor the host’s labels are in it.

SKILL-082

MUST · binds the client

Hosts MUST identify servers by a host-assigned label, not the server’s self-reported serverInfo.name.

specification/stable/skills.mdx

Excluded. Concerns reads across two servers, or the labels the host gives them: a recording holds one session with one server, so neither the second server nor the host’s labels are in it.

SKILL-083

MUST · binds the client

Any cross-origin read MUST be gated behind explicit per-call user approval naming both servers.

specification/stable/skills.mdx

Excluded. Concerns reads across two servers, or the labels the host gives them: a recording holds one session with one server, so neither the second server nor the host’s labels are in it.

SKILL-084

MUST · binds the client

Hosts MUST resolve skill names within a per-origin namespace, identifying servers by a host-assigned label.

specification/stable/skills.mdx

Excluded. Binds how the host resolves skill names against other servers and its own filesystem skills: a recording holds one session with one server and none of the host’s other origins, and name resolution produces no message.

SKILL-085

MUST NOT · binds the client

Hosts MUST NOT let an MCP-served skill silently shadow, replace, or intercept invocations of a same-named skill from any other origin, including the host’s filesystem skills.

specification/stable/skills.mdx

Excluded. Binds how the host resolves skill names against other servers and its own filesystem skills: a recording holds one session with one server and none of the host’s other origins, and name resolution produces no message.

SKILL-086

SHOULD · binds the client

Hosts SHOULD surface collisions to the user.

specification/stable/skills.mdx

Excluded. Binds what the host shows its user, which strategy rule 2 keeps out: none of it is a message.

SKILL-087

MUST NOT · binds the client

Hosts MUST NOT honor frontmatter fields that widen the model’s tool or filesystem permissions when the skill arrives over MCP.

specification/stable/skills.mdx

Excluded. Binds what the host lets the model execute and which permissions it grants, decided inside the host; a tool the model then runs on the host is not an MCP message to this server.

SKILL-088

MUST · binds the client

In particular, the Agent Skills allowed-tools field MUST be ignored for MCP-origin skills unless the user has explicitly approved that grant for that skill.

specification/stable/skills.mdx

Excluded. Binds what the host lets the model execute and which permissions it grants, decided inside the host; a tool the model then runs on the host is not an MCP message to this server.

SKILL-089

MUST NOT · binds the client

Hosts MUST NOT treat skill resources as higher-authority than other context.

specification/stable/skills.mdx

Excluded. Binds how the host treats skill content inside the model’s context — its trust, its provenance tags, its authority, how it is presented — which strategy rule 2 keeps out: none of it is a message to the server.

SKILL-090

SHOULD · binds the client

Hosts SHOULD indicate which server a skill originates from when presenting it.

specification/stable/skills.mdx

Excluded. Binds what the host shows its user, which strategy rule 2 keeps out: none of it is a message.

SKILL-091

SHOULD · binds the client

Hosts SHOULD let users inspect a skill’s content before it is loaded into model context.

specification/stable/skills.mdx

Excluded. Binds what the host shows its user, which strategy rule 2 keeps out: none of it is a message.

SKILL-092

MUST · binds the client

When a host persists any per-skill user approval, it MUST be bound to the entry’s resources set (every uri and digest) observed at the moment of approval.

specification/stable/skills.mdx

Excluded. Approval, its persistence and its revocation are host state and user interaction; a re-prompt is not a message, so a recording cannot tell a host that revoked an approval from one that never had one.

SKILL-093

MUST · binds the client

If a subsequent entry for that skill, from skills/list or skills/get, advertises a different set, whether a file was rotated, added, or removed, the host MUST treat the prior approval as revoked and re-prompt before loading or executing.

specification/stable/skills.mdx

Excluded. Approval, its persistence and its revocation are host state and user interaction; a re-prompt is not a message, so a recording cannot tell a host that revoked an approval from one that never had one.

SKILL-094

MUST NOT · binds the client

Hosts MAY decline to load it, and MUST NOT treat a persisted approval as covering whatever content the server currently serves.

specification/stable/skills.mdx

Excluded. Approval, its persistence and its revocation are host state and user interaction; a re-prompt is not a message, so a recording cannot tell a host that revoked an approval from one that never had one.

SKILL-095

SHOULD · binds the client

Hosts SHOULD cache verified skill content locally, populated on demand as files are read rather than in bulk.

specification/stable/skills.mdx

Excluded. Binds the host’s disk cache — where it lives, who may write it, how its bytes are checked and when they are removed — none of which crosses the MCP connection.

SKILL-096

MUST · binds the client

Hosts that cache skill content on disk MUST do one of the following for every file served from the cache.

specification/stable/skills.mdx

Excluded. Binds the host’s disk cache — where it lives, who may write it, how its bytes are checked and when they are removed — none of which crosses the MCP connection.

SKILL-097

MUST · binds the client

Hosts that cache MCP-served skill content on disk MUST do so in a location excluded from every filesystem-skill discovery path.

specification/stable/skills.mdx

Excluded. Binds the host’s disk cache — where it lives, who may write it, how its bytes are checked and when they are removed — none of which crosses the MCP connection.

SKILL-098

MUST · binds the client

Hosts MUST treat content loaded from that location as having arrived over MCP for all purposes of the no-implicit-local-execution rule above, including after host restart and after the originating server is disconnected.

specification/stable/skills.mdx

Excluded. Binds the host’s disk cache — where it lives, who may write it, how its bytes are checked and when they are removed — none of which crosses the MCP connection.

SKILL-099

SHOULD · binds the client

Hosts SHOULD remove a server’s cached skill content when the user removes that server.

specification/stable/skills.mdx

Excluded. Binds the host’s disk cache — where it lives, who may write it, how its bytes are checked and when they are removed — none of which crosses the MCP connection.