The file-allowlist rule in Integrity and verification applied "while
acting on a skill", but the SEP never said what that meant. Define it
as the span from loading the skill's SKILL.md into the model's context
until, at the earliest, that SKILL.md leaves context; hosts may keep
the window open longer, never shorter, and hold the entry they loaded
from for the whole of it.

Use the same term in the content-bound approval rule in Security
Implications, which previously said "while it holds the approved
entry" for the same window.

Regenerate the rendered SEP docs.

No-Verification-Needed: documentation-only change

…access

The SEP encourages hosts to cache skill content on disk but said
nothing about keeping that cache honest. Verification at fetch time
does not carry over to bytes that may have changed since, so a cache
writable by the model, by scripts it runs, or by other users would
bypass digest verification entirely.

Require hosts that cache on disk to either keep the cache where only
the host can write and never modify cached files in place, or
recompute the SHA-256 digest from the cached bytes on every access.
State explicitly that a stored digest label or modification time is
not verification.

Regenerate the rendered SEP docs.

No-Verification-Needed: documentation-only change

…rialized paths to encode it

The SEP said a skill is identified by its URI, which holds only within
one server: two connected servers may both serve
skill://refunds/SKILL.md, and those are unrelated skills. State that
the identity of an MCP-served skill is the pair of the host's identity
for the originating server and the skill URI, and that hosts must
preserve both halves in the registry, persisted approvals, the cache,
and any tool or path the model reaches the skill through.

Require any path at which a host materializes skill content, whether a
cache directory or a virtual mount, to encode the server identity as
well as the URI, so same-URI skills from different servers land at
distinct paths and the originating server is recoverable from the
path. Note in the host integration sketch that a virtual mount is one
root per server.

Regenerate the rendered SEP docs.

No-Verification-Needed: documentation-only change

resources/read is transport: it returns bytes to whoever asked, via a
generic resource tool, a resource browser, or a user inspecting the
server. Nothing said that such a read is not a skill load, which left
the verification, approval, and acting-on window bypassable by reading
the URI directly.

State in Reading that a skill is loaded only through the host's own
skill-loading path, that a SKILL.md read arriving by any other route
grants no approval, opens no window, and confers no standing on the
skill's supporting files, and that such content is ordinary resource
content. Note in the host integration sketch that read_skill is that
path and read_resource on the same URI is not.

Regenerate the rendered SEP docs.

No-Verification-Needed: documentation-only change

Add a paragraph to Rationale stating that a skills/list entry is
intentionally the complete manifest of a skill, verbatim frontmatter
plus the full resources set with digests, rather than a summary to be
completed by a follow-up call. One pass over the listing gives a host
everything it needs to build its registry, present the skill for
approval, bind the approval to content, and verify later reads, with
no second round-trip per skill.

skills/get exists only for what the listing does not serve: refreshing
one skill's entry without re-enumerating the catalog, and obtaining an
entry for a skill a partial listing omitted. It is never a step needed
to complete a listed entry.

Regenerate the rendered SEP docs.

No-Verification-Needed: documentation-only change

Directory Listing never mentioned the manifest a host already holds
for a skill with resources, nor what happens when a directory read
lists a child the manifest lacks. Add a subsection covering this:

- For a skill with a manifest, the entry already says what files
  exist; directory reading serves dynamic skills, non-skill trees, and
  a current server view without first refreshing the entry.
- A newly listed child is the stale-snapshot case Integrity and
  verification already governs. Under the held entry the host must not
  read it or surface it as a skill file; it refreshes with skills/get,
  which changes the resources set, revokes any persisted approval, and
  requires re-approval before the file is readable. Hosts should
  present this as a changed skill, not a read error.
- No shared version or cache token relates a directory result to an
  entry; the manifest is authoritative and a directory read must not
  be treated as extending it.
- For a dynamic skill without resources, directory reading discovers
  files but supplies no integrity.

Regenerate the rendered SEP docs.

No-Verification-Needed: documentation-only change

A skill with dynamically generated content previously signalled that by
omitting resources, which a host could not distinguish from a
malformed entry. Make resources required on every entry, taking either
the array of {uri, digest, size} triples or the string "dynamic".

An entry with no resources at all, or with any other value, is invalid
and must not be loaded. A "dynamic" skill keeps its existing standing:
no content integrity, no content-bound approval, and hosts may decline
it. Update every passage that referred to an omitted resources field.

Regenerate the rendered SEP docs.

No-Verification-Needed: documentation-only change