MCP Trust Registry
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| MCP_TRUST_ENGINE | No | Scan engine to use (e.g., mcpaudit). Default is built-in StubEngine. | |
| MCP_TRUST_SANDBOX | No | Sandbox mode for scanning (e.g., docker). Default is no sandbox. | |
| MCP_TRUST_SCAN_TOKEN | No | Token for authenticated scan triggering (passed as Bearer token). | |
| MCP_TRUST_RECEIPTS_DIR | No | Directory to archive JSON receipts (e.g., /data/mcp-trust/receipts). | |
| MCP_TRUST_PUBLIC_READONLY | No | Set to 1 to disable scan triggering via API (fail-closed). | |
| MCP_TRUST_ALLOW_UNAUTHENTICATED_STUB_SCANS | No | Set to 1 to allow unauthenticated stub scans (do not use in public). |
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 | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| list_serversA | List every graded MCP server with its trust grade and scan freshness. |
| check_serverA | Look up the full trust grade, dimensions, and findings for one server by slug. |
| get_methodologyA | Explain how trust grades are computed and the honesty model behind them. |
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 3 tools
Each tool has a distinct purpose: list_servers provides an overview, check_server focuses on a single entity, and get_methodology explains the grading process. There is no overlap in functionality, making selection unambiguous.
All tool names follow a consistent verb_noun pattern: list_servers, check_server, get_methodology. The verbs are clear and uniform, providing a predictable naming convention.
The three tools together cover the core functionality of a trust registry: browsing, inspecting, and understanding the grading system. The count is well-scoped for the domain, not overly sparse nor excessive.
For a read-only trust registry that grades servers, the surface is complete: you can list all servers, retrieve details for a specific server, and access methodology. There are no dead ends or missing core operations.