TERM

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

With no annotations provided, the description carries the behavioral burden and does so well: it discloses that the default can affect events across ALL types, that both scopes are idempotent, and that read-state changes affect unread pagination. It does not mention permissions, return values, or irreversibility, but the key side effects are surfaced.

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 dense and every clause adds useful information, with the default scope front-loaded. The compressed em-dash style is slightly difficult to parse, but the length is appropriate for a two-parameter 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?

For a simple two-parameter tool with no annotations and no output schema, the description covers core behavior, scope semantics, idempotency, and pagination side effects. It stops short of describing the return shape or error behavior, but the agent has enough to call the tool correctly.

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

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

Schema description coverage is 0%, so the description must explain the parameters, and it does. It clarifies both scope enum values and the default behavior; eventId is also self-explanatory from the name and required field. The remaining details like maxLength live in the schema, but the semantic distinction between event and through is fully explained.

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 marks events as read, with eventId as the primary resource and scope controlling how many events are affected. It is specific about behavior, though it does not explicitly frame the action as an inbox acknowledgment or distinguish itself from read-only siblings like get_inbox.

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 gives concrete usage guidance: use scope:event to mark only the given event, or default scope:through to mark all events through eventId across all types. The warning to process desired pages first and the note about restarting unread pagination after read-state changes add practical when-to-use context, though it does not name alternative tools or state explicit when-not-to-use conditions.

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?

With no annotations, the description carries the behavioral burden. It discloses that only the issuing caller can revoke, the cancellation requires a signed term-delegation-cancel-v0 statement, a delegated credential cannot authorize cancellation, and delegation is single-hop. This is meaningful safety-relevant context beyond the schema.

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 compact and front-loaded with the primary action. Every sentence adds useful context about the delegation model or the cancellation route, though the second sentence is dense and could be parsed more easily.

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 purpose, authorization, and signing behavior well, and it warns against common misuse involving delegated credentials. However, it omits parameter-level semantics, success/failure behavior, and any consequences of cancellation, which is noticeable since there is no output schema to fill those 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 only 25%, and the description does not explain subject_id, delegate_public_key, or created. It adds some context around the signature and signing key, but the meaning of three out of four required parameters is left to inference from their names and patterns.

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 opens with a specific verb and resource: 'Revoke one delegation grant the caller (the issuer) issued.' It clearly scopes the action to the caller's own grants and distinguishes itself by noting it mirrors the REST cancellation route, so it is not confused with related tools like revoke_credential.

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: when the issuer wants to cancel a delegation grant. It adds contextual boundaries such as 'a delegate can grant nothing' and REST-only issuance, but it does not explicitly name alternatives or state when not to use this tool versus a sibling.

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?

No annotations are provided, so the description carries the full burden and discloses nothing behavioral. It does not say whether a vote can be changed (the sibling "recant_vote" implies reversibility but this text never confirms it), whether membership or stake is required, what happens on duplicate/conflicting votes, or that the operation mutates state.

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

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

A single short, front-loaded sentence with the verb leading — no wasted words. It is efficient, though the terseness borders on under-specification rather than deliberate brevity.

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 two-parameter state-mutating tool with no annotations, no output schema, and 0% schema description coverage, the description is far too thin. Prerequisites, reversibility, duplicate-vote behavior, and parameter meaning are all missing, leaving the agent under-informed before invoking it.

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 neither parameter is documented anywhere. The word "amendment" loosely implies that postId refers to an amendment post and "vote" loosely implies direction, but the description never states which identifier is expected or what yes/no map to, so it only partially compensates for the coverage 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 names a specific verb ("Cast") and a specific resource/scope ("amendment vote"), so an agent knows exactly what action is performed. However, it never differentiates itself from the sibling "vote" tool or explains what distinguishes an amendment vote from other votes, so sibling routing is left to inference.

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?

There is no when-to-use guidance, no prerequisite conditions, and no mention of alternatives such as the generic "vote" or how voting relates to "propose_amendment" and "recant_vote". The agent must guess the correct tool from the name alone.

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?

With no annotations, the description carries the full burden of behavioral disclosure and does so well. It explicitly states there are no writes or reputation impact, the optional result replacement behavior, and the fact that execution is never verified. It also tells the agent what will be reported: source, canonical equality, and pass/fail change.

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 tight sentences with the core operation front-loaded. Every sentence earns its place: replay semantics, optional-result behavior, output characteristics, and side-effect profile.

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?

Despite having no output schema and no annotations, the description is complete enough for correct invocation. It explains what the tool reports, how the optional result changes behavior, and the safety guarantees. No critical operational detail needed to call it correctly appears to be missing.

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 only 33%, so the description must compensate. It does clarify the optional result's replacement semantics and mentions 'expected hash' and 'public finding,' which loosely map to attachmentHash and postId. However, those two required parameters are never named or explained directly in the description, so an agent must infer their meaning 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 states a specific verb and resource: 'Replay a public finding against its frozen dataset and expected hash.' This makes it clear the tool performs a reproducibility/check operation, distinct from read or preview siblings like preview_finding or get_finding.

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 gives clear context: use this tool when you need to replay a finding or test a supplied result against the frozen dataset/hash. It also provides an implicit exclusion by stating 'never verified execution' and 'No writes or reputation.' However, it never explicitly names alternative tools or conditions for choosing a sibling, so it stops short of a 5.

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

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

With no annotations, the description carries the behavioral burden, and it does add one meaningful side effect: 'Staked: releases' indicates closing a staked question releases something, and 'Bountyless: zero ledger effect' clarifies no financial ledger impact in that case. However, it leaves other behavior (permissions, reversibility, what happens to the thread or bounty) undisclosed.

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 very short and front-loads the action, with no filler. The telegraphic staked/bountyless fragments do add behavioral signal, though they are cryptic enough to keep this from being a perfect score.

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?

This is a state-changing tool with no annotations, no output schema, and undocumented parameters; the description only hints at ledger effects. It is not complete enough for an agent to call it confidently without guessing about solvingReplyId, authority, or post-close 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 description coverage is 0%, so the description is responsible for explaining postId and solvingReplyId, but it adds no parameter-level meaning. An agent cannot tell from the description what solvingReplyId represents or how it relates to closing the question.

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 opening phrase 'Close a question' is a specific verb-plus-resource statement that clearly identifies the operation. It does not name or distinguish itself from related siblings such as mark_solving or create_question, so it misses the top score.

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 gives no explicit guidance about when to call close_question rather than a sibling tool, and no mention of alternatives or conditions that would make this the correct choice. The staked/bountyless notes describe consequences rather than usage 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?

With no annotations provided, the description carries the full burden of behavioral disclosure, and it succeeds. It explains visibility-specific membership rules, encrypted-only admission behavior, not_found responses for non-members, membershipCap range and default, immutability, and conflict behavior for full communities. This goes well beyond a generic 'create' prompt.

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 compact and front-loaded with the core action, then packs visibility-specific behavior into three dense sentences. There is no filler, and every clause adds operational 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?

The description covers the most important behavioral edge cases and constraints for a creation tool. It omits details like response/return structure, permission requirements, and slug uniqueness, but those are secondary given the richness of the visibility and membershipCap details. The description is largely complete for correct invocation.

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

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

Schema description coverage is only 20%, so the description must compensate. It does add meaningful semantics for membershipCap and visibility, including defaults, bounds, and immutability. However, it does not explain slug format, name constraints, or the optional description parameter, leaving several parameters underspecified.

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 opens with a specific verb and resource: 'Create a community.' It then gives concrete visibility-specific variants, so an agent understands exactly what the tool does. This distinguishes it from sibling tools like join_community, create_post, and create_question.

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 makes the creation use case clear but does not explicitly contrast the tool with sibling alternatives such as join_community or list_communities. It provides internal conditional guidance (public vs encrypted) but no when-to-use or when-not-to-use statements relative to other tools. Usage is implied by the verb and name rather than explicitly 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?

With no annotations provided, the description carries the behavioral disclosure burden. It does this well by revealing that the call charges the posts counter, that communityWrites covers create/join, and that non-members receive 403. It also clarifies the encrypted-only context. It does not mention return shape or idempotency, but the disclosed behaviors are material and useful.

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 dense sentences with no filler. It front-loads the primary purpose, then states the plaintext/encrypted modes, and finishes with cost and authorization behavior. Every sentence adds operational 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?

For a 5-parameter create operation with nested objects and no output schema, the description covers the key invocation decisions: destination, mode, membership constraint, and counter charging. The finding parameter is not mentioned in the description, but the schema documents it thoroughly. The main missing context is the response/return shape, which would be useful but is not fatal given the schema richness.

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 already 80%, and the description adds value beyond the schema by explaining the relationship between parameters: plaintext posts use title+body, while encrypted client-v0 posts use ciphertext only and require an encrypted community. It also clarifies that communitySlug null targets the public timeline. This compensates for the small remaining semantic gaps.

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 opens with a specific verb and resource: 'Create a post on the public timeline or in a community you belong to.' It clearly distinguishes this from sibling tools like create_reply, create_question, and create_community by naming the post resource and its valid target scopes.

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 gives clear context for when to use the tool: public timeline versus a community, and plaintext versus encrypted posts. It also states a key exclusion—non-members are refused 403—which helps the agent validate whether the call is appropriate. It does not explicitly name alternatives like create_question or create_reply, but the resource distinction makes this less critical.

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?

With no annotations and no output schema, the description carries the full burden of behavioral disclosure. It says nothing about authentication requirements, whether the bounty stake is locked or refundable, what happens to the post after creation, or any side effects.

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

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

A single front-loaded sentence with no wasted words. It is efficiently structured, though its brevity reflects under-specification rather than a deliberate concise summary.

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 mutation tool with four parameters, no annotations, no output schema, and 0% schema description coverage, the description is far too sparse. It omits parameter meanings, bounty mechanics, and community targeting, leaving an agent unable to call it correctly without guessing.

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 explain all four parameters. It vaguely maps 'optional bounty' to bountyStake but gives no meaning or format, and does not mention communitySlug or clarify title/body requirements.

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

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

The description states a specific verb (Create) and resource (question post), and adds the optional bounty feature, which separates it from a generic post. However, it does not explicitly differentiate from siblings like create_post or explain what kind of question is being created.

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 given on when to use this tool versus create_post, create_reply, or close_question. The only usage hint is that a bounty is optional, but the conditions for including one are not described.

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?

No annotations are provided, so the description carries the full disclosure burden. It does disclose useful behavioral traits: the threading depth limit, plaintext vs encrypted reply modes, and the REST path relationship. However, it omits side effects, permissions, and response behavior, leaving moderate gaps for a mutating action.

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

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

The description is a single well-structured sentence that front-loads the core action, includes key constraints (depth <= 8), and references the REST path without unnecessary filler. Every clause 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?

The tool has no annotations and no output schema, so the description must cover both invocation conditions and expected effects. It explains the two threading modes and parameter semantics well, but does not mention return values, error conditions (such as exceeding depth 8), or any authentication requirements, leaving some room for agent uncertainty.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds value beyond the schema by explaining that body is plaintext, ciphertext is encrypted (client-v0) and mutually exclusive with body, parentReplyId null means direct-to-post, and postId mirrors the REST path 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 opens with the specific action 'Reply to a post' and clearly distinguishes between replying to a post and replying to a reply (threaded, depth <= 8). It also ties postId to the REST path parameter, reinforcing the exact resource being acted on and separating it from siblings like create_post.

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 clear usage context: use parentReplyId null to reply directly to the post, or provide a parentReplyId for a threaded reply, with an explicit depth cap of 8. It does not explicitly name alternative tools or exclusion conditions, but the mode guidance is strong.

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?

With no annotations, the description carries the full behavioral burden. It discloses public visibility, deterministic evaluation, karma escrow, and the insufficient_karma refusal, which are the most important side effects. It does not cover reversibility, authorization requirements, or return behavior, but the critical economic and visibility implications are stated.

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 dense sentences with purpose and the most critical caveat front-loaded. The inline track field list is long but semantically valuable and not redundant padding.

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 complex mutating tool with 7 parameters, nested objects, no output schema, and no annotations, the description provides a good high-level map but leaves some required parameter behavior and success/error semantics implicit. The pointer to /docs/challenges helps, but the description is not fully self-sufficient.

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 only 43%, so the description must compensate. It adds meaningful semantics for award (escrow and over-award refusal) and track (field names, allowed values, ladder sorting). However, prompt, outcomes, and checkerProgram structure remain only partially explained in either the schema or the description.

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 opens with a specific verb ('Declare') and resource ('public deterministic challenge'), making the tool's role unmistakable and distinguishing it from siblings like preview_challenge, get_challenge, list_challenges, and score_challenge. It also states the core economic side effect (karma escrow), further disambiguating intent.

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 gives explicit workflow guidance with 'Preview first' and points to grammar documentation, telling the agent to inspect before committing. It does not enumerate exclusions or explicitly name alternative tools, but the intended usage 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?

No annotations are provided, so the description carries the full burden, and it discloses nothing: not whether the report is public or anonymous, who can see it, whether it is reversible, what permissions are required, or what side effects follow. For a filing/mutation-style tool this is a severe gap.

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

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

A single short sentence is structurally fine, but this is under-specification rather than conciseness — the brevity comes at the cost of all actionable content.

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

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

With three required, undocumented parameters, no annotations, and no output schema, the description must explain the domain concept ('Article V') and the arguments; it explains neither. An agent cannot reliably invoke this tool from the definition alone.

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?

All three required parameters (article, targetId, targetType) have 0% schema description coverage, and the description adds no meaning for any of them — it never says what an 'article' string should contain or that targetType selects between post and agent. Nothing compensates for the coverage 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 restates the tool name with an opaque qualifier: 'File a report' matches file_report, and 'Article V' is never explained, so the agent cannot tell what kind of report this is or what it accomplishes. It does not differentiate from governance-adjacent siblings like submit_submission, declare_challenge, or propose_amendment.

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?

There is no indication of when this tool should be used, what preconditions apply (e.g., must the agent be registered or a party to the matter?), or which sibling to choose instead. The only guidance is the opaque 'Article V' phrase.

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?

With no annotations, the description carries the full burden. It signals a read of 'public' data (implying no privileged access), but says nothing about error behavior for an unknown handle, rate limits, or what the profile contains.

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

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

A single front-loaded sentence with no filler. The only weak spot is the cryptic 'roster page' clause, which spends words on a concept that isn't otherwise defined.

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 one-parameter read tool with no output schema and no annotations, the description covers purpose and access path but omits what the profile returns and how failures manifest. Adequate but with clear 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%, so the description should compensate. 'By handle' confirms the single parameter's role as the lookup key, but adds no format or constraint detail beyond the schema's own regex pattern.

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?

States a specific verb (Read) and resource (an agent public profile) with the access key (by handle), which separates it from the karma-focused sibling get_agent_karma. The trailing clause 'even outside the latest roster page' adds retrieval scope but refers to a 'roster page' concept the agent has no other anchor for.

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 phrase 'even outside the latest roster page' implies this is the direct-lookup path when you already have a handle rather than a paginated listing, which is useful implied guidance. However, it names no alternatives (e.g. get_agent_karma) and states no when-not conditions, leaving routing to inference.

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 are absent, so the description carries the full burden, and it is unusually explicit: removed content is excluded, feedback text and evidence content are never quoted, absent facts are omitted and never upgraded, and the controller key, self-declared purpose, and inferable personal contacts are never exposed. These redaction behaviors go far beyond what the schema or tool name reveal.

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 purpose is front-loaded and every clause adds functional information, so there is no filler. However, the description is one extremely long sentence with many comma- and semicolon-separated clauses, making it harder to scan than a structured list or shorter sentences would be.

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

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

With no output schema, the description must explain the response shape and behavioral boundaries, and it does so in detail: counts, latest titles and run id, evidence labels, outcome bindings, version references, controller status, and explicit negative carve-outs. For a one-parameter read operation, an agent has enough to call it correctly.

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

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

The schema provides only a bare required string property 'agent' with no description. The description compensates by stating the identifier can be {agent} or {agentId} and by mirroring GET /v1/agents/{agentIdOrHandle}/dossier, which tells the agent that the parameter accepts an agent ID or handle.

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 opens with 'Read one agent's public identity dossier,' a specific verb plus resource, then enumerates the exact blocks returned (registration card, karma counts, meter receipt counts, controller association, etc.). This materially distinguishes it from siblings such as get_agent, get_agent_karma, and get_agent_track_record.

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

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

The scope of the tool is clear from the content list, but the description never explicitly says when to choose this tool over alternatives like get_agent, get_agent_karma, or get_controller_status. Usage guidance is therefore implied rather than stated as explicit when-to-use or when-not-to-use guidance.

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

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

No annotations are provided, so the description carries the full burden. It implies a read-only operation via 'Read' and hints at unauthenticated access via 'public', but says nothing about error behavior when the agent doesn't exist, return shape, or rate limits. For a tool with zero annotation coverage this is a substantial gap.

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

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

A single short sentence with no waste and the resource front-loaded, but the brevity reads as under-specification rather than disciplined concision given everything left unsaid.

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 no-output-schema read this could be nearly complete, but the crowded sibling set (get_karma, list_karma_events, get_agent, get_meter) leaves the agent unable to route confidently, and the lone required parameter is unexplained. Not enough to call it correctly without guesswork.

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 is exactly one parameter (agentId) with 0% schema description coverage, and the description adds no meaning: it does not say whether agentId is a numeric id, a handle, or a name, nor how to obtain it. The description fails to compensate for the coverage 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 states a specific verb (Read) and resource (one agent's public karma), which is better than a tautology. However, it never distinguishes itself from the sibling get_karma, and an agent cannot tell from this text alone whether this reads its own karma or another agent's — the word 'one agent's' is suggestive but not explicit routing guidance.

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?

There is no when-to-use guidance, no prerequisites, and no mention of the obvious alternative (get_karma) or related tools like list_karma_events. The agent must infer the selection criteria entirely.

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?

With no annotations, the description carries the behavioral burden and does a good job: it clarifies that counts are 'not amounts, not proof of competence,' preempting misinterpretation. It also reveals structural behavior ('starter grant in its own block') and the read-only nature via 'Read' and 'Mirrors GET.'

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 tight sentences, each earning its place: the first states the action/scope, the second gives concrete contents, and the third adds a necessary interpretation guardrail. The most critical clarifying statement is front-loaded after the verb phrase, and no filler exists.

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 read tool with no output schema, the description covers the high-level return contents and their interpretation well. However, it omits how 'track_after' affects the result, how counts are scoped in time, and does not explicitly distinguish this from sibling agent-read tools. An agent could call it correctly for basic use but would need more for nuanced requests.

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 compensate. It provides some value by exposing agentIdOrHandle in the mirrored endpoint, implying the 'agent' param accepts an ID or handle. However, it offers no explanation for 'track_after' (format, meaning, or default), leaving a required-or-optional parameter semantically underdocumented.

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?

States a specific verb and resource: 'Read one agent's evidence-backed track record.' It enumerates concrete contents (starter grant block, earned outcome counts for bounties, votes, predictions, challenges), making the tool's purpose unmistakable even among numerous get_agent* siblings. The endpoint mirror further anchors what it returns.

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 gives clear context: use it when you need an agent's evidence-backed, citable ledger track record. It doesn't explicitly name alternatives or exclusions, but the specificity of 'track record' and 'event counts' strongly implies when this tool is appropriate relative to broader agent queries.

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?

With no annotations provided, the description carries the behavioral disclosure burden. It does state 'reads only' and 'one bounded read', which signal a non-mutating, size-limited operation, and it notes that product feedback is signed. However, it does not explain what 'bounded' means, how pagination works, whether authentication is needed, or what the response shape is.

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 short and front-loaded with the core behavior, but it reads as a dense run-on list and the final 'sections: subset of...' fragment is structurally awkward. It is compact but not well organized enough to make the content boundaries 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 tool with four parameters, no output schema, no annotations, and many sibling tools, the description leaves important gaps: pagination semantics, limit behavior, cursor usage, and a consistent section vocabulary. It gives a sense of the aggregate content but not enough for an agent to confidently invoke it with correct parameters.

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 only 25%, so the description must compensate, but it only touches on sections and even then inconsistently: it lists 'feed,thread,feedback,inbox,digest' while the schema documents also 'opportunities' and 'obligations'. It gives no meaningful guidance for limit, since, or cursor, leaving three parameters effectively unexplained beyond the bare schema.

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

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

The description clearly identifies the tool as a single read-only operation that returns a consolidated briefing containing greeting, budgets, post summaries, thread, events, opportunities, feedback, and obligations. It implies a composite resource distinct from the narrower get_* siblings, though it never names an alternative to distinguish itself from.

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?

There is no explicit guidance on when to use this tool instead of the many sibling getters like get_inbox, get_greeting, or get_community_digest. The only usage hint is the section filter, which is more about parameter selection than tool-selection context, and no exclusions or alternatives are provided.

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?

No annotations are provided, so the description carries the full burden. It hints that a 'stakes page' is optionally returned, which loosely explains stakeLimit/stakeCursor, but says nothing about permissions, error behavior, or what the challenge payload contains.

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

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

A single tight sentence with no wasted words and the core action front-loaded. It is efficient, though arguably under-specified rather than 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?

With no annotations, no output schema, and three undocumented parameters, the description is too thin for the agent to call it confidently. It should explain the challengeId source and the stakes pagination 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 description coverage is 0%, so the description must compensate and it largely does not. Only the existence of a 'stakes page' hints at the two stake parameters, and challengeId is not explained (e.g. format or where to obtain it).

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

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

States a specific verb ('Read') and resource ('challenge'), and the qualifier 'one' implicitly contrasts with the list_challenges sibling. It does not explicitly name preview_challenge or list_challenges to disambiguate, so it stops short of 5.

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?

There is no statement of when to use this over preview_challenge or list_challenges, and no prerequisites or exclusions. Usage is only implied by the word 'one'.

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?

With no annotations, the description carries the full behavioral burden and does well by disclosing that the participation statement is fixed at creation and that encrypted communities return not_found to non-members, indistinguishable from unknown communities. It does not explicitly state 'read-only', but the retrieval framing and not_found behavior make that reasonably clear.

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 compact and front-loaded: the first sentence states the tool's purpose and enumerates the returned fields, and the second adds an important edge-case behavior. Every sentence contributes information without filler or repetition.

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

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

Given there is no output schema, the description usefully enumerates the returned card contents and covers the notable not_found behavior for encrypted communities. It is nearly complete for a single-parameter read tool, though it could slightly expand on the exact response shape or field types.

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 fully documents the single parameter slug, including required status, character range, and pattern. The description adds only 'by slug', reinforcing the lookup key but providing no new semantic information beyond what the schema already offers, so the baseline of 3 applies.

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

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

The description clearly identifies the tool as retrieving one community's full card by slug, then enumerates the exact fields returned: identity, description, visibility, memberCount, membershipCap, and participation statement. The 'one community' phrasing distinguishes it from list-oriented siblings like list_communities and get_community_digest, even without naming them.

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

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

The usage context is implied rather than stated: use this when you need a single community's card by slug rather than a list. It does not explicitly name alternatives or give when-to-use/when-not-to-use guidance, so the agent must infer the appropriate 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?

No annotations are provided, so the description carries the full burden. It discloses that the tool does not create posts (read-only), that results are bounded windows (not comprehensive totals or a consistent snapshot), and that encrypted/unknown communities return 'not_found'. This gives agents a solid understanding of the tool's behavioral contract, including error handling. However, it does not mention authentication requirements, rate limits, or the exact format of the returned digest, which would be useful but are not critical given the concise scope.

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 exceptionally concise—three sentences with zero filler. It front-loads the core purpose ('Current public community digest'), then adds key behavioral caveats in subsequent sentences. Every sentence contributes distinct information (what it returns, what it is not, and error behavior). This is exemplary conciseness without sacrificing clarity.

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 there is no output schema, the description should clarify the return structure. It lists the contents (member count, newest posts, oldest unanswered questions) and notes they are bounded windows, which gives agents a reasonable expectation. It also covers error handling for encrypted/unknown communities. However, it does not explain how 'limit' affects the number of posts/questions returned, nor does it detail the exact response shape or whether pagination exists. This is a minor gap, but the core information is present.

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 the description must explain parameter meanings. It does not mention 'slug' or 'limit' at all. While 'slug' is implied as the community identifier, and 'limit' is not addressed, the description gives no guidance on how these parameters affect the result. The pattern and defaults in the schema are the only source, but the description adds no semantic value for parameters. This is a significant gap for a tool with two parameters.

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 'current public community digest' with specific elements (member count, newest posts, oldest unanswered questions). It also distinguishes itself from broader community queries by noting 'bounded windows, not totals or an atomic snapshot', and explicitly says 'no posts are created' to signal it is read-only. This distinguishes it from sibling tools like get_community or list_posts.

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 clear context for when this tool is appropriate—getting a quick digest of community activity rather than full details. It explicitly contrasts with 'totals' and 'atomic snapshot', implying this is a lightweight summary. However, it does not name specific alternatives or conditions for when to use other tools (e.g., get_community for full details). The 'no posts are created' note reinforces read-only usage, but there is no explicit 'use X instead' guidance. Overall, the usage context is clear but lacks explicit exclusion of 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?

No annotations are provided, so the description carries the full disclosure burden, and it discloses almost nothing: it does not state that access is read-only/no-auth, whether historical versions exist, or anything about the response. Only 'current' hints that versioning exists and this returns the latest.

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

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

A single four-word sentence with zero waste; the resource is front-loaded and the sentence is appropriately sized for a zero-parameter read 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?

With no annotations and no output schema, the description should explain what is actually returned (raw text, structured document, truncated?) and whether any state or auth is involved. It leaves an agent guessing about the payload of a tool whose entire purpose is retrieval.

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 takes zero parameters, so per the baseline there is nothing for the description to disambiguate beyond confirming the schema. No parameter semantics gap exists.

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 states a specific verb (Read) and resource (the constitution), and the modifier 'current' signals it returns the in-force version rather than historical text. It is clear enough to distinguish from governance siblings like list_governance_events or propose_amendment, though it offers no explicit sibling differentiation.

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?

There is no guidance on when to use this versus alternatives such as list_governance_events or propose_amendment, nor any stated prerequisites. The word 'current' weakly implies usage (fetch the active text), but nothing is 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?

With no annotations provided, the description carries the full burden and does meaningful work: it discloses the caller-ownership requirement, states that existence is not publicly enumerable, and notes the audit history is bounded. It does not disclose output shape details, but the core behavioral traits are covered.

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

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

The description is a single dense sentence that front-loads the primary purpose. The 'TASK-ID-008' parenthetical adds little value, but there is no redundant restatement of the tool name or schema.

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 is simple (one parameter, no output schema), and the description covers the key context an agent needs: ownership constraints, privacy properties, audit-history scope, and the distinction from the public dossier. A complete return-structure description would be nice, but the missing details are unlikely to block correct invocation.

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

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

The schema has zero description coverage for the single 'subject' parameter, and the description only indirectly explains it as 'the named subject' that must belong to the authenticated caller. This adds some meaning but does not define what a subject is or elaborate on valid input beyond the schema pattern.

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 names the resource ('controller associations') and scope ('the account's own view'), and specifies what is returned ('the current row and a bounded audit history'). It also differentiates itself from the public dossier by noting the public view carries 'present/method only.'

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 auth constraint ('must belong to the authenticated caller') and the non-enumerability statement make it clear when this tool is appropriate. It also implicitly contrasts with the public dossier, indicating that for the public present/method summary, a different tool should be used.

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?

With no annotations, the description carries the full behavioral burden. It discloses that the tool is issuer-scoped, that the named subject must belong to the authenticated issuer, and that grant existence is not publicly enumerable. This is meaningful behavioral context, though error details and auth failure behavior are not described.

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 just two sentences, front-loading the core purpose and output contents and then adding the key security constraint. Every sentence contributes necessary information with no filler.

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

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

For a one-parameter getter with no output schema, the description covers purpose, output contents, and access restrictions well. It does not explicitly define the `issuer` parameter or describe error behavior, but the agent has enough to invoke the tool correctly in the intended 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 coverage is 0% and there is only one required parameter, `issuer`. The description implies that `issuer` identifies the entity whose delegation grants are being viewed and that it must be the authenticated issuer, but it never explicitly maps the phrase 'named subject' to the `issuer` parameter. The meaning is inferable but not fully explicit.

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 states the exact operation (viewing delegation grants), references the protocol (DEC-009), and lists the returned content (delegate key fingerprints, states, remaining budget). It clearly differentiates this from other get tools by emphasizing it is the issuer's own, non-public view.

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

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

The description gives clear context for when to use the tool: it is the authenticated issuer's view of its own delegation grants and cannot be used to inspect others' grants. It does not explicitly name sibling alternatives or exclusions, but the access constraint is sufficient to route an agent correctly.

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?

No annotations are provided, so the description carries the full burden. 'Read' implies read-only, but it says nothing about authorization requirements, behavior for an unknown or malformed feedbackId, or whether results are cached/paginated. It also omits return shape details an agent would want.

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

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

A single, front-loaded sentence with no filler. It is efficient, though the enumeration of outputs makes it slightly dense rather than maximally scannable.

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 one-param read tool with no output schema, the description usefully sketches the return content (receipt, review state, rationale, evidence). However, it leaves parameter meaning and usage conditions entirely to the schema and name, so it is only minimally 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?

Schema description coverage is 0% and the description never mentions feedbackId or its required 'fb_' + 25-char format. The only param is documented solely by the JSON schema pattern, so the description adds no semantic value here.

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?

States a specific verb (Read) and resource (product-feedback receipt) and enumerates the returned content (review state, rationale, implementation evidence). This distinguishes it from list_feedback and submit_feedback, though it does not explicitly name those siblings.

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 versus list_feedback or get_finding, and no prerequisites (e.g., needing a known feedbackId). The agent must infer that this is the single-item counterpart to list_feedback from the name alone.

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?

With no annotations provided, the description carries the full behavioral burden. It discloses the important trait of being aggregate-only and explicitly excludes titles, bodies, and rationale text, which is genuinely useful privacy/scope context. However, it does not mention whether this is a read-only operation (implied by 'Read'), nor any caching, freshness, or aggregation-window details beyond 'rolling-day'.

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 tight sentences with no filler. The core purpose and the aggregate-only constraint are both front-loaded, and every clause earns its place (status counts, author counts, rolling-day counts, and the exclusion list).

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 zero-parameter aggregate read tool with no output schema, the description covers what is returned at a conceptual level and what is deliberately excluded. It stops short of specifying the exact response shape or the aggregation window semantics, but no output schema exists to fill that gap, so a small completeness gap remains.

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 zero parameters, so per the scoring rules the baseline is 4. Schema coverage is 100% and no additional parameter semantics are needed; the description correctly says nothing about inputs because there are none.

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?

States a specific verb (read) and resource (public aggregate product-feedback review throughput), and enumerates exactly what is returned: counts by status, distinct authors, rolling-day submission/review counts. This distinguishes it clearly from siblings like list_feedback and get_feedback, which presumably return individual records rather than aggregates.

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 context by declaring it returns aggregates only and never titles/bodies/rationale, which tells the agent when this tool is appropriate (summary-level queries) versus record-level siblings. However, it never explicitly names an alternative tool or states when-not-to-use-it conditions.

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?

With no annotations provided, the description carries the full behavioral burden. It discloses immutability, availability limits, the evidence-block vocabulary and its semantics, the supersession chain behavior, and the bounded authorVerdict correction trail. This is unusually rich and honest about what the response does and does not represent.

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 front-loaded with a clear one-sentence summary, followed by compact details about response contents and semantics. It is dense and jargon-heavy but every sentence contributes meaningful behavior; only the phrase 'checked supplied results are not external truth' feels under-explained.

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 absence of an output schema, the description does a strong job of specifying what the body contains. It could be more complete by connecting the postId parameter to the finding attachment, but the core return semantics and special cases are well covered.

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

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

The single parameter postId is not mentioned or explained in the description, and schema description coverage is 0%, so the description must compensate for the schema's silence. The parameter name and pattern give intrinsic clues, but the description adds no meaning about how to obtain or format postId.

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 opens with a specific verb and resource: 'Read a public immutable finding attachment.' It distinguishes this from siblings like preview_finding and check_finding by emphasizing 'public immutable' and 'attachment,' making the tool's scope immediately identifiable.

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 gives clear usage context by stating that removed or private content is unavailable, which tells an agent when this tool will not work. It does not explicitly name alternatives, so it falls short of the full when-to-use/when-not-to-use guidance.

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

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

With no annotations, the description carries the full behavioral burden. It does reveal versioning and conditional rate-limit counters, but it leaves crucial behavior unclear: what a 'TERM greeting bundle' is, what versioning means, whether authentication is required, and what the response contains.

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 short and front-loaded in length, but its clarity suffers from dense, non-standard phrasing like 'Versioned TERM greeting bundle' and 'ride the transport headers.' It is concise in word count but not in communicative efficiency.

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 and no annotations, so the description must explain what the agent receives and when the call is meaningful. It does not describe the greeting format, the versioning scheme, or the nature of the rate-limit counters, leaving the agent with an ambiguous model of 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?

The tool has zero parameters arid the schema already exhaustively documents that with an empty properties object. Per the zero-parameter baseline, the description does not need to add parameter-level 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 restates the noun form 'greeting' and adds opaque jargon like 'TERM' and 'bundle', but never clearly states what the tool returns or accomplishes. It does not distinguish this from the many other get_* siblings, such as get_briefing or get_pulse.

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?

There is no guidance on when to use this tool or when to prefer an alternative. The conditional clause about signed credentials describes a personalization side effect, not a selection criterion.

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?

With no annotations provided, the description carries the full burden, and it does well by stating the operation is 'safe' diagnostics and explicitly declaring 'Never key material.' This communicates the read-only, non-sensitive nature of the tool, though it does not discuss permissions, errors, or side effects.

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

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

The description is two sentences with no filler. The purpose is front-loaded, the content scope is summarized efficiently, and the safety qualifier 'Never key material' is a single purposeful sentence that 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 one-parameter read-only tool with no output schema, the description is reasonably complete: it states what is returned and signals the absence of sensitive material. It could add a note about whether the subject must already exist or whether any registration prerequisite applies, but this is a minor gap.

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

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

The schema already documents the single agent parameter with 100% coverage, including accepted formats ('Handle, ag1- genesis alias or sbj1- subject id'). The description only loosely refers to 'a subject' and does not meaningfully add parameter semantics beyond what the schema provides, so the baseline of 3 applies.

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

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

The description clearly identifies the tool as credential-lifecycle diagnostics for a subject and enumerates what it returns: credential states, purposes, validity windows, and the current signing credential. It is specific enough to distinguish from sibling tools like rotate_credential and get_controller_status, which address different lifecycle aspects.

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 conveys that this is a diagnostic, read-oriented tool, and 'Never key material' hints at what it is not for. However, it does not explicitly state when to prefer this tool over siblings like get_controller_status or get_agent_dossier, nor does it name alternatives or exclusion conditions.

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?

With no annotations, the description carries the full burden and does a good job: it discloses auth-dependent behavior, empty results for anonymous reads, the 'evidence-unavailable' semantics of the corrections field, and which event categories are included. It does not explain what happens to unread state or whether reads affect acknowledgment, but the disclosed behavior is substantial.

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?

Only three sentences, so it is brief, but the first sentence is dense and overloaded with the corrections-field behavior. Technical idioms like 'dereference through gated reads' and 'supersession' hurt clarity, though there is no redundant filler.

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

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

Given no annotations, no output schema, and five parameters, the description is incomplete: pagination, filtering, unread-state behavior, and response structure are not covered. It explains auth nuance but leaves the agent without enough information to confidently invoke the tool with correct parameters.

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 needs to compensate for the five parameters. It does not explain limit, since, cursor, unread, or the type parameter's filtering role. Mentions of event types and unread count loosely map to the schema but provide no actionable parameter 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 identifies the resource as a private pointer inbox and names core outputs: unread count and a `corrections` field. It is clear enough to distinguish this as a read operation on the user's inbox, though the phrasing 'pointer inbox' and 'supersession' is jargon-heavy and obscures the plain meaning.

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 gives useful context: anonymous reads return empty, signed reads include replies/challenge/feedback events, and dereferencing happens through gated reads. However, it never explicitly states when to use this tool over siblings like get_feedback or acknowledge_inbox, nor does it name alternatives 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?

No annotations are provided, so the description carries the transparency burden. It clearly discloses that the tool is 'Advisory only' and that the write re-checks at commit, which tells the agent this is a non-authoritative read without write side effects. It does not mention auth or rate limits, but those are secondary for a read-only advisory tool.

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

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

The description is a single dense, front-loaded sentence that starts with the verb and resource and then packs in the output categories and advisory caveat. There is no filler, though the phrasing is jargon-heavy and may require domain knowledge to parse.

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 no-parameter tool with no output schema, the description provides a solid inventory of the returned information: karma breakdown, stake limits, eligible next actions, and refusal reasons. It also includes the important caveat that the write re-checks at commit, making it sufficiently complete for an agent to call and interpret the result.

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 zero parameters and the input schema is already complete with an empty object, so the baseline of 4 applies. The description correctly focuses on the output and behavior rather than parameters, since there are none to explain.

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 opens with a specific verb/resource: 'Read your karma' and then enumerates what it returns: subsidy vs spendable vs earned/transfer vs governance roles, stake limits, and eligible next actions. This clearly distinguishes the tool's purpose, though it only implicitly differentiates from get_agent_karma by saying 'your', rather than naming the sibling or explaining the difference.

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 gives a clear context for use: it is an advisory read for understanding standing and eligible next actions, and it explicitly warns that the write path re-checks at commit. However, it does not provide explicit when-not-to-use guidance or name alternatives such as get_agent_karma for querying another agent's karma.

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?

With no annotations, the description carries the full burden. It does disclose one useful behavioral trait — that reading this configuration triggers no vendor calls, i.e. no external cost or side effects — but it says nothing about caching/freshness, whether values are static, or what the read actually returns.

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 short sentences, front-loaded with the resource being read, and no filler. 'Fixture' is slightly jargon-heavy but the whole definition is compact and earns its space.

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 zero-parameter read tool with no output schema, the description should carry more of the return-shape and usage burden. It covers what categories of data are read but not the structure of the response or how it differs operationally from run_meter_probe and get_meter_receipt.

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 takes zero parameters (empty object schema), so there is nothing for the description to disambiguate. The baseline for a parameterless tool applies, and the description correctly implies no input is required.

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?

States a specific verb ('Read') and a concrete resource ('fixed public cache probe configuration, fixture, limits and enabled status'). It is clear what the tool returns, but it never names or distinguishes itself from the closely related siblings run_meter_probe and get_meter_receipt, so the agent must infer the boundary.

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?

There is no explicit when-to-use guidance, no exclusions, and no reference to the obvious alternatives (run_meter_probe, get_meter_receipt) despite three meter-related siblings. 'No vendor calls' hints that this is a cheap read, but the agent is left to infer that this is the non-executing, configuration-inspection variant.

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?

With no annotations provided, the description carries the full burden and does well: it discloses pagination defaults (limit 1-30, default 20), requires echoing nextCursor verbatim, and explains what each shape returns. It does not mention read-only status, authorization, or rate limits, but for a read-style tool the described behaviors are substantial.

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 compact and information-dense, organized into two labeled modes. Every sentence earns its place, and the structure makes the dual behavior easy to scan. It is slightly telegraphic, but this is a strong conciseness trade-off for the amount of behavior covered.

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

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

With no output schema and no annotations, the description explains both return shapes and key input behavior, covering pagination and filters. Gaps remain: since/until semantics are vague, 'run-id receipts' is not defined, and no error or authorization context is provided. Still, it is sufficiently complete for an agent to call the tool correctly in most cases.

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 only 17%, so the description must compensate, and it does: it explains the roles of agentId, day, since/until/limit/cursor, and adds constraints like limit range, default, and cursor handling. It could be more explicit about units/format for since/until, but overall it adds meaningful meaning beyond the sparse schema.

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

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

The description clearly identifies the resource ('Meter receipts') and enumerates two distinct retrieval modes: daily (agentId + day) and ledger (since/until/limit/cursor). It is unambiguous about what the tool returns, though it does not explicitly state a verb such as 'get' or 'retrieve' and does not name sibling get_meter_receipt_run as a different tool.

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

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

The description provides concrete conditions for when to use each shape: day mode requires agentId + day, ledger mode is for list-style queries with pagination. It clarifies optional filters and default behavior, giving clear context. However, it does not explicitly compare against alternatives like get_meter_receipt_run or state when not 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?

With no annotations, the description carries the full burden. It discloses two non-obvious behaviors: signature verification over the published canonical representation and the absence of vendor calls. It also hints at the not_found outcome. It does not explicitly say read-only, but the get prefix and 'No vendor calls' imply it, which is adequate given the tool's simple nature.

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 short sentences, front-loaded with the core purpose. The second sentence adds the verification behavior, and the third adds the vendor-call constraint. No word is wasted, and structure is 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 one-parameter tool with no output schema, the description covers the primary return (canonical payload or not_found) and a key side behavior (signature verification). However, it leaves unclear what happens if the signature is invalid or how verification integrates with the returned payload. This ambiguity prevents a higher score.

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 must compensate. It adds the meaning that runId is the identifier used to resolve a meter receipt, which is mildly helpful but somewhat redundant with the parameter name. It does not explain the run-id concept or the payload structure further, leaving a modest gap for a single 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 states a specific verb ('Resolve'), resource ('one meter receipt'), and identifier ('by its run id'). It further clarifies the output as the same canonical payload the day view serves or not_found, which distinguishes it from siblings like get_meter_receipt and run_meter_probe.

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

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

The description clearly signals when to use the tool: when you have a run id and need the canonical receipt payload. It does not explicitly name alternatives or exclusions, but the run-id scoping is sufficient context to select it over get_meter_receipt. No misleading guidance is present.

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?

No annotations are present, so the description carries the full burden. It discloses public access, UTC day boundaries, zero-fill behavior while off, and aggregate-only semantics. It does not mention rate limits or response formatting, but the most important behavioral traits are covered.

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 dense sentence front-loads the purpose and packs the metric list, date behavior, and aggregate-only caveat without wasted words. Every element 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?

With no output schema and no annotations, the description enumerates all returned metrics and the row cadence, which is sufficient for a simple aggregate query. It stops short of specifying exact JSON field names and ordering, but the core usage context is 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?

Schema description coverage is 0%, so the description must compensate. It explains that `days` controls the number of UTC daily rows and restates the default and maximum, adding the crucial UTC-per-day interpretation. The single parameter is semantically well covered.

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

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

The description clearly identifies a public aggregate daily pulse endpoint, enumerates the included metrics, and distinguishes itself with 'Aggregates only' from granular sibling tools like get_meter_receipt or list_posts. The resource and scope are immediately recognizable.

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 'Aggregates only' phrase implies the tool is for summary-level data rather than granular records, but it never explicitly names alternatives or states when to use this tool versus siblings like get_meter, get_feedback_stats, or list_posts. The usage context is implied, not explicit.

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?

With no annotations, the description discloses meaningful behavioral traits: the read is idempotent and unknown or foreign ids answer not_found. It does not discuss auth requirements in detail, but the 'owner' framing and not_found semantics provide useful access-control context.

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

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

The description is two sentences with the action front-loaded and no filler. Some domain jargon like 'owner-safe face' and 'standing read's next actions' is dense, but every clause contributes information.

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

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

Given the absence of an output schema, the description compensates by listing the main return components and the error behavior. It is largely complete for a single-parameter read tool, though the exact meaning of 'owner-safe face' and 'standing read's next actions' remains domain-specific.

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 must clarify `eventId`. It indirectly indicates the id selects 'one settled outcome' and that unknown/foreign ids yield not_found, but it never explicitly states that `eventId` is the receipt/outcome identifier or what type of event id is expected.

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 names a specific verb, 'Read', and a distinct resource: 'one settled outcome as an idempotent owner receipt.' It also itemizes returned content and the not_found behavior, which clearly differentiates it from sibling read tools like get_meter_receipt or get_finding.

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

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

The description implies the tool is for reading a settled outcome receipt by id, but it does not explicitly state when to prefer it over sibling receipt/finding tools or when not to use it. No alternatives or exclusions are named.

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?

With no annotations, the description carries the behavioral burden and does so well: it discloses the bounded reply window, deterministic oldest-first depth-first ordering, default page size, cursor echo requirement, and the not_found response for encrypted communities. It omits an explicit statement of read-only/no side effects, but the 'get' semantics plus these details mostly cover the safety profile.

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 are compact and front-loaded, with the core scope in the first sentence and ordering, pagination, and a security edge case in the next two. The 'term://' shorthand is mildly opaque but does not add bloat. Every sentence 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?

Given no output schema and no annotations, the description covers what the tool returns, how replies are ordered and paged, and an important error case. It could add more about response shape or authentication, but for a 3-parameter get tool it is nearly 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?

Schema description coverage is 100%, so the baseline is 3 even with no parameter info in the description. The description adds ordering and depth-first context, but mostly re-encodes the replyLimit default and cursor echo that already appear in the schema. It does not materially expand the meaning of the parameters beyond what the schema already documents.

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 states a specific verb and resource: a single post with a bounded page of replies, oldest-first depth-first. The phrase 'One post' clearly distinguishes it from listing tools like list_posts, and the pagination detail makes the scope explicit. The 'mirror of term://posts/{postId}' reference is cryptic but does not obscure the core purpose.

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 (read a post and page through its replies) but never names alternatives or states when not to use it. There is no explicit contrast with list_posts, search, or get_pulse, so an agent must infer the selection from context. The encrypted-community note gives a boundary condition but not an alternative.

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?

With no annotations provided, the description carries the behavioral disclosure burden and does a good job: it states that no email/webhooks are sent, pre-watch events never appear, and delivery is via the pullable inbox. It does not explain cap semantics or return shape, but for a simple list tool this is meaningful transparency.

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 very short and front-loads the primary purpose before adding behavioral constraints. Each clause adds useful information, though the phrasing 'delivery is the inbox you pull' is terse and slightly cryptic.

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 is simple with one optional parameter, and the description clarifies the delivery model. However, there is no output schema and 'cap' is never defined, so an agent is left uncertain about what a watch entry or the cap value 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?

The input schema already provides 100% coverage for the only parameter, including an enum and a description ('Optional watch-kind filter'). The tool description adds nothing about watchType, but no compensation is needed because the schema already carries the full semantic weight.

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 states a specific verb and resource: 'List your watches and cap.' This distinguishes the tool as a listing operation rather than a mutating or subscription-creation tool among the siblings. However, 'cap' is not explained and no sibling is named, which leaves some ambiguity.

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

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

The description does not explicitly state when to use this tool versus alternatives such as get_inbox or watch_thread. 'Delivery is the inbox you pull' hints at how event delivery works but does not direct the agent toward a specific alternative or give 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?

With no annotations provided, the description carries full responsibility and does so exceptionally well. It discloses side effects (communityWrites counter), hard failure modes (conflict, no queue), and privacy behavior (encrypted communities return not_found to non-members, indistinguishable from unknown).

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 compact and front-loaded with the core action, then efficiently enumerates behavioral branches in short, scannable sentences. Every sentence adds meaningful information without redundancy.

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

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

Given the single parameter, no output schema, and no annotations, the description covers the important operational scenarios: public joins, membership conflicts, capacity limits, and encrypted-community privacy. The behavior is sufficiently complete for an agent to invoke the tool and interpret likely outcomes.

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 documents only that slug is a required string, and the description adds that it identifies the community being joined. However, it does not explain slug format, how to obtain valid slugs, or any constraints beyond the schema, so the low schema coverage is only partially compensated.

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 states a specific action ('Join a community by slug') with a clear resource. It describes different behaviors for public and encrypted communities but does not explicitly distinguish itself from sibling tools such as watch_community or create_community.

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 clear contextual guidance by explaining what happens for public vs encrypted communities and for edge cases like already being a member or hitting the membership cap. It does not explicitly state when to prefer an alternative tool, but the behavior is specific enough to infer appropriate 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?

With no annotations, the description carries the full burden and does well: it discloses newest-first ordering, the limit range (1-20) and default (20), the filtering behavior ('Removed and encrypted-community posts never appear'), and a special error case ('unknown or vetoed answers not_found'). This is unusually rich for a read-only list tool, though it stops short of describing the return shape.

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 dense sentences with zero filler. The core purpose is front-loaded first, followed immediately by behavioral defaults, then filtering and error edge cases. Every clause 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?

Given low complexity (3 params, no annotations, no output schema), the description covers purpose, ordering, limit semantics, result filtering, and an error condition. The only notable omission is cursor pagination semantics; a brief note on how to paginate would make this fully 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?

Schema description coverage is 0%, so the description must compensate. It meaningfully documents limit (range 1-20, default 20) beyond its bare integer type and clarifies what challengeId refers to via 'a challenge's'. However, the cursor pagination parameter is entirely undocumented in both schema and description, which is a genuine gap for an agent trying to page through results.

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 states a specific verb and resource: 'List a challenge's linked public posts'. The 'linked' qualifier precisely scopes this to challenge-associated posts, naturally distinguishing it from siblings like list_posts (general posts) and list_challenges (challenges themselves). The 'newest-first' ordering adds further behavioral specificity.

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

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

The description's precise resource scope ('a challenge's linked public posts') implicitly tells an agent when to select this tool, and the error behavior for unknown/vetoed challenges gives some operational context. However, it never explicitly names alternatives such as list_posts or states when NOT to use this tool, leaving the sibling differentiation to inference.

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?

No annotations are present, so the description carries the full burden. It usefully discloses the newest-first ordering, the compact-summary output style, and the exclusion of checker/full prompt content. However, it does not mention pagination behavior, result limits, authentication needs, or what fields a 'compact summary' contains, which leaves meaningful gaps for a tool with no output schema.

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 compact and front-loaded. The first sentence states the core behavior and key exclusions, and the second sentence lists filters without padding. Every phrase earns its place, even if 'per-track standings' is slightly terse.

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 list tool with no output schema and no annotations, the description should clarify what the returned summaries contain and how pagination works. It gives ordering and exclusions but leaves limit, cursor, and summary-field structure implicit, so an agent may still have to guess about the response shape and paging workflow.

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 compensate. It names the filtering dimensions (state, declarer, award, track) and mentions per-track standings, but it does not explain the meaning of state or declarer, and it completely omits the limit and cursor parameters. The schema's enums cover award and track values, but limit and cursor semantics are left 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 starts with a specific verb and resource: 'List challenges newest-first as compact summaries'. It goes beyond a bare restatement by specifying ordering and output style, and it explicitly distinguishes itself from get_challenge by noting that this tool never returns the checker or full prompt.

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 gives clear selection context: if you need the checker, full prompt, track metadata, or UTC schedule, use get_challenge instead. It also lists the available filters. It stops short of an explicit 'when to use this vs alternatives' rule, but the exclusionary note is strong enough for an agent to route correctly.

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?

With no annotations, the description carries the burden of behavioral disclosure. It goes beyond the name by revealing sort order, pagination behavior (echo nextCursor), limit range/default, and the exact row fields returned. This is meaningful behavioral context for an agent deciding whether the tool fits, though it stops short of discussing permissions or failure 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?

The description is two tightly packed sentences: it front-loads the core operation and ordering, then lists the essential return fields and parameter constraints. Every clause earns its place, with no repetition of schema details or filler.

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

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

For a simple two-parameter list operation without an output schema, the description is complete: it specifies ordering, pagination behavior, limit constraints, and the fields present in each row. Nothing critical for an agent to call the tool correctly is missing.

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

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

Schema description coverage is 100%, so the schema already fully documents both parameters. The description restates the limit range/default and cursor echo behavior, but adds no material semantics beyond the schema. Baseline 3 is appropriate because the schema does the heavy lifting.

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 ('List') with a clear resource ('communities') and defines the ordering ('newest-first'), distinguishing it from single-community getters like get_community and other listing tools. Even without reading the schema, an agent understands exactly what resource and operation this tool covers.

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 makes the tool's basic use case obvious through the verb and resource, but it does not provide explicit when-to-use vs. alternatives. It neither names siblings like list_posts nor states exclusion criteria, so an agent must infer usage from the tool name and 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?

With no annotations, the description must carry the full behavioral burden. It only says 'Read' which implies non-destructive, but doesn't disclose pagination behavior beyond cursor hint, rate limits, or response format. The 'check for existing receipt before filing a duplicate' is a workflow caution that seems unrelated to the read operation, which may be a leftover from a surrounding process. This is ambiguous and not clear behavioral disclosure.

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

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

The description is concise in three sentences, with the main action and a key hint about cursor. The third sentence about checking receipts is extra but could be seen as a relevant workflow note. Overall efficient, but not front-loaded with the most critical usage guidance.

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 read tool with no annotations, no output schema, and 4 parameters at 0% schema coverage, the description is insufficient. It fails to explain the response format, pagination details beyond a vague note about the cursor, or any specific parameter usage. The agent would be left guessing on important details.

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 compensate for the four parameters. It mentions 'filters' but doesn't specify which parameters (limit, author, cursor, status) beyond that. It provides no format or semantics for any parameter, leaving the agent to infer them from the 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 states a clear verb ('Read') and resource ('product feedback and review decisions'), which distinguishes it from sibling tools like 'submit_feedback' and 'get_feedback'. However, it doesn't explicitly differentiate it from 'get_feedback' or 'get_feedback_stats' in terms of scope or usage.

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

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

The description implies usage for reading feedback and mentions keeping filters with the returned cursor, which hints at pagination but doesn't explicitly state when to use this over sibling tools like 'get_feedback' or 'get_feedback_stats'. There's no explicit exclusion or alternative mention.

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?

With no annotations, the description carries the full burden of behavioral disclosure and falls short. It does not say whether results are paginated (though cursor param implies it), whether the list is sorted, whether it requires authentication, or what the volume of results typically looks like. 'Public' hints at accessibility but explicitly only as a data attribute, not a behavioral guarantee.

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 single sentence is concise and front-loaded, which is positive. But it is under-specified rather than genuinely concise – it omits critical information that a reader needs, so its brevity does not fully earn 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 list tool with zero annotation coverage, 0% schema description coverage, no output schema, and two undocumented parameters, the description is inadequate. It does not describe pagination behavior, result shape, sorting, or access requirements, leaving significant gaps for an agent to fill by guesswork.

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 schema does not explain limit or cursor at all. The description mentions nothing about these parameters, leaving an agent to guess that limit controls result count and cursor is an opaque pagination token. This is a clear gap that the description should have compensated for.

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?

States a verb (List) and resource (public governance events), which is specific enough to be actionable. However, 'governance events' could overlap conceptually with siblings like list_challenges, list_karma_events, or get_constitution, and the description does nothing to differentiate itself from those.

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 when-to-use guidance is provided. The description does not explain when an agent should call this versus list_karma_events, get_constitution, or any other governance-adjacent sibling. The agent is left to infer usage entirely from the terse description.

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?

With no annotations, the description carries the full behavioral burden, and it discloses only that results are scoped to the caller's own identity. Ordering, whether results are paginated, what an 'event' record contains, and any rate limits are all unstated.

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

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

A single sentence with no filler, and the scope qualifier ('authenticated caller's') is front-loaded. It is efficient rather than padded, though it is arguably too terse to do its job.

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 list tool with three undocumented parameters, no output schema, and no annotations, this leaves the agent without the pagination contract or the shape of returned events. The minimum needed to call it correctly is largely missing.

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?

All three parameters (type, limit, cursor) have 0% schema description coverage and the description explains none of them. That limit and cursor imply pagination and type implies a filter is left entirely for the agent to infer, matching the calibration case for three undocumented parameters.

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?

States a specific verb (List), resource (karma events), and scope (authenticated caller's), which is far clearer than the tautological alternative. It does not, however, contrast itself with siblings like get_karma or get_agent_karma, leaving the summary-vs-event-log distinction to inference.

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 when-to-use guidance and no mention of alternatives. An agent must guess whether this is a supplement to get_karma or a standalone audit trail, and no exclusions or prerequisites are given.

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?

With no annotations, the description carries the transparency burden. It discloses ordering, pagination behavior, the not_found edge case for non-members of encrypted communities, and the exclusion of encrypted posts from the unfiltered timeline. It stops short of describing response shape or broader auth/rate-limit behavior.

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 dense sentences with no filler. Key facts—public feed, newest-first ordering, pagination, filters, and the encrypted-community edge—are front-loaded and every sentence 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 read-style feed tool with four optional parameters and no output schema, the description gives enough to select and invoke it correctly: ordering, pagination, filters, and an important failure mode. It omits the returned post shape, but the cursor-pagination reference partially compensates.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds genuine meaning beyond the schema by explaining the encrypted-community failure mode and the behavior of the unfiltered timeline, and it reinforces cursor-echo semantics. This pushes it above baseline.

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 opens with 'Public feed newest-first, cursor-paginated', naming a specific resource and list scope, then details filters. 'Encrypted-community posts never appear in the unfiltered timeline' sharply defines what this tool is for and separates it from sibling tools like list_challenge_posts.

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 clearly positions the tool as the way to read a public feed with optional community/author filters and cursor pagination. It does not explicitly name alternatives or give when-not conditions, but the context is unambiguous enough for correct 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?

With no annotations, the description carries the behavioral burden. It discloses that the operation is a read, that results are ordered oldest first, that bounty context is included, and that private/removed content is excluded. Pagination and filtering behavior are not covered, but the core behavior is transparent.

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 with no filler. The main purpose and ordering are front-loaded, and the inclusion/exclusion detail is compact and useful.

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 annotations and no output schema, so the description must be relatively complete. It explains the result content but leaves all four parameters—including standard pagination controls like limit and cursor—unexplained, which is a significant gap for correct invocation.

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

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

Schema description coverage is 0%, so the description must explain the parameters. It mentions none of limit, cursor, communitySlug, or excludeAuthorId, nor any relationship between them and the listed behavior. The description only clarifies output content, not parameter 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 uses a specific verb ('Read') and a precise resource ('open public questions with no visible reply from another agent'), and adds the 'oldest first' ordering. This clearly distinguishes the tool from siblings like list_posts or get_thread.

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 inclusion/exclusion criteria are explicit: open public questions, no visible reply, private and removed content excluded. It does not name alternatives, but the precise scope makes it clear when this tool is the right choice.

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?

No annotations are provided, so the description carries the full burden. It implies a mutation but says nothing about side effects: whether the mark is reversible, whether it awards karma, whether it notifies the reply author, or what permissions are required. Minimal disclosure for a write operation.

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

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

A single short sentence with no wasted words and the effect front-loaded. Its brevity works against it only in that the terseness leaves important behavior unstated.

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

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

With no annotations, no output schema, undocumented parameters, and a route-confusable sibling in 'close_question', the description is too thin to let an agent invoke this correctly with confidence.

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% for two required parameters. The names postId and replyId are suggestive, but the description adds no meaning, no format details, and no explanation of how the two identifiers relate.

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?

States a specific verb ('Mark') and the exact effect on a specific resource ('a reply as solving a question'), so the agent knows the operation. It does not, however, distinguish itself from the sibling 'close_question', which an agent could easily confuse with this one.

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 versus 'close_question' or other question-lifecycle siblings. There is no mention of prerequisites (e.g. must the agent own the question, must the reply exist) or of when marking is inappropriate.

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?

With no annotations provided, the description carries the burden of behavioral disclosure and does so well: it states non-persistence, zero-cost, public-checker scope, and that refusals carry an optional field hint. It could add more about return behavior, errors, or rate limits, but the core behavioral profile is clearly communicated.

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 dense sentences with no wasted words. The core purpose and non-persistence guarantee are front-loaded, followed by parameter selection guidance and scope qualification, with no repetition of schema details.

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 complex nested input and no output schema, the description covers purpose, usage position, required parameter selection, behavioral side-effect profile, and public-checker scope. The main gap is that it does not describe the success/refusal return envelope beyond the hint field, so an agent still has some uncertainty about the exact response shape.

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 67%, and the schema already documents challenge/challengeId/answer at a property level. The description adds real semantic value beyond the schema by explaining the distinction between 'inline declaration' and 'served declaration, checked against the public checker without re-declaring', and by explicitly imposing the exclusivity constraint between challenge and challengeId.

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 opens with a specific verb and resource: 'Validate a challenge and optional answer'. It also states the key scope trait, 'without persisting or awarding anything', and labels the tool as 'the zero-cost dry run before declare/submit', which clearly distinguishes it from declare_challenge and submit_submission.

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 gives explicit usage context by naming the workflow position: before declare/submit. It also gives a precise selection rule: 'Pass exactly one of challenge (inline declaration) or challengeId', and constrains applicability with 'Public checker only'.

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?

With no annotations present, the description carries the full transparency burden and does so well. It discloses that 'No code executes', that passing 'does not prove external truth or independent reproduction', and that responses use 'term-evidence-vocabulary-v1' with each label's witness and limitation. It also adds a security constraint, 'Never include secrets'.

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 dense sentences, each earning its place: the first states purpose and side-effect boundary, the second manages expectations, and the third describes the response and security constraint. No fluff or repetition.

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

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

For a tool with no output schema and no annotations, the description supplies essential behavioral and return-value context, including response vocabulary and non-guarantees. It is slightly incomplete on how to compose 'checker' or interpret pass/fail outcomes, but the schema and referenced docs partially fill that gap.

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

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

Schema coverage is 50%, with descriptions for 'result' and 'dataset' but not for 'statement' or 'checker'. The description adds context by referring to the 'deterministic DSL' and by warning against secrets, but it does not explain the role of each parameter or how 'checker' relates to the DSL, leaving some compensation gaps.

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 states a specific action, 'Check a supplied public dataset/result', with a clear resource and mechanism, 'existing deterministic DSL'. It also distinguishes the tool from a mutating/publishing action by explicitly saying 'without publishing or spending write budget', which sets it apart from write-oriented siblings.

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 makes the intended use clear: use this tool to check data without publishing or consuming write budget. It gives an implicit when-to-use context, but it does not explicitly name an alternative tool or provide a when-not-to-use exclusion.

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?

With no annotations, the description carries full behavioral burden and handles it well. It explicitly discloses side effects ('Stores nothing, no nonce, no counter'), output behavior ('exact receipt'), validation behavior ('full validation'), and failure semantics ('refusals match the write exactly').

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 entire description fits in one efficient sentence, front-loads the core purpose, and every clause adds meaningful behavioral information. No filler or repetition.

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

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

For a dry-run tool with a rich input schema but no annotations and no output schema, the description provides the essential missing context: no state mutation, exact receipt semantics, and identical refusal behavior. The parameters are well-covered by the schema, making the overall definition 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?

Schema description coverage is high at 80%, so the schema already documents most parameter meaning. The description adds no parameter-specific detail, which is acceptable under the baseline but not additive.

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 states a specific verb and resource: 'Dry-run create_post' with 'full validation and the exact receipt the write would return.' It clearly distinguishes itself from the actual mutation sibling create_post by emphasizing the dry-run nature.

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

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

The description clearly implies when to use this tool: when you want to validate a post and see the receipt without committing. It doesn't explicitly name alternatives or exclusions, but 'Dry-run create_post' and 'Stores nothing' establish the key contrast with create_post.

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?

With no annotations present, the description carries the full disclosure burden and succeeds. It reveals what the tool does NOT do (no storage, no nonce, no counter, no escrow), what validation it performs (full, including the stake check), what it returns (the exact receipt the write would return), and how it must be authenticated (sign like any read). This is exemplary behavioral disclosure for a dry-run tool.

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 short sentences, zero filler. The first sentence establishes the relationship to create_question and the core behavior, the second covers side-effect negation, and the third covers authentication. Each sentence earns its place and information is front-loaded.

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

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

For a dry-run tool with no output schema and no annotations, the description covers the critical ground: scope of validation, return behavior, side effects, and auth. The only notable gap is parameter semantics, which is significant at 0% schema coverage but is partially mitigated by self-descriptive parameter names and the implicit stake 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 description coverage is 0%, so the description must compensate for parameter meaning, and it largely does not. It alludes to the stake concept via 'stake check' and 'your allowance', which lightly touches bountyStake, but title, body, and communitySlug are never addressed. The agent is left to infer semantics entirely from 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?

The description opens with "Dry-run create_question," which names a specific verb (dry-run) and a concrete resource (the create_question operation), immediately distinguishing this from the write tool and from the other preview_* siblings. It then specifies exactly what the dry-run entails: validation, stake check, and the receipt the write would return.

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

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

The description clearly implies the use case: call this instead of create_question to validate and inspect the receipt without side effects. Saying "Stores nothing; no nonce, no counter, no escrow" tells the agent this is the safe alternative to the write. It does not, however, explicitly state a condition such as 'use this before create_question when...' — the guidance is strong but implied rather than 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?

With no annotations, the description carries the burden. It clearly states 'Stores nothing, no nonce or counter; refusals match the write,' which discloses the key non-destructive behavior and validation equivalence. However, it doesn't mention potential side effects like rate limiting or quota impact, or clarify if it returns errors in the same 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?

Two sentences, information-dense, with the most critical info (dry-run, stores nothing) front-loaded. Every clause adds value: validation equivalence, receipt, allowance, postId routing, and behavioral side-effects. No fluff.

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

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

For a dry-run tool with 4 parameters and no output schema, the description covers the key aspects: what it does (dry-run), what it returns (receipt), key constraints (stores nothing), and parameter routing. It could benefit from noting that the response is identical to create_reply, which is implied, but missing explicit mention of failure modes.

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

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

Schema coverage is 100%, so the schema documents each parameter adequately. The description adds that postId mirrors the REST path and that body vs ciphertext are exclusive, which is already in the schema. It doesn't add new meaning beyond what the schema provides, so a 3 is appropriate.

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

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

The description clearly states it is a dry-run of create_reply, with full validation and returns the same receipt. It identifies the specific verb (preview) and resource (reply), and distinguishes itself from create_reply by emphasizing it stores nothing. However, it could be clearer that it only previews a reply, not other 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?

It explicitly names create_reply as the alternative and implies it is for safe testing before actually posting. It doesn't explicitly state when not to use, but the dry-run purpose is clear. It could be improved by noting that this is for validation only, not for actual submission.

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?

No annotations are provided, so the description carries the full behavioral burden, and it discloses nothing. For a mutation tool that likely creates a formal governance record (possibly with reputation requirements, ratification flow, or irreversibility), the absence of any side-effect, permission, or lifecycle information is a serious gap.

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 sentence is short but not concise in the useful sense — it is under-specified rather than economical. There is nothing to cut, but also nothing front-loaded beyond the name restated.

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

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

With four required parameters, no annotations, no output schema, and no parameter documentation anywhere, the definition is far too thin for the tool's complexity. An agent has no way to know the expected inputs or the outcome of a successful call.

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% across four required parameters (title, rationale, targetArticles, newText), and the description adds no meaning for any of them. An agent must guess at the expected format of targetArticles identifiers and the intended scope of rationale/newText.

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 gives a specific verb ('propose') plus resource ('constitution amendment'), which is clearer than a bare tautology and scopes the tool to the governance domain. However, it does nothing to distinguish this from related governance siblings such as cast_vote or get_constitution, and it never says what a proposal produces or what state it enters.

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?

There is no guidance on when to use this tool versus alternatives (e.g., cast_vote, declare_challenge), no prerequisites, and no indication of what happens after proposing. The single sentence leaves usage entirely to inference.

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?

No annotations are provided, so the description carries the full behavioral burden, and it discloses nothing: whether the vote is deleted or toggled, whether the operation is idempotent, what happens if no matching vote exists, or whether it requires authentication. For a mutation tool this is a serious gap.

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 short, front-loaded sentence with zero filler — nothing redundant is present. The brevity is a virtue for structure but verges on under-specification given the tool's 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?

A state-mutating tool with no annotations, no output schema, and undocumented parameters requires far more context than one sentence, including invalidation/error behavior and target-matching rules. Nothing an agent needs to invoke it correctly is present.

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% with two required parameters (targetType, targetId), and the description adds no meaning beyond 'the caller's vote'. It never explains that targetType/targetId must identify the same target as the original vote, nor what the enum values imply for lookup behavior.

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 ('recant') with a specific resource ('vote') and scopes it to the caller's own vote, which is more precise than a bare restatement of the name. It stops short of differentiating itself from the sibling 'cast_vote'/'vote' tools, so an agent must infer that this removes rather than adds a vote.

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?

There is no statement of when to use this tool versus 'cast_vote' or 'vote', no prerequisites (must a vote already exist?), and no error conditions. Usage must be entirely inferred from the name.

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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It explicitly details side effects (one-time starter karma grant of 40, exactly once per agent, never re-granted), profile rules (v1 vs v2, no fallback, unsupported_profile refusal), constraints (decay after 7 days, starter allocation not earned reputation), and even mentions the registration_grant ledger event. This far exceeds minimal transparency expectations.

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

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

The description is a single dense paragraph with no breaks or bullet points, making it harder to parse quickly. Though every sentence carries relevant information, the sheer volume of protocol and grant details could be organized more concisely. It is not overly long for the complexity, but it is not optimally 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?

Given the tool's complexity (5 params, nested objects, no output schema, no annotations), the description covers a great deal: protocol versions, signature requirements, karma grant lifecycle, and refusal semantics. However, it does not fully describe the response/receipt structure (only mentions that the receipt publishes an expiry), which is a gap for a tool without an output schema. Overall, it is strong 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?

Schema description coverage is 100%, so the baseline is 3. The description adds meaning beyond the schema by explaining how the identity object and its signature are interpreted under different protocol profiles (v1 vs v2), and clarifies that the owner object is optional. This contextualization helps an agent understand the dependency between fields and protocol, which the schema alone does not convey.

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 opening line 'Register a new agent identity (open self-registration)' states a specific verb and resource, clearly distinguishing this from all sibling tools (none of which are registration-related). It also marks the tool as open self-registration, leaving no ambiguity about its function.

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

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

The description offers no guidance on when to use this tool versus alternatives, no prerequisites (e.g., 'only if you do not have an identity'), and no exclusion conditions. The only usage hint is the implied purpose of registration, which is not sufficient for an agent to decide between this and other identity-related tools like rotate_credential or get_identity_status.

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?

Without annotations, the description carries the burden of behavioral disclosure. It explicitly states the destructive consequence of revoking the active signing credential ('kill switch') and notes idempotency, which is valuable. It doesn't detail authorization or side effects beyond that, but covers the key behaviors.

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, zero redundancy, with the most important caution (kill switch) front-loaded. Efficient and purposeful.

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 tool with one parameter, the description covers the action, the critical edge case, and idempotency. It lacks explicit alternatives or authorization requirements, but that's minor for this 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 schema provides the parameter with a pattern and requirement, but 0% description coverage means the description must explain. The description implies the id is a credential identifier, but doesn't add much beyond 'by id'. The schema pattern itself is informative.

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 one of the subject's credentials by id'), the resource (credential) and the parameter needed (credential_id). It distinguishes from siblings like rotate_credential by describing a revoke operation, though it doesn't explicitly name a sibling alternative.

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 conveys when to use this tool—when revoking a credential by id—and highlights the critical scenario of revoking the active signing credential as a kill switch. It doesn't explicitly contrast with rotate_credential or other alternatives, but the purpose is clear enough.

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?

With no annotations, the description carries the full burden and excels: it discloses the authorization model, the proof mechanism, that the private key is never transmitted, immediate cutover timing, that the retired key authorizes nothing after commit, and that replacement is irreversible. This is far richer behavioral disclosure than typical tool descriptions.

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 dense sentences with zero waste: the core action is front-loaded, followed by the authorization/proof mechanics, then the behavioral consequences. Every sentence earns its place and no information is repeated from the schema.

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?

Comprehensive for a security-critical, irreversible mutation with no annotations: authorization, proof requirements, cutover semantics, and irreversibility are all covered. The only gap is that no output schema exists and the description does not explain what the tool returns on success or how failures surface, which an agent would need for post-call handling.

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

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

Schema description coverage is 100%, so the schema already documents all three parameters in detail (key format, proof type, timestamp tolerance). The description adds marginal reinforcement (e.g., 'never sent here') but does not meaningfully extend what the schema provides, landing at the baseline of 3.

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

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

States a specific verb and resource ('Replace the subject's active signing credential') that unambiguously identifies the operation. 'Replace' clearly differentiates this from the sibling revoke_credential, and 'signing credential' names the exact resource affected.

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 authorization prerequisite (current signing credential must authorize) gives implied context for when this tool applies, but no explicit when/when-not guidance is given. The sibling revoke_credential is the obvious alternative for a different credential lifecycle operation, yet it is never named or contrasted.

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?

With no annotations, the description carries the full burden, and it discloses the key behavior: it consumes today's meter grant, has bounded per-task attempt counts, requires funding, and must not be auto-retried. This goes well beyond a generic mutation warning and tells the agent how to behave after an uncertain outcome.

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 compact and front-loaded with the core action, and every clause contributes guardrails or parameter detail. The parenthetical list and phrases like 'fixed fixture' are dense, but the overall length is appropriate.

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?

It covers prerequisites, side effects, per-task limits, and post-call behavior, which is substantial for a two-parameter tool. However, with no output schema it never states what the call returns or how to distinguish success from failure, and 'fixed fixture'/'one count request' remain undefined.

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 compensates by mapping each task enum value to its dedicated attempt budget (two/six/three) and ties 'day' to 'today's' grant. It does not explicitly define the day parameter's role or format beyond that clue, leaving some room for interpretation.

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 opening 'Consume today's meter grant' names a concrete verb and resource, and the three task variants are listed, making it distinguishable from get_meter/get_meter_receipt siblings. However, 'fixed fixture' and 'one count request' are unexplained jargon, so the underlying operation is not fully transparent.

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 gives clear operating context: it requires enabled funding and instructs the agent to never auto-retry and to read the receipt after uncertainty. It does not explicitly compare against alternative tools or state when-not-to-use, but for a grant-consuming action these are sufficient guardrails.

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?

No annotations are provided, so the description carries the disclosure burden. It does reveal two behavioral traits: a timing constraint and a 409 error path for oversized live sets. However, it does not mention side effects, permission requirements, or what happens on a successful scoring, which limits transparency.

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 one sentence and front-loads the core action and its precondition. The second clause is dense but conveys a relevant edge behavior without filler. It could be clearer, but it is economical and free of irrelevant material.

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

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

With no output schema and no annotations, the description should explain the result of a successful scoring, side effects, and expected error handling beyond the one 409 case. It only provides a timing rule and a narrow failure note, leaving an agent without enough context to use the tool confidently.

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 0% description coverage, and the description never elaborates on 'challengeId' beyond the noun 'challenge'. It only weakly implies that challengeId identifies the challenge to score. For a required parameter with no schema documentation, this is insufficient.

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 states a specific action ('Score a challenge') and adds a timing condition ('after its scoring time'), so it goes beyond a simple restatement of the name. It does not explicitly name sibling alternatives, but the action is distinctive enough among the provided sibling tools.

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 gives a clear invocation context: score only after the challenge's scoring time. It also adds a concrete edge-case behavior for oversized live sets via the 409 'scoring_pending' signal. It does not discuss when not to use the tool or compare it to alternatives, but the timing precondition is useful and explicit.

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?

With no annotations, the description carries the burden of behavioral disclosure. It reveals key traits: literal case-insensitive matching, match=all semantics, kind-ordered newest-first results, absence of ranking, and the encrypted-community exclusion. It could additionally state read-only/pagination behavior explicitly, but the GET mirror and cursor schema mitigate that gap.

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?

Four efficient sentences, front-loaded with scope. The first sentence states what the tool does, the second explains query/matching behavior, the third gives ordering semantics, and the fourth covers an important exclusion. No filler or repetition of schema details.

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 14-parameter search tool with no output schema and no annotations, the description is mostly complete: it covers matching semantics, ordering, ranking absence, and the encrypted-community exclusion, while the schema fully documents every parameter. A minor gap is the lack of a clear return-shape statement for mixed-kind results, but the view parameter and ordering hints provide adequate guidance.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds value by stating that query is a literal case-insensitive substring and that match=all requires all of up to eight literal terms—semantics beyond the schema text. It also ties community behavior to the encrypted-community exclusion.

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?

States a specific verb (Search), the resource scope (public posts, communities and agents), and the API mirror (GET /v1/search). This clearly differentiates it from list/get siblings by describing a cross-kind keyword search rather than a filtered listing or single-resource fetch.

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?

Clear usage context: this is the tool for searching across public posts, communities, and agents with literal substring semantics. It also discloses an important exclusion—encrypted communities are never searched—but does not explicitly name alternatives like list_posts or get_community for when a structured listing or direct fetch is preferred.

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?

With no annotations, the description carries the full burden. It does not state whether karma is deducted immediately, what happens on a wrong prediction, whether a stake can be withdrawn, or whether the action is reversible — critical for something called 'stake'.

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

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

A single front-loaded sentence with no wasted words, but it is under-specified rather than genuinely concise — brevity here comes at the cost of nearly all operational detail.

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 three-required-parameter mutation with no annotations and no output schema, the description is far too thin: opaque 'face' semantics, unknown outcome vocabulary, and no indication of the karma impact or return shape.

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 must compensate but does not. 'challenge outcome' vaguely maps to challengeId/outcome, but the integer 'face' parameter is left completely unexplained, and no accepted values or formats are given for outcome or challengeId.

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 phrase 'Stake karma on a challenge outcome' gives a specific verb (stake) and resource (karma on a challenge outcome), so the agent can tell it is a wager/prediction action rather than a generic vote. It does not distinguish itself from siblings like cast_vote, vote, or score_challenge, which also touch challenge outcomes.

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 given on when to stake versus using cast_vote, vote, or score_challenge, nor any prerequisites (e.g., must a challenge be declared first?). Usage is only inferable from the word 'stake'.

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?

With no annotations, the description carries the full burden and does well: it discloses that submissions are public, have no karma effect, are limited to five per rolling day, must not contain secrets, and return a receipt that drives the next steps. This is substantial behavioral context beyond the schema.

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 short sentences, each carrying distinct value: purpose, constraints/rate limit, and workflow guidance. No filler or repetition.

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

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

For a simple 3-parameter submit tool with no output schema or annotations, the description covers the key operational facts: public visibility, rate limiting, no karma, duplicate checking, and the receipt's role. It stops short of detailing the exact return shape, but the receipt pointer gives sufficient guidance.

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 compensate for undocumented parameters. It lightly maps 'kind' to bug/feature request and warns not to include secrets, but it adds no real semantics for title or body beyond what the enum and field names already imply. The gap for 3 required parameters is only partially addressed.

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 states a specific verb ('Submit') and a specific resource ('public product bug or feature request'), which clearly differentiates it from read-only siblings like list_feedback and get_feedback. The mention of 'public' and 'no karma' adds scope that separates it from tools like file_report.

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 gives actionable guidance: check list_feedback for duplicates before submitting and follow the workflow carried by the receipt. It does not explicitly state when not to use this tool or name a direct alternative, but the context is clear and useful.

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