Is It Trust Ready — agent-trust-readiness scanner
Server Details
Scan any website or MCP server for agent-trust-readiness; returns a signed, verifiable scorecard.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 4.2/5 across 8 of 8 tools scored. Lowest: 3.6/5.
Each tool targets a distinct operation: agent lookup, reputation retrieval, badge generation, orientation, website scanning, directory search, and two verification types. No two tools overlap in purpose.
All tool names follow a consistent verb_noun snake_case pattern (e.g., get_agent, scan_trust, verify_reputation). The slight exception "get_started" is still a clear verb phrase.
With 8 tools, the server is well-scoped for its domain of trust readiness scanning and reputation verification. Each tool serves a clear purpose without bloat or deficiency.
The tool surface covers the full workflow: discover agents (search_reputation_directory), inspect identity (get_agent), read reputation (get_reputation), display badge (get_reputation_badge), scan websites (scan_trust), and verify outputs (verify_reputation, verify_scan). No obvious gaps for the stated purpose.
Available Tools
8 toolsget_agentARead-onlyIdempotentInspect
Look up an agent's public identity and trust state by ID — the accountable record other agents and humans can rely on.
| Name | Required | Description | Default |
|---|---|---|---|
| agent_id | Yes | Agent identifier (e.g. smolt-abc123) |
Output Schema
| Name | Required | Description |
|---|---|---|
| id | No | |
| name | No | Agent name (2-32 chars, alphanumeric + hyphens). Present on all list and get responses. |
| No | ||
| caller | No | Self-describing caller context for THIS response. `org_member` callers receive the full owner record (all fields here); `anonymous`/`authenticated` (non-member) callers receive the reduced public projection (id, name, claimed, created_at, last_seen, status, avatar_url, caller). The differing field set is GOVERNED by this value — read it instead of inferring why a field is absent. |
| org_id | No | Owner projection: the agent's org binding (ADR-062 authz boundary). |
| public | No | Identity-record visibility axis — whether the agent's IDENTITY RECORD is publicly discoverable. This is DISTINCT from reputation visibility: every registered agent's reputation is public by accountability standard (see `ReputationScore.visibility`). `public` here governs only the identity record, never the Trust Rating. |
| status | No | |
| claimed | No | Public projection only: whether the agent has been claimed by a user. |
| user_id | No | |
| last_seen | No | |
| agent_hash | No | First 16 hex chars of `SHA256(apiKey + '|' + agentName)` for named agents, or `SHA256(apiKey)` for unnamed singleton agents. The gateway computes the same value on each request and uses it as the lookup key. See [Agent Identity](https://docs.mnemom.ai/concepts/agent-identity#agent_hash--the-canonical-identity-hash). |
| avatar_url | No | |
| claimed_at | No | |
| claimed_by | No | Owner projection: user id that claimed the agent. |
| created_at | No | |
| created_by | No | Owner projection: user id that created the agent (provenance). |
| deleted_at | No | Owner projection: soft-delete timestamp (null when live). |
| key_prefix | No | First 8 chars of the bound API key hash — useful for key-rotation debugging. |
| agent_proof_hash | No | Owner projection: captured hash_proof of the bound key (mig 263). |
| billing_account_id | No | |
| containment_status | No | Containment state of the agent (ADR-053). |
| aip_enforcement_mode | No | |
| agent_proof_captured_at | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, so the description adds value by explaining what data is returned (public identity, trust state) and that it is an authoritative record. No contradiction exists.
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?
Single, well-structured sentence that front-loads the action and purpose. No extraneous words; every part contributes meaning.
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 output schema exists (not shown but indicated), the description sufficiently covers the tool's purpose and single parameter. It does not address error cases or non-existence, but for a simple lookup, this is adequate.
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 coverage is 100% with a clear description for agent_id. The tool description adds no additional parameter semantics beyond the schema, meeting the baseline but not exceeding it.
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 identifies the tool as retrieving an agent's public identity and trust state by ID. While it mentions 'accountable record,' it does not explicitly differentiate from sibling tools like get_reputation or verify_reputation, which reduces specificity.
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 provides no guidance on when to use this tool versus alternatives, no when-not-to-use conditions, and no explicit context for tool selection. It only states the core action.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_reputationARead-onlyIdempotentInspect
Look up an AI agent's published Trust Rating — Mnemom's portable reliability signal for autonomous software, computed from the agent's own verified activity record. Returns the rating plus the technical factors behind it. Free, public, read-only: every registered agent's rating is published by standard (the visibility field is the reputation-publication axis, distinct from identity-record visibility).
| Name | Required | Description | Default |
|---|---|---|---|
| agent_id | Yes | Agent identifier (e.g. smolt-abc123) |
Output Schema
| Name | Required | Description |
|---|---|---|
| tier | No | |
| grade | Yes | AAA–D or NR. |
| score | Yes | |
| claimed | No | |
| agent_id | Yes | |
| trend_30d | No | |
| agent_name | No | |
| components | Yes | |
| confidence | Yes | |
| visibility | Yes | Reputation-publication axis — whether this agent's Trust Rating is published. Every registered agent's reputation is `public` by accountability standard (the default; that is the whole point of a portable, verifiable rating); `private` is a rare owner opt-out that 403s the read to non-owners. This is DISTINCT from `Agent.public` (the identity-record visibility axis) — they share the word "public" but govern different things. |
| computed_at | No | |
| is_eligible | Yes | |
| next_compute_at | No | Next scheduled recompute — the 00/06/12/18 UTC cron slot strictly after `computed_at` (`floor(computed_at/6h)*6h + 6h`). Null when `computed_at` is null. |
| checkpoint_count | Yes | |
| a2a_trust_extension | No | A2A trust extension for interop. Only present on `GET /reputation/{agent_id}` (not on batch/compare rows). |
| checkpoint_accounting | No | Structured breakdown of how checkpoints were counted toward the score. `analyzed` is the scoring population; `excluded` buckets are mutually exclusive and `analyzed + synthetic + insufficient_thinking + quarantined = total`. Null for legacy rows computed before this field existed. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool as readOnly and non-destructive. The description adds value by noting it returns the rating plus technical factors, emphasizes it's free and public, and clarifies the visibility field's role relative to identity-record visibility, providing behavioral context beyond 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 three sentences, each serving a purpose: stating the primary action, describing the output, and clarifying public availability and a nuance about visibility. It is front-loaded with the key purpose and contains no redundant information.
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?
With an output schema present, the description does not need to detail return values. It explains the concept, the free/public nature, and a subtle distinction (visibility field). The tool is simple (1 parameter) and the description covers all necessary context for correct usage.
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 single parameter agent_id is well-described in the schema with an example. The description does not add additional semantic detail about the parameter beyond what the schema provides, and schema coverage is 100%, so baseline score of 3 is appropriate.
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 clearly states the tool looks up an AI agent's Trust Rating, defines it as 'Mnemom's portable reliability signal', and distinguishes it from siblings like get_reputation_badge and verify_reputation by specifying the returned data (rating plus technical factors).
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 explicitly says the tool is 'free, public, read-only', implying safe usage. However, it does not directly state when not to use it or provide explicit alternatives among the siblings, though the context of 'every registered agent's rating' helps guide selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_reputation_badgeARead-onlyIdempotentInspect
Get an embeddable Trust Rating badge for an agent — returns the badge image URL plus ready-to-paste Markdown and HTML snippets for a README or agent card.
| Name | Required | Description | Default |
|---|---|---|---|
| agent_id | Yes | Agent identifier (e.g. smolt-abc123) |
Output Schema
| Name | Required | Description |
|---|---|---|
| agent_id | Yes | The agent the badge is for (echoed from the request). |
| badge_url | Yes | Canonical SVG Trust Rating badge image URL (always on api.mnemom.ai). |
| html_embed | Yes | Paste-ready HTML badge snippet. |
| profile_url | Yes | Human-readable reputation profile page (on www.mnemom.ai). |
| verified_url | Yes | Public cryptographic verification URL for the rating. |
| markdown_embed | Yes | Paste-ready Markdown badge snippet. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readonly, idempotent, non-destructive. The description adds that it returns embeddable assets (URL and snippets), providing behavioral context beyond the 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?
Single sentence, front-loaded with purpose, no redundant information. Every word adds value.
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?
Description is sufficient given low complexity, existing output schema, and annotation coverage. It summarizes return values well, though could mention the badge is for external embedding.
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 coverage is 100% and the description does not elaborate on parameter meaning or usage beyond what the schema provides. Baseline 3 is appropriate.
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 the tool gets an embeddable Trust Rating badge, specifying the return includes badge image URL and Markdown/HTML snippets. It distinguishes from siblings by focusing on embedding rather than raw data.
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 the tool is for embedding badges (e.g., in READMEs) but does not explicitly state when to use it versus alternatives like get_reputation or verify_reputation, leaving the agent to infer.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_startedARead-onlyIdempotentInspect
Zero-auth, no-args orientation: who Mnemom is, the surface map, how to authenticate and what it unlocks, and the value tools to try right now (headlining scan_trust + the reputation reads).
| Name | Required | Description | Default |
|---|---|---|---|
| token | No | Optional Dojo try-me invite token. When supplied and valid, returns the token-gated dojo briefing manifest (the same content as GET /v1/dojo/try-me/resolve); omit for public orientation. |
Output Schema
| Name | Required | Description |
|---|---|---|
| who | Yes | One-line positioning. |
| verify | Yes | How to verify signed artifacts in-band (verify, don't trust). |
| try_now | Yes | Zero-auth value tools to call right now. |
| doctrine | Yes | |
| value_prop | Yes | What Mnemom does for an agent. |
| surface_map | Yes | Stable links to the canonical read-only surfaces. |
| authenticate | Yes | How to authenticate and what auth unlocks. |
| showcase_agent | Yes | A real Mnemom-owned agent the try_now reputation reads target, so the loop runs verbatim. |
| sovereignty_path | Yes | The five-step on-ramp to becoming a sovereign, accountable agent, composed from existing tools. Walked end to end by the become_sovereign MCP prompt. |
| visibility_model | Yes | Disambiguates the two axes that share the word 'public': reputation-publication visibility (public by standard) vs identity-record visibility (agent.public), plus the caller-context self-description. |
| what_we_keep_private_and_why | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, etc. The description adds behavioral context: zero-auth, no-args orientation, and what content is returned. No contradiction with 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, dense sentence that efficiently conveys all necessary information. No wasted words; front-loaded with key features.
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 output schema exists, the description appropriately omits return value details. It covers purpose, scope, usage hints, and references to other tools. Complete for a simple orientation 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?
Schema coverage is 100% with a well-described optional token parameter. The description adds no new parameter details beyond the schema, and it says 'no-args', which downplays the optional parameter. Baseline 3 is appropriate.
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 it is a zero-auth, no-args orientation tool, specifying exactly what it provides (who Mnemom is, surface map, authentication guidance, value tools). It distinguishes itself from siblings like scan_trust by naming them.
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 it is the starting point but does not explicitly state when to use this tool versus alternatives or when not to use it. The mention of 'no-args' contrasts with the optional token parameter, causing slight ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
scan_trustARead-onlyIdempotentInspect
Scan a website's agent-trust-readiness and return a signed scorecard (Trust, plus an Access axis on newer rubrics). Zero-auth. Results are CACHED for up to 24h — check cached and scannedAt on the result; pass fresh: true to force a re-scan (rate-limited). Proxies to the SSRF-locked isittrustready scanner; the Ed25519 signature + permalink are preserved verbatim. Rubric + docs: https://www.isittrustready.ai/rubric and https://docs.mnemom.ai/.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Domain or URL to scan, e.g. "example.com" or "https://example.com". | |
| fresh | No | Force a fresh re-scan instead of the cached result (results are cached up to 24h; the engine rate-limits re-scans). Equivalent to the scanner's rescan flag. |
Output Schema
| Name | Required | Description |
|---|---|---|
| grade | Yes | Trust letter grade (A+…F). |
| score | Yes | 0–100 weighted overall TRUST score. |
| access | No | The independent Access/discoverability axis (never blended with Trust). Present from the two-axis rubric (0.3.0+). |
| cached | No | True when served from the scanner's 24h cache rather than a fresh scan. |
| schema | Yes | iitr-scan schema version string (e.g. "iitr-scan/v0.N"). |
| target | Yes | Normalized host that was scanned. |
| permalink | No | Shareable /r/ permalink (only on /r/ responses; transport field). |
| scannedAt | No | When this scorecard was produced. Results are cached up to 24h — pass fresh:true to scan_trust to force a re-scan. |
| signature | Yes | Ed25519 signature over the canonical result (transport field; stripped before verify). |
| categories | No | Trust-axis categories with per-category scores + checks. |
| verification | No | Self-describing in-band verification block {alg, kid, jwks, canonicalization} — how to verify this scorecard's signature. Self-describing, so signed-EXCLUDED (stripped before verify). |
| rubricVersion | No | Rubric version (e.g. "0.4.0"). |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds details beyond annotations: caching for 24h, force re-scan (rate-limited), proxy to external scanner, Ed25519 signature preservation. No contradictions.
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?
Compact three sentences, each serving a purpose: main action, caching behavior, and source/tooling context. No fluff.
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?
With output schema and rich annotations, the description covers caching, rate limits, external proxy, and links to rubric/docs. Complete for the tool's complexity.
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?
Both parameters have schema descriptions; the description adds context (examples for url, caching behavior for fresh) that enhances understanding.
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 the tool scans a website for agent-trust-readiness and returns a signed scorecard. It distinguishes from siblings by mentioning the SSRF-locked isittrustready scanner, caching, and signature.
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?
Explicitly states zero-auth and caching behavior with fresh parameter. Implicitly differentiates from siblings like get_reputation but lacks explicit when-not-to-use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_reputation_directoryARead-onlyIdempotentInspect
Resolve an agent name or id-prefix to a real agent_id over the PUBLIC reputation directory (only agents whose reputation visibility is public). Zero-auth. The arriving-agent entry point: discover a concrete agent_id, then call get_reputation / verify_reputation on it.
| Name | Required | Description | Default |
|---|---|---|---|
| q | No | Name search (ilike) or agent-id prefix match. | |
| page | No | 1-based page number for pagination. Default 1. | |
| sort | No | Result ordering. Default "score" (highest-rated first); other supported keys order by recency or name. | score |
| grade | No | Filter to one grade (e.g. `AAA`, `B`, `NR`). | |
| per_page | No | Number of results per page. 1–100, default 20. | |
| confidence | No | Filter to agents at a given reputation-confidence level (driven by how much evidence backs the score). |
Output Schema
| Name | Required | Description |
|---|---|---|
| page | Yes | |
| total | Yes | |
| agents | Yes | |
| per_page | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the agent knows it is safe. The description adds minimal extra context: zero-auth and public-only constraint, which is useful but not extensive.
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 three sentences that are front-loaded with the core purpose, then auth, then usage flow. No superfluous information; every sentence adds value.
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 six optional parameters and available output schema, the description covers the essential use case and flow. It could briefly mention pagination or sorting, but the schema covers those details, so this is a minor gap.
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 coverage is 100%, so each parameter's purpose is already defined in the input schema. The description does not add further parameter-level detail beyond what the schema provides.
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 explicitly states the tool resolves an agent name or id-prefix to a real agent_id over the public reputation directory. It distinguishes itself from siblings by positioning as the entry point before calling get_reputation or verify_reputation.
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 clearly states when to use this tool (as the arriving-agent entry point to discover a concrete agent_id) and suggests subsequent calls. It does not explicitly state when not to use, but the context is clear given sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
verify_reputationARead-onlyIdempotentInspect
Attest an agent's Trust Rating — returns a Merkle-root + hash-chain attestation (hash_chain_valid) proving the rating derives from an unbroken, append-only checkpoint chain, plus a pointer to the signed integrity certificate. This is a chain-integrity attestation, NOT an in-band Ed25519 signature check (that parity is verify_scan, for website scorecards).
| Name | Required | Description | Default |
|---|---|---|---|
| agent_id | Yes | Agent identifier (e.g. smolt-abc123) |
Output Schema
| Name | Required | Description |
|---|---|---|
| grade | Yes | |
| score | Yes | |
| agent_id | Yes | |
| computed_at | Yes | |
| verification | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds valuable behavioral context: it explains the attestation type (chain-integrity), return components (Merkle-root, hash_chain_valid, integrity certificate pointer), and clarifies it does not perform an Ed25519 check. No contradiction with 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 two sentences long, front-loaded with purpose and output, and each sentence adds essential information without redundancy. It is efficiently structured for quick comprehension.
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 (1 required parameter, no enums, output schema exists), the description fully covers what the tool does, what it returns, and how it differs from siblings. No missing information needed for correct invocation.
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 coverage is 100% for the single parameter 'agent_id', which has a clear description. The tool description does not add further parameter detail, but the baseline 3 is appropriate since the schema already provides sufficient semantics.
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 the tool's purpose ('Attest an agent's Trust Rating') and specifies the output (Merkle-root + hash-chain attestation). It distinguishes from sibling 'verify_scan' by stating this is not an Ed25519 signature check, ensuring the agent selects the correct tool.
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?
Explicitly tells the agent when not to use this tool ('NOT an in-band Ed25519 signature check') and points to the alternative ('that parity is verify_scan'). This provides clear usage guidance and avoids misuse.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
verify_scanARead-onlyIdempotentInspect
Verify a website scan scorecard's Ed25519 signature IN-BAND (verify, don't trust). Pass a scan (a scorecard from scan_trust) or a url to re-scan; returns {verified, key_id, canonicalization} checked against the public key at mnemom://iitr/jwks. Zero-auth. Spec + rubric: https://www.isittrustready.ai/rubric and https://docs.mnemom.ai/.
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | Alternatively, a domain/URL to re-scan and then verify. | |
| scan | No | A scan scorecard previously returned by scan_trust (or iitr's /r/ JSON), passed back verbatim to verify. Same shape as scan_trust's result; the signature is checked against mnemom://iitr/jwks. |
Output Schema
| Name | Required | Description |
|---|---|---|
| key_id | Yes | The signing key id (kid) checked. |
| reason | No | Why verification failed or could not be evaluated (absent when verified). |
| verified | Yes | True iff the signature verifies against the in-band JWKS. |
| algorithm | Yes | Always "Ed25519". |
| scorecard | No | The scorecard verified (present when re-scanned via `url`). |
| canonicalization | Yes | The exact canonicalization used (so the verdict is reproducible). |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false. The description adds behavioral context: 'IN-BAND (verify, don't trust)', the return shape '{verified, key_id, canonicalization}', and the key source 'mnemom://iitr/jwks'. It also explains the two input modes, which is additional transparency beyond 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 extremely concise: two sentences covering the core purpose, input options, return, and key source, plus a link to spec. Every sentence serves a purpose, front-loaded with the main action.
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 complexity (two optional mutually exclusive params, nested objects, output schema exists), the description is complete. It covers both input modes, the return shape, the key source, and provides links for spec. With an output schema present, the description need not detail return fields.
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 coverage is 100%, so the schema already documents parameters fully. The description adds value by explaining the two input options ('scan' vs 'url') and their relationship, including that passing a url triggers a re-scan. This provides usage context beyond the schema's static definitions.
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 the verb 'verify' and the specific resource: 'a website scan scorecard's Ed25519 signature'. It distinguishes itself from sibling tools like scan_trust (which produces the scorecard) and verify_reputation (likely for reputation verification) by focusing on in-band signature verification and providing alternative input modes.
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 explicitly says to pass a 'scan' (from scan_trust) or a 'url' to re-scan, giving clear usage guidance. It also mentions 'Zero-auth' indicating no authentication needed. However, it does not explicitly contrast with verify_reputation, though the context of sibling tools makes the distinction clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!