Synpareia Trust Toolkit
OfficialServer Quality Checklist
Latest release: v0.9.0
- Disambiguation4/5
Tools are generally well-separated by domain (identity, reputation, recording, witness, claims), with detailed descriptions distinguishing similar functions. A few pairs (e.g., make_claim vs encode_signed, record_interaction vs remember_counterparty) could cause misselection if descriptions are skimmed, but the distinctions are substantive.
Naming Consistency4/5Most tools follow a verb_noun snake_case pattern (publish_profile, verify_claim, recording_start), and witness/recording prefixes group related families. Minor deviations include bare verbs 'orient' and 'learn', and a handful of noun-phrase names (attested_reputation, network_reputation), but the overall pattern is predictable.
Tool Count2/536 tools is well beyond the 25+ threshold for heavy, even though the toolkit covers a broad trust/identity domain. The count risks overwhelming agents and suggests the surface could be consolidated (e.g., combining witness_* or recording_* into fewer parameterized tools).
Completeness5/5The surface is remarkably complete: identity lifecycle, local journal, network reputation, consent, persistence, claims, recordings, witness seals, and blind exchanges are all covered. There are no obvious dead ends, and even edge cases like consent withdrawal and erasure are handled.
Average 4.3/5 across 36 of 36 tools scored. Lowest: 3.3/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 10 commits in the last 12 weeks
- Last stable release on
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under Apache 2.0.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
This repository includes a glama.json configuration file.
If you are the author, simply .
If the server belongs to an organization, first add
glama.jsonto the root of your repository:{ "$schema": "https://glama.ai/mcp/schemas/server.json", "maintainers": [ "your-github-username" ] }Then . Browse examples.
Add related servers to improve discoverability.
How to sync the server with GitHub?
Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.
To manually sync the server, click the "Sync Server" button in the MCP server admin interface.
How is the quality score calculated?
The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).
Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.
Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).
Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.
Tool Scores
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description mentions 'recovers identity and in-flight recordings' but does not explain how it works without parameters, or whether it is read-only. It assumes conversational context without clarification, leaving behavioral traits under-specified given no annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Description is one concise paragraph with key usage guidance and a behavioral note. Slightly verbose due to example phrasing, but overall efficient and front-loaded with the primary purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for a zero-parameter tool with output schema, but lacks clarity on output format and how context is consumed. The description covers when to use but not what the tool returns or how it integrates with siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has zero parameters (100% coverage), so minimal need for parameter explanation. However, description implies the tool uses 'situation' from context, which is not captured in schema, causing ambiguity about how input is provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
Description uses 'map your situation to the right trust tools' implying a recommendation function, but the core action is vague and not explicitly stated as a tool suggestion or decision support. Lacks a specific verb-resource pairing like 'suggest tools' or 'recommend actions'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to call: when stakes are high with another agent or after context loss. Provides clear scenarios (rely, prove, agree, recover identity) and distinguishes from sibling tools by positioning itself as a meta-advice tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that the envelope is self-attested, returns specific tiers, and can be dropped into any transport. However, it omits potential failure modes, size limits, or auth requirements, which are relevant for a signing tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is four sentences, front-loading the purpose, then adding usage and return info. Every sentence adds value with no redundancy. Highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has one parameter and an output schema (not shown), the description covers the main output characteristics (self-contained string, tiers). It lacks error handling or edge-case details, but for a simple wrap tool, it is fairly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% for the single parameter 'content'. The description mentions 'wrap content' but provides no guidance on expected format, length, or constraints. Since the schema does not describe the parameter, the description should have compensated but barely does.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool wraps content as a signed synpareia envelope, with a specific verb and resource. It distinguishes from siblings like decode_signed and make_claim. However, jargon like 'Tier 4' and 'synpareia' may reduce clarity for agents unfamiliar with the domain.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use the tool—producing a portable signed envelope for any transport—and hints at an alternative (make_claim for witness upgrade). It does not explicitly state when not to use it, but the context is clear enough for selection among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description reveals key steps (loading, overriding, signing, publishing) and return values. However, it lacks details on error conditions, reversibility, or required permissions, leaving some behavioral aspects unclear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise and well-structured, front-loading the main action and progressively adding details. Every sentence provides necessary information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the existence of an output schema and the complexity of 9 parameters, the description covers the main workflow and return type but omits prerequisites (e.g., must have a published card) and error handling, limiting completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not explain any of the 9 parameters beyond listing them in the schema. With 0% schema description coverage, it fails to add semantic value, leaving the agent to rely solely on parameter names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action: updating card fields and re-publishing. It specifies the process (loads, applies overrides, signs, publishes) and distinguishes from siblings by mentioning that persistence opt-in is handled via a different tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for modifying an existing published profile, noting that fields not supplied are preserved and that persistence cannot be withdrawn here. It indirectly guides users to use 'disable_persistence' for that purpose, but does not explicitly contrast with 'publish_profile' for creation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description covers behavioral traits: identity layer source, operator-controlled fields, return value format, default persistence opt-in (no opt-in, GDPR-default), and environment variable requirement. It does not mention failure modes or whether publishing overwrites an existing card.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three paragraphs, front-loaded with the main action, and covers key points without excessive verbosity. It could be slightly more structured but is efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 10 parameters, 1 required, and an output schema mentioned, the description covers high-level behavior, identity, persistence, and env requirement. However, it lacks parameter-level details and does not explain the 'operator-controlled' concept fully, leaving some gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain individual parameters. It only mentions 'name' indirectly and refers to 'other fields' as operator-controlled. No detail on skills, url, version, provider, etc.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Build, sign, and publish your agent card to the directory.' It specifies the verb (publish), resource (agent card), and distinguishes from sibling tools like delete_profile or get_profile.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context: identity comes from local profile, persistence opt-in is separate, and requires SYNPAREIA_NETWORK_URL. It implies this is for publishing but lacks explicit when-not-to-use or comparison with alternatives like update_profile_policy.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the action (tombstone/delete), the return format ({ok: True} or structured error), and a specific error condition (403). However, it does not address idempotency, reversibility, or authorization requirements, leaving gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences, front-loading the main action and then providing key error context. Every sentence adds value, though it could be slightly more structured for readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (single row deletion with a precondition), the description covers the action, return type, and critical error condition. It does not elaborate on the full implications of tombstoning, but with an output schema available, return values need not be fully described.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must explain parameters. It implicitly ties 'version' to the card-version row but does not describe 'reason' at all. The description adds minimal value beyond the schema's type definitions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'tombstone' and identifies the exact resource: 'a single card-version row in the operator's history.' This clearly distinguishes it from sibling like 'delete_profile' which targets the entire profile.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains a key precondition: the call is rejected if the persistence opt-in includes 'card_history', and directs to 'disable_persistence' first. This provides clear usage guidance, though it does not explicitly compare against other history-related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses the signing action and purpose, but lacks details on side effects (is it a write operation?), idempotency, or permission requirements. No annotations to supplement.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Four sentences, front-loaded with action and parameters. The example scenario adds length but improves understanding. Reasonably concise for the complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose and basic behavior, but missing return value description, error conditions (e.g., invalid head hash), and prerequisites. Adequate but leaves gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Adds meaning to chain_head_hex (hex format) and implies both parameters are used for signing. However, chain_id format is not specified, and schema coverage is 0%. Partially compensates.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: checkpointing a chain's state via witness signing. It distinguishes from sibling tools like witness_seal_timestamp by focusing on state proof, not timestamp sealing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides a concrete use case (proving no retcon) and explains the cryptographic mechanism. Missing explicit when-not-to-use or alternatives, but the context is strong for applicability.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It states that the tool returns matches annotated with 'identifier' and 'display_names', implying read-only behavior. However, it does not explicitly confirm that no mutations occur, nor does it mention any side effects, permissions, or performance characteristics. This is adequate but not thorough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, consisting of three short paragraphs. The main purpose is front-loaded in the first sentence. Examples and a usage note follow without excess. Every sentence adds value, though the note on tag consistency could be integrated more succinctly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter) and the existence of an output schema (which covers return structure), the description is reasonably complete. It explains what is returned (identifier and display_names), gives usage patterns, and sets expectations about tag conventions. It lacks explicit mention of counterparty scope or authentication, but these are minor gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has a single required parameter 'tag' with no description (schema coverage 0%). The description compensates somewhat by providing three concrete example tags ('missed_deadline', 'shipped_on_time', 'unreliable') and noting that tag vocabulary is agent-convention. However, it does not define what a tag is, its format, or constraints, leaving some ambiguity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches 'Tier-1 evaluations across all counterparties by tag'. It uses a specific verb ('Search') and resource ('evaluations'), and distinguishes itself from sibling tools like 'add_evaluation' (which adds) and 'evaluate_agent' (which evaluates). The scope ('across all counterparties') further differentiates it.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides example usage patterns (e.g., find_evaluations('missed_deadline')) and advises on tag consistency, which helps the agent understand typical use. However, it does not explicitly state when NOT to use this tool or suggest alternatives, though this is less critical for a simple search tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully bears the burden of behavioral disclosure. It clearly states the return values (did, exists, name, etc.) and the edge case for unknown DIDs (exists=False with a fixed-shape envelope). This provides strong transparency about what the tool does and its safety profile (read-only).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, no wasted words. The first sentence states the purpose, the second explains the return structure and edge-case behavior. It is front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given there is only one parameter and an output schema exists, the description is nearly complete. It covers the purpose, return shape, and edge-case. However, it lacks explanation of the DID parameter itself (what it is, format), which would make it fully complete for a tool with no annotation support.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, and the description only mentions 'by DID' without elaborating on the parameter format, constraints, or what constitutes a valid DID. Since the schema offers no structural detail beyond type and title, the description should compensate but does not provide sufficient semantic meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states it fetches a published agent card by DID, using specific verb 'Fetch' and resource 'agent card'. It distinguishes from sibling tools like delete_profile and publish_profile by focusing on read-only retrieval. The return format is also specified, making the purpose crystal clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for retrieving a profile by DID, but it does not explicitly state when to use it versus alternatives like search or evaluation tools. No exclusions or contextual triggers are provided, so the guidance is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses signing, hash-linking, tamper evidence, and event_type validation. It lacks details on error conditions, prerequisites (active recording), or idempotency, but covers key behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with a clear first sentence and supporting paragraphs. It avoids redundancy but could be slightly more structured (e.g., bullet points for constraints).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema, return values are not needed. However, the description omits prerequisites (active recording must exist), error handling, and size limits, leaving some ambiguity for a mutation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but description only adds meaning for event_type (allowed values). Content and recording_id receive no additional semantic explanation beyond their names, leaving significant gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Append'), the resource ('signed, hash-linked block'), and the context ('to an active recording'). This distinguishes it from sibling tools like recording_start, recording_end, and recording_list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use the tool (to append a block to an active recording) and specifies valid event_type values. However, it does not explicitly state when not to use it or mention alternatives, though context from sibling tools makes the purpose clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It explains parameter roles but does not disclose error behavior (e.g., what happens if identifier doesn't exist), side effects, or any constraints beyond the parameter descriptions. The mention that score has no imposed scale is good, but more transparency about failures would improve the score.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (6 sentences) and well-structured: it starts with the main purpose, then explains each parameter in a logical order. Every sentence adds value, and there is no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 4 parameters and the presence of an output schema (which the description need not explain), the description covers the key points. However, it falls short by not mentioning what happens on failure (e.g., invalid identifier) or any return value summary. The missing error handling context leaves a gap for agents.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Since schema description coverage is 0%, the description adds significant value: it explains that text is required, tags enable search, score is a free float with no conventional scale, and identifier must exist. This goes beyond the raw schema and provides meaningful usage context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'attach' and the resource 'evaluation to an existing counterparty record'. It distinguishes itself from siblings like 'remember_counterparty' (which creates the record) and 'find_evaluations' (which searches for evaluations), making the purpose specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit context: identifier must already exist, and if it's a new counterparty, call remember_counterparty first. It explains the optional parameters (tags for search, score as free float) and notes that using them enables search affordances. While it doesn't explicitly state when NOT to use the tool, the guidelines are clear and practical.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but the description explains the behavioral protocol: sealing an assessment via a commitment hash and nonce. It also instructs on subsequent verification steps. Does not detail store/side effects, but adequately covers key behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Very concise (3 sentences) with each sentence adding value. Front-loaded with purpose. Could be slightly more structured but efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given one parameter and an output schema (not shown), the description provides sufficient context for an agent to use the tool correctly. Includes follow-up steps (verify with verify_claim). Minor ambiguity about return format but acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter content is not explicitly described; the description implies it is the assessment to be sealed but does not specify format or constraints. With 0% schema coverage, the description should provide more explicit parameter meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool seals an assessment before seeing others', establishing a commitment protocol. It distinguishes from siblings like make_claim and verify_claim by specifying the role in a commitment-reveal pattern.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says when to use (before seeing others' assessments) and what to do with the outputs: share only commitment_hash, keep nonce_b64 secret, and later verify with verify_claim. It lacks explicit when-not-to-use or alternatives but is sufficiently specific.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must cover behavioral aspects. It explains the three types and the aliasing of did for agent_did in identity verification. However, it lacks details on side effects, permissions, error handling, or return values.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two clear paragraphs: a one-sentence purpose followed by type enumeration and alias explanation. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 8 parameters and one required, the description adequately covers the main usage patterns (three types) and the alias feature. It could mention return values or error conditions, but an output schema exists to cover those.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Given 0% schema coverage, the description compensates by mapping parameters to claim types and explaining the did/agent_did alias. This adds crucial meaning beyond the raw schema, though not all 8 parameters are individually detailed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Verify a claim' and enumerates three distinct verification types (signature, identity, commitment), which distinguishes it from sibling tools like make_claim and decode_signed.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use each type based on the claim_type, but does not explicitly state when not to use this tool or provide direct comparisons to sibling tools. Usage is implied through the type enumeration.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden and discloses that the result always contains signature and verification instructions, explains synchronous nature, and details witness followup behavior. It lacks error handling or security notes but covers key behavioral aspects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with purpose first, then witness workflow. It is efficient and front-loaded, though the second paragraph could be slightly more concise without losing clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given an output schema exists, the description need not detail all return values. It mentions signature, verification instructions, and witness followup fields. Together with sibling context, it provides sufficient completeness for an agent to use the tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so description must compensate. It thoroughly explains the 'witness' parameter (behavior, result format, chaining), but for 'content' it only says 'Sign content' without specifying format (e.g., plain text, JSON), leaving ambiguity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'Sign content with your private key, creating a verifiable claim.' This is a specific verb and resource, and it clearly distinguishes the tool from siblings like 'verify_claim' or 'encode_signed' by focusing on claim creation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains the workflow for witness mode, including how to chain with the async 'witness_seal_timestamp' tool. However, it does not explicitly state when not to use this tool or provide alternative scenarios, though the witness guidance is helpful.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations present, the description carries full responsibility. It discloses that the tool returns status and commitment hashes, and includes a behavioral note about self-asserted identities. It does not explicitly state idempotency or side effects, but the read-only nature is implied. The transparency is good but could mention error handling or behavior before any submission.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three well-structured sentences: purpose, return values, and a key limitation. Every sentence adds essential information with no redundancy. It is appropriately front-loaded and concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (1 parameter, no output schema, no annotations), the description covers the core functionality, return values, and a behavioral limitation. It references the paired sibling tool. It does not describe error cases or behavior when called before any commitment exists, but overall it provides sufficient context for an agent to understand and use the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% (no descriptions in schema), so the description must compensate. It does not individually describe the 'conclusion_key' parameter, its format, or constraints. The parameter's meaning is only implied through the tool's context. This is insufficient for an agent to understand exactly what value to provide, especially without schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'Check the status of a blind conclusion exchange' with a specific verb and resource. It distinguishes from siblings by referencing 'Pair to `witness_submit_blind`' and details what it returns: whether both parties submitted and commitment hashes. This is a clear, unambiguous purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context by stating it pairs with `witness_submit_blind`, indicating an intended usage sequence. It does not explicitly state when not to use it, but the pairing hint and explanation of return values effectively guide appropriate usage. No exclusion criteria are needed for such a focused tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses that the witness does not verify identity, that identity is self-asserted in v1, and that commitments are revealed only after both submissions. It adds context beyond basic usage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a purpose statement, a concept paragraph, a numbered flow, and a note. While informative, it is slightly verbose; each sentence earns its place but could be tightened.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a blind conclusion exchange, the description covers the concept, flow, and caveats well. It lacks return value information since there is no output schema, but the tool likely returns a confirmation or status.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must explain parameters. It describes conclusion_key as a shared identifier with examples, and mentions commitment_hash_hex as the hash. However, it does not specify exact format (e.g., hex length, hash algorithm) or constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool submits a committed assessment to a blind conclusion exchange, with a detailed explanation of the concept. It distinguishes from siblings like prove_independence (local sealing) and witness_get_blind (retrieval of commitments).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description outlines the flow: both parties must first seal locally via prove_independence, then use this tool with the same conclusion_key. It provides clear context on when to use, though it does not explicitly state when not to use or name alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It details data sources (synpareia network, MolTrust), labeling behavior, and critically states 'Absent config returns a structured not_configured response... never raises.' This covers error handling and mutation safety comprehensively.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two well-structured paragraphs: first one states action and parameter, second adds details. It is concise with no redundant sentences, though the tier comparison adds some length but is informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given one parameter and an existing output schema, the description explains return format (signals with provider labels, not_configured response) and tier levels. It does not cover pagination or ordering, but those may be in the output schema. Overall adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, forcing description to compensate. The description explains 'identifier' as a 'DID, provider-scoped ID, or opaque network handle,' adding meaningful context beyond the schema's generic string type. For a single parameter, this is sufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool 'query[ies] signed reputation for a counterparty from attestation networks' and specifies the identifier type. It differentiates from siblings by mentioning 'Tier 3' and contrasting with Tier 1 and 2, but does not explicitly distinguish from tools like recall_counterparty or find_evaluations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use this tool (query signed reputation from Tier 3 networks) and provides context on tier hierarchy. It also describes the 'not_configured' response and env var guidance. However, it does not explicitly list alternative tools or exclusionary rules.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It implies a read-only operation ('Load a detailed guide') but does not explicitly state it has no side effects or describe the output format. It does add useful behavioral details about form keying ('form-*') and indexing via learn('interaction-forms'), which goes beyond a bare description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences and front-loaded with the primary action. The long list of areas is necessary and not fluff. It is slightly dense, but every sentence earns its place; no redundant or irrelevant wording.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given a single parameter, an output schema, and no annotations, the description adequately covers the argument and usage. It does not describe the return guide structure, but output schema likely handles that. It is complete enough for an agent to select and call the tool appropriately.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides only a bare 'area' string with 0% description coverage. The description compensates fully by enumerating all valid areas (deciding-what-to-establish, interaction-forms, etc.) and explaining how to discover forms dynamically. This is exactly the meaning an agent needs to invoke the tool correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool loads a detailed guide for one area or the recipe for one interaction Form, using specific verbs ('load') and resources ('guide', 'recipe'). It distinguishes itself from the sibling action tools by being a meta/educational tool, and enumerates exact area names.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides clear context for when to use the tool (to obtain guides or recipes) and gives specific guidance for accessing interaction forms via the keying convention and the indexing command. It does not explicitly name alternatives or exclusions, but the context is sufficient for an agent to understand the tool's role.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral disclosure burden. It reveals that after the call the chain is closed, append is blocked, and proof export remains possible. It also describes how optional parameters are embedded as a closing block. However, it does not explicitly state that the operation is irreversible or mention any side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences long, front-loaded with the primary purpose, and each sentence adds essential information. There is no redundancy or wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and the presence of an output schema (so return values need not be explained), the description covers purpose, consequences, and parameter roles. It could be improved by mentioning prerequisites (e.g., an active recording) or potential errors, but overall it is fairly complete for a tool of moderate complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains that 'rating' (1-5) and 'notes' are embedded as the closing block for summary assessment. However, it does not describe the 'recording_id' parameter beyond its role implied by context. Meaning is added for two of three parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Finalize a recording and persist the chain.' It uses specific verbs and resources, and distinguishes from siblings by noting that after this call no further 'recording_append' is possible, and the chain remains exportable via 'recording_proof'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool (to close a recording after appending) and mentions a related tool ('recording_proof') for export. However, it does not explicitly state when not to use it or provide direct alternatives for finalization.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes return format and interpretation (empty lists not errors), but does not explicitly state side effects or permissions. Given no annotations, it covers basic behavior but lacks depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Description is concise, well-structured, and front-loaded. Each sentence provides essential information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers parameters, return structure, and usage intent well. Lacks mention of error conditions or prerequisites, but overall complete for a read-like evaluation tool with no required parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% coverage, but description explains each parameter in detail: namespace as platform context, id as identifier, namespace_id as shortcut from remember_counterparty. Fully compensates.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'Evaluate a counterparty across every configured tier', with specific verb and resource. Distinguishes from siblings like 'find_evaluations' because it evaluates across all tiers.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explains how to route with namespace+id or namespace_id, and provides context for when to use each. No explicit when-not but adequate guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description covers behavioral aspects: the witness signs the hash with its private key, returns a SealPayload, and emphasizes it's an independent third-party signature. It does not detail authorization or rate limits, but for a simple timestamp tool, this is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is reasonably concise with no redundant words. It uses line breaks for readability. Could be slightly shorter, but it's well-structured and front-loaded with the key action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given one parameter, no output schema, and no annotations, the description covers input requirements, the signing process, return value (SealPayload), and verification counterpart. It feels complete for the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter block_hash_hex lacks schema description (0% coverage). The description adds meaning by specifying it's a hex-encoded content hash, which is essential for proper usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool timestamps a block using a witness to prove existence. It distinguishes itself from sibling tools like witness_verify_seal and witness_seal_state by focusing on creation of the seal.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells when to use the tool ('to create evidence that a decision, claim, or observation predates some later event') and mentions verification with witness_verify_seal. It does not explicitly state when not to use it, but provides sufficient usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully carries the burden. It details the return shape, explains edge cases (synpareia_validated=False and True with valid=False), and explicitly states 'never raises'. This is very transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise: one main action sentence and a structured list of return fields. Every part is informative and front-loaded. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter) and the presence of an output schema, the description is complete. It explains the tool's behavior, return shape, and edge cases, leaving no obvious gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and the description adds no additional meaning about the 'encoded' parameter beyond its name. It doesn't specify format or constraints, leaving the agent to infer from context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'unwrap' and resource 'synpareia-signed envelope', clearly distinguishing it from siblings like encode_signed and verify_claim.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The purpose is clear and implicitly differentiates from encode_signed (inverse operation), but no explicit when-to-use or when-not-to-use guidance for alternatives is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It comprehensively discloses cascade-tombstone behavior, the 403 error with code persistence_opt_in, the annotation of the local file with tombstoned_at and tombstoned_reason, and the effect on the 'orient' tool's directory.published flag.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear main statement followed by details. It is somewhat long but every sentence adds value. Could be slightly more concise, but overall effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema (not detailed here but indicated), the description covers behavior, side effects, error conditions, and comparison. The only missing piece is the 'reason' parameter documentation, which prevents a perfect score.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one optional parameter 'reason', but the description does not mention it at all. With 0% schema description coverage, the description should add meaning to this parameter. This is a significant gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Cascade-tombstone every history row for the operator's profile.' It distinguishes itself from sibling tool 'delete_profile_history' by specifying it performs a cascade-tombstone and references persistence-opt-in semantics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool versus alternatives: it mentions the persistence-opt-in error behavior, explains that the local cached card remains but is annotated, and suggests manual removal for a fully-clean slate. It also references 'delete_profile_history' for comparison.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully covers behavioral traits: it states the output is JSON, contains a hash-linked chain, is safe to share, does not contain private keys, and can be verified offline. This is comprehensive for an export tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is relatively concise, with a slight overhead from the code block, but every sentence adds value. It avoids redundancy and is front-loaded with the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, output schema exists), the description covers all necessary aspects: purpose, output format, verification method, and safety guarantees. No further information is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter, recording_id, is self-explanatory from its name, but the description does not elaborate on it. With 0% schema coverage, the description could add more detail (e.g., format or constraints), but the parameter's simplicity mitigates this.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the action ('Export a recording'), the resource ('as an independently verifiable proof bundle'), and provides a unique output format. This clearly distinguishes it from sibling tools like recording_list or recording_start.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for offline verification and provides a code example, but it does not explicitly state when not to use this tool or suggest alternatives among siblings. It gives good context for appropriate use but lacks exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses key behavioral traits: the opt-in is recorded with timestamp, re-published in the next card, and withdrawal via disable_persistence is prospective only. It also notes that verifiers expect data to remain available. It does not detail error conditions but sufficiently covers the primary behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is six sentences with a clear front-loaded purpose. Every sentence adds value—explaining scope, implications, non-reversibility, and prerequisites—without any fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has one parameter and an output schema exists, the description covers all necessary context: purpose, parameter details, behavioral effects, relationship to disable_persistence, and prerequisite. It is 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.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description fully explains the 'scope' parameter: it lists the three categories (card_history, key_chain, reputation) and their meanings, adding essential context beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool opts into non-erasure persistence and re-publishes, using specific verbs and resource. It distinguishes from the sibling 'disable_persistence' by describing the opt-in and prospective withdrawal behavior.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use it (to commit to keeping persistent data like card_history, key_chain, reputation) and mentions a prerequisite (requires a previously-published card on disk). It lacks explicit exclusions but provides clear usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but description discloses that signals are self-reported, directional, and have reputation_tier=2 and assurance_tier=1. It mentions possible no_adapter response. Could mention any limitations or side effects but sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Description is well-structured and mostly concise, though slightly wordy in explaining parameters in two separate sentences. Generally efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema, the description provides necessary context: supported platform, fallback behavior, and signal nature. 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.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema coverage, description fully explains both parameters: namespace as the platform (with examples) and handle as the counterparty identifier. Adds meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool queries media-platform reputation signals for a counterparty. It explains parameters namespace and handle, and distinguishes from siblings by specifying which platforms are supported and fallback options.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use: for Moltbook (supported) and when not: other namespaces return no_adapter status. Provides guidance to fallback to remember_counterparty + add_evaluation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must convey behavioral traits. It states the tool only returns in-progress recordings, implying it is read-only and non-destructive. It could further mention no side effects, but the current description is sufficient for a lightweight peek.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise: two sentences with a clear front-loaded purpose and a line for alternatives. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters and an output schema (implied), the description fully covers the tool's purpose, usage guidance, and limitations. It leaves no obvious gaps for an agent to misuse.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, and the baseline score is 4. The description does not need to add parameter details, and the schema coverage is 100%.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists recordings that are currently in progress, using a specific verb ('list') and resource ('recordings'). It distinguishes from sibling tools like recording_start, recording_end, and the resource for ended recordings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says when to use this tool (lost track of in-flight recording_id, check for open sessions) and when not to (for ended recordings, use synpareia://recordings). It provides clear context and alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but description fully explains the hash-linked chain, tamper-evidence, creation of recording_id, active until recording_end, and exportable as cryptographic proof. 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise paragraphs with front-loaded purpose. Every sentence adds value; no redundancy. Well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity, presence of siblings, and no annotations, the description is complete: explains lifecycle, data structure, and usage. Output schema exists, so return value explanation is adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but description adds meaning for both parameters: description is the interaction being recorded, counterparty_did is optional but recommended for dialogues and embedded in the chain. More detail on format would improve.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool begins a tamper-evident recording, distinguishing it from siblings like recording_append, recording_end, recording_list, and recording_proof. The verb 'begin' and resource 'recording' are specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context: when to start a recording, mentions subsequent calls (recording_append) and termination (recording_end), and optional counterparty_did for dialogues. Lacks explicit when-not-to-use or alternatives, but sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden and exceeds expectations. It discloses content policy ('This tool records no content'), idempotency semantics ('The same id records once; a new id records again'), opt-in consent requirements, and environment prerequisites ('Requires SYNPAREIA_NETWORK_URL and a published identity'). It even notes the residual risk of author-chosen slugs in the broader system, showing deep transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with bold leads, section separation, and bullet lists that make key facts scannable. However, the extended discussion about the network-level context slug allowlist and the 'earlier version of this note' is tangential to using this tool and adds verbosity without direct operational value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, the description covers everything an agent needs: when to use, parameter meanings, failure modes, privacy semantics, idempotency, and required environment. It preempts common mistakes (e.g., retrying on opt-in failure, assuming content can be recorded) and fully addresses the high complexity of a shared-network write tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description compensates fully with detailed bullet explanations for magnitude (scale and driving weight), valence (omission semantics), shareable (two-sided consent), and event_id (retry safety). Only counterparty_did is not explicitly described, but its meaning is clear from context and the sibling tool ecosystem.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Record that you dealt with another agent, and optionally how it went.' It clearly distinguishes this tool from siblings by stating 'This writes to the shared network, not your local journal,' identifying the unique network-facing interaction-recording scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit guidance is provided on when to use: 'Use it after a real interaction — a job done, a claim verified, a commitment kept or broken.' It also clarifies a key non-error failure mode and remedy: 'If the counterparty has not opted in, this fails and that is not an error in your request... the remedy is to ask them, not to retry.' However, it does not name alternative sibling tools (e.g., remember_counterparty) for other use cases, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but description fully discloses behavioral traits: upsert semantics, display_name history accumulation, custom_fields constraints (primitive values only, no nested dicts), and return of record dict with identifier.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with bullet-like formatting, each sentence adds value. Slightly verbose but not wasteful; could tighten a few phrases.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity, no annotations, and 0% schema coverage, the description is thorough: explains return format, usage with sibling tools, and parameter constraints. Context signals fully addressed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema coverage, description adds full meaning for all 4 parameters, including namespace/namespace_id as match key, display_name history, and custom_fields restrictions beyond schema types.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Create or update a Tier-1 local record for a counterparty' with specific verb and resource. It distinguishes from siblings like recall_counterparty and add_evaluation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides context for use with upserts and references recall_counterparty and add_evaluation for related operations, but lacks explicit when-not-to-use or alternatives section.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses return fields and requirement, but could explicitly state it's a read-only operation. Still adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Concise, front-loaded, with three clear sections: purpose, context, return fields and requirement. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description explains return values and requirement. Complexity is low, and coverage is complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist (0 params = baseline 4). Description adds context about what is returned, which is sufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool fetches the witness service's identity and public key, distinguishing it from sibling tools like witness_verify_seal and seal tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance: retrieve public key once, then use with witness_verify_seal for offline verification. Also notes the environment variable requirement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description fully discloses behavior: it operates offline, reconstructs the envelope, checks Ed25519 signature, returns valid: True/False, and returns a specific error for missing target fields. It explains that missing targets lead to incomplete_verification_input error, not a false valid flag. No annotations are provided, so the description carries the full burden and meets it well.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: an opening summary, usage guidance, specifics for seal types and aliases, and return value/error behavior. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no output schema and 10 parameters, the description is remarkably complete. It explains the input expected from seal responses, the difference between seal types, alias handling, the boolean output, and the error condition. No important aspects are omitted.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 10 parameters with 0% description coverage. The description explains the key target parameters (target_block_hash_hex for timestamp, target_chain_id and target_chain_head_hex for state) and alias fields (target_block_hash, target_chain_head). It implies the other required parameters come from the seal response, but does not explicitly describe each one. This provides valuable context beyond the schema, though not exhaustive.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool verifies witness seals offline, reconstructing the signing envelope and checking Ed25519 signatures. It distinguishes itself from sibling tools like witness_seal_timestamp and witness_seal_state by emphasizing offline verification and using their responses as input.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use the tool: for verifying seals offline by feeding fields from witness_seal_timestamp or witness_seal_state responses. It explains the difference between timestamp and state seals and mentions alias field names for backward compatibility. However, it does not mention when not to use this tool versus other verification tools like verify_claim.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite no annotations, the description covers all key behavioral traits: read-only nature, case-insensitive search, return of multiple matches, empty list for no matches, and interpretation of a Tier-1 miss. This is thorough and prevents misinterpretation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is four sentences, each adding essential information. It is front-loaded with the core purpose, followed by input details, output behavior, and a clarifying note. No redundant or vague statements.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only lookup tool with one parameter and output schema indicated, the description covers all necessary aspects: input, output, behavior on missing data, and usage responsibility. It is complete and leaves no ambiguity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, but the description fully explains the single parameter 'identifier_or_name', detailing acceptable formats (local:... or DID alias, display name) and constraints (exact or historical, case-insensitive). This compensates entirely for the schema gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Look up'), the resource ('counterparty'), the scope ('Tier-1 local journal'), and the mode ('read-only'). It effectively distinguishes this tool from its sibling 'remember_counterparty' which is likely a write operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear guidance on acceptable inputs (identifier or display name) and output behavior (returns every match, agent disambiguation). Implies read-only use, but does not explicitly state when not to use the tool or mention alternatives beyond the context of sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses key behavioral traits: prospective withdrawal, data accumulation retained, future erasure success, and blocked publishes only with new opt-in, without contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Very concise, front-loaded description with no redundant sentences, every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters and presence of output schema, description fully explains effect and side effects, making it complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist; baseline score 4 applies as description adds no parameter info, which is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Withdraw the persistence opt-in and re-publish', specifying the action and distinguishing from sibling 'enable_persistence'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explains prospective nature, data retention, future behavior of erasure calls, and condition for blocked deletion, guiding when to use and what to expect.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It details permanent removal of Tier-1 record, display-name history, custom fields, notes/scores. It clarifies what is NOT touched (conversation files) and describes idempotent behavior and response structure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is lengthy but well-structured with clear sections. The GDPR reference adds some verbosity but is relevant. Every sentence adds value, though could be slightly tighter.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity and presence of output schema, the description covers all key aspects: action, scope, limitations, idempotency, and related tools. It is complete for an agent to understand and invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter `identifier` is documented in the description as expecting a `local:...` id or a DID alias, adding meaning beyond the schema's type string. Schema coverage is 0%, but description compensates fully.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool erases a counterparty and all evaluations from the local journal. It specifies the resource and action, and distinguishes from the sibling tool `delete_profile` by noting the tool operates on the local journal vs directory-side.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit when-to-use (erasure under user control, GDPR enforcement) and when-not-to-use (does not delete conversation chains). It suggests calling `recall_counterparty` first for confirmation, and explains idempotent behavior.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and exceeds it. It discloses return semantics (magnitude range, confidence as non-probability weight), scalar meaning at 0.0, vantage-specific computation, anonymity of reports, impossibility of discovering DIDs, and signing requirements. This is exceptional behavioral transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but every paragraph earns its place. It uses bolded key terms, a clear opening line, 'Advisory' marker, and logical flow from purpose to interpretation to caveats. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite its complexity, the description is complete: return values, interpretation pitfalls, privacy guarantees, prerequisites, and edge cases are all covered. It stands alone even without an output schema, and the explicit distinction from sibling tools provides full contextual grounding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although the schema only lists counterparty_did, the description enriches it substantially: it explains the parameter is a DID, that results are computed relative to your own DID, and that an unknown DID yields confidence 0.0. It also explicitly addresses the 'unknown agent' edge case, fully compensating for the schema's lack of detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Ask the network what it can tell you about another agent.' It clearly distinguishes itself from siblings by naming record_interaction as its counterpart ('The other half of record_interaction') and referencing recall_counterparty and check_media_signals as distinct inputs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage guidance is explicit: it contrasts with record_interaction ('That tool tells the network what happened; this one asks the network what others have told it'), and the 'Advisory' section explicitly frames it as one input among others, naming alternatives. It also specifies prerequisites (SYNPAREIA_NETWORK_URL, published identity) and a critical reading order ('Check confidence first').
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully discloses critical behaviors: hard rejection of un-consented events, prospective withdrawal (no erasure of past recordings), the difference between omitting an argument and passing [] (null vs empty array), and the requirement for a previously-published card. This is exemplary transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Although detailed, every sentence adds critical value. The structure is logical: main action first, then the why (refusal), then the two axes, then the middle state, then channel examples, then withdrawal semantics, and finally argument handling. No unnecessary verbiage; it is as concise as the complexity demands.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers all necessary aspects for correct tool use: consent necessity, axes semantics, common channels, free-form channel names, prospective withdrawal, omission vs [] behavior, and the prerequisite of a published card. Given the tool's complexity and the presence of an output schema, nothing important is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description compensates fully by defining both parameters in depth: accept_attestations as 'may-record' channels and accept_delivery as 'may-serve' channels. It also clarifies nuanced semantics like 'deliver-without-record does nothing' and the distinct handling of omission vs [].
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Declare which channels others may record — and serve — events about you on.' It distinguishes between the two independent axes (accept_attestations and accept_delivery) and differentiates this from recording, erasure, and other sibling tools by focusing on consent management.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly explains when this tool is necessary: 'Without this, you are un-recordable' and that the network refuses un-consented events. It also describes useful sub-cases (record-without-deliver) and points to erasure tools for withdrawal, giving clear context for when to use this tool versus alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
GitHub Badge
Glama performs regular codebase and documentation scans to:
- Confirm that the MCP server is working as expected.
- Confirm that there are no obvious security issues.
- Evaluate tool definition quality.
Our badge communicates server capabilities, safety, and installation instructions.
Card Badge
Copy to your README.md:
Score Badge
Copy to your README.md:
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
MCP directory API
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/synpareia/trust-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server