Answer
How do I pin an MCP server version?
Pin an exact version or a commit hash, record the digest you reviewed, and require a new review when the pin changes. A tag that moves is not a pin.
What counts as pinned?
- npm:
@scope/server@1.4.2, not@scope/serverand not@latest. - Python:
package==1.4.2, not a range and not a bare name. - Container: an image digest,
image@sha256:..., not:latest. - Git: a full commit hash, not a branch. A branch is a moving target even when the URL looks stable.
Why does it matter for an agent?
Approval is a statement about a version. If the version can change after the review, the review describes something that no longer exists. The OWASP MCP guidance calls the change after approval a rug pull and recommends hashing the reviewed tool definition, including the schema and annotations, so a change is visible.
What should the manifest record?
The exact version, the digest where the registry provides one, the publisher, the page you checked and the date. The checker flags a missing pin as SC-02 and the missing publisher as SC-01, because a pin without a source is a version of something you still cannot name.
What about a remote server?
A remote server has a version too, even when it is not in the URL. Record the server version the publisher reports, the endpoint, and the date you checked it. If the publisher does not publish a version, say so in the manifest and treat the endpoint as unpinned.
Source note. The pinning guidance follows the OWASP MCP Security Cheat Sheet's rule on pinning reviewed tool definitions and the MCP security best practices page. All sources.