mcp-pin
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| mcp_pin_server_statusA | Look up a public MCP server in the signed public log kept by mcp-pin, to see whether its tool definitions have changed and when. Use it before installing or approving an MCP server, or when the user asks if a server changed. Input: query, an npm package name (for example @modelcontextprotocol/server-filesystem) or part of one. Returns up to 5 matching servers, exact name first: name, registry, tool count, first seen date, last change date with the earliest day it could have happened, last successful check, and a link to the full history. Only names, dates and counts are returned, never tool descriptions. An unchanged server is not proof of safety: a server can be hostile from its first version. |
| mcp_pin_my_serversA | List the MCP servers mcp-pin protects on this machine and whether any of them has a change waiting for review. Use it when the user asks which servers are pinned, or after mcp-pin blocked a server. No input. Returns, per server: id, label, tool and prompt counts, the date it was approved, and pending (true when a change is waiting). It never returns definitions or changed text. For a pending change, call mcp_pin_change_summary with its id, then ask the user to run "mcp-pin review " in a terminal to read the diff. |
| mcp_pin_change_summaryA | Explain what kind of change mcp-pin blocked on one pinned server, without the changed text. Use it after mcp_pin_my_servers shows pending: true, to tell the user what they are about to review. Input: id, the 16-character server id from mcp_pin_my_servers. Returns one entry per changed tool, prompt or instruction block with label keys: new-tool, new-prompt, new-field, new-argument, instruction, secrets, link, hidden, hints, field-type, output-schema, field-removed, removed, wording. Approving is always the user's decision: never run "mcp-pin approve" for them. |
| mcp_pin_how_to_protectA | Give the exact steps to put mcp-pin in front of MCP servers in one AI app, so the user can copy them. Use it when the user asks how to protect their MCP servers or set up mcp-pin. Input: app, one of every_app, claude_code, claude_desktop, cursor, vscode, codex, gemini_cli, one_server. Returns the commands or config text for that app and the version they pin. It changes nothing by itself. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 4 tools
Each tool targets a distinct scope: local pinned servers (my_servers), details of a pending local change (change_summary), public registry lookup (server_status), and setup instructions (how_to_protect). Although my_servers and server_status both concern server changes, their local-versus-public scopes are explicitly separated in the descriptions, leaving no real ambiguity.
All tools share the mcp_pin_ prefix and snake_case, so the namespace and style are consistent. The suffixes are a mix of noun phrases (change_summary, server_status), a possessive (my_servers), and a how-to phrase (how_to_protect), which deviates from a pure verb_noun pattern but remains readable and predictable.
Four tools is well-scoped for a pinning/protection server. Each tool earns its place, and the design intentionally delegates approval, review, and full diff inspection to the CLI rather than bloating the MCP surface.
The surface covers discovery, pending-change explanation, public log checks, and setup guidance, forming a coherent lifecycle. Approval/review and the actual changed text are intentionally left to terminal commands, a reasonable gap an agent can work around, though there is no MCP-native way to inspect the changed content.