MCP Trust Registry
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@MCP Trust RegistryCheck the danger grade for mcp-reference-time"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
MCP Trust Registry
Check before you connect. A neutral, public danger grade for the MCP servers your AI agents rely on.
Live: mcp-trust.vercel.app
Not yet published to PyPI. Install from source using the Quickstart below.
Use as an MCP server
mcp-trust runs as a read-only MCP server so an agent can check a server's
danger grade before connecting — it serves a baked snapshot of real scan
grades with explicit per-record provenance, so no database or network is needed.
mcp-trust mcp-serve # from a source/dev install (works today)
uvx mcp-trust mcp-serve # once published to PyPITool | Description |
| Every graded MCP server with its A-F grade, transparency, and danger score. |
| Full grade, risk dimensions, and findings for one server by slug. |
| How the A-F grade and transparency axis are computed, plus the honesty model. |
The MCP runtime admits the packaged catalog only after deterministic schema-v2 validation, including duplicate-key rejection, required field/type checks, unique slugs and source coordinates, supported enums, sandbox/scan-mode agreement, and timezone-aware scan timestamps. Admission also binds grade to danger score, transparency to annotation coverage, and critical findings to the grade cap. Raw JSON is limited to 1 MiB, with deterministic server, finding, tool, and public-string ceilings. Schema v2 preserves additive unknown fields; missing or invalid required fields and unknown schema versions fail closed.
If catalog admission fails, list_servers and check_server serve zero records
and return mcp-trust-mcp-error.v1 with status UNKNOWN, error code
CATALOG_SNAPSHOT_INVALID, sorted reason codes, and server_count_served: 0.
get_methodology remains available. This boundary checks internal consistency;
it does not prove snapshot authenticity, authorship, immutability, or freshness.
Offline consumers can add those missing publication checks with
mcp-trust verify-snapshot: a detached Ed25519 statement binds the exact
snapshot bytes, publisher ID, bounded issue/expiry window, monotonic publication
ID, and prior consumer checkpoint. The consumer must independently pin the
trust-root SHA-256 and preserve the returned checkpoint for rollback resistance.
Invalid, expired, unknown-signer, forked, or rolled-back inputs return only
UNKNOWN reason codes and no grades. See
docs/OFFLINE-SNAPSHOT-TRUST-V1.md.
Statement freshness proves recent publication authorization, not a recent scan;
the per-record scan timestamp and 90-day stale policy remain separate checks.
No production trust root, signing key, statement, or checkpoint ships today, so the built-in MCP snapshot remains structural-only unless a consumer separately supplies and pins those inputs. Test fixture keys are not publication keys.
Connecting an MCP server hands it influence over what your agent does. Tool poisoning, prompt injection, over-broad permissions, and rug-pull tool mutations are documented attack classes -- and today there's no quick way to vet a server before you wire it in. MCP Trust Registry scans public MCP servers and gives each one a single readable danger grade (A-F), a separate transparency signal, and the findings behind them.
Think OSV.dev / Socket.dev / haveibeenpwned, scoped to MCP servers.
Related MCP server: dominion-observatory
Prerequisites
Python >= 3.11
uv(used for dependency management and running the project)
MCP config portability studio
Render one versioned, secret-placeholder-only MCP connection intent into staged Codex, Claude Code, Claude Desktop, or VS Code configuration and receive an explicit semantic loss/widening report:
uv run --frozen --extra dev mcp-trust portability validate \
tests/fixtures/portability/local-stdio.json
uv run --frozen --extra dev mcp-trust portability round-trip \
tests/fixtures/portability/local-stdio.json --host codexThe studio is local-only. It never discovers or edits a real host config,
launches an MCP server, contacts a URL, or emits modeled secret values. Generated
configuration proves only documented host-format compatibility, not a runtime
connection or adoption. See
docs/MCP-CONFIG-PORTABILITY-STUDIO.md.
How it works
register a server -> scan via engine -> derive grade -> persist -> serve at a stable URLThe registry does not reimplement vulnerability detection. It orchestrates a
pluggable scan engine -- the shipping backend wraps the public
mcp-audits (>=2.1) package -- and owns the
catalog, the public trust-grade normalization, persistence, and the lookup API.
Quickstart
git clone https://github.com/saagpatel/mcp-trust.git && cd mcp-trust
uv pip install -e ".[dev]" # core + dev deps (runs on the built-in StubEngine)
mcp-trust seed # load the seed catalog
mcp-trust scan mcp-reference-time # scan a catalog server, print its grade
mcp-trust check mcp-reference-time # look up the latest stored grade
mcp-trust serve # serve the API on http://127.0.0.1:8000For real scanning install the engine extra and select it:
uv pip install -e ".[dev,engine]"
MCP_TRUST_ENGINE=mcpaudit mcp-trust scan mcp-reference-timeScanning launches the server's process. For untrusted servers, isolate execution in a locked-down container (no network, read-only fs, dropped caps, resource limits):
MCP_TRUST_ENGINE=mcpaudit MCP_TRUST_SANDBOX=docker mcp-trust scan mcp-reference-timeThe default is no sandbox (safe only for servers you trust).
API
Method | Path | Purpose |
|
| web -- public catalog page (grade + transparency per server) |
|
| web -- server detail page + README badge-embed snippet |
|
| liveness |
|
| catalog + latest grade, provenance, and staleness per server (JSON) |
|
| full latest scan record + provenance/staleness and metadata (JSON) |
|
| operator scan trigger; public deployments disable this route |
|
| shields.io-compatible README badge |
Every server has two orthogonal signals: a danger grade (A-F) and a transparency level (high/medium/low, from annotation coverage). Automated grades are not endorsements, certifications, or claims that a server is malicious. A low grade on a low-transparency server means "cannot verify safe," not "known dangerous."
HTTP scan triggering is fail-closed by default. Public deployments should set
MCP_TRUST_PUBLIC_READONLY=1, which makes POST /servers/{slug}/scan return
403 before any engine can run. Operator scans should normally run through the
CLI against the persistent registry DB, not through public traffic.
For local API demos with the deterministic StubEngine, set
MCP_TRUST_ALLOW_UNAUTHENTICATED_STUB_SCANS=1. Do not set that in public.
Token-gated API scan triggering is still available for private operator surfaces
by setting MCP_TRUST_SCAN_TOKEN and passing it as Authorization: Bearer <token> or X-MCP-Trust-Scan-Token.
If the newest stored scan row is unreadable, API, web, static, badge, and
snapshot projections fail closed to UNKNOWN; they never resurrect an older
grade. Stored source/risk/finding/evidence JSON has a 1 MiB per-field admission
ceiling, with bounded finding/tool collections and content-free diagnostics.
An unreadable older row leaves a readable latest grade intact but makes scan
history and grade-change claims explicitly UNKNOWN. Snapshot construction
stops until unreadable history is repaired or dispositioned.
Set MCP_TRUST_RECEIPTS_DIR=/data/mcp-trust/receipts during real scan runs to
archive a JSON receipt for each scan and store its portable artifact filename in
report_ref.
Remote authorization metadata preflight
Remote Registry candidates can be checked for discoverable MCP authorization
metadata without contacting the MCP endpoint or handling credentials. First
build a candidate manifest from a previously saved official Registry response,
then select one exact stable_id:
uv run python scripts/plan_registry_corpus.py \
--input path/to/saved-registry-response.json > /tmp/registry-candidates.json
uv run mcp-trust auth-posture com.example/remote@1.0.0 \
--manifest /tmp/registry-candidates.json \
--prettyIf a public WWW-Authenticate: Bearer challenge has already been obtained by a
separate operator workflow, pass its value with --www-authenticate. Otherwise
the command tries the MCP-required protected-resource well-known paths, followed
by RFC 8414 and OpenID Connect authorization-server discovery in specification
order.
The command emits McpAuthorizationPostureV1 JSON. Exit 0 and
state=metadata-ready mean only that at least one authorization server exposes
the endpoints and PKCE S256 metadata needed for policy review. They do not
prove authorization, credential availability, runtime security, scan
eligibility, or a trust grade. Unknown or invalid evidence exits 1 and stays
blocked; an invalid local manifest binding exits 2.
The network boundary is deliberately narrow: HTTPS metadata GETs only, no
ambient proxies, redirects, credentials, endpoint session, or writes. DNS is
resolved once per request; every answer must be globally routable, and the
connection is pinned to an accepted address while TLS validation and SNI remain
bound to the original hostname. Response bodies are size-bounded, validated,
and represented in output only by byte count and SHA-256. Successful metadata
responses must also carry a valid HTTP Date; declared cache freshness is
honored up to a 24-hour policy cap, while missing, future-dated, or stale source
evidence remains unknown. The implementation is based on the
MCP authorization specification,
RFC 9728,
RFC 8414, and
OpenID Connect Discovery.
Reusable web release readback
This repository owns the language-neutral WebReleaseReadbackV1 contract and
its standard-library reference verifier. A consumer supplies an explicit HTTPS
origin plus a versioned route-sentinel manifest:
python scripts/web_release_readback.py \
--manifest path/to/release-routes.json \
--target-url https://preview.example.com \
--prettyThe command emits one structured receipt to stdout and exits nonzero when any
status, required or forbidden sentinel, exact body, digest, body bound, timeout,
or redirect assertion fails. It implements only GET and HEAD, ignores ambient
proxies, accepts no credentials, and has no deployment, alias, DNS, promotion,
or rollback capability. The schemas, deterministic artifact manifest, versioning
policy, and rollback boundary live under
contracts/web-release-readback-v1/.
The owner repository also consumes the contract through
deploy/web-release-readback.json. deploy/smoke-readonly.sh emits the shared
route receipt before running the registry-specific health, API, badge, portable
receipt-reference, and denied scan-POST assertions. This self-adoption is a
release readback check only; it neither deploys nor changes an alias.
This generic receipt is additive. Product-specific API, badge, privacy, release lineage, and denied-mutation checks remain owned by each consumer until proven receipt parity justifies removing only their duplicated HTTP assertion plumbing.
Evidence lineage decisions
EvidenceLineageLedgerV1 is a metadata-only, fail-closed contract for MCP
corpus admit, refresh, publish, and withdraw decisions. It binds exact identity,
digests, portable receipt references, freshness, rights evidence, public
projections, supersession, and retention without storing raw logs or secrets.
The read-only assessor requires an explicit observation time and emits stable
reason codes; only an explicit ALLOWED status can authorize admit or publish.
See docs/EVIDENCE-LINEAGE-LEDGER-V1.md
for the schema, decision semantics, three-record packaged-catalog pilot, claim
ceiling, and rollback boundary. This source capability does not itself migrate
the catalog, publish or withdraw records, run scans, or change deployment state.
Manual refresh candidates
Create a review candidate without mutating the canonical registry, baked snapshot, static site, schedule, or deployment:
uv run --frozen --extra engine python scripts/refresh_candidate.py create \
--db ./registry.db \
--out-dir ./dist/refresh-candidatesThe command refuses local-process scans unless Docker and every catalog-pinned image are already available locally. Those sources run through the existing network-off, read-only, capability-dropped, resource-bounded sandbox. Remote endpoints are probed over their live network transport without a local process sandbox and are labeled accordingly. The immutable bundle contains receipts, catalog identity, scan times and ages, masked/failed/unknown evidence states, attributed scan drift, an honest static snapshot, and a content-bound manifest.
Candidate creation has no publication or deployment authority. A structurally
valid candidate must first pass verify, then receive a separate digest-bound,
short-lived approve receipt before publish may stage it in a local output
directory. verify exits successfully only for a current, complete,
reviewed-input-bound candidate that is eligible for publication. Eligibility
never grants approval, publication, deployment, or scheduling authority.
Snapshot signing is a separate authority after candidate approval/staging. The refresh process never receives a signing or recovery key, and its SHA-256 manifest is not a publisher identity. Production signing remains disabled until an operator chooses the root, custody, thresholds, publication counter, and checkpoint owner described in the offline trust contract.
Status
Live at mcp-trust.vercel.app as a statically
generated catalog, regenerated from the local registry. The bundled catalog
snapshot contains 23 visible real mcp-audits grades; eight reviewed entries
are withheld by masked-grades.json and are absent from the public snapshot.
The bundled snapshot labels the visible local-process grades' network and
sandbox provenance as unknown; only a receipt-verified refresh candidate may
claim network-off execution. Every grade is labeled by provenance, so
demo/stub data can never read as a real scan, and an unscanned server never
shows a letter grade. The current production deployment is the 31-server
static catalog; grades are static since 2026-07-11, when the weekly re-scan
lane was disabled and its deploy authority removed (see
docs/CAPABILITY-RULING-2026-07-10.md).
The static front door is the low-ops launch path (see
DEPLOY-VERCEL.md); a weekly launchd job under
deploy/launchd/ remains installed but disabled. Its
compatibility entrypoint can create a local review candidate only; it cannot
publish or deploy. The live FastAPI service + VM path remains
documented in DEPLOY-VM.md as an alternative. See
SPEC.md for the full contract and LAUNCH-GATE.md
for launch history. The deployed catalog reports scan timestamps as its
freshness authority; static HTML does not claim to attest machine-local
scheduler state.
Contributing
uv.lock is intentionally committed to the repository to ensure reproducible
installs across environments. When adding or updating dependencies, commit the
updated uv.lock alongside your pyproject.toml changes.
License
MIT
Available Tools
3 toolscheck_serverA
Look up the full trust grade, dimensions, and findings for one server by slug.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. 'Look up' implies a read-only operation, and the mention of 'full trust grade, dimensions, and findings' indicates the kind of data returned. However, it does not disclose error behavior, authentication requirements, or any limitations, which would be valuable for a tool with no annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that conveys the essential information without wasted words. Every word earns its place, and the structure is immediately scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter lookup tool with an output schema, the description is adequate. It specifies the input (slug) and the nature of the output (trust grade, dimensions, findings). The output schema presumably details return fields, so the description needn't repeat them. Minor gaps like prerequisites (e.g., slug must exist in list_servers) are implied.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It does by stating 'by slug', clarifying that the 'slug' parameter is the identifier for selecting a single server. This adds meaning beyond the bare schema property name, though it doesn't specify slug format or examples.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description uses a specific verb 'look up' and identifies the exact resource: 'full trust grade, dimensions, and findings for one server by slug'. This clearly distinguishes it from list_servers, which presumably lists all servers, though it does not explicitly name siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage: use when you need detailed information for a specific server identified by slug, but it does not explicitly state when not to use it or mention alternatives like list_servers. Context signals provide sibling tool names but the description itself lacks exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_methodologyA
Explain how trust grades are computed and the honesty model behind them.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only states the purpose ('Explain...') without disclosing any behavioral traits such as read-only nature, authentication requirements, potential side effects, or return behavior. It carries the full burden but offers no transparency beyond the core function.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that directly conveys the tool's purpose without any redundant words or extra detail. It is perfectly sized for a tool with no parameters.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no parameters) and the presence of an output schema, the description is sufficient. It states what the tool explains, and since an output schema exists, the description does not need to describe return values. The description fully covers the necessary context for an agent to invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema covers 100% by default. The baseline is 4 for zero-parameter tools, and the description adds no parameter-related information because none is needed. No additional meaning is required.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb and resource: 'Explain how trust grades are computed and the honesty model behind them.' This distinguishes it from sibling tools list_servers and check_server, which focus on server information rather than methodology.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when a user needs to understand trust grade computation or the honesty model, but it does not explicitly mention when not to use it or reference alternative tools. Sibling tools have different purposes, so context is clear but no explicit exclusions or alternatives are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_serversA
List every graded MCP server with its trust grade and scan freshness.
Returns JSON; each row carries scanned_at, scan_age_days, and a stale
flag alongside the grade.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the return format ('Returns JSON') and the key fields (scanned_at, scan_age_days, stale flag, grade), giving the agent insight into what to expect. It does not mention side effects, but the verb 'List' implies a read-only operation, and the output description adds meaningful context beyond the empty input schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long and front-loaded with the main purpose. The second sentence adds specific output details without redundancy. No word is wasted, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (no params, no annotations) and the description fully covers what the tool does and what it returns. The output schema exists, so the description doesn't need to exhaustively list return values, but it already provides key fields. For a list tool, this is complete enough for an agent to select and invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the description does not need to explain parameter usage. The schema is empty and coverage is 100%, meeting the baseline for no-parameter tools. The description appropriately focuses on the output rather than inputs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'List' and clearly identifies the resource: 'every graded MCP server.' It also states what the output contains (trust grade and scan freshness), distinguishing it from sibling tools like check_server (which likely checks a specific server) and get_methodology.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'List every' clearly indicates this is for retrieving an overview of all servers. It doesn't explicitly name alternatives or exclusions, but the scope is unambiguous. The context of siblings (check_server, get_methodology) implies usage, though no explicit when-to-use guidance is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
3 tool updates
v0.1.1- First observed
check_server - First observed
get_methodology - First observed
list_servers
TDQS
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.
Maintenance
Resources
Unclaimed servers have limited discoverability.
Looking for Admin?
If you are the server author, to access and configure the admin panel.
Related MCP Connectors
Independent A-F trust grade for any MCP server, watched for drift. Free, never for sale.
Look up independent trust ratings and security, maintenance, and adoption evidence for MCP servers.
Trust verification for MCP servers. Check scores, scan for security issues, search 4,200+ servers.
Related MCP Servers
- AlicenseNot gradedqualityCmaintenanceSecurity scanner for MCP servers and AI-generated code. Detects leaked API keys, PII, prompt injection, and MCP misconfigs with A-F security grades.MIT
- AlicenseNot gradedqualityAmaintenanceBehavioral trust scoring for MCP servers and AI agents. Live registry tracking 4,500+ servers with trust scores (0-100) based on interaction history, success rates, and latency2MIT
- FlicenseNot gradedqualityDmaintenanceEnables AI agents to query trust scores and security reviews for MCP servers before connecting, helping assess safety via a composite score and letter grade.-

Agent-Townofficial
AlicenseNot gradedqualityCmaintenanceA neutral verification court for AI tools that ranks MCP servers by executing them against ground truth and recording results. Enables agents to consult execution records, contribute verdicts, and challenge claims.Apache 2.0
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
MCP directory API
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/saagpatel/mcp-trust'
If you have feedback or need assistance with the MCP directory API, please join our Discord server