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.4/5 across 9 of 9 tools scored. Lowest: 3.8/5.
Each tool targets a distinct purpose: identity lookup, reputation retrieval, badge generation, risk history, orientation, scanning, directory search, reputation verification, and scan verification. There is no overlap or ambiguity between them.
All tools follow a consistent verb_noun pattern (e.g., get_agent, search_reputation_directory, verify_scan). The naming is predictable and clear, with no mixing of conventions.
With 9 tools, the set is well-scoped for the server's purpose—covering identity, reputation, scanning, and verification without unnecessary bloat or missing essentials.
The surface covers the full lifecycle: discovery (search_reputation_directory), identity (get_agent), reputation reading (get_reputation, get_reputation_badge, get_risk_history), scanning (scan_trust), and verification (verify_reputation, verify_scan), plus orientation (get_started). No obvious gaps.
Available Tools
9 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 | |
| ddr_mode | No | Owner projection: drift-detection-response mode (mig default 'flag'). |
| 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. |
| proof_rate | No | Owner projection: proof sampling rate (0–100%). |
| aap_enabled | No | Owner projection: AAP pipeline enabled. |
| aip_enabled | No | Owner projection: AIP pipeline enabled. |
| proof_enabled | No | Owner projection: proof capture enabled. |
| analyze_output | No | Owner projection: analyze agent output. |
| nudge_strategy | No | Owner projection: nudge strategy. |
| 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 indicate readOnlyHint=true and destructiveHint=false. The description adds value by explaining that the record is 'accountable' and reliable, and mentions 'trust state' which goes beyond the annotations. 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?
The description is a single sentence that is front-loaded with the verb 'Look up'. It contains no unnecessary words and effectively communicates the tool's purpose.
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 simple tool (one parameter, output schema present, clear annotations), the description covers all necessary aspects: what it does, what it returns, and the nature of the record. No gaps.
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 mentions 'by ID' but does not add meaning beyond what the schema provides, so baseline score of 3 applies.
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 'Look up an agent's public identity and trust state by ID', providing a specific verb and resource. It distinguishes from sibling tools like get_reputation and get_risk_history by focusing on the agent's base identity and trust record.
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 implies when to use the tool: when you need an agent's public identity and trust state. However, it does not explicitly state when not to use it or name specific alternatives, leaving some inference required.
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_risk_historyARead-onlyIdempotentInspect
Read an agent's risk-assessment history — the trail of prior safety assessments over time. Public, read-only signal.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of risk assessments to return (most recent first). 1–100, default 20. | |
| offset | No | Number of assessments to skip before returning results, for pagination. Default 0. | |
| agent_id | Yes | Agent identifier (e.g. smolt-abc123) | |
| include_playground | No | When true, include assessments produced in playground/test runs alongside production ones. Default false (production only). |
Output Schema
| Name | Required | Description |
|---|---|---|
| limit | No | |
| total | No | |
| offset | No | |
| assessments | No |
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 description's mention of 'read-only' and 'public' adds limited new behavioral context. It conveys that the tool is safe and publicly accessible, but does not detail response format or pagination behavior beyond schema hints.
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 at just two clauses, front-loading the key action ('Read an agent's risk-assessment history') and then adding essential context. Every word serves a purpose with zero redundancy.
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 that an output schema exists (per context signals), the description does not need to detail return values. It covers the tool's core purpose and public nature. Minor gap: it does not explicitly state the chronological ordering (most recent first), but the schema's limit parameter description mentions 'most recent first', partially filling this 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% with parameter-level descriptions (e.g., limit, offset, agent_id, include_playground) that are already informative. The description adds no extra semantic information about any parameter, so it meets the baseline but does not exceed 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 'Read an agent's risk-assessment history' uses a specific verb ('Read') and resource ('risk-assessment history'), clearly distinguishing it from sibling tools like get_agent or get_reputation. It explicitly states it's a public, read-only signal, leaving no ambiguity about its scope.
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 for reading historical risk assessments but does not explicitly state when to use this tool versus alternatives such as get_reputation or verify_reputation. No guidance on prerequisites or exclusions is provided.
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 |
|---|---|---|---|
No parameters | |||
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 safety (readOnlyHint=true, destructiveHint=false). Description adds context that no authentication is required and no arguments needed, plus outlines what information is returned, exceeding annotation coverage.
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, concise sentence that packs essential information (zero-auth, no-args, orientation purpose, and next steps) without extraneous content. Perfectly front-loaded.
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 zero parameters and presence of an output schema, the description fully covers what the tool does, when to use it, and what to expect. No gaps remain.
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?
No parameters exist, and schema coverage is 100%. The description confirms 'no-args', eliminating any ambiguity about required inputs, which is valuable for an agent.
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 an orientation tool that introduces Mnemom, authentication, and recommended starting tools. It distinguishes from sibling tools by being the introductory entry point.
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 says 'Zero-auth, no-args orientation' indicating it's the first tool to use without prior setup. Lists next steps like trying scan_trust and reputation reads, providing clear guidance on when and what to do next.
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 / get_risk_history 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, destructiveHint=false. The description adds valuable context: 'PUBLIC reputation directory (only agents whose reputation visibility is public)' and 'Zero-auth', which go beyond the annotations to disclose scope and authentication requirements.
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, front-loads the core action, and every sentence adds value. No unnecessary words.
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 is complete: it covers purpose, public scope, zero-auth, and the usage flow. The tool is simple and well-explained.
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 input schema has 100% description coverage, so the schema already documents all parameters. The description does not add additional meaning beyond the schema, meeting the baseline expectation.
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 resolves an agent name or id-prefix to a real agent_id over the PUBLIC reputation directory. It uses specific verbs and distinguishes from sibling tools by positioning itself as the entry point for discovering agent IDs before calling other tools like get_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?
Explicitly says when to use: 'The arriving-agent entry point: discover a concrete agent_id, then call get_reputation / verify_reputation / get_risk_history on it.' This provides clear guidance on the workflow and alternatives.
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!