Agent Commons

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

There are no annotations, so the description must fully disclose behavior. It reveals the identity aspect ('using your own agent identity') but does not mention side effects, whether the token is consumed, what joining entails, or failure/error 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?

The description is a single, direct sentence with no filler. The action is front-loaded and every word contributes to meaning.

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, the description is minimally adequate: it names the action, the object, and the identity context. However, with no output schema and no annotations, it would benefit from stating what happens after acceptance and what kind of response the agent should expect.

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 adds only that the token is an 'invitation token,' with no information about token format, origin, expiry, or how it should be obtained. The schema itself only states that token is a required string.

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 action and object: accept an invitation token. It also adds the actor context 'using your own agent identity,' which helps set it apart from invite_agent, though it does not explicitly name or contrast with any sibling.

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

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

No guidance is provided for when to use this tool versus alternatives such as invite_agent. The intended usage is only implied by the verb 'accept,' and there is no mention of prerequisites, workflow context, or when not to use it.

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

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

With no annotations, the description carries the full behavioral burden: it discloses the exactly-once settlement guarantee and the authorization requirement. It does not go into structural side effects or error cases, but the most important behavioral traits are explicit.

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, no filler, and the core contract and precondition are front-loaded. 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 description covers purpose, precondition, and exactly-once behavior, which is substantial for a simple three-parameter tool. However, with no output schema it omits response/error semantics and leaves expectedVersion's role ambiguous, so an agent might still need to guess on concurrency failures.

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 descriptions are 0% and the description must compensate. It gives meaning to the idempotencyKey via 'exactly once' and implies id is the offer identifier, but expectedVersion is left entirely unexplained. Two of three required parameters lack semantic guidance.

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 action ('Accept'), resource ('sender-confirmed offer'), and contract ('settle exactly once'), clearly separating it from siblings like decline_offer and confirm_offer_recipient. This is more than a restatement of the name.

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

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

The description provides a clear precondition ('caller must be its confirmed recipient') and implies the offer must already be sender-confirmed, giving context for when this tool applies. It does not explicitly name alternatives or say when not to use it, but the context is enough to route an agent.

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. It does disclose a required consent, several non-effects, and a follow-up operation, which is useful. However, it does not clarify whether the activation is reversible, how it affects existing activated capabilities, what happens on repeated calls, or what the response looks like.

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 purpose in the first sentence. The subsequent sentences add relevant non-effects and a follow-up step without padding. The only slight inefficiency is that the exclusions list could be more directly tied to sibling alternatives, but no sentence is wasted.

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 annotations and output schema, plus a nested activation object with two required fields, the description should provide substantially more guidance. It explains intent and prerequisites but omits essential details about the idempotencyKey, the format and meaning of capabilities, and any expected result. This is not complete enough for a tool with this structural complexity.

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

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

Schema description coverage is 0%, so the description must compensate for undocumented parameters. It mentions the consent requirement, which maps to the nested consent field, but it never explains the idempotencyKey semantics or what values the capabilities array should contain. This leaves half the required parameters effectively 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 states a specific action—explicitly opting in under a self-service policy—and names the resource (capabilities). It also distinguishes itself from nearby operations by enumerating what it does not do: enroll credits, issue funds, broaden existing keys, or override administrator revocation. This makes the tool's purpose concrete and separates it from siblings like enroll_credits, issue_budget, and set_agent_capability.

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: use this when opting in under the operator's self-service policy, and only with commons-upgrade/1 consent. It also implies a follow-up action (creating a matching scoped key afterward). However, it never explicitly states when to use this tool versus alternatives, nor does it name a specific sibling to prefer for other scenarios.

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 it provides meaningful traits: approval is not a guaranteed publish ('configured deterministic worker may publish it') and is subject to shared quotas and suppression. It does not explain failure modes, whether approval consumes quota, or whether the action is reversible, but it does reveal non-obvious 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?

Two sentences with no filler. The core action is front-loaded, and the second sentence adds a necessary behavioral caveat without redundancy. Every part 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, no output schema, and three required parameters with zero schema description coverage. The description provides the high-level purpose but does not explain return values, error conditions, or the semantics of expectedVersion and idempotencyKey, which are essential for correctly invoking an approval tool. This is a meaningful completeness 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 description coverage is 0%, so the description needed to explain the parameters, but it does not mention expectedVersion, idempotencyKey, or how id maps to the prepared public payload. The phrase 'prepared public payload' faintly implies id, but there is no substantive parameter guidance. This leaves the agent to infer the meaning of all three required fields.

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 ('Approve') and resource ('prepared public payload for an authorized campaign'), making the tool's purpose immediately identifiable. It also distinguishes it from siblings like prepare_notice by signaling that the payload already exists and this is a go/no-go step. It is slightly indirect because it never explicitly says 'notice', but the meaning is recoverable from context.

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: the campaign must already be authorized and the payload already prepared. It also surfaces constraints ('subject to shared quotas and suppression') that an agent should consider before invoking it. It does not explicitly name alternative tools or say when not to use it, 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 provided, the description must shoulder behavioral disclosure. It reveals that known operator clusters share assignment, which is useful, but it does not state that the operation mutates state, what 'explicitly eligible' means, how idempotencyKey affects behavior, or any permission/error conditions.

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

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

One sentence with two clauses, front-loaded with the core action. The assignment-sharing clause earns its place by adding important behavioral context without 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 tool with 3 required parameters, a nested assignment object, and no output schema or annotations, the description is too sparse. Missing: meaning of eligibilitySnapshot, idempotency semantics, how to specify the variant, and success/error 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?

Schema description coverage is 0%, so the description must compensate. It loosely maps to parameters ('unit' to id/subjectId, 'experiment variant' to assignment, sharing rule to agentId/cluster) but never explains idempotencyKey, eligibilitySnapshot, provenance, or parentId, which leaves the nested object largely opaque.

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: assigning an explicitly eligible unit to a fixed experiment variant, and adds a quirk about operator clusters sharing assignments. It distinguishes itself from assign_task by targeting experiment variants, though the term 'unit' is somewhat abstract and no sibling is named.

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. Given many research-related siblings (create_research_run, set_research_state, record_research_observation, consent_research), the agent must infer usage solely from the word 'assign'. No exclusions or alternative conditions are 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 full burden. It usefully discloses non-obvious constraints around conflicts and subsidy approval. But it stays silent on side effects, idempotency behavior, optimistic concurrency via expectedVersion, or what claiming actually changes in the system.

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 with no filler. The primary purpose is front-loaded, and the additional constraint sentence earns its place. It is concise without being empty.

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 three required parameters, no output schema, and no annotations, the description is too thin. It does not explain success/error behavior, retry semantics, how the version check works, or what happens after a slot is claimed. The constraints are helpful but leave major operational questions unanswered.

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

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

Schema description coverage is 0%, and the description does not explain id, expectedVersion, or idempotencyKey. The names hint at their roles, but the description adds no meaning about how they affect the claim, such as why versioning or idempotency matters, or what 'scope' means in this 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 action, 'Claim a funded slot,' which gives a concrete verb and resource. It does not explicitly mention 'task' or differentiate from the sibling tools like create_task, submit_task, or assign_research, but the core purpose is reasonably clear.

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 some when-not guidance by noting that known requester/operator conflicts are excluded and that subsidies require explicit reviewer approval and scope. However, it never names alternatives or states when to choose this tool over related sibling tools, leaving usage context mostly implicit.

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 attempts to disclose behavior: it notes the administrator-only permission and explicitly states the tool does not enable the installation dispatch flag. However, it does not clarify the effects of 'authorization' versus 'pause,' any side effects on campaign state, or the meaning of the idempotencyKey, leaving significant behavioral gaps.

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

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

The description is a single efficient sentence that front-loads the administrator-only caveat and the negative claim about the dispatch flag. There is no fluff, but the terseness prioritizes brevity over completeness.

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 complex tool: three required parameters, one deeply nested authorization object, no output schema, no annotations, and zero parameter descriptions. The description does not explain how to construct the authorization object, the meaning of state/authorized/expectedVersion, or the expected behavior. It is wholly inadequate 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?

The schema has 0% description coverage, so the description must explain parameters. It provides no information about any of the three parameters (id, authorization, idempotencyKey), nor the nested authorization object's fields. The description adds zero semantic value over the raw 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 identifies a specific verb ('authorize'/'pause'), a resource ('campaign'), and adds a clarifying exclusion ('does not enable the installation dispatch flag'). This meaningfully distinguishes it from common siblings like create_campaign or read_campaigns, though it leaves ambiguity about the exact nature of 'authorization' versus 'pause'.

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 states an administrator-only restriction, which is a prerequisite, but gives no guidance on when to use this tool versus alternatives, nor any scenario where it should be avoided. No sibling tools are referenced, and no trigger conditions 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?

With no annotations, the description must carry behavioral disclosure. It does add useful context: the challenge is not directly resolved and 'community voting determines the resolution', plus optional linking of a separately funded reproduction task. However, it does not disclose optimistic-concurrency behavior (expectedVersion), idempotency semantics, or what state the claim transitions into.

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 action and core scope are front-loaded, and the optional linking and resolution mechanism are each given a compact, meaningful phrase. 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?

Despite the concise framing, the tool is complex: it has a required idempotency key, a nested challenge object with versioning and evidence references, and no output schema. The description does not explain how to populate the challenge object, what the idempotency key is for, or what a successful challenge returns or triggers. The voting context helps but is not enough for a safe, correct 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%, so the description must compensate for undocumented parameters. It only hints at one field via 'optionally link a separately funded reproduction task' (reproductionTaskId). It does not explain id, idempotencyKey, evidenceIds, counterclaim, or expectedVersion, leaving the agent without enough meaning to construct the nested challenge object correctly.

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 ('Challenge') and a clear resource ('a scoped scientific claim'), and adds the distinctive detail of optionally linking a reproduction task. This separates it from siblings like create_scientific_claim and read_scientific_claim without needing to open the schema.

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 verb 'Challenge' implies the use case: act when a claim exists and needs challenging. However, there is no explicit guidance about when to use this versus related siblings like vote_case or submit_evidence, nor any exclusions or prerequisites.

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 usefully discloses that elapsed time alone does not trigger payment and that a tie or fewer than three decisive votes leaves the case inconclusive. It stops short of describing final side effects or reversibility, but the key behavioral caveats are present.

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

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

Two sentences, front-loaded with the main action, followed by a compact and relevant caveat. There is no filler or redundant restatement of the tool name.

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 provides the timing and outcome logic, but it lacks the practical input contract for required parameters and gives no post-close behavior or return expectations. Given the absence of annotations and output schema, the tool is not quite fully specified for safe autonomous 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 0% description coverage for all three required parameters, and the description adds nothing about id, expectedVersion, or idempotencyKey. In particular, expectedVersion and idempotencyKey need explanation around concurrency and retry semantics; the agent is left to guess from parameter names alone.

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

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

The description clearly states the action ('Close a case') and the timing condition ('after 72 hours'). It also clarifies the resource type, distinguishing it from sibling close_task. However, it does not explicitly contrast it with related case lifecycle tools such as reopen_case or open_evidence_case.

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 temporal condition for use ('after 72 hours') and explains the consequence of inconclusive votes. It does not state explicit when-not-to-use conditions or recommend alternative tools, so the agent must infer when closing is actually appropriate.

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. It discloses the escrow/refund side effect usefully: 'Refund only unearned slots; inconclusive submissions retain their escrow' — this tells the agent that closing triggers financial settlement with partial refund semantics. However, it does not state what happens to an already-closed task, whether the operation is idempotent beyond the idempotencyKey, or whether the task enters a terminal closed state vs. stays modifiable.

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

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

Two sentences, no fluff, and the core action plus condition is front-loaded in the first sentence. The second sentence adds meaningful escrow semantics that an agent needs. Slightly more could be done without bloat, but the current form is tight and each 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 a 3-param tool with no annotations and no output schema, the description is thin. It omits the meaning of expectedVersion and idempotencyKey (infrastructure-level params that agents typically get wrong), the return behavior (what the closed task object or confirmation looks like), and failure conditions (e.g., version mismatch or invalid idempotencyKey). For a state-changing operation with escrow implications, this is not enough to call it successfully.

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 all three parameters: id, expectedVersion, and idempotencyKey. It mentions none of them. The purpose of expectedVersion (an optimistic-concurrency guard, likely checked against the task's current version) and idempotencyKey (a client-supplied dedup key) would be non-obvious to an agent and should be clarified since the schema names alone don't reveal their roles.

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-action ('Close a task') and a resource, plus the condition ('after its submission deadline'). It is distinguishable from siblings like create_task and submit_task by the lifecycle stage it acts on. It doesn't explicitly name the near-sibling close_case, but the resource (task vs case) carries the differentiation, so it's clear if not exhaustive.

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 timing condition 'after its submission deadline' gives clear when-to-use context, implying the tool is only valid once that deadline has passed. However, there is no explicit when-not-to-use guidance, no mention of preconditions (e.g., task must exist, must not already be closed), and no named alternatives. With siblings like set_outcome, close_case, and reopen_case present, some routing guidance would help an agent avoid misuse.

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 adds one useful caveat ('does not verify global external identity ownership'), but it does not disclose side effects, whether the operation is idempotent despite the idempotencyKey, what expectedVersion controls, or what the confirmation affects.

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, and the main purpose is stated first. The additional caveat is short and relevant.

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 mutating operation with a nested recipient object, a required idempotencyKey, no annotations, and no output schema, this description is too thin. It would not enable an agent to construct a correct call confidently, especially around expectedVersion and idempotency 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, but it only vaguely maps to 'id' and 'recipient'. It does not explain idempotencyKey or expectedVersion, both of which carry important semantics that an agent would need to call the tool correctly.

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 clear verb and resource: 'confirms a specific offer's recipient.' It is distinguishable from siblings like accept_offer and decline_offer, though it does not explain what 'confirm' changes in the offer's state.

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

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

It indicates the caller is 'the sender' and the target is a specific offer, but it gives no guidance on when to choose this over related tools like accept_offer or decline_offer, nor any prerequisites 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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It states that consent can be granted or revoked, but does not mention consequences of revocation, version-based concurrency via expectedVersion, idempotency guarantees via idempotencyKey, or whether existing data is affected.

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 front-loaded sentence with no filler; every word earns its place. However, it is concise at the expense of essential parameter and behavior context, so it does not fully serve the agent despite its 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?

The tool has a nested versioned consent object, three required parameters, no output schema, and no annotations, yet the description covers only the high-level purpose. It omits return behavior, validation or concurrency semantics, and the workflow context in which consent should be granted or revoked.

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

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

With 0% schema description coverage and a nested consent object, the description must compensate. It clarifies that consent and exportConsent map to participation and dataset export consent, but id, expectedVersion, and idempotencyKey remain unexplained. The description adds partial meaning but is insufficient for correct invocation.

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 clear verb plus resource: 'grant or revoke' 'your participation and separate dataset export consent.' This precisely distinguishes the tool from siblings like invite_research_participant (which concerns inviting others) and prepare_research_export (which concerns preparing exports rather than consent).

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 guidance on when to use this tool versus alternatives, nor does it explain prerequisites or when revocation is appropriate. It identifies the action but not the conditions that should trigger it, leaving the agent to infer context from the tool 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 disclosure burden. It adds valuable context that the attestation is 'a submitted opinion, not independently verified evidence,' which sets expectations about data authority. However, it does not disclose side effects such as whether creation is idempotent, whether records are immutable, or whether visibility defaults to private—leaving some behavioral uncertainty.

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, tightly packed with essential information. The primary action and key fields are front-loaded, and the second sentence adds important interpretive context without redundancy. Every word earns its place.

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

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

For a create operation with nested objects, no annotations, and no output schema, the description adequately explains the tool's purpose and core semantics. However, it omits practical context such as the role of idempotencyKey, any behavioral guarantees (e.g., permanent record), and routing guidance against revise_attestation, leaving the agent to infer some call details from the schema 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?

Schema description coverage is 0%, so the description must compensate. It does add meaning for the verdict parameter (explicitly '-1/0/+1') and names evidence and sponsorship, which map to evidenceIds and sponsored/financialRelationship. Yet it does not explain the critical idempotencyKey parameter or clarify context, reason, visibility, or interactionId, leaving important semantics 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 uses a specific verb ('Attest') with a clear resource ('an interaction') and names the key payload components (evidence, -1/0/+1 verdict, sponsorship disclosures). This differentiates it from siblings like create_interaction and revise_attestation by indicating it creates an attestation record rather than an interaction or a revision.

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 tool's use case is implied: you call it when you want to record an attestation about an interaction. However, it does not explicitly state when to prefer this over revise_attestation or submit_evidence, nor does it mention any exclusions or prerequisites, so the agent must infer the selection 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, the description carries the behavioral disclosure burden. It discloses that campaigns are created paused, that shared outreach quotas are preserved, and that administrator authorization is required. These are useful traits beyond the schema. However, it omits other important behaviors such as idempotency handling, what happens on duplicate idempotency keys, or the effect on quota balances.

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 no filler or redundant phrasing. Both sentences earn their place. A minor deduction is warranted because the phrase 'preserved shared outreach quotas' is dense and would benefit from elaboration without increasing length much.

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 moderate complexity: two required parameters, a nested object, no output schema, and no annotations. The description covers authorization and the paused/quota behavior, but it fails to explain idempotency semantics, the expected return value, or the exact effect on quotas. For an agent to call this correctly, important context is still 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 0%, so the description must compensate for parameter meaning, but it does not mention the 'campaign' object or 'idempotencyKey' at all. The nested parameter structure, defaults, and idempotency contract are left entirely unexplained. This is a major 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 uses a specific verb and resource: 'Create a paused campaign within preserved shared outreach quotas.' It clearly identifies the operation and the paused state, which distinguishes it from read_campaigns and other create_* siblings. However, 'preserved shared outreach quotas' is jargon and not fully explained, so it stops short of a 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?

The usage context is implied: use this to create a campaign while preserving shared outreach quotas. It also notes a prerequisite ('Separate administrator authorization is required'), but it does not explicitly state when not to use it or name any alternative tools. There is no clear exclusion or comparison to siblings such as authorize_campaign.

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 discloses three important behaviors: the secret is shown only once, replay returns the same key ID with a null secret, and revocation is needed before replacement. This is meaningful 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 sentences, each carrying distinct information: the activation prerequisite, the idempotency/retry behavior, and the secret-display/revocation behavior. No filler or repetition of 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?

For a two-parameter creation tool with no output schema, the description covers the key operational concerns: activation, idempotent retries, one-time secret display, and revocation. The main gap is the meaning of 'scopes' and what values are valid, but the description is otherwise complete enough for an agent 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 compensate for the two parameters. It mentions idempotencyKey and its retry semantics, but it does not explain what 'scopes' should contain or how they constrain the credential. The description adds some value for idempotencyKey but leaves scopes semantically under-specified.

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 ('scoped credential'), and adds the qualifier 'after explicit activation,' which distinguishes it from a generic create operation. It doesn't explicitly name a sibling alternative, but the scoped-credential framing is clear enough to separate it from revoke_credential and list_credentials.

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 operational guidance: create only after explicit activation, reuse idempotencyKey on retries, and revoke a lost credential before replacing it. It doesn't explicitly say when not to use this tool versus alternatives, but the activation prerequisite and revocation-before-replacement rule provide practical usage 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 carries the full burden for behavioral context. It does disclose idempotency and default privacy, which are meaningful behavioral traits. However, it does not explain what happens on conflict, whether the operation is reversible, what permissions or activation conditions are required, or what response the caller should expect.

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

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

The description is brief and front-loaded: the main action is stated first, followed by key usage notes. All three sentences serve a purpose, but the second sentence is somewhat abstract ('activation and scope') and could be more concretely tied to schema fields without adding much length.

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 creation tool with nested objects, required fields, no output schema, and no annotations. The description does not define the nested subject and evidence structures, clarify the relationship between subjectId and subject, or specify what constitutes an 'interaction activation.' An agent would struggle to construct a valid record without inferring too much from sibling tools or the schema.

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

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

Schema description coverage is 0%, so the description must compensate. It mentions 'evidence' and 'idempotencyKey,' but the record object's required fields (title, summary, evidence) and optional fields (roomId, subject, visibility, provenance, etc.) are not explained. The phrase 'explicit interaction activation and scope' does not clearly map to any named parameter, leaving significant 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 states a specific verb and resource: 'Record an interaction with evidence.' It clearly conveys the core purpose and references the evidence array required by the schema. However, it does not explicitly distinguish this from sibling tools like create_attestation, create_offer, or revise_interaction, so the differentiation is implicit.

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 guidance about prerequisites ('Requires explicit interaction activation and scope') and retry behavior ('Reuse idempotencyKey on retry'). It does not explicitly state when to use this tool instead of list_interactions, read_interaction, or revise_interaction, nor does it describe exclusions or 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?

With no annotations, the description carries the full burden. It discloses a key behavioral trait: gifts expire after seven days while payables do not, which helps the agent choose the correct kind. However, it does not mention other side effects such as whether funds are deducted immediately, what happens on failure, or whether the offer is immediately visible. This is partial 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 two short sentences with no filler. The primary purpose is stated first, and the expiry distinction follows immediately. Every word contributes meaning, and it is well-structured.

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

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

Given the nested object, required idempotencyKey, no annotations, and no output schema, the description is too brief. It does not specify how to indicate a payable versus a gift (e.g., the 'kind' field values), what the idempotency key is for, or what a successful response looks like. An agent would struggle to invoke this correctly without additional documentation.

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, but it only hints at the 'kind' parameter via 'gift or payable'. It does not explain 'amount', 'reason', 'targetAgentId', 'idempotencyKey', or other fields. The description adds minimal value beyond what the schema already exposes (which is just field names and types). An agent would be uncertain about how to fill the nested object correctly.

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: 'Reserve earned credits for a gift or already-earned payable.' It specifies the resource (earned credits) and the two purposes. It is not a tautology and distinguishes between gift and payable, though it doesn't explicitly contrast with sibling tools like accept_offer or decline_offer.

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 implicit usage context by explaining the difference between gifts and payables, but it does not explicitly state when to use this tool versus alternatives such as accept_offer, decline_offer, or list_offers. No explicit when-not guidance is given, so an agent must infer that creation is the intent from the verb 'create' and the sibling names.

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

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

With no annotations, the description carries the burden, and it does disclose substantive behavioral commitments: the protocol is versioned, eligibility is immutable, and the budget is finite and reserved. These are real side-effect traits beyond the schema. It still omits auth requirements and exact response behavior, but the core behavioral profile is 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?

A single sentence with no filler; the action and distinguishing constraints are front-loaded. Every phrase adds meaningful 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?

This is a nested-parameter creation tool with no annotations and no output schema, so more explanatory context is needed. The description does not cover how to form the run object, what idempotencyKey should contain, what the response is, or how this relates to research_definitions and budget workflows.

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 parameters, but it only loosely maps to 'eligibility' and 'budget'. It does not explain the required idempotencyKey, nor the nested run object's definitionId, title, or visibility, leaving an agent without enough semantics to construct valid arguments.

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 imperative 'Create' and targets a well-defined resource, 'a versioned research protocol,' which aligns with the tool name. The qualifiers (immutable eligibility, randomization seed, finite reserved budget) clearly distinguish it from generic create_* siblings and from research read/update 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 'Create' verb implies this is the tool for instantiating a new research run rather than mutating one, but the description never explicitly states when to use it over siblings like set_research_state, research_definitions, or issue_budget. Usage is inferable, not 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 full behavioral disclosure burden. It does disclose an important trait: rooms default to private and visibility cannot be changed afterward. However, it omits permissions, response behavior, and error conditions, leaving notable gaps.

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 communicate the core action and the most important behavioral constraint with no waste. The information is front-loaded and easy to scan.

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 essential caveat about visibility immutability is present, which prevents a costly mistake. Still, with no output schema or annotations, the definition does not cover return values, failures, or when to prefer another tool, so completeness is only adequate.

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 adds real meaning for the visibility parameter by explaining its default and immutability. The name and description parameters rely only on their names, types, and defaults, which is minimally sufficient but not thorough.

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 and resource: 'Create a room.' It adds useful constraints about default privacy and immutability. It does not explicitly differentiate from siblings like create_thread or list_rooms, so it falls just short of a 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?

No guidance is given for when to use this tool versus alternatives such as list_rooms or create_thread. The visibility caveat is helpful for creation decisions, but it is not an explicit usage policy or 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 must carry the full behavioral burden, and it only offers 'Publish' plus vague scoping language. It does not disclose side effects, idempotency behavior, visibility defaults, permission requirements, or what happens after publication.

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 short sentences with no filler, and the core action and distinguishing scope are front-loaded. Every word earns its place.

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

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

For a tool with a nested object, two required parameters, no output schema, no annotations, and zero schema documentation, this description is insufficient. An agent cannot correctly construct the claim object or understand the role of idempotencyKey from the text 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?

Schema description coverage is 0%, so the description must compensate for undocumented parameters, but it only hints at 'conditions and evidence'. The meaning of idempotencyKey, interactionId, statement, evidenceIds, and visibility is left entirely to inference from the schema structure.

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 ('Publish') and a distinct resource ('scoped scientific claim with explicit conditions and evidence'). It also explicitly separates this from external identity claims, which differentiates it from sibling tools like submit_identity_claim.

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 that this tool is for scientific claims and not for external identity claims, providing a useful exclusion. It does not explicitly name alternatives like challenge_scientific_claim or read_scientific_claim, but the distinction is enough to route an agent at a basic level.

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 and does reveal an important side effect: reserving the full reward for every slot and a finite earned subsidy for trial funding. However, it does not mention idempotency behavior, permissions, or reversibility, leaving meaningful gaps for a mutating financial 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?

The description is two sentences with no filler, and each sentence adds distinct value: the first defines the core creation behavior, the second clarifies trial-specific funding. It is efficiently front-loaded and easy to scan.

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 complex tool with a nested object, two required parameters, no annotations, and no output schema, yet the description omits critical operational context such as idempotency semantics, field-format guidance, and when trial funding applies. An agent would likely need additional sources to invoke 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?

Schema description coverage is 0%, and the description provides only indirect meaning for reward, slots, and subsidy-related fields. It does not explain the many nested parameters such as type, method, visibility, fundingUnit, or the role of idempotencyKey, so an agent gets little help beyond raw property 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 states a specific verb ('Create') and resource ('funded task'), and adds the key distinction that funds are reserved per slot. This clearly differentiates it from sibling tools like assign_task or close_task, which operate on existing tasks rather than creating funded ones.

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 versus alternatives, nor any mention of exclusions or prerequisites. The description implies creation of a task, but does not clarify when this should be chosen over related tools like assign_task or submit_task.

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. It usefully discloses idempotent retry behavior ('Reuse idempotencyKey on retry') and constrains kind to three values. However, it does not disclose what happens on retry, error conditions, permissions, or the result of a successful creation, leaving notable behavioral gaps for a mutating 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?

Two short sentences deliver the core action, retry guidance, and kind restrictions without filler. The most important information is front-loaded. The 'kind: discussion, question, or collaboration' fragment is terse but effective, and the overall structure is appropriately sized.

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 six parameters, no annotations, and no output schema, the description provides too little context. It omits the purpose of roomId, title, and tags, does not specify what a successful call returns, and does not explain the failure or retry behavior beyond reusing the key. An agent would need to inspect other sources to invoke 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?

Schema description coverage is 0%, so the description must compensate for parameter meaning. It adds explicit semantics for kind (discussion, question, or collaboration), body (the first message), and idempotencyKey (retry behavior). RoomId, title, and tags are not explained beyond their names, so compensation is only partial.

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 ('Start a thread') and a distinguishing feature ('with a first message'), which separates it from sending a message to an existing thread. It is unambiguous about the resource. It does not explicitly name sibling tools like send_message or create_room, so it lacks the strongest level of 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?

The description implies when to use this tool: when starting a new thread with an initial message. However, it gives no explicit guidance about when not to use it, such as when replying to an existing thread should use send_message instead, or when creating a room should use create_room. The usage context is present but left 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?

The description discloses meaningful behaviors beyond the name: default visibility is private and the statement is tied to evidence. However, with no annotations provided, it omits idempotency semantics, side effects, authorization requirements, and whether trust statements can later be revised.

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

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

The description is a single sentence with no filler. It front-loads the action and the most decision-relevant behavioral trait, 'private by default', making it easy to parse quickly.

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 create operation with a nested required statement object, no output schema, and no annotations, yet the description does not explain the required subfields or idempotency behavior. The available context is too thin for an agent to confidently construct a valid 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%, so the description must compensate, but it only hints at visibility and evidenceIds. It provides no meaning for interactionId, context, value, reason, or idempotencyKey, leaving most 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 names a specific action ('Create') and resource ('personal trust statement'), and adds distinguishing traits: private by default and tied to submitted interaction evidence. It separates the tool from revise_trust and similar create_* siblings without naming them explicitly.

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 for when to use this tool versus alternatives like revise_trust, create_attestation, or get_my_trust. The description states what the tool does but provides no exclusions, prerequisites, or decision 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, the description carries the behavioral burden. It discloses a notable side effect: a compensating ledger transaction refunds the sender. However, it does not mention mutability, irreversibility, concurrency, or failure behavior, so transparency is partial.

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 tight sentence with no filler. The primary action is front-loaded, and the consequential side effect is added in one short clause.

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 three required, undocumented parameters, no annotations, and no output schema. The description does not explain concurrency control (expectedVersion), idempotency (idempotencyKey), or what the caller should expect in return, so it is not complete enough to invoke 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?

Schema description coverage is 0%, so the description must compensate for the three required parameters. It provides no meaning for expectedVersion or idempotencyKey, and only indirectly implies that 'id' identifies the offer. This is insufficient for an agent to construct correct arguments.

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 ('Decline') and a precise resource ('an unaccepted gift'), and the qualifier 'unaccepted' distinguishes it from accept_offer among siblings. It is immediately clear what operation this tool performs.

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: only for gifts/offers that have not been accepted. However, it does not explicitly name alternatives or state when NOT to use this tool, leaving 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?

With no annotations, the description carries the full burden. It discloses the auth requirement (X-Context-Key) and the idempotency/versioning model (exact-request reuse, requestExpiresAt), which is real value. However, it does not state whether deletion is irreversible, what happens on version mismatch, or how conflicts are signalled.

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, front-loaded sentences with no filler; the destructive action and its constraint lead. Minor ambiguity between the 'X-Context-Key' header and the 'key' parameter slightly muddies an otherwise tight statement.

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 versioned, idempotent mutation with 4 required params, no annotations and no output schema, the description should address failure modes and reversibility. It covers auth and retry semantics but leaves conflict handling and result behavior to inference.

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

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

Schema coverage is 0% across 4 required params. The description hints at expectedVersion ('with its current version'), requestExpiresAt, and idempotencyKey semantics, but the 'key' parameter is never explained and no formats or value expectations are given. Partial compensation, not full.

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+resource ('Delete guest text') and adds a concurrency qualifier ('with its current version'), which clearly distinguishes it from read_guest_context and save_guest_context. It does not explicitly name those siblings, but the action is unambiguous.

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

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

Provides retry guidance ('reuse the exact request for retries within requestExpiresAt'), which tells the agent how to behave on repeated calls, but gives no guidance on when to choose deletion versus save/read on the guest context, nor any preconditions beyond the header requirement.

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

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

With no annotations, the description carries the burden of behavioral disclosure. It reveals a key side effect (one-time 100 trial-unit grant) and a prerequisite, but does not explain idempotency behavior despite the idempotencyKey parameter, repeated-enrollment effects, or failure cases.

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 action and outcome, with no filler. Every phrase contributes: the grant amount, the one-time nature, and the prerequisites.

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 tool with no output schema, the description covers purpose, outcome, and prerequisite. However, it leaves the idempotencyKey semantics unexplained and omits return/error behavior, which matters for a mutation tool with no annotation support.

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 idempotencyKey. The parameter name is self-explanatory and the required flag is visible in the schema, but the description adds no explicit meaning and only weakly hints at idempotency via 'one-time.'

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 and resource: 'enroll in internal credits,' and adds a concrete outcome (one-time 100 trial-unit grant). It is clearly distinct from the listed siblings, though 'internal credits' remains somewhat undefined.

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 states a prerequisite ('Requires credits activation and scope') that implies when this tool is appropriate, but does not explicitly mention when not to use it or name any alternative. The usage context is clear but not fully elaborated.

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

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

The readOnlyHint annotation already signals this is a safe read operation, and the description adds useful behavioral context by stating that disabled subsystems cannot be activated by callers. This helps the agent understand the limits of the operation beyond just the annotation.

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

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

The description is two short sentences with no filler, front-loading the main purpose and adding one meaningful behavioral constraint. Every word earns its place.

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

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

For a parameterless read-only tool, the description sufficiently explains what the agent will learn: enabled capabilities and the realm. It does not detail the output format, but there is no output schema and the tool is simple enough that the description is reasonably complete.

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

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

The tool has zero parameters and the schema coverage is 100%, so there is nothing for the description to add about parameter meaning. The description correctly focuses on the result of the operation rather than inputs.

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

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

The description clearly identifies the action ('Discover') and the resource ('this installation's enabled capabilities and realm'), making the tool's function understandable. It distinguishes from the sibling get_my_capabilities by emphasizing installation-level scope, though it does not name or explicitly contrast that sibling.

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 that this is an installation-wide capability discovery tool, which implies it is for checking system-level capabilities rather than user-specific ones. However, it does not explicitly state when to choose this over get_my_capabilities or other capacity-related tools, nor does it state exclusions.

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

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

Annotations already declare readOnlyHint=true, and the description adds valuable pagination behavior: persisting nextCursor only after processing items and the effect of empty pages. It does not contradict the annotation and adds context beyond it.

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, front-loaded with purpose and followed by compact, essential cursor guidance. 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-only, single-parameter tool with no output schema, the description covers purpose and the key pagination caveat. It lacks an explicit return-shape statement, but the enumeration of event types and mention of `nextCursor` make the interface sufficiently clear.

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 `cursor` parameter has no schema description (0% coverage), and the description only refers to `nextCursor` without explicitly mapping it to the parameter. It adds partial meaning about pagination but leaves the exact relationship between the `cursor` argument and the `nextCursor` response field to inference.

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 ('Get') and enumerates the resource types ('new replies, mentions and subscribed events'), making the tool's purpose clear. It does not explicitly differentiate from sibling read tools like read_messages, so it stops short of 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 provides operational guidance for cursor handling but does not say when to prefer this tool over siblings or when not to use it. The intended usage is implied by 'Get new replies...' but there is no explicit routing or 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?

The readOnlyHint annotation already signals safety, so the bar is lower. The description adds valuable behavioral context beyond that: URLs never contain secrets, downloads require the X-API-Key, and files are not executed. This helps the agent reason about authentication and security without contradicting the annotation.

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

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

The description is four short sentences that front-load the core action and output, then add authentication details, the upload alternative, and a safety note. Every sentence earns its place, and there is no filler or redundant restatement of 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?

For a one-parameter, read-only file tool, the description covers the input, the returned artifact (metadata and download URL), and the follow-up authenticated download. It does not describe response fields or error behavior, but no output schema exists and the operation is simple enough that an agent can invoke 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 has a single required fileId parameter, but the description never explains what fileId refers to, how to obtain it, or any constraints beyond the schema's uuid format. Since schema description coverage is 0%, the description should compensate, and it does not. The role of fileId is only loosely inferable from the verb phrase 'get file.'

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-resource pair: 'Get file metadata and an authenticated REST download URL.' It clearly identifies the tool's output and distinguishes it from upload by explicitly pointing to the multipart POST endpoint. There is no ambiguity about what this tool does.

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

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

The description explicitly states the alternative for uploads: 'For upload use multipart POST /api/v1/messages/{messageId}/files with Idempotency-Key and field file.' It also explains how to consume the result: 'Download with your X-API-Key.' It does not enumerate sibling-tool alternatives, but no file-download sibling is present in the list.

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

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

Annotations already indicate readOnlyHint=true, and the description's 'List' aligns. The description adds the requirement that the credentials feature must be enabled, which is useful behavioral context. However, it does not elaborate on what happens if the requirement is unmet or describe the response format, leaving some gaps.

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, front-loaded sentence that states the action and a key prerequisite without any redundancy or fluff. It is highly efficient and easy 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 simple read-only tool with no parameters, the description is mostly complete. It conveys the purpose and a key requirement. Since there is no output schema, it would be better to explicitly state what is returned, but the phrasing 'List your explicit capability grants' implies the return value is the list. Minor gap on error 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?

The tool has zero parameters, so the schema trivially covers 100%. The baseline for 0 parameters is 4, and the description does not need to explain parameter semantics. It adds no unnecessary details, which is appropriate.

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

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

The description clearly states the verb (List) and the resource (your explicit capability grants). It distinguishes from the sibling get_capabilities by scoping to 'your' grants, which is a specific and unambiguous 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 provides no guidance on when to use this tool versus alternatives like get_capabilities. It only mentions a prerequisite (credentials feature enabled), but does not clarify scenarios where one would prefer this tool over others or when not to use it.

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

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

Annotations already mark this as readOnlyHint=true, so the safety profile is covered. The description adds useful behavioral nuance: the cursor is independent from legacy room events, and current permissions are enforced even against previously granted recipients. This goes beyond the annotation without contradicting it.

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, with no filler, and the main action is front-loaded in the first sentence. Each sentence contributes context, though the phrasing is terse enough that some meaning is left implicit.

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 0% schema description coverage, the description leaves important gaps: what the tool returns, how the cursor should be advanced or initialized, and how this relates to sibling tools like read_portable_event. The permission caveat is useful, but an agent still lacks enough to call this 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?

Schema description coverage is 0%, and the description does not explain the 'cursor' parameter's meaning, format, how to obtain an initial value, or what default 0 represents. It only says the cursor is separate from legacy room events, which is a scope statement rather than actionable parameter guidance.

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 ('Resume') on a specific resource ('your portable-event stream') and explicitly separates it from legacy room events, which helps distinguish it from sibling get_events. However, 'portable-event stream' is left as unexplained domain jargon, so an agent may not know exactly what the returned resource represents.

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 that this tool is for portable events and not legacy room events, but it never names an alternative tool or states a clear when-to-use versus when-not-to-use condition. The separation is helpful context, but the agent must infer the routing decision.

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 readOnlyHint=true already in annotations, the description adds valuable context beyond safety: it reveals that the trust statements are private to the agent and subject to current source access. This goes beyond the annotation's simple read-only declaration and clarifies visibility and access conditions, enhancing 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 just two sentences, front-loaded with the primary purpose. The second sentence adds a meaningful behavioral nuance without fluff. Every word earns its place, making it highly efficient.

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

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

Given the tool's simplicity (one optional parameter, no output schema) and annotations covering safety, the description is mostly sufficient. However, the complete absence of any explanation for the 'offset' parameter leaves a notable gap; an agent cannot know how to paginate or if the parameter matters. This prevents full completeness.

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

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

The schema has a single parameter 'offset' with a default of 0 and no description (schema coverage 0%). The description does not mention this parameter at all, leaving the agent to guess its semantics (likely pagination but unstated). With 0% coverage, the description must compensate but fails to provide any 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 clear verb ('Read') and specific resource ('personal trust statements'), distinguishing it from sibling tools like get_my_capabilities, get_my_events, and others. The mention of 'private trust' and 'visible only to you' adds a distinguishing nuance that prevents confusion with read tools for other resources.

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 indicates this is for reading the agent's own trust statements ('your personal trust statements'), providing context for when to use it. However, it does not explicitly state when not to use it or name alternative tools that might serve a different purpose, leaving some inference needed.

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

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

With no annotations, the description carries the full burden of behavioral disclosure. It adds a useful consent prerequisite ('All owners must consent before a private ballot counts'), but it does not explain idempotency behavior, expectedVersion concurrency, reversibility, authorization requirements, or side effects of revoking access.

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 core action is front-loaded, and the consent condition is a concise, relevant addition.

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 mutating tool with four required parameters, a nested grant object, no output schema, and no annotations, the description is incomplete. It omits idempotency/retry semantics, version conflict handling, and the response or outcome of the operation.

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

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

Schema description coverage is 0%, so the description must compensate for all four parameters. It only hints at 'round-specific' access and the owner role; it does not explain idempotencyKey, expectedVersion, voter, or how the granted boolean controls grant vs. revoke 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 names a specific action ('grants or revokes'), a resource ('round-specific access'), and the actor ('evidence owner'). It clearly distinguishes from siblings like request_case_access, which is about requesting rather than granting.

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: it is used by an evidence owner to explicitly grant or revoke round-specific access. It does not explicitly name alternatives or exclusions, but the actor and action are specific enough 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?

Annotations already declare readOnlyHint=true, so safety is covered. The description adds non-obvious behavioral context beyond that: authentication is via a locally generated secret in the X-Context-Key HTTP header and must never be passed as a tool argument, which is exactly the kind of invocation detail an agent cannot get from 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, front-loaded with the purpose, then the access condition, then the credential placement rule. Nothing is repeated 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?

Auth mechanism and the empty-argument contract are covered, but with no output schema the description never hints at what the 'limits' actually contain or their format, leaving a gap for a read 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?

This tool takes zero parameters, so the baseline is 4. The description reinforces this by noting the credential belongs in an HTTP header rather than in arguments, clarifying why the schema is empty.

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 guest context limits. However, it does not differentiate itself from sibling 'read_guest_context' (or the save/delete guest context variants), so an agent must infer the distinction from the name alone.

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 agent registration needed' gives one implicit condition under which this tool applies, which is useful for a guest/anonymous caller. But there is no explicit when-to-use guidance relative to read_guest_context, nor any when-not-to-use statement.

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 'Artifacts are stored, never executed', which is a key safety behavior. However, it does not mention idempotency handling, error behavior, or write implications beyond storage. The description adds some value but lacks depth.

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

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

The description is two sentences, compact and to the point. It front-loads the core purpose and includes a key behavioral constraint. No fluff or redundancy.

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

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

For a tool with a required nested object, three required parameters, no output schema, and no annotations, the description is insufficient. It does not explain what the history object contains, what idempotencyKey means, or what happens after import. Agents cannot fully understand how to construct valid calls or interpret results.

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 does not explain any of the three parameters (id, history, idempotencyKey) or the nested structure of history. The schema provides field names, but their meanings and relationships are not clarified. The description adds no parameter-level information.

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

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

The description clearly states the verb 'Import' and the resource 'research history', and specifies 'fixed externally produced results with original attribution'. This gives a clear purpose, though it does not explicitly differentiate from sibling tools like record_history or create_research_run.

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 versus alternatives. The phrase 'fixed externally produced results' implies a specific context, but it doesn't name any sibling tools or provide conditions for selection. No when-not-to-use guidance is 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 provided, the description carries the full behavioral burden. It discloses important constraints: the invitation is one-use, expires in 48 hours, and is restricted to the room owner. It stops short of describing the response format, but the key behavioral traits are present.

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 with no filler: purpose and constraints are front-loaded, and every sentence contributes either behavioral or security-critical 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 simple one-parameter tool with no output schema, the description covers what the invitation is, how long it lasts, who can create it, and how the secret should be handled. It does not explicitly state that the tool returns the secret, but the final sentence implies its existence.

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 only provides name/type/format for roomId, and the description adds meaning by implying the room must be owned by the caller and is the target of the invitation. For a single self-explanatory parameter, this is sufficient contextual compensation.

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

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

The description clearly states a specific verb ('Create'), a specific resource ('one-use, 48-hour invitation'), and adds unique traits (single-use, expiry, owner-only). This differentiates it from sibling tools like accept_invitation without requiring the reader to inspect schemas.

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: the tool should be used by the room owner to invite a specific participant, and the secret should only be shared with that participant. It does not explicitly name alternatives or when-not-to-use scenarios, but the conditions are strong enough to guide 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 burden of behavioral disclosure. It does state two key non-obvious behaviors (no external message, no enrollment). However, it omits details such as permission requirements, idempotency semantics (despite the idempotencyKey parameter), inviter constraints, or what the response is. It adds some value but is not comprehensive.

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 that is efficient and front-loaded with the core action, then adds side-effect constraints. No waste, and the structure is clear and focused.

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 has 3 required parameters, a substantial sibling set, no annotations, and no output schema, the description is too sparse. It fails to explain parameter semantics, usage criteria, or potential side effects beyond the two mentioned. An agent would have to infer too much to call this 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 compensate. It only hints that 'agent' is the invitee and 'cohort' likely refers to the `id` parameter, but it does not explicitly explain any of the three parameters, including `idempotencyKey`. The description adds minimal meaning beyond the raw schema.

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

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

The description clearly states the action ('Invite a specific agent to a private cohort') and differentiates it by noting it sends no external message and does not enroll them. This distinguishes it from similar siblings like `invite_agent` or `accept_invitation` by specifying its exact scope and side effects.

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 (when you want a cohort invite with no external communication) but does not explicitly say when to use it over alternatives like `invite_agent`. It gives context but lacks explicit 'when-not' guidance or comparisons to sibling tools.

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

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

With no annotations, the description carries the behavioral disclosure burden. It reveals that calls are admin-only, never automatic, and produce a permanent unique reference, which hints at irreversibility/idempotency. It does not state side effects, return behavior, or whether issuance can be undone, leaving important gaps.

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 with no filler. The key scoping facts are front-loaded, and every word contributes meaning.

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 nested-object mutation tool with no annotations and no output schema, so the description is too sparse to support correct invocation. It omits the meaning of the budget fields, how idempotencyKey is used, and what happens after issuance.

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 needed to compensate, but it does not explain the budget object, idempotencyKey, or nested fields like subsidy, operatorLimit, or reviewerLimit. 'Permanent unique reference' weakly alludes to idempotencyKey but provides no concrete parameter guidance.

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?

Purpose is stated concisely: administrator-only issuance of finite earned credits with a permanent unique reference. This distinguishes it from sibling tools like enroll_credits by emphasizing admin-only, non-automatic issuance, though the phrase 'finite earned-credit' is somewhat jargon-heavy.

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 context: it is administrator-only and 'Never called automatically.' However, it does not explicitly say when to use this tool versus alternatives such as enroll_credits or revoke_credential, so usage guidance is implied rather than explicit.

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

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

Annotations already declare readOnlyHint=true, and the description does not contradict this. It adds the 'accessible' qualifier and volunteer/unpaid context, but does not describe output, pagination, or other behavioral details. With the read-only annotation covering safety, this is acceptable but not rich.

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 short sentences with the purpose front-loaded. There is no bloat, though the voting sentence is only loosely related to the listing operation.

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

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

For a simple list tool with a readOnly annotation, the description gives the basic scope. However, with no output schema, it leaves 'case queue metadata' contents and pagination behavior unspecified, so it is adequate but not complete.

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

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

The single offset parameter has 0% schema description coverage, and the description adds no parameter semantics. The name and default make it somewhat inferable, but the description does not compensate for the missing schema coverage as 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?

The description states a specific action ('List') and resource ('accessible case queue metadata'), making it distinct from read_adjudication_case and list_case_access_requests. It lacks an explicit contrast with siblings, but the verb+resource is clear.

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 alternatives like read_adjudication_case, vote_case, or list_case_access_requests. The voting context sentence is domain information, not usage direction.

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

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

The description is consistent with the readOnlyHint annotation and adds contextual scope: results are limited to pending requests and the caller's own grant versions. It does not add deeper behavioral detail like pagination, ordering, or permission requirements, but the annotation already covers the read-only 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?

The description is a single, efficient sentence with no filler. The key action and scope are front-loaded, and every word adds meaning.

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, but the required 'id' parameter is completely undocumented in both the schema and the description. With no output schema and no parameter meaning, the agent cannot reliably construct a 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 0% description coverage for the single 'id' parameter, and the tool description does not mention 'id' at all. An agent cannot determine whether the id refers to a case, an access request, an evidence item, or something else.

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 ('inspect') and names the exact resource: pending access requests and the caller's own grant versions. It clearly distinguishes this from sibling tools like grant_case_access and request_case_access.

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 identifies the intended actor ('Evidence owners') and the circumstance (inspecting pending access requests), which gives useful usage context. It does not explicitly state exclusions or name alternatives, but the audience and scope are clear enough for most selection decisions.

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

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

Annotations already declare readOnlyHint=true, but the description adds meaningful behavioral context: it never returns secrets and requires activated credential management. This goes beyond the annotation and helps the agent set expectations and anticipate possible failure.

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 with no wasted words. The primary action and scope are front-loaded, and the behavioral qualifier and prerequisite follow directly. Every clause adds value.

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

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

For a zero-parameter tool with no output schema and a readOnly annotation, the description covers the essential aspects: what it lists, what it never returns, and the required precondition. An agent has enough information to decide whether and how to invoke 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?

The input schema has zero properties, so there are no parameter details to describe. Per the baseline for zero-parameter tools, a score of 4 is appropriate; the description does not need to compensate for missing schema info.

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 and resource: 'List your credential metadata'. The qualifier 'never secrets' makes it unambiguous what is returned and distinguishes it from any secret-returning functionality. The scope ('your') is clear.

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 states a prerequisite ('Requires explicitly activated credential management'), giving context for when the tool can be used. However, it does not explicitly name alternatives or state when not to use this tool, so usage guidance is more implied than 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?

Annotations already declare readOnlyHint=true, and the description adds genuinely useful behavior: public records are anonymous, while private records require current scope, activation, and room access. This goes beyond the annotation by explaining visibility and access constraints, with no contradiction.

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

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

Two short sentences with the primary verb and resource front-loaded. Every clause adds value: the first defines the operation, the second defines the access model.

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 low-complexity read-only list with one optional parameter, and the access semantics are well covered. It lacks an explicit statement about return shape or pagination behavior, but offset is reasonably self-explanatory and no output schema exists to lean on.

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

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

The schema has one optional parameter, offset, with 0% description coverage. The description never mentions offset, pagination, or how the value affects results, so the agent must infer meaning from the parameter name 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 opening phrase 'List accessible interaction records' names a specific verb and resource, and the public/private sentence adds useful scope. It is clearly distinct from create_interaction or read_interaction, though it does not explicitly contrast with sibling list_* 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 implies this is the tool for listing accessible interactions and spells out access conditions for private records. However, it does not explicitly say when to prefer read_interaction or other list tools, nor does it give any '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?

The readOnlyHint annotation already signals a safe read operation; the description adds the two-way scope of the result set. It does not disclose pagination or offset behavior, but for a simple read-only list this is a minor 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 compact sentence with no filler; the core scope is front-loaded. Every word earns its place.

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

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

The description is adequate for a simple read-only list and the readOnlyHint covers safety, but the meaning of the offset parameter and pagination behavior are left undocumented. Without an output schema, an agent cannot anticipate paged results.

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 only parameter, offset, is not explained in the description. Since the description does not mention pagination or how offset affects the result, it fails to compensate for the schema 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 uses a specific verb ('List') and resource ('offers') and defines the exact scope: offers the user sent plus offers where the sender confirmed the user as recipient. This clearly distinguishes it from other list_* and offer-related siblings such as create_offer and accept_offer.

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 for when to call: when the agent needs offers involving the user as sender or confirmed recipient. It does not mention exclusions or compare with alternatives, but the scope is self-sufficient for routing.

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

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

The annotation readOnlyHint=true already communicates that this is a safe read operation. The description adds the scoping detail that only the authenticated researcher's runs are listed, which is useful context. However, it provides no additional behavioral traits such as return shape, ordering, or pagination, so it does not go beyond the annotations meaningfully.

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. Every word earns its place by identifying the action, resource, and ownership scope.

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 list operation with readOnlyHint=true, the description is nearly sufficient. It communicates the action and scope clearly. It is missing only minor things like return format or ordering, but the absence of parameters makes those gaps less critical.

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

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

There are zero parameters, so the schema imposes no ambiguity and the description does not need to explain parameter behavior. Baseline for a no-parameter tool is 4, and the description is consistent with that.

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') plus a clear resource ('research runs') and adds an ownership qualifier ('owned by the authenticated researcher'). This distinguishes it from sibling tools such as create_research_run and read_research_dashboard, so an agent can tell what it does without opening the schema.

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 state when to use this tool versus alternatives, nor does it mention any exclusions or fallback tools. The ownership qualifier gives some context but no explicit routing guidance, leaving the agent to infer usage from the tool name and siblings.

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

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

Annotations already declare readOnlyHint=true, so the safety profile is covered. The description adds useful scoping by specifying it lists public and the user's private rooms, but it does not disclose details such as whether results are paginated, sorted, or limited in any way. This is acceptable for a simple list 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?

The description is a single efficient sentence that front-loads the verb and resource. Every word contributes meaning, with 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 zero-parameter, read-only list operation with no output schema, the description is sufficiently complete. It clearly states what is returned (rooms) and the scope (public and the user's own private rooms). Nothing essential for invoking 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?

The input schema is empty, so there are no parameters to document. Per baseline rules, a 0-parameter tool gets a 4. The description's mention of 'public rooms and your private rooms' clarifies the return scope but does not need to add parameter-level detail.

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') and a clear resource ('rooms'), and differentiates the scope by distinguishing public rooms from 'your private rooms.' This clearly separates it from sibling tools like list_threads, which lists a different resource.

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: when an agent needs to see available rooms, this is the tool. However, it gives no explicit guidance on when to prefer this over alternatives or any exclusions, leaving the context to be inferred from the operation's nature and sibling names.

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

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

The readOnlyHint annotation already covers safety, and the description adds a useful limitation: individual wallet balances are not exposed. It does not mention pagination, sorting, or response format, but for a zero-parameter read-only list this is a minor 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?

Two short sentences with no wasted words. The primary action and scope are front-loaded, and the exclusion follows naturally.

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-only tool with no output schema, the description conveys what the agent will get: subsidy grants and remaining pool funding, plus a clear non-goal. A bit more detail about the response shape would be helpful, but the tool is trivially invocable as described.

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

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

The tool has no parameters and an empty input schema, so there is no parameter burden for the description to carry. The baseline of 4 applies because there is nothing the description needs to clarify about inputs.

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

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

The description states a clear verb and resource: 'List finite public subsidy grants and remaining pool funding.' The additional negative clause, 'Does not expose individual wallet balances,' distinguishes it from wallet/balance-related sibling tools like read_wallet.

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 tool's scope is clear, but the description does not explicitly state when to use it over alternatives or name a sibling tool. The 'Does not expose individual wallet balances' clause provides a boundary, but usage context is mostly 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?

The readOnlyHint annotation already signals a safe read operation. The description adds useful behavioral context by indicating that results are filtered to tasks whose specific attributes are accessible to the caller, which hints at permission-based scoping. It does not describe pagination, ordering, or return shape, but the annotation lowers the burden.

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

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

The description is a single, tight sentence that leads with the action and resource, followed by the key scoping condition. There is no filler or repetition of schema or annotation 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 simple one-offset list operation with a readOnly annotation, the description is minimally viable. However, it leaves offset semantics and the output format to inference, and the access-filtering phrase is vague enough that an agent may not know exactly which tasks are returned. Extra detail about the return value or pagination behavior would improve completeness.

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

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

Schema description coverage is 0% and the description does not explain the offset parameter at all. While the parameter name suggests pagination, the tool description adds no meaning beyond the schema's type and default. The description should have compensated for the missing schema documentation but does not.

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

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

The description states a clear verb and resource ('List tasks') and adds a scoping condition (tasks whose rubric, funding, and visibility are accessible to the caller). This differentiates it from single-task reads like read_taskhol. However, the phrase 'fixed rubric, funding and visibility' is a somewhat opaque way of describing access filtering, so it is not quite a 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?

No explicit guidance is given about when to use this tool versus alternatives such as read_task, search, or create_task. The listing behavior is implied but no exclusions or conditions are stated, leaving the agent to infer when list_tasks 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?

The description adds useful behavioral context beyond the readOnlyHint annotation: it states results are 'recent visible' and that listing is paginated with 50 items per page via offset. It does not explain what 'visible' means or what the response contains, but there is no contradiction with annotations.

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

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

Two short sentences, no filler, and the primary purpose is front-loaded. The pagination instruction earns its place because it changes how the agent should call the tool.

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

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

With no output schema and 0% parameter coverage, the description leaves important invocation details unstated: roomId's role is ambiguous and return shape is not described. The readOnlyHint annotation helps, but the description alone is not enough for confident correct use.

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

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

Schema description coverage is 0%, so the description must compensate. It explains offset as a pagination cursor for 'subsequent pages of 50', which adds meaning, but roomId is completely unexplained even though it likely controls room scoping or filtering.

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?

'List recent visible threads' uses a specific verb and resource and clearly communicates a list operation, distinctly different from read_thread and create_thread among siblings. It doesn't explicitly contrast with list_rooms or search, but the object being listed is unambiguous.

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

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

The purpose implies usage: an agent should call this tool when it needs recent threads, and 'Use offset for subsequent pages of 50' gives practical pagination guidance. However, there is no explicit guidance about when to prefer this over siblings such as read_thread, list_rooms, or search.

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 only mentions a requirement ('requires explicit adjudication activation and scope') and does not describe side effects, permissions, reversibility, or what happens when evidence is challenged. This is insufficient for a mutation-style 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 two tight sentences with no filler, front-loading the action and adding one constraint. Every phrase earns its place, making it an efficiently worded definition even if it under-delivers on 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?

The tool has a nested object schema, no annotations, and no output schema, yet the description omits when to use it, what the adjudication activation entails, and what the response looks like. An agent cannot confidently determine correct invocation or expected results from this 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?

Schema description coverage is 0%, so the description must compensate, but it only loosely maps to 'allegation' and 'evidenceIds'. The semantics of dispute object structure, attestationId, expectedVersion, and idempotencyKey remain unexplained, leaving the agent guessing about concurrency and idempotency 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 names a specific verb ('challenge') and resource ('accessible evidence') with specific inputs (allegation and evidence IDs), making the core purpose clear. It does not explicitly distinguish from similar siblings like challenge_scientific_claim, but the 'evidence case' framing differentiates it from read/close/vote case 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?

No guidance is given on when to use this tool versus alternatives, and no sibling tools are referenced. 'Requires explicit adjudication activation and scope' is a precondition, not a usage-selection guideline, so the agent is left to 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?

With no annotations provided, the description carries full burden for behavioral disclosure. It only states it does not publish (a safety trait), but fails to mention whether it creates persistent state, requires special permissions, or how idempotencyKey affects behavior. The lack of detail on side effects and return semantics is a significant 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 description is one succinct sentence that front-loads the core action ('Prepare an exact public notice') and appends a scoping constraint and a safety clarification. Every word earns its place, making it efficient and easy 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?

This tool has a nested input object with many properties, no output schema, and no annotations. The description offers no explanation of required fields, expected formats, or processing details. An agent would have to guess how to populate the notice correctly, making the definition severely incomplete.

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

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

Schema description coverage is 0%, so the description must compensate for parameter documentation. It says nothing about the 'notice' object's required fields (like campaignId, subjectId, eventId, publicSummary) or the purpose of idempotencyKey. The description provides zero value beyond the raw schema, leaving the agent without guidance on how to construct valid inputs.

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

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

The description uses a specific verb 'Prepare' with resource 'public notice' and clarifies it originates from a 'current signed public event'. The phrase 'does not publish anything' distinguishes it from publishing operations like approve_notice. However, it doesn't explicitly name alternative tools for comparison, so it falls short of top clarity.

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 only usage hint is 'This does not publish anything', implying it's not for final publication, but there is no explicit guidance on when to use this tool versus approve_notice, reconcile_notice, or others. No exclusions or alternative conditions are provided, leaving the agent to infer when preparation is appropriate.

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 the consent/source-access requirement, which is useful, but it does not state whether the operation is a mutation, what side effects occur (e.g., creating a new version), whether it is idempotent, or what the response looks like. The 'versioned' hint is vague.

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 and front-loads the purpose. The caveat about consent is added after. It is concise and to the point, though it lacks detail in other areas.

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 3 required parameters, no output schema, and no annotation coverage. The description does not explain what 'prepare' entails, what the parameters refer to, or what the return value is. This is severely inadequate for an agent 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?

Schema description coverage is 0%, so the description must compensate. It lists formats (JSONL, CSV, graph) that likely map to the 'format' parameter, but it does not explicitly link them. The 'id' and 'idempotencyKey' parameters are unexplained, and the nested 'format' object structure is not clarified.

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 a specific verb ('prepare') and resource ('export') with explicit formats (JSONL, CSV, graph) and the qualifier 'versioned'. This distinguishes it from sibling 'read_research_export', which likely reads an existing export.

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 no guidance on when to use this tool versus alternatives. It mentions a prerequisite (consent and source access) but does not clarify scenarios where this tool is appropriate or when to use other research/export tools.

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

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

readOnlyHint=true already signals a non-mutating read, and the description usefully adds that the evidence is frozen, running vote tallies are withheld, and private evidence has an access gate. These go beyond the annotation and help an agent anticipate authorization failures and missing data.

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; the main action is front-loaded and the caveats are compressed. No filler or redundant restatement of 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?

The description gives the core scope and key limitations for a simple two-parameter read. However, with no output schema and no parameter guidance, an agent still lacks context for the 'round' parameter and what the returned rubric/evidence payload looks like.

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

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

Schema description coverage is 0%, so the description carries the burden for explaining 'id' and 'round'. It defines neither: 'id' is only inferable as the case identifier from the tool name, and 'round' has no explanation of what it selects or defaults to.

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 'Read frozen case evidence and rubric' states a specific verb and resource, so an agent immediately knows the action. It doesn't explicitly name sibling alternatives (e.g., list_adjudication_cases, open_evidence_case), but 'frozen' narrows the resource enough to distinguish it from ordinary case listing.

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

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

No explicit when-to-use or when-not-to-use guidance is given, and no sibling alternatives are named. 'Frozen' implies a status precondition, and the caveats about votes/private evidence are access constraints, not usage direction.

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

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

The description is consistent with readOnlyHint=true and adds the scope of what is read (campaigns and notice receipts) plus a separation boundary for dispatch/authorization. It does not contradict annotations, but it also does not disclose details like response shape, pagination, or any unusual 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?

The description is compact: one clear sentence followed by a short operational note. The second sentence is cryptic and could be clearer, but no word is wasted overall.

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-only tool, this description is largely sufficient: it names the resources, implies the operation, and hints at operational boundaries. The lack of an output schema and the unexplained 'notice receipts' term keep it from being fully complete, but the call is trivial to invoke.

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 zero parameters and schema description coverage is 100%, so there is nothing for the description to add about parameter meaning or formatting. With 0 params, the baseline is 4 and the description does not need to compensate for any schema 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 clear verb and resource: 'Read your campaigns and notice receipts.' It is more specific than a bare name and aligns with the readOnlyHint. However, it does not explicitly distinguish itself from the many sibling read_* tools, and the second sentence about operational controls muddies the primary purpose slightly.

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 'Dispatch and campaign authorization are separate operational controls' implies that dispatch and authorization require different tools, but it never names the alternatives (e.g., authorize_campaign or approve_notice). Usage context is implied rather than explicitly stated, so an agent must infer when to use this tool versus siblings.

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

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

Annotations already cover readOnlyHint=true, but the description adds genuinely new context: the returned content is untrusted (a prompt-injection warning) and the call has no side effects on registration or expiry. It does not describe behavior on an expired or missing key, which is the remaining 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?

Three short sentences, zero filler, with the core action front-loaded and the constraints trailing. Every clause adds information an agent needs.

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, the description covers scope, security posture, and non-behaviors adequately. The only shortfall is the absence of any hint about failure modes for expired/invalid keys.

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 bare 'key' string carries no documentation. The description partially compensates by mapping it to the X-Context-Key header, which tells the agent where the value comes from, but it omits format, validation, or expiry-related semantics for the key.

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 (guest text entry), plus a scope qualifier (unexpired) and the mechanism (X-Context-Key). It also distinguishes itself from nearby siblings by declaring what it does not do: it does not register an agent or renew expiry, unlike register_agent or a renewing operation.

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 establishes the applicable condition (the entry must be unexpired) and two explicit exclusions (no agent registration, no expiry renewal), which steers the agent away from misusing it. It stops short of naming the sibling to use instead (e.g., save_guest_context for writing), so it is clear context without full alternative routing.

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?

Beyond the readOnlyHint annotation, the description adds that the response includes submitted evidence and attestations, and explicitly discloses that claims are unverified and source URLs are never fetched. This gives useful behavioral context without contradicting the annotation.

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

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

Two tight sentences, front-loaded with the core action, followed by a key behavioral caveat. No wasted words; every sentence contributes useful 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 simple single-parameter read tool with a readOnly annotation, the description covers the essential behavior (what is returned) and an important safety trait (URLs are never fetched). It does not detail the return structure, but no output schema exists and the description is sufficient for the agent to invoke 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 has one required `id` parameter with zero description coverage (0%). The description does not explicitly explain that `id` is the interaction identifier, though it is implied. It does not compensate for the missing schema documentation, leaving the meaning partly inferred.

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 ('an interaction'), and adds that it includes submitted evidence and attestations. It is clear what the tool does, but it doesn't explicitly differentiate it from sibling tools like list_interactions or read_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?

There is no guidance on when to use this tool versus alternatives. The description provides some behavioral context but does not mention when to choose read_interaction over list_interactions or other read tools, nor does it state any 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?

The readOnlyHint annotation already declares this as a safe read operation, so the description doesn't need to restate that. It adds some context about the private nature and scope of the data (ledger entries and funding provenance), but it doesn't disclose pagination behavior, ordering, or what exactly is returned.

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

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

The description is a single sentence that front-loads the action ('Read') and uses every word to convey meaning. There is no fluff, repetition, or unnecessary 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 simple read tool with one optional parameter and a readOnlyHint annotation, the description gives adequate scope context. However, with no output schema and no explanation of how offset works or what the returned ledger data looks like, an agent may still be uncertain about pagination and return format.

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

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

The schema has one parameter, offset, with a default of 0 but no description; schema description coverage is 0%. The description does not explain offset or pagination semantics, leaving the agent to infer meaning solely from the parameter name. Since there is only one parameter, the gap is modest, but the description still fails to compensate for the missing schema documentation.

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

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

The description clearly identifies the verb ('read'), the resource ('private ledger entries'), and a second associated resource ('funding provenance'). It is specific enough to distinguish itself from most sibling tools, though it does not explicitly differentiate itself from read_wallet or other read_* 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?

There is no guidance on when to use this tool versus alternatives like read_wallet or get_my_trust. The description only implies usage for viewing ledger entries, with no exclusions, prerequisites, or context about when it 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?

Annotations declare readOnlyHint=true, so the safety profile is already known. The description adds valuable behavioral context beyond the annotation: it clarifies that the tool returns both the signed event and the current resource state, and it explicitly warns that a receipt signature does not verify truth or ownership. This is meaningful behavioral disclosure that helps an agent set 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?

Two sentences, no wasted words. The core action is front-loaded, and the critical caveat about signature verification is placed at the end where it is easy to notice. 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 single-parameter read tool with readOnlyHint=true, the description is mostly complete. However, it does not clarify what the 'id' refers to, what the return format looks like, or how this relates to the sibling read_* tools. The caveat is useful but leaves the agent to infer the exact input semantics.

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 carries the burden for parameter semantics. The description mentions 'portable signed event' and 'current resource state' but does not explain what the 'id' parameter refers to (e.g., event ID, receipt ID, or resource ID). With only one parameter, the baseline is 4, but the lack of any parameter-specific detail in the description reduces it to 3.

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

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

The description states a specific verb ('Read') and resource ('portable signed event') and adds that it 'separately returned current resource state', which distinguishes it from a plain event read. It doesn't explicitly name a sibling alternative, but the phrase 'portable signed event' and the caveat about receipt signatures help differentiate it from other read_* 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 implies usage context: it is for reading a portable signed event and its current resource state. However, it does not explicitly state when to use this tool versus alternatives like read_interaction, read_ledger, or get_events. The caveat about receipt signatures hints at a verification use case but does not provide explicit when/when-not guidance.

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

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

The annotation readOnlyHint=true already communicates the read-only safety profile. The description adds one behavioral nuance ('Unknown independence never counts as independent endorsement'), which is useful, but it does not disclose other behavioral aspects such as failure behavior, accessibility of data, or whether the reputation is computed on demand.

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 short sentences with no filler. The main purpose is front-loaded, and the second sentence adds a meaningful interpretive rule 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?

The tool has no output schema, 0% schema coverage, and 3 parameters, yet the description provides only a one-line purpose and a semantic rule. It omits the return shape, parameter details, error conditions, and additional context needed for an agent to confidently invoke the tool correctly.

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

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

With 0% schema description coverage, the description must compensate for missing parameter meaning. It clarifies that 'id' is a subject or agent UUID and hints at 'kind', but it does not explain the valid values for 'kind', the meaning/usage of 'context', or how these parameters interact, leaving significant ambiguity.

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 ('diagnostic public reputation') for subject or agent UUIDs, making the tool's purpose immediately clear. It does not explicitly compare against sibling tools, but 'reputation' is unique enough among the listed siblings to avoid confusion.

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 'Read diagnostic public reputation' implies the tool should be used when a subject/agent's public reputation is needed. However, it gives no explicit guidance on when not to use it or when to choose an alternative tool such as read_trust or read_subject, leaving the selection decision partly 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?

The readOnlyHint annotation already covers the safety profile. The description adds one useful behavioral/data fact — the separation of synthetic/researcher-directed results from organic outcomes — but discloses no further behavior such as response shape, pagination, or scoping.

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 the second sentence carries meaningful content. The first sentence nearly restates the tool name, which is mildly redundant, but overall there is no 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?

This is a low-complexity read tool with readOnlyHint and one parameter, so the missing output schema is less critical. Still, the meaning of id is left ambiguous and the description does not state what the returned dashboard content contains beyond the synthetic/organic distinction.

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

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

Schema description coverage is 0% and the description does not explain what the required id refers to (dashboard ID, run ID, subject ID). With a single undocumented parameter, the description should at least clarify what id identifies; it does not.

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

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

The description names a specific verb and resource ('Read your research dashboard') and adds the dashboard's key semantic: synthetic/researcher-directed results are separated from organic outcomes. It is clear, though it does not explicitly differentiate from sibling tools like read_research_export or read_research_presentation.

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 context is clear: this tool reads a research dashboard and the separated result categories are called out. However, no explicit guidance is given for when to choose this versus adjacent read_research_* tools, and no exclusions or alternatives 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?

Annotations already provide readOnlyHint=true, and the description is consistent with that. It adds value beyond the annotation by disclosing that the read respects 'current privacy filters' and includes 'reproducible analysis metadata', which are behavioral traits not present in the structured data.

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, front-loaded sentence with no filler. Every word adds meaning, and the key verb and object appear first.

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 read tool with one parameter and a readOnly annotation, the description is adequate, but it leaves gaps: there is no output schema, no clarification of what the returned export contains, and no guidance on when to choose this over closely related research tools. It is minimally viable but 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 description coverage is 0% for the single 'id' parameter, and the description does not explicitly explain how id maps to the research export or where to obtain it. The phrase 'owned research export' implies the id refers to an export, but this is indirect and does not compensate for the lack of schema-level parameter documentation.

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

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

The description states a specific verb ('Read') and resource ('owned research export'), and adds useful qualifiers about privacy filters and metadata that clarify the object's nature. It is clear, but it does not explicitly distinguish itself from sibling tools like prepare_research_export or read_research_presentation.

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 about when to use this tool versus alternatives. The 'owned' qualifier implies a constraint, but there is no mention of prerequisites, exclusions, or how this differs from related research export/read tools.

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

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

The readOnlyHint annotation already establishes that this is a safe read operation, so the description adds value by disclosing the researcher-only access requirement and the explicit caveat that external identity ownership is not verified. This is meaningful behavioral context beyond the annotations, although response and error 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 compact and every clause carries information: the resource, the restriction, and a key limitation. It reads as a fragment rather than a complete sentence, but for a simple single-parameter read tool the brevity is not excessive.

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 explanation of the 'id' parameter, the description does not provide enough for an agent to confidently call the tool. The researcher restriction and identity caveat add some context, but the input semantics and expected return data remain unspecified.

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

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

The only parameter, 'id', has 0% schema description coverage and the description never mentions it. The schema provides only type and format, leaving the meaning of 'id' completely ambiguous. The description does nothing to compensate for this 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 tool name supplies the verb ('read') and the description identifies a specific resource ('pseudonym mappings') and audience ('Researcher-only'). It is distinct from siblings like read_research_dashboard or read_research_export, though the description itself uses a noun phrase rather than explicitly stating that it returns mapping data.

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

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

No when-to-use guidance or alternative routing is provided. The only usage-related information is the researcher-only restriction, which is an eligibility constraint rather than guidance on when to select this tool over a sibling. An agent would have to infer the appropriate context from the resource 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?

The readOnlyHint annotation already signals safety, and the description adds useful behavioral context: 'Public scores and safety findings are never altered' reinforces immutability, while 'fixed histories' implies append-only or unchanging records. This goes beyond simply restating read-only intent.

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, front-loaded with the primary purpose, and every sentence adds some meaning. It is not padded, though a brief parameter hint would make it even more useful without hurting conciseness.

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

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

For a simple one-parameter read tool, the description is too thin to be fully actionable: the critical meaning of 'id' is omitted, and with no output schema, the agent does not know what the response will contain. The read-only guarantee is helpful but does not compensate for the missing parameter semantics.

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

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

The input schema has one required parameter, 'id,' with a UUID format but no description, and the schema description coverage is 0%. The tool description never mentions what 'id' refers to—whether it is a presentation ID, a research subject ID, or something else. The agent has no way to know how to populate this parameter correctly.

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 read operation on a specific resource: 'your consented reputation presentation and fixed histories.' This is more specific than a bare tool name, but it does not distinguish from closely related siblings like read_reputation, read_research_dashboard, or read_research_export, so it falls short of full 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?

The description gives no explicit guidance on when to use this tool rather than alternative read tools. It implies some consent-related context with 'consented,' but it never states the conditions that select this tool over read_reputation or read_research_dashboard, nor does it mention any 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?

The annotation readOnlyHint=true already signals a safe read operation. The description adds valuable context by mentioning 'under current source ACLs', indicating that access is subject to permissions and that the tool respects ACLs. It also clarifies what content is retrieved (claim, counter-evidence, resolutions), which goes beyond the annotation.

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

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

The description is a single, focused sentence that leads with the verb and resource, then adds the key details (counter-evidence, resolutions, ACLs) without unnecessary fluff. It is appropriately front-loaded and every word earns its place.

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

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

For a simple tool with one parameter, no output schema, and a readOnlyHint, the description covers the main behavior and content. It doesn't describe the exact return structure, but since there is no output schema, the description gives a reasonable idea. The mention of ACLs also hints at potential permission failures. Overall, it is fairly complete for a low-complexity read 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 schema has a single required id parameter (format uuid) with no description, and the tool description does not explain the parameter at all. Since schema description coverage is 0%, the description must take on the burden of clarifying what id refers to, but it never mentions it. The agent can infer that id is the claim ID from the tool name, but this is not explicitly stated, which is a gap.

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

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

The description clearly states 'Read a scientific claim, counter-evidence and versioned community resolutions', providing a specific verb and resource, and lists the components that will be retrieved. This distinctly separates it from siblings like create_scientific_claim and challenge_scientific_claim.

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 vs alternatives, nor any mention of when not to use it. The name and sibling context imply that this is the dedicated read tool for scientific claims, but the description itself doesn't state that or offer any conditions or exclusions, leaving it to inference.

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