Trace an MCP install from directory entry to running artefact

A directory result, a GitHub repository and an install command can all have similar names. They are not necessarily the same artefact. Before you add an MCP server to a client, write down the path between them.

For a local install, my review note would look like this:

Directory entry:       link and date checked
Publisher:             repository owner and package/image namespace
Install command:       command from the actual client configuration
Running artefact:      package version or image digest
Permissions:           directories, accounts and scopes granted
Review owner:          person who checks changes and can disconnect it

This is an operational note, not an MCP requirement or a security certificate. Start at a source you trust and follow its links to the package. Do not assume a package with a matching name was built from the repository linked by a directory card. The MCP Registry holds metadata and installation information, while package registries host the artefacts; its namespace verification ties a publisher to a GitHub account or domain, not to safe behaviour.

For a concrete branching point, GitHub's MCP server README documents a GitHub-hosted remote server and a local option that can run as a container or built binary. Those paths differ in who operates the service, what runs locally and how it changes. Read the configuration the client will actually load.

If you use an image, a tag can be repointed, whereas a digest identifies fixed image content. Pinning helps you reproduce the version reviewed; it does not prove the code is benign. Docker documentation For an npm package with provenance, inspect the recorded source commit and build workflow, and verify the attestation if that matters to the deployment. Provenance helps connect a published package to a build source, but still leaves questions about code and permissions. npm documentation

A remote server has no package installed on your machine to pin in the same way. Record its exact endpoint and operator, and review the scopes the client is asked to grant. If the endpoint or scopes change, repeat the decision.

Finally, inspect the tools exposed to your client using tools/list and compare them with the job. The MCP tools specification dated 28 July 2026 says tool annotations are untrusted unless they come from a trusted server. A readOnlyHint is not a test of an unknown server. Keep the tool list with your review note, and check again after an update or reconnect.

Kapyn's discovery work can be a starting point, not certification. I work with Rahul on Kapyn; the journal original explains the wider provenance decision.