Mnemom — Trust Ratings for AI Agents
Server Details
Trust infrastructure for AI agents: read a verifiable Trust Rating, claim an identity, earn a badge.
- 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.1/5 across 15 of 15 tools scored. Lowest: 3.5/5.
Each tool has a clearly distinct purpose. Reputation tools vary by output (rating, badge, attestation, history). Scanning, verification, alignment, and agent management tools are all well-separated.
All tool names follow a consistent verb_noun pattern with underscores, e.g., get_reputation, scan_trust, verify_scan. Even longer names like preview_compose_alignment_by_agent maintain the pattern.
15 tools is optimal for the server's scope, covering identity, reputation, scanning, alignment, and verification without being excessive or sparse.
The tool surface covers core workflows: identity claiming, reputation retrieval and verification, scanning, alignment management. Minor gaps exist (no agent update/delete) but these are not central to the trust rating domain.
Available Tools
15 toolsclaim_agentAInspect
Claim a verifiable identity — bind an agent to your organization so its trust and accountability record is provably yours. No human in the loop.
| Name | Required | Description | Default |
|---|---|---|---|
| org_id | No | Optional. The organization to claim the agent into (e.g. `org-...` or `pers-...`). The caller must be a member of this org (role floor: member). If omitted, the agent is claimed into the caller's personal org. | |
| agent_id | Yes | Agent identifier (e.g. smolt-abc123) | |
| hash_proof | Yes | Agent possession proof: the full 64-hex SHA-256 digest of `${apiKey}|${agentName}` (or `${apiKey}` for an unnamed singleton agent). |
Output Schema
| Name | Required | Description |
|---|---|---|
| org_id | Yes | The organization the agent was claimed into (echoes the resolved org — the supplied `org_id`, or the caller's personal org when omitted). |
| claimed | Yes | |
| agent_id | Yes | |
| claimed_at | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide minimal behavioral cues (all false). The description adds context about binding and automation but does not disclose side effects, reversibility, or consequences of claiming an already-claimed agent.
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?
Two sentences, front-loaded with purpose, no wasted words. Efficient and clear.
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 present, return values are covered. However, the description lacks context on prerequisites (e.g., having an API key) and the effect on existing agent bindings, leaving some gaps for a complex operation.
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 100%, so baseline is 3. The description does not add extra parameter-level meaning beyond what the schema already 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 clearly states the action (claim/bind), the resource (agent to organization), and the outcome (trust record provably yours). It distinguishes from sibling tools like get_agent and verify_agent_binding.
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 automated usage ('No human in the loop') but does not explicitly state when to use this tool versus alternatives or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_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 declare readOnlyHint=true and destructiveHint=false, indicating a safe read operation. The description adds that it is 'the accountable record other agents and humans can rely on', which provides some behavioral context about reliability but not extensive 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 a single concise sentence, front-loaded with the action, 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?
Given the tool's simplicity (one required parameter with full schema coverage, and the presence of an output schema), the description adequately covers the purpose and the nature of the returned record. No additional information is needed.
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 includes a description. The tool description does not add any additional meaning or constraints beyond what the schema provides, 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?
The description specifies the verb 'look up', the resource 'agent's public identity and trust state', and the method 'by ID'. It clearly distinguishes from siblings like 'list_agents' (listing all) and 'claim_agent' (creation).
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 a basic lookup by ID but does not explicitly state when to use this tool versus alternatives like 'search_reputation_directory' or 'verify_agent_binding'. No exclusions or when-not-to-use guidance is provided.
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 declare readOnlyHint, idempotentHint, and destructiveHint. Description adds context: it is free, public, read-only, and explains the visibility field's role. This goes beyond the annotations but does not fully cover potential rate limits or authorization needs.
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?
Description is two sentences, front-loaded with the main purpose, and every clause adds value (e.g., free, public, read-only, visibility distinction). No wasted 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?
For a simple look-up tool with one parameter and an output schema (not shown), the description adequately states what is returned and key contextual information. No additional details are necessary for an agent.
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 description for agent_id. The tool description does not add any additional parameter context (e.g., format, examples), so 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?
Description clearly states the verb 'Look up' and the resource 'published Trust Rating', and distinguishes it from sibling tools by explaining it returns both the rating and technical factors, and clarifying the visibility axis distinction.
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?
Description implies usage (look up a reputation rating) but does not explicitly compare this tool to siblings like get_reputation_badge, search_reputation_directory, or verify_reputation. No when/when-not guidance is given.
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 declare readOnlyHint, idempotentHint, and destructiveHint=false, indicating a safe read operation. The description adds value by detailing the return format (badge URL and snippets), which goes beyond annotations. No contradictions noted.
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, well-structured sentence that efficiently conveys the tool's purpose with 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?
Considering the tool's simplicity (one parameter), rich annotations, and the presence of an output schema (though not shown), the description is complete. It mentions the return content, providing sufficient context without needing further elaboration.
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 required parameter 'agent_id' with a clear description in the schema. The tool description adds no additional parameter semantics beyond what the schema provides, resulting in a baseline score of 3.
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 retrieves an embeddable Trust Rating badge, specifying the return includes a badge image URL and ready-to-paste snippets. This distinguishes it from siblings like 'get_reputation' which likely return raw data, and 'verify_reputation' which is for verification.
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 embedding in README or agent cards, providing clear context. However, it does not explicitly state when to use this tool versus alternatives like 'get_reputation' or when not to use it, missing a perfect score.
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?
Adds 'Public' and temporal context beyond annotations (readOnlyHint), describing the history as a trail over time, without contradiction.
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 front-loaded with verb and resource, no extraneous 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?
Adequate for a simple read tool with output schema and 4 straightforward parameters; sufficiently covers purpose and constraints.
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 baseline is 3; description does not add parameter details beyond what 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?
Description uses specific verb 'Read' and resource 'agent's risk-assessment history', clearly distinguishing from siblings like get_agent or 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?
States 'Public, read-only signal' implying safe to call, but does not explicitly guide when to use vs alternatives or provide exclusions.
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 readOnly, idempotent, non-destructive. Description adds that it's zero-auth and no-args, providing useful 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?
Single sentence, front-loaded with key info, no wasted words. Efficient and informative.
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?
Fully adequate for a zero-param orientation tool with output schema and annotations. Description covers scope and suggests next steps.
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?
With 0 parameters, baseline is 4. The description adds meaning by explaining what the tool provides without needing any 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 clearly states 'orientation' with specifics (who Mnemom is, surface map, auth, value tools). It distinguishes from sibling tools which are specific actions like scan_trust or 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?
The description indicates this is for first-time users ('Zero-auth, no-args orientation') and suggests trying other tools. It lacks explicit exclusions but context makes usage clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_agentsARead-onlyIdempotentInspect
List your agents — List all agents owned by the authenticated user. Supports pagination.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of agents to return (max 100) | |
| offset | No | Number of agents to skip for pagination |
Output Schema
| Name | Required | Description |
|---|---|---|
| scope | Yes | Echoes the resolved listing scope. |
| agents | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds 'owned by authenticated user' and 'supports pagination', which are useful behavioral details without contradicting 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 with two sentences, no wasted words, and front-loaded with the key action and resource.
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 with 2 parameters, clear annotations, and an output schema (not shown), the description covers the core functionality and pagination adequately. Minor missing details on sorting or default order are not critical.
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 description need not explain parameter details. The mention of pagination reinforces the purpose of limit and offset but does not add substantial new meaning.
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 'list' and resource 'agents', specifying ownership by the authenticated user. It distinguishes from siblings like 'get_agent' (singular) and 'claim_agent'.
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 does not explicitly compare to alternatives or state when not to use. While the purpose is clear, guidance on when to use vs 'get_agent' or 'search_reputation_directory' is missing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
preview_compose_alignment_by_agentARead-onlyIdempotentInspect
Preview composed alignment (dry run) — Composes the cascade against a hypothetical body at the agent layer and returns conflicts + the composed view. No DB writes. Used by the dashboard editor for live conflict markers.
| Name | Required | Description | Default |
|---|---|---|---|
| body | No | Unified alignment card (ADR-008/ADR-039). Authored in YAML or JSON; composed server-side with platform defaults, org template, and active exemptions before storage. This schema matches the runtime validator at src/composition/validate.ts EXACTLY — a card authored strictly to it passes `PUT /v1/agents/{id}/alignment-card` and the preview-compose endpoint. Output-only fields (card_id, issued_at, expires_at, _composition, content_hash, version) are server-assigned and must NOT be sent on a PUT. | |
| agent_id | Yes | Agent identifier (e.g. smolt-abc123) |
Output Schema
| Name | Required | Description |
|---|---|---|
| ok | Yes | |
| tool | Yes | |
| summary | Yes | |
| conflicts | Yes | |
| effective | Yes | |
| full_report | Yes | |
| what_changed | Yes | |
| what_to_do_next | Yes | |
| what_would_break | Yes | |
| coherence_violations | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true; the description adds context by confirming 'No DB writes' and detailing return values (conflicts + composed view). No contradiction.
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, front-loaded with the key action and context, and contains no superfluous 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?
Given the tool's complexity (nested input schema, rich output schema), the description covers the core purpose, behavior, and use case. It does not detail the output format, but an output schema is provided separately.
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 100%, so baseline is 3. The description does not add additional meaning to the two parameters beyond what the schema already 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 clearly states the verb 'preview composed alignment (dry run)' and specifies the resource 'alignment by agent'. It distinguishes itself from write operations by explicitly noting 'No DB writes' and mentions specific outputs (conflicts + composed view).
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 as a preview tool for the dashboard editor and contrasts with write operations via 'No DB writes', but it does not explicitly name alternative tools or provide when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
put_alignment_by_agentADestructiveIdempotentInspect
Publish or replace the alignment manifest — Accepts YAML (text/yaml, application/yaml) or JSON. Body is the full UnifiedAlignmentCard; server-side composition merges it across the platform → org → team → agent cascade and writes the canonical composed card. Requires Idempotency-Key. Honor...
| Name | Required | Description | Default |
|---|---|---|---|
| body | No | Unified alignment card (ADR-008/ADR-039). Authored in YAML or JSON; composed server-side with platform defaults, org template, and active exemptions before storage. This schema matches the runtime validator at src/composition/validate.ts EXACTLY — a card authored strictly to it passes `PUT /v1/agents/{id}/alignment-card` and the preview-compose endpoint. Output-only fields (card_id, issued_at, expires_at, _composition, content_hash, version) are server-assigned and must NOT be sent on a PUT. | |
| agent_id | Yes | Agent identifier (e.g. smolt-abc123) |
Output Schema
| Name | Required | Description |
|---|---|---|
| audit | Yes | |
| values | Yes | |
| card_id | No | Card row id. Server-assigned on PUT (`ac-{uuid}`). |
| version | No | Response-only: monotonic card version, injected by the GET/PUT response. Server-assigned — do not send on a PUT. |
| agent_id | Yes | Target agent id. On PUT, server overwrites to match the URL path. |
| autonomy | Yes | |
| issued_at | No | |
| principal | Yes | Required object describing whose authority the agent acts under (ADR-039 Decision 10). |
| conscience | No | |
| expires_at | No | |
| extensions | No | |
| enforcement | No | Optional ADR-039 Decision-3 user-facing knobs for unmapped-tool handling. The legacy `mode`, `unmapped_tool_action` and `fail_open` keys are REJECTED by the validator (mode → top-level autonomy_mode; fail_open → gateway env config). |
| _composition | No | |
| capabilities | No | |
| card_version | Yes | Card schema version (required, non-empty). Current canonical value: `unified/2026-04-26`. |
| content_hash | No | Response-only: content hash of the composed card (`sha256:<hex>`), injected by the GET/PUT response. Server-assigned — do not send on a PUT. |
| autonomy_mode | Yes | ADR-039 master switch for the action-policing pipeline (autonomy constraints). Required at the top level post-cutover; the legacy `enforcement.mode` location is rejected. |
| integrity_mode | Yes | ADR-039 master switch for the values/conscience pipeline (integrity constraints). Required at the top level post-cutover; the legacy `integrity.enforcement_mode` location is rejected. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true and idempotentHint=true. The description adds value by explaining that the server performs a cascading merge (platform → org → team → agent) and writes a canonical composed card. It also notes the required Idempotency-Key, which is 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?
The description is a single, somewhat run-on sentence. It front-loads the core purpose but could be better structured with separate sentences for format, composition behavior, and idempotency requirement. It is not overly verbose but lacks optimal clarity in structure.
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 (nested input, many fields, output schema exists), the description covers key aspects: publish/replace action, accepted formats, server-side composition, and idempotency. However, it does not describe the return value or explicitly differentiate from preview. It is adequate but not fully comprehensive.
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%, but the description adds meaning beyond the schema: it specifies that the body can be YAML or JSON, and it explicitly mentions the required Idempotency-Key (which is not in the schema). This helps the agent understand input format and additional requirements.
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 'Publish or replace the alignment manifest', identifying the resource and action. It specifies accepted formats (YAML, JSON) and distinguishes itself from the sibling 'preview_compose_alignment_by_agent' by emphasizing that this endpoint performs the actual composition and write.
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 mentions the requirement for an 'Idempotency-Key', which provides some usage guidance. However, it does not explicitly advise when to use this tool versus the preview sibling or other tools, leaving the agent to infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
report_recipe_fn_fpAInspect
Submit a false-positive / false-negative correction for one of Mnemom's automated detection rules (a 'recipe') — technical feedback that improves detection accuracy, like filing a bug report against a spam filter.
| Name | Required | Description | Default |
|---|---|---|---|
| type | Yes | 'fn' (false negative — recipe should have fired) or 'fp' (false positive — recipe fired on legitimate behaviour). | |
| summary | Yes | Customer's description of what happened. | |
| agent_id | No | Optional. Customer's agent id, when the report concerns a specific agent. | |
| evidence | No | Optional raw payload / log excerpt the admin reviewer can inspect. | |
| recipeId | Yes | The detection_recipes id the report is filed against (the recipe that misfired or failed to fire). | |
| checkpoint_id | No | Optional. Related integrity_checkpoints id (helps the reviewer correlate). |
Output Schema
| Name | Required | Description |
|---|---|---|
| ok | Yes | |
| type | Yes | |
| candidate_id | Yes | |
| related_recipe_id | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description conveys that the tool submits technical feedback, but beyond the analogy to a bug report, it does not disclose behavioral traits such as side effects, persistence, or review process. Since annotations provide minimal behavioral hints (only non-destructive), the description could add more context about what happens after submission.
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, well-structured sentence that immediately states the core action and resource, followed by an effective analogy. No unnecessary words or repetition.
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 description adequately explains the tool's purpose for a simple submission action. With full schema coverage and an output schema (not shown), the description does not need to detail return values. Minor improvement would be mentioning that a report is created for admin review, but overall it is complete enough for this 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?
Input schema covers all 6 parameters with descriptions, achieving 100% coverage. The global description adds overall context but does not supplement individual parameter details. Given the high schema coverage, a 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?
The description clearly identifies the action ('submit'), resource ('correction'), and specifies the two types (false-positive/false-negative), making the purpose immediately clear. It also distinguishes the tool from all sibling tools, none of which perform a similar reporting function.
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 reporting incorrect detections, akin to filing a bug report, but it does not explicitly state when to use it or when not to, nor does it provide alternatives or prerequisites. The usage context is clear but lacks explicit guidance.
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?
The description discloses caching behavior (24h), the fresh parameter to bypass cache, rate-limiting, proxy to SSRF-locked scanner, and preservation of Ed25519 signature and permalink. These details go well beyond the annotations (readOnlyHint, idempotentHint) to provide operational context.
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 concise at three sentences, front-loads the main action, and every sentence adds essential information without 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 the tool's simplicity (2 parameters, output schema exists), the description fully covers behavior: caching, fresh scans, signatures, documentation links. No gaps remain for effective agent 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% (both parameters described). The description adds examples for 'url' and explains the 'fresh' flag's purpose, equivalence to scanner's rescan flag, and rate-limiting implications, providing value beyond the schema.
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 specifies the action and resource but does not differentiate from sibling tools like verify_scan or 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?
The description implies usage for obtaining a trust scorecard, mentions caching and the fresh flag, but provides no explicit guidance on when to use this tool versus alternatives or when not to use it.
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 provide readOnlyHint, idempotentHint, destructiveHint. Description adds key behaviors: zero-auth, public directory only, and positions it as entry point. No contradiction.
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?
Concise, front-loaded with main action, and provides flow guidance. Each sentence adds value. Could be slightly more streamlined but overall efficient.
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 output schema exists and parameters have full descriptions, the description adequately covers usage context, auth, and subsequent steps. Complete for the tool's purpose.
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 100%, so parameters are already well-documented. Description adds minimal parameter-specific detail beyond the schema, meeting the baseline for high coverage.
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 distinguishes itself from sibling tools by positioning as the entry point for discovery.
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 when to use: as the first step to discover an agent_id, then call other tools. Also mentions zero-auth and public scope. Lacks explicit 'when not to use' but provides clear positive guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
verify_agent_bindingARead-onlyIdempotentInspect
Verify that an API key is bound to this agent — confirms the holder is the accountable owner (anti-impersonation), hashing the key client-side.
| Name | Required | Description | Default |
|---|---|---|---|
| agent_id | Yes | Agent identifier (e.g. smolt-abc123) | |
| key_hash | Yes | First 16 hex chars of SHA256(apiKey) or SHA256(apiKey + '|' + agentName) for named agents. |
Output Schema
| Name | Required | Description |
|---|---|---|
| bound | Yes | True if the submitted hash matches the registered key. |
| caller | Yes | Self-describing caller context. `key_prefix` is present iff `caller` is `org_member`; `anonymous` and `authenticated` (non-member) callers receive `{ bound, caller }` only. This is BY DESIGN, not a partial or leaky response — read `caller` instead of treating an absent `key_prefix` as a leak. The boolean `bound` is an anti-impersonation confirmation that reveals nothing the caller did not already supply. |
| key_prefix | No | First 16 chars of the registered key (or null if not yet captured). Returned ONLY to callers who are members of the agent's org (`caller` === `org_member`); omitted for anonymous / cross-org callers. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, indicating safety and idempotency. The description adds the specific behavioral detail of client-side hashing, which is valuable 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?
A single well-structured sentence that front-loads the core action ('Verify that an API key is bound to this agent') and concisely explains the purpose and method without any filler.
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 annotations and presence of an output schema, the description adequately covers the tool's purpose and key behavior. It could benefit from mentioning the output format or common use cases, but these are partially covered by the output schema.
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 covers both parameters with descriptions and an example. The description adds the context that the key is hashed client-side, reinforcing the key_hash parameter's purpose. With 100% schema coverage, the description provides marginal added value.
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 action (verify), resource (API key bound to agent), and purpose (anti-impersonation). It distinguishes itself from sibling tools like verify_reputation by focusing on key binding ownership.
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 use for identity verification during impersonation concerns, but it does not explicitly state when to use this tool vs alternatives. No when-not-to-use guidance or exclusions are provided.
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, idempotentHint, and destructiveHint. The description adds behavioral context: it returns a Merkle-root + hash-chain attestation and a pointer to a signed integrity certificate, clarifying the nature of the attestation 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?
Two sentences, front-loaded with the core purpose and output, then a clarifying distinction. Every sentence earns its place, no extraneous 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?
Given the tool's simplicity (one required parameter, no nested objects), the description is complete. It explains the output nature and the type of attestation, sufficient for an agent to understand its use.
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 fully described in the schema (100% coverage). The description does not add additional meaning beyond what the schema provides, so it meets the baseline of 3.
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 attests an agent's trust rating, using specific verb 'attest' and specifying the resource. It distinguishes itself from verify_scan by clarifying it's a chain-integrity attestation, not an Ed25519 signature check.
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 contrasts with verify_scan, indicating when not to use this tool. However, it doesn't provide broader guidance on when to use this tool versus other siblings like get_reputation or scan_trust.
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?
The description adds value beyond annotations by stating the tool is zero-auth and describes the return format ({verified, key_id, canonicalization}) and verification against a public key URI. Annotations already indicate read-only, idempotent behavior, so the description enriches context without contradiction.
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 long, each serving a distinct purpose: stating the action, specifying parameters, and providing reference links. No extraneous information; every sentence is justified.
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 complexity of the tool (nested objects, output schema exists), the description covers the core purpose, input options, behavioral notes (zero-auth), and references for further detail. It fully equips an agent to invoke the tool 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?
Schema coverage is 100%, but the description adds context: the scan parameter originates from scan_trust, and the url parameter triggers a re-scan. This goes beyond the schema descriptions, which detail object properties but not the behavioral implications of each parameter.
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 verifies the Ed25519 signature of a website scan scorecard in-band. It explicitly distinguishes itself from siblings by focusing on verification of scan scorecards, as opposed to scanning (scan_trust) or verifying other entities (verify_agent_binding, 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 explains the tool accepts a scan from scan_trust or a URL to re-scan, implying when to use it after obtaining a scorecard. However, it does not explicitly state when not to use it or provide direct comparisons to alternatives, which would elevate it to a 5.
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!