Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Discloses important behavioral traits beyond annotations: no step-up needed, and reading notes during countdown is safe and never cancels. This adds value beyond idempotentHint and destructiveHint annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three sentences, front-loaded with purpose, each sentence adds value. No waste.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Covers behavior, safety, and uniqueness well for a simple tool. However, lacks parameter explanation, which reduces completeness slightly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0% and there is no description of the session_token parameter. The description does not add meaning to the parameter, which is a gap given the low coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'cancel' and the resource 'account deletion' with specific scope: 'whichever phase'. It also distinguishes from siblings by asserting that nothing else does this implicitly.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides clear context on when to use (cancel pending deletion) and explicitly states no alternative does this implicitly. While it doesn't list when-not-to-use, the context is sufficient.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations indicate destructiveHint=true, which description confirms with 'permanent deletion' and 'no undelete'. Description adds extensive behavioral context: irreversible, requires multiple confirmations on different days, puzzle challenge, lapsed attempts start over. No contradictions.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Description is fairly long but every sentence adds value, starting with the core purpose and irreversibility. It is well-structured with clear steps. Could be slightly more concise, but no unnecessary information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema and 3 optional params, the description provides complete guidance on how to use the tool, including the multi-step process, puzzle requirement, and time limits. No important behavioral aspects are missing for an agent to correctly invoke the tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema has 3 params with 0% description coverage. Description explains that omitting challenge_id and answer returns a fresh puzzle, adding meaning to those parameters. Session_token is not explained, but overall the description compensates well for the lack of schema descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states it requests permanent deletion of account and notes, distinguishes from note deletion by noting there is no grace period. It also explains the multi-step confirmation process, making the purpose specific and differentiating from siblings like bardo_account_deletion_cancel.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Describes when to use (to initiate permanent deletion) and when parameters should be supplied or omitted. It explains the puzzle mechanism and that each confirmation needs a new puzzle. Some implicit guidance on not using for cancellation or status, but could be more explicit about alternative tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, and the description adds value by explaining the possible statuses (none, gathering, confirmed) and their meanings, 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single concise sentence that front-loads the key action and enumerates possible statuses, with no unnecessary words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple status check tool, the description covers the return values adequately, though it does not address error cases or authentication context.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has one optional parameter (session_token) with 0% schema description coverage, and the description does not mention or explain this parameter at all.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'Check' and the resource 'deletion status', and distinguishes from sibling tools like bardo_account_deletion_cancel and bardo_account_deletion_request.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for checking status after a deletion request, but does not explicitly state when not to use or mention alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description thoroughly explains behavioral traits not in annotations: document is not stored, return shape changes with keep_copy, copy failure doesn't block document return. Annotations (all false) are consistent with the description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured and front-loaded, but somewhat lengthy due to detailed parameter explanations. Every sentence adds value, though some redundancy could be trimmed.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description is comprehensive for a tool with 6 nullable parameters and no output schema: explains return behavior with/without keep_copy, references related tools, and provides examples for parameter usage.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema description coverage, the description fully explains all parameters: claim (free-form, reference), subject_id, expires_at, service, keep_copy (including return shape). Only session_token is not described but likely internal.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: 'Assemble and sign a verifiable attestation — a self-contained, offline-verifiable claim about anything.' It distinguishes from siblings like bardo_sign and bardo_document_revoke.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implicitly indicates when to use (to issue an attestation) and references related tools for revoke and status. However, it does not explicitly state when not to use or provide alternative tools for similar tasks beyond those mentioned.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description goes beyond annotations by detailing the non-obvious puzzle mechanism: if challenge_id and answer are omitted, a fresh puzzle is returned, requiring a subsequent call. This fully discloses the interactive behavior, which is critical for correct invocation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is three sentences: purpose, requirement, and two-step flow. It is front-loaded, concise, and contains no extraneous information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description covers the core puzzle workflow and the destructive nature, but it omits details about the return on success or failure, and the session_token parameter is not addressed. Given the lack of output schema, some aspects are left to inference.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The description adds meaning to challenge_id and answer by linking them to the puzzle, but it does not explain the session_token parameter. With no schema descriptions (0% coverage), the description partially compensates but leaves a gap for one parameter.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool removes a registered contact endpoint, which matches the name 'bardo_contact_delete'. However, it does not elaborate on what a 'registered contact endpoint' is, leaving some ambiguity 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.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explains the step-up puzzle requirement and the two-step process if the puzzle is not provided, but it does not provide guidance on when to use this tool versus its siblings (e.g., bardo_contact_get, bardo_contact_set) or any exclusion criteria.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already indicate readOnlyHint=true, so the read-only nature is clear. The description adds specific context: the endpoint is for 'out-of-band security alerts', which is useful beyond annotations. It does not contradict annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence that conveys the core purpose without any waste. It is frontloaded and efficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

While the tool is simple (1 param, no output schema, read-only), the description omits any explanation of the session_token parameter. This leaves a significant gap for an agent to correctly invoke the tool, especially given high sibling count.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, and the description does not explain the single parameter 'session_token' at all. The description adds no meaning beyond the schema, leaving the parameter completely undocumented.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it 'view[s] the contact endpoint registered for out-of-band security alerts', specifying the verb 'view' and the resource 'contact endpoint'. This distinguishes it from sibling tools like bardo_contact_set (set) and bardo_contact_delete (delete).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for viewing a contact endpoint but provides no explicit guidance on when to use this tool versus alternatives, nor any conditions or prerequisites. The context is implied but not elaborated.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations indicate idempotentHint true and destructiveHint false. The description adds the behavioral trait of requiring a step-up puzzle and the two-call flow, which is beyond annotations. It does not contradict annotations. The description could be improved by mentioning idempotency, but the annotation already covers that.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences, concise, and front-loaded with the primary purpose. Every sentence adds necessary information. No waste.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description covers the puzzle workflow and the purpose. However, it does not explain the return value format (what the puzzle looks like) or the purpose of session_token. No output schema exists, so the description should compensate. Slight gaps remain.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must clarify parameters. It explains endpoint (the contact to set/update), challenge_id and answer (puzzle solution). However, session_token is not mentioned. This leaves one parameter undocumented, but the description adds value for the others.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Set or update the contact endpoint (email or webhook URL) for security alerts.' The verb 'set or update' and the resource 'contact endpoint' are specific. The mention of 'security alerts' provides context, and it distinguishes from sibling tools like bardo_contact_delete and bardo_contact_get.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explains the step-up puzzle requirement and the two-call process: first call without challenge_id and answer to get a puzzle, then solve it and call again with all three parameters. This provides clear usage guidance. However, it does not explicitly mention when not to use this tool or compare directly with sibling tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations indicate readOnlyHint=true, which is consistent with the read behavior. The description adds value by detailing the returned data (note counts, notices, tags, pinned notes, policy), going beyond the annotation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, information-dense sentence that front-loads the purpose and enumerates contents. It could be broken into a bulleted list for readability, but it remains efficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Without an output schema, the description provides a comprehensive list of returned items. It covers the essential aspects of the dashboard, though it omits details like data format or limits.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The only parameter (session_token) has 0% schema description coverage and is not mentioned in the description. The code likely uses it for authentication, but the description provides no guidance on its usage or meaning.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool returns a dashboard with specific data points (note count vs limits, unread notices, tags, pinned notes, policy) and contrasts with making several separate calls. It effectively distinguishes from siblings like bardo_notes_list and bardo_policy_get.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies use when a broad orientation is needed, explicitly mentioning it replaces multiple round trips. It does not provide explicit exclusions or when to use individual tools, but the contrast with separate calls gives clear context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations provide readOnlyHint=true, and description adds no extra behavioral details (e.g., key requirements, error handling). Description does not contradict annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Single sentence is concise but lacks necessary detail. It front-loads the action but is too brief for the complexity of a decryption tool.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema and 0% parameter description coverage. The description does not cover return values, parameter details, or usage context, leaving significant gaps for an agent.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema description coverage, the description should compensate but does not explain any parameters (service, session_token, ciphertext_b64). Only ciphertext is implied.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Decrypt a sealed-box ciphertext addressed to you (root or service key)', specifying the action and resource. It distinguishes from siblings like bardo_encrypt and bardo_sign.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool versus alternatives like bardo_encrypt or bardo_sign. No mention of prerequisites or context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already indicate idempotentHint=true, readOnlyHint=false, destructiveHint=false. The description adds no additional behavioral context: no mention of authentication requirements, side effects, or what 'register' entails beyond the trivial.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

One sentence, no wasted words. The core purpose is front-loaded. However, it could be restructured to include more details without losing conciseness.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 2 parameters and no output schema, the description should clarify return values, error conditions (e.g., duplicate service?), and prerequisites. It does not, leaving the agent underinformed.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, but the description provides only an example for 'service' and does not explain 'session_token'. The one example ('github.com') hints at format, but lacks explicit documentation of parameter roles, constraints, or defaults.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('derive and register') and the object ('service-scoped identity'), with a concrete example ('github.com'). This distinguishes it from sibling tools, which are about accounts, documents, etc.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool vs alternatives like bardo_register, bardo_login, or other identity-related tools. The description does not mention prerequisites, postconditions, or when not to use.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations indicate destructiveHint=true and idempotentHint=true. The description adds critical context: the revocation is irreversible, requires a fresh cryptographic signature, and does not need a session at the protocol level. No contradiction with annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with purpose, then explains mechanism and parameters. Some redundancy (e.g., repeated mention of no session), but all sentences add value. Could be slightly more concise, but overall well-structured.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Covers main aspects: purpose, mechanism, parameter usage, idempotency, irreversibility. Missing return value description (no output schema) and session_token parameter detail, but sufficiently complete given complexity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so description must compensate. 'document' and 'signature_b64' are well explained; 'service' is partially explained; 'session_token' is not explicitly described (only implied via 'active session'). This partial coverage yields a score of 3.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Revoke a document you issued' and explains the proof mechanism using a signature over 'revoke:' + document id. This distinguishes it from siblings like bardo_document_status, which checks status rather than revoking.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explains when to provide signature_b64 versus omit for automatic signing via session, when to include service parameter, and notes idempotency and irreversibility. It does not explicitly mention alternatives or when not to use this tool, but the context is clear.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true and openWorldHint=false. The description adds caching behavior context, which is useful beyond the annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two efficient sentences: first states purpose, second explains parameter and caching. No wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Covers purpose, parameter details, and caching behavior. Lacks output schema, but mentions response Cache-Control, implying response structure exists.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Despite 0% schema description coverage, the description fully explains the `id` parameter: its format (ni:// URI) and relationship to credentialStatus.id. This compensates completely for missing schema documentation.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states the verb 'Check' and the specific resource 'whether a signed document is revoked'. This distinguishes it from sibling tools like bardo_document_revoke.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides caching guidance and mentions the response's Cache-Control header. While it doesn't explicitly state when not to use, it offers practical advice for efficient usage.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations declare readOnlyHint=true, indicating no state change. The description adds no behavioral details beyond annotations, such as side effects or output format.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Description is a single sentence with no extraneous information. Front-loaded with key action and target.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Lacks explanation of 'sealed-box' encryption, output format, and prerequisites. No output schema, so description should provide more context.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema has 0% description coverage. The description mentions 'plaintext' and 'recipient's encryption public key' but does not explain formats or constraints beyond 'UTF-8 plaintext' and base64 key implied by parameter name.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool encrypts a UTF-8 plaintext using sealed-box encryption for a recipient's public key. It distinguishes from siblings like bardo_decrypt, bardo_sign, and bardo_verify.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is implied: encrypt plaintext for a recipient. However, no explicit guidance on when to use this tool versus alternatives (e.g., bardo_sign) or when not to use it.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Discloses behavioral traits beyond annotations: automatic policy check, puzzle return on chllenge omission, failure modes under different export modes.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Each sentence adds value; could be slightly tighter but remains focused and front-loaded with main purpose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Covers key behaviors for a sensitive export tool with puzzle handling and policy modes; no output schema, but mentions puzzle return behavior.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage 0%, but description richly explains the purpose of challenge_id and answer for puzzle solving, and the optional session_token context.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Clearly states 'Export the raw spirit key' with specific verb and resource. Distinguishes from siblings by focusing on export and policy handling.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides explicit when-to-use guidance including puzzle handling, parameter omission logic, and three export modes (require_repuzzle, allow, disabled).

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description goes beyond annotations by detailing behavioral traits: one-way and stateless, no memory across calls, and that operator replies appear as ordinary notices. This adds critical context not present in the minimal annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is longer than necessary but each sentence adds value: purpose, statelessness advice, and reply mechanism. It is front-loaded with the main action. Minor redundancy could be trimmed, but overall it is effective.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema and limited annotations, the description provides sufficient context for correct usage: purpose, behavior, parameter meanings (except session_token), and integration with notices. It covers the essential aspects for an agent to invoke the tool properly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The description explains the 'kind' parameter with its three allowed values and implies 'message' is the content. However, it does not mention 'session_token', which is undefined in the schema with 0% coverage. The description partially compensates for the missing schema descriptions but leaves one parameter unexplained.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool sends feedback to Bardo's operator, listing specific kinds (suggestion, complaint, security). It uses a specific verb 'send' and resource 'feedback', differentiating from sibling tools like bardo_notices which handle replies.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explains when to use the tool (sending feedback) and provides explicit guidance on statelessness: say everything in one message as follow-up calls won't retain context. It also notes that replies arrive as bardo_notices, directing the agent to an alternative for receiving responses.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Discloses mutation behavior (creating a link) and the lack of edit capability. No annotation contradictions; readOnlyHint false and destructiveHint false are consistent with creation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three sentences, front-loaded with the main action. Every sentence adds essential information with no redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Covers main purpose and param semantics. Lacks details on error handling or return values (no output schema), but adequate for a simple creation tool with clear annotations.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema coverage, description compensates by explaining the 'reason' parameter's perspective and 'is_bidi' meaning. Does not cover session_token, but context may imply it. Adds value beyond parameter names.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Clearly states it connects two notes with a reason, from the perspective of from_note_id. Distinguishes from sibling tools like bardo_link_delete by focusing on creation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides explicit guidance on when to set is_bidi (true for symmetric relations, false for directional) and how to modify links (delete and re-add). Implicitly contrasts with bardo_link_delete.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The annotations already indicate destructiveHint=true and readOnlyHint=false. The description merely reiterates 'Remove', adding no further behavioral context such as reversibility, ownership requirements, or effects on related entities.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise with no fluff, but it lacks important details that would make it useful. It achieves conciseness at the expense of informativeness, falling short of the ideal balance.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description is too brief for a tool with two parameters, no output schema, and destructive behavior. It omits authentication context, error cases, and what happens if the link does not exist, leaving significant gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, meaning parameters have no descriptions in the schema. The tool description does not explain the parameters (link_id, session_token) beyond their names, leaving the agent to guess their semantics.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action 'Remove' and the resource 'a link between two notes'. It distinguishes from siblings like bardo_link_add (add a link) and bardo_note_delete (delete a note), making the purpose unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No usage guidance is provided. The description does not specify when to use this tool, prerequisites, or alternatives. Given the destructive nature (destructiveHint=true), guidance on when not to use would be helpful.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Discloses that the tool returns a puzzle requiring manual solving and that the server won't solve it. This adds behavioral context beyond annotations, which are all false.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, no waste. Front-loaded with purpose and immediate next step.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with no parameters, no output schema, and minimal annotations, the description provides essential context: its purpose and the required follow-up action.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

No parameters, so schema coverage is 100%. Description adds meaning by explaining what the tool does, which is sufficient for a parameterless tool.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool begins authentication and returns a puzzle, with explicit instruction to call bardo_solve, distinguishing it from siblings like bardo_solve.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly says when to use (begin auth) and what to do next (solve puzzle yourself, call bardo_solve). Lacks explicit when-not or alternatives, but the sequential nature makes it clear.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Explains effects of title, summary, tags, pinned, locked but omits behavior for required 'text' and 'session_token'. No mention of return value or authentication needs. Annotations are all false so description carries burden.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Description is poetic and somewhat lengthy, with a front-loaded sentence that is not immediately informative. Parameter explanations are organized but could be more direct.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Missing explanation for two parameters and no return value description. No output schema, so description should cover these gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage 0%, but description explains 5 of 7 parameters. Misses required 'text' and 'session_token'. Partial compensation but incomplete.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description 'Leave a note for your future, stateless self' clearly indicates adding a note, distinguishing it from siblings like bardo_note_get or bardo_note_delete.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides some context (pinned max 5, unlock via bardo_note_update) but no explicit when-to-use or alternatives for adding vs other note operations.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description goes beyond annotations by detailing the grace period, immediate disappearance vs. actual purge, recoverability, and lock condition with error code. This adds significant context beyond the destructiveHint annotation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three sentences front-loaded with the core action, followed by behavioral nuance and error handling. No superfluous words; every sentence contributes essential information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description covers behavior, side effects, error case, and recovery, but omits explanation of the session_token parameter and does not specify the response (though no output schema exists). It is nearly complete for the tool's complexity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema coverage, the description should explain parameters. It implicitly references note_id in the workaround but does not describe it or session_token explicitly, leaving the agent to infer parameter purpose from context.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action: 'Delete a note (the whole thing, all versions together).' It specifies the resource (note) and scope (all versions), distinguishing it from siblings like bardo_note_undelete and bardo_note_update.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides guidance on when not to use (if locked) and an alternative (unlock via bardo_note_update). It also hints at a recovery path (bardo_note_undelete). However, it does not explicitly contrast with other note-related tools or state preferred use cases.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, so the read-only nature is known. The description adds valuable behavioral details: 'always the current version — any id from this note's history still resolves here' and 'the response's total_length tells you how much more there is'. These go beyond annotations and help the agent understand exactly what to expect.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, no filler. The main purpose is front-loaded, and every word adds value. It is appropriately sized for the complexity of the tool.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description covers the main fetch action, version behavior, linked notes preview, and pagination. Given 6 parameters, this is fairly complete. However, the response format is not described, and since there is no output schema, a bit more detail about the linked notes preview or total_length would increase completeness.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so the description carries the burden. It explains offset and length well, and implies links_limit and links_offset via 'preview of its directly linked notes'. But it does not explain session_token or note_id beyond the title. The note_id description adds value ('any id from this note's history still resolves here'), but session_token is left undocumented. Overall, partial compensation.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description starts with 'Fetch one note's full text' which is a specific verb+resource. It also mentions 'plus a preview of its directly linked notes', clearly distinguishing it from siblings like bardo_note_history or bardo_notes_list. The purpose is immediately clear and differentiated.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit guidance on using offset/length for pagination: 'Omit offset/length for the whole text in one call; pass them to read a large note in bounded slices'. It also clarifies that any historical id resolves to the current version. However, it does not explicitly mention when to use alternatives like bardo_note_history, so it lacks explicit when-not guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true and openWorldHint=false. The description adds specifics: the tool returns up to 10 versions, ordered newest to oldest, and includes the actual wording (not just metadata). This goes beyond annotations and provides actionable behavioral context. No contradiction with annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Single, well-structured sentence. Front-loaded with the main action and key details (ordering, limit, content type). No redundant words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool has no output schema, so the description should inform about return format. It hints at 'actual wording' but does not specify structure, error cases, or pagination behavior. While the limit of 10 edits is given, completeness is adequate but not thorough.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%. The description does not explain the parameters. While note_id is inferable from context, session_token is completely unexplained. For a parameter with no schema description, the tool description should clarify its role but does not.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'See', the resource 'surviving versions of a note', and adds details like ordering (newest to oldest) and limit (up to 10 edits). It also distinguishes from sibling tools like bardo_note_get or bardo_notes_list by emphasizing 'actual wording' versus metadata.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for retrieving historical note content but does not explicitly contrast with alternatives such as bardo_note_get or bardo_notes_list. There is no 'when-not-to-use' guidance, leaving the agent to infer context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Adds context beyond readOnlyHint: states 'never full text' and implies the tool returns previews only. Aligns with annotations and provides useful behavioral constraints.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two concise sentences with front-loaded purpose and no fluff. Every sentence adds value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Describes returned fields (title/summary/snippet/tags/links) and mentions total_notes for pagination. Adequate for a list endpoint without output schema; could mention response is a list.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema has 0% description coverage; description adds meaning for limit and offset via pagination hint, but session_token remains undocumented. Partial improvement over schema alone.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'List your notes — previews only' and lists the specific fields (title/summary/snippet/tags/links), distinguishing it from other note tools like bardo_note_get (full text) and bardo_note_add.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides specific pagination guidance: 'Omit limit for everything; pass it to page through a large list, using the returned total_notes to know how much is left.' Does not explicitly contrast with alternatives, but sibling tools imply when full-text retrieval is needed.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations indicate write operation (readOnlyHint=false) but not destructive (destructiveHint=false), and not idempotent. Description adds the critical constraint of 'post-delete grace period', providing context beyond annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Single, efficient sentence front-loading the key action and constraint. No unnecessary words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Describes core behavior and constraint (grace period) for a simple tool with 2 parameters. Lacks details on error conditions or return values, but acceptable given tool simplicity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, with two parameters (note_id and session_token) lacking descriptions. The tool description does not explain their roles or format, failing to compensate for the missing schema descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Description uses specific verb 'Restore' and resource 'note', explaining the action and a key condition (grace period). It clearly distinguishes from siblings like bardo_note_delete and bardo_note_get.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Implied usage for undeleting a recently deleted note, but no explicit guidance on when not to use or comparison with alternatives like bardo_note_get or bardo_note_delete.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Discloses behavioral traits beyond annotations: text edits create a new version with history, metadata updates are in-place, conflict error structure, locked note handling, and pin limit. No contradiction with annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Description is detailed and well-structured with bulleted modes, but could be slightly more concise. Every sentence adds value, though length is justified by complexity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Complex tool with many parameters and edge cases; description covers conflict and lock behavior but lacks specification of success response (no output schema). Missing output description slightly reduces completeness.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema coverage, description adds meaning to most parameters (text modes, clear, pinned, locked, title, summary, tags). However, session_token and note_id lack explanation, and inter-relationships are well covered but not exhaustive.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states 'Edit a note' and lists specific editing modes (text, append_text, find+replace) and metadata fields, distinguishing it from related tools like bardo_note_add.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides explicit guidance: 'Give at most one text-edit mode', explains when to use metadata-only, conflict handling, and locked note behavior. Alternative actions clearly stated.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already indicate readOnlyHint=true, so the description adds little beyond listing the type of notices. It does not describe pagination, ordering, or how many results are returned, but it does not contradict annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single efficient sentence with no redundant information. However, adding parameter details would improve structure without sacrificing conciseness.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema and two parameters, the description lacks details on pagination, ordering, or how to act on results (e.g., acknowledging notices). It is incomplete for a new agent.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, and the description does not explain the two parameters (unread_only, session_token) at all. The agent cannot infer their meaning or usage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'List' and the resource 'first-party notices about your account' with examples like policy changes and exports. It distinguishes from siblings such as bardo_notices_ack and bardo_notes_list.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus alternatives like bardo_notices_ack for acknowledging notices. There is no mention of prerequisites or context for selection.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already indicate idempotent and non-destructive behavior. The description adds the scope of operation (all or specific ids) but does not disclose potential side effects or whether marking read is permanent.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, clear sentence with no extraneous words, efficiently conveying the tool's functionality.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple two-parameter tool with no output schema and annotated behavior, the description provides sufficient context about the action and its two modes, though it could cover the session token or return behavior.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema coverage, the description meaningfully explains the 'ids' parameter (optional, null means all). However, the 'session_token' parameter is not mentioned, leaving its purpose unclear.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb ('mark') and resource ('notices read'), and clarifies the two modes of operation (all or specific ids), clearly distinguishing it from sibling 'bardo_notices' which lists notices.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies when to use the tool (after retrieving notices to acknowledge them), but does not explicitly state when not to use it or mention alternatives like bardo_notices for listing.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description adds behavioral context beyond annotations: 'aborting only ever tightens back to the current policy' and 'no step-up needed', which are not captured by the idempotent and destructive hints.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two concise sentences that front-load the action and key constraints, with no unnecessary words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description covers tool purpose and behavior but omits details about the parameter and return values, though the optional parameter and no output schema reduce the burden slightly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema has one optional parameter (session_token) with 0% schema description coverage, but the description does not explain its purpose or usage, leaving a gap.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'abort' and the resource 'queued policy loosening', and it distinguishes this tool from siblings like bardo_policy_set by specifying it acts on pending changes.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It indicates when to use ('before it takes effect') and provides a safety note ('no step-up needed'), but does not explicitly state when not to use or list alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, and the description adds value by detailing what is viewed (e.g., export mode, session TTL cap) and mentioning pending loosening, without contradicting annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence that efficiently conveys the tool's purpose and outputs, with no unnecessary words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description adequately lists return fields but lacks explanation of the session_token parameter, which is a gap given the absence of schema descriptions and output schema.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With schema description coverage at 0%, the description fails to explain the session_token parameter, which is optional but undocumented. It only describes the return fields, not the input.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'View your self-binding security policy' and lists specific fields like export mode, session TTL cap, etc., distinguishing it from sibling tools like bardo_policy_set and bardo_policy_abort_pending.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for viewing the security policy but does not explicitly mention when to use this tool versus alternatives like bardo_policy_set or bardo_policy_abort_pending.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations provide idempotentHint=true and destructiveHint=false. The description adds detailed behavioral context: tightening applies immediately, loosening is delayed and abortable, and a step-up puzzle may be required. No contradictions with annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is longer but front-loaded with purpose and behavioral details. Every sentence adds value, though it could be slightly more concise. No wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity (10 parameters, step-up puzzle, delayed vs immediate), the description covers the main flow and key parameters. It references sibling tools for abort and read. No output schema, but the description doesn't need to detail return values for input-focused tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema description coverage, the description compensates well by explaining key parameters: export_mode (allowed values), clear (semantics), max_session_ttl, service_allowlist, challenge_id, and answer. Some parameters (tags_encrypted, delete_grace_seconds, loosen_delay_seconds) are not explicitly covered, but the core ones are.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Propose a change to your security policy' with a specific verb and resource. It differentiates from siblings like bardo_policy_get (read) and bardo_policy_abort_pending (abort).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explains when to use (changing policy), distinguishes tightening vs loosening with immediate vs delayed application, and references the abort mechanism via bardo_policy_abort_pending. It also explains the step-up puzzle requirement.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, and description is consistent. Adds context about key types and scoping but no extra behavioral traits (e.g., rate limits, auth needs). Acceptable but not enhanced.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Single sentence, front-loaded with verb, no wasted words. Efficient and clear.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given low complexity (2 optional params, no output schema), description covers purpose and scoping but lacks parameter documentation and return format. Adequate but not fully comprehensive.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage 0% with two parameters. Description only hints at 'service' scoping ('root, or for a service') but does not explain 'session_token' or add format/details. Inadequate compensation.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'Fetch' and resource 'public keys', specifying types (signing + encryption) and scoping (root or for a service). It distinguishes from siblings like bardo_encrypt/bardo_decrypt.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool vs alternatives like bardo_derive or bardo_encrypt. No explicit when/when-not context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations provide minimal behavioral hints, but the description adds valuable context: it creates an identity, stores an API key locally, returns a claim_url, and notes that authentication will fail until the user visits the URL. This goes beyond the annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three sentences, no filler. Each sentence adds essential information: purpose, one-time nature, and the claim_url workflow. Front-loaded with the primary action.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema, the description covers the key steps (creation, claim_url, user acknowledgment). However, it could briefly mention the returned data (e.g., claim_url format). Still, it's mostly complete for a registration tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

There are no parameters, so schema coverage is effectively 100%. The description adds no parameter info, but that's not needed. Baseline 4 for zero-parameter tools is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Create a new Bardo identity', using a specific verb and resource. It distinguishes from siblings like bardo_login and bardo_encrypt by focusing on registration.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It indicates this is a one-time operation and provides a crucial next step: pass the claim_url to the user for acknowledgment. It implies when not to use (already registered) but doesn't explicitly state alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true. The description adds behavioral context by specifying the returned data (public keys and revoked status), beyond what annotations provide. No contradictions.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Single sentence with no wasted words. Front-loaded with the primary function, followed by detail on included fields. Efficient and clear.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple list tool with one optional parameter and no output schema, the description covers core output (identities, keys, status). Minor gap: no guidance on session_token or behavior when no identities exist.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 1 parameter (session_token) with 0% schema description coverage. The description does not explain the parameter's purpose, format, or when to include it, failing to compensate for the lack of schema documentation.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool lists service-scoped identities derived via bardo_derive, including public keys and revoked status. This specific verb-resource combination distinguishes it from siblings like bardo_derive.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage after bardo_derive, but provides no explicit guidance on when not to use this tool or alternative tools for different scenarios. No exclusions or context for when to choose another tool.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description adds context beyond the annotations by specifying that the current session is revoked and that future session-gated actions require re-authentication. This is consistent with the 'destructiveHint' and 'idempotentHint' annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two concise sentences with no unnecessary information. It is front-loaded with the action and provides essential follow-up context efficiently.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description covers the tool's action and aftermath but does not explain the optional session_token parameter. For a simple revoke tool, it is mostly complete, but the parameter omission leaves a gap.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has a single optional parameter 'session_token' with no description, and the tool description does not mention or explain this parameter. With 0% schema coverage, the description fails to add any meaning for the parameter.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states that the tool revokes the current session and mentions the need to re-authenticate. It does not explicitly differentiate from the sibling tool 'bardo_sessions_revoke_all', but the name and description are specific enough.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies when to use the tool (to revoke the current session) and notes the consequence (need to login again). However, it does not provide guidance on when not to use it or compare to alternatives like revoking all sessions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already mark readOnlyHint=true. Description adds valuable behavioral details beyond annotations: sessions have a sliding TTL and absolute 24-hour cap. No contradictions.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

One sentence, front-loaded with purpose. Every word earns its place. No redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple list tool, the description covers the core action and constraints. However, it omits the return format (no output schema) and does not clarify the optional parameter's purpose. Slightly incomplete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%. The description does not explain the single optional parameter 'session_token'. Nothing is added beyond the schema definition.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states the tool lists active sessions, with specific constraints (sliding TTL, absolute 24h cap). The name matches, and it distinguishes from sibling tools like bardo_session_revoke_current which perform different actions.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool versus alternatives. Does not mention when not to use it, prerequisites, or preference over other session-related tools. Only states what it does.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations indicate destructiveHint=true and idempotentHint=true, which are consistent with revoking all sessions. The description adds useful behavioral context (re-login required) and implies the tool is used in security incidents. No contradiction with annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise: two sentences that front-load the core purpose and a critical side effect. Every word earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple destructive tool, the description covers the main purpose, a typical scenario, and the post-effect. No output schema is needed. Minor gap: does not clarify the role of session_token, but this is a single optional parameter.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has a single optional parameter (session_token) with 0% description coverage. The description does not explain the parameter's purpose or behavior, leaving ambiguity about whether it's needed for authentication or can be ignored.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('revoke every active session') and the resource ('for your identity'), with a concrete example ('suspected API-key leak'). This distinguishes it from siblings like bardo_session_revoke_current (revokes only current session) and bardo_sessions_list.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides a clear use case ('after a suspected API-key leak') and a notable consequence ('You'll need to log in again afterward'). However, it does not explicitly contrast with alternative tools or state when not to use it.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, so the description does not need to repeat non-destructiveness. It adds context about using the spirit key or service-derived key, which is useful. However, it does not disclose output format, authentication needs, or potential side effects like key usage.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence that is front-loaded with the core purpose. Every word earns its place; no unnecessary information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 3 parameters, no output schema, and a cryptographic operation, the description is too minimal. It does not explain what the tool returns (e.g., a signature), the role of optional parameters, or error conditions. A user or agent would need to infer or look elsewhere.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema description coverage, the description should explain parameters. It only implicitly covers 'message' ('UTF-8 message'), but fails to describe 'service' and 'session_token', leaving them ambiguous. The schema provides only names and types, no further meaning.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('Sign'), the resource ('a UTF-8 message'), and the key type ('spirit key or service-derived key'). This differentiates it from siblings like bardo_encrypt (encrypt) and bardo_verify (verify), though it does not mention the output (signature).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies use for signing messages but provides no explicit guidance on when not to use it, prerequisites (e.g., having a key), or alternatives (e.g., bardo_verify for verification). The context is clear but lacks exclusions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already indicate non-readOnly and non-destructive. The description adds that on success a session is opened, which is a key behavioral detail. However, it does not mention failure behavior or side effects beyond session creation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise, two sentences with no wasted words, and immediately communicates the core action and outcome.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a single-parameter submission tool, the description provides the essential purpose and outcome but lacks details on return values (e.g., session token) and what 'opens a session' means in practice. Could be more complete without being verbose.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The only parameter 'answer' is a string, but the description does not specify its format, origin, or constraints. With 0% schema coverage, the description fails to add meaningful semantics.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's verb ('Submit'), resource ('answer to the login puzzle'), and outcome ('opens a session'). It is specific and distinct from siblings like bardo_login.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is implied (when you have an answer to the puzzle), but there is no explicit guidance on when to use vs. alternatives, prerequisites, or exclusions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Describes the minting action and the need to solve the puzzle, then pass challenge_id and answer. Annotations provide no behavioral detail, so description adds valuable context despite not covering all potential traits.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two efficient sentences that convey purpose, usage, and distinction from sibling. No wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity and lack of output schema, the description adequately explains what it does and how to use the result. Missing explicit mention of output format, but implied by usage instructions.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The description does not mention the single parameter session_token at all, and schema coverage is 0%. No added meaning beyond schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Clearly states it mints a step-up puzzle for bardo_policy_set, distinguishing it from the sibling that also mints one on demand. Verb 'mint' and resource 'step-up puzzle' are specific.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly says to call this directly only if you want the puzzle up front, and mentions bardo_policy_set mints one itself. Provides clear context for when to use this tool.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already provide readOnlyHint=true, and the description adds that it is public and requires no session. This confirms read-only behavior but does not disclose details like error handling or invalid signature response. No contradiction with annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences long, front-loading the core purpose. Every word is necessary, with no superfluous details. Highly concise.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple verification tool with no output schema, the description provides core functionality and authentication context. However, it lacks information about the return value (e.g., boolean success or error message) and does not explain what a valid/invalid signature outcome looks like.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, meaning the description provides no information about the three required parameters (message, signature_b64, public_key_b64). The description must compensate for low coverage but fails to explain parameter formats, constraints, or encoding.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool verifies a signature over a UTF-8 message. It is distinct from sibling tools like bardo_sign (which creates signatures) and bardo_encrypt/decrypt (encryption). The verb 'verify' and resource 'signature' are 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.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description includes 'Public utility (no session)', indicating no authentication is needed, which guides usage context. However, it does not explicitly mention when not to use this tool or provide alternatives beyond what is implied by sibling names.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The annotations already indicate readOnlyHint=true, so the tool is safe. The description adds minimal extra behavioral context beyond stating what it shows. No mention of side effects or limitations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

One sentence that is concise and front-loaded with the action and resources. No wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Without an output schema, the description should explain what is returned. It mentions identity and session status but provides no details on format or content. For a simple tool, it is adequate but not complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has no parameters, and the schema coverage is 100%. The description does not need to add parameter information. Baseline for no parameters is 4.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'Show' and specifies the resources: 'stored identity' and 'session status'. It uniquely identifies the tool's purpose among many sibling tools focused on account management, notes, encryption, etc.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No explicit guidance on when to use this tool versus alternatives is provided. However, the context of checking identity and session status is clear from the description, and it's implied that this is the go-to tool for that purpose.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.