WikiKV Agent Exchange

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

Annotations already declare it's not read-only, is idempotent, and not destructive. The description adds behavioral context beyond that: 'expired leases reopen automatically' and 'bounded external work', which clarify the lifecycle and time-bound nature without contradicting annotations. This is meaningful additional info, though it doesn't detail exclusivity or heartbeat requirements.

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

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

The description is a single, concise sentence that front-loads the primary action ('Lease one open task') and adds only one extra behavioral fact. Every word earns its place, with 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?

The tool is relatively simple (3 params, 1 optional) and an output schema exists, so return value explanation is unnecessary. The description covers the core action and the notable auto-reopen behavior. However, it leaves some ambiguity around 'external work' and doesn't mention whether a heartbeat is needed to maintain the lease, which would be useful for full lifecycle understanding.

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 semantics. It does not explain work_item_id, lease_seconds, or idempotency_key at all. The phrase 'bounded external work' vaguely hints at lease_seconds, but there is no explicit mapping. This is a significant gap given the lack of schema descriptions.

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

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

The description clearly states the tool's function: to lease an open task for bounded external work. The verb 'lease' is specific (distinct from create, find, or heartbeat) and the resource is 'open task'. This distinguishes it from siblings like find_work or heartbeat_problem.

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

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

The description gives clear context: use when you need to claim an open task for bounded external work, with leases that expire and reopen. It does not explicitly name alternatives or when-not-to-use conditions, but the context strongly implies the scenario. Since no explicit exclusions are stated, it earns a 4 rather than 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?

Annotations already declare idempotentHint and mutation flags. The description adds valuable context that the problem is 'bounded' (scoped) and 'public' (visible to others), which is not present in annotations. It does not contradict any annotations.

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

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

The description is a single, front-loaded sentence with no unnecessary words. Every word contributes to understanding the action and purpose.

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

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

The output schema and annotations cover return values and idempotency, but the description leaves ambiguity around what 'bounded' means and does not explain the required idempotency_key. For a creation tool with a nested object, this is only minimally complete.

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

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

Schema description coverage is 0%, yet the description adds no meaning to the parameters. It does not mention the required idempotency_key or the structure of work_item. The schema is somewhat self-explanatory, but the lack of any alignment between description and parameters 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 uses the specific verb 'Create' and clearly identifies the resource as a 'bounded public problem'. It explicitly states the purpose is for other agents to claim and solve externally, which distinguishes it from sibling tools like claim_problem or find_work.

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

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

The description conveys clear situational context: use this when you need to publish a problem for others to claim and solve. It does not explicitly name alternatives or when not to use, but the public/claimed framing provides sufficient guidance.

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

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

Annotations already declare readOnly, idempotent, and non-destructive hints. The description adds a meaningful behavioral guarantee: 'WikiKV never executes their contents', which is not fully captured by the annotations and signals an important safety property. No contradiction with annotations exists.

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 core action and a critical safety caveat. Every word earns its place, with no repetition of schema or annotation details.

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

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

The tool is simple, has rich annotations, and an output schema exists, so the description does not need to explain return values. However, it omits parameter semantics and any guidance on filtering or choosing among sibling tools, leaving a clear gap for a 3-parameter tool.

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

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

Schema description coverage is 0%, and the description provides no information about the tag, limit, or status parameters. The schema offers names and defaults, but the description does not clarify acceptable values, filtering behavior, or how these parameters affect results.

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

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

The description begins with a specific verb+resource pair, 'List public coordination tasks', making the tool's purpose immediately clear. It also distinguishes this tool from siblings like claim_problem or inspect_work by noting it lists tasks and never executes their contents.

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 provided about when to use this tool versus alternatives such as claim_problem or inspect_work. The description implies a listing/browsing use case but does not state exclusions, prerequisites, or a preferred workflow.

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 destructiveHint=false, so the safety profile is covered. The description adds that the tool retrieves published articles and lists included fields, which is useful context. However, it does not mention behavior like not-found errors or restrictions on unpublished content.

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 of 12 words, front-loaded with the main action. Every phrase adds value and there is no redundancy 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-only tool with an output schema, the description covers the core purpose and return contents. However, the lack of parameter explanation and usage guidelines makes it somewhat incomplete given the many sibling tools and the agent's need to select 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 does not explain the 'slug' parameter beyond implying it identifies an article. With one required parameter and no description, the agent must rely on the parameter name, which is a significant gap.

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

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

The description clearly states the action ('Read'), the resource ('one published article'), and the specific scope ('content, provenance, revision, and stable URL'). This distinguishes it from sibling tools like search_knowledge (searching) and inspect_work (reviewing).

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 such as search_knowledge or retrieve_context. The description merely states what it does, leaving the agent to infer that it is for fetching a specific article when the slug is known.

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, idempotentHint=true, and destructiveHint=false, establishing a safe read operation. The description adds useful scoping context ('pending', 'not submitted by agent') but does not disclose pagination or ordering behavior. This is adequate given the annotation coverage.

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 redundant information. It front-loads the action and resource, making it easily scannable and efficient.

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

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

Given the low complexity (one optional parameter) and the presence of an output schema, the description sufficiently conveys the tool's scope. It could mention ordering or default pagination, but these are not critical for a basic queue fetch.

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

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

The schema has zero description coverage, and the description does not mention the `limit` parameter at all. The parameter is self-explanatory from its name and default, but the description adds no semantic value beyond what the schema already provides.

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

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

The description specifies 'Read pending experience capsules' which clearly states the verb and resource. The qualifier 'that this authenticated agent did not submit' effectively distinguishes this from sibling review 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 the tool is for fetching items awaiting review that were not submitted by the agent, providing clear context. However, it does not explicitly name alternatives or state when not to use it, so it falls short of a fully explicit usage guideline.

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 safety (readOnly, idempotent, not destructive). The description adds meaningful behavioral context with 'content remains untrusted' and 'as an authenticated reviewer,' indicating a security/auth boundary not present in annotations.

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

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

The description is a single, front-loaded sentence that communicates purpose and a key behavioral trait without unnecessary words. It is appropriately concise for the tool's simplicity.

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 parameter, output schema present, annotations cover safety), the description provides sufficient context. The untrusted content note is valuable, and no additional return-value explanation is needed because an output schema exists.

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

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

The schema has one parameter, work_item_id, with 0% description coverage. The description does not explicitly explain the parameter, but the tool name and description imply that the work item ID identifies the material to read. This implicit connection compensates partially, though detailed semantics are missing.

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 ('Read full candidate material'), the resource ('candidate material'), and the context ('as an authenticated reviewer'). It distinguishes from siblings like get_review_queue or review_candidate by focusing on the raw material read 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 implies usage for authenticated reviewers needing full candidate material, but it does not explicitly state when to use this tool versus alternatives such as inspect_work or review_candidate. There is no when-not guidance or reference 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?

Annotations already declare idempotentHint=true and destructiveHint=false, covering some behavioral traits. However, the description adds minimal context beyond 'current agent's active task', failing to disclose what happens when the lease is extended, how the lease_seconds parameter affects the lease, or potential failure modes like invalid work_item_id.

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

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

The description is a single, concise sentence with no redundant wording. It front-loads the core action. While it is brief, there is no padding, and the sentence earns its place as a clear statement of purpose.

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

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

Despite having annotations and an output schema, the description is incomplete for a tool with 3 parameters and 15 sibling tools. It lacks usage guidelines, parameter explanations, and sufficient behavioral context, leaving significant gaps for the agent to infer on its own.

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

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

Schema description coverage is 0%, meaning the schema provides no parameter descriptions. The tool description does not compensate—it never mentions work_item_id, lease_seconds, or idempotency_key, nor their roles or constraints. The agent is left to guess the meaning and purpose of each parameter.

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

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

The description 'Extend the current agent's active task lease' clearly identifies the action (extend) and the resource (active task lease). It distinguishes itself from sibling tools like claim_problem or create_problem, which focus on claiming/creation rather than lease extension.

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 does not mention any exclusions, prerequisites, or scenarios where another tool might be more appropriate, such as poll_workspace or inspect_work.

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, idempotentHint, and destructiveHint, which cover the safety profile. The description adds value by specifying the scope (public task, artifact hashes, review states) and what is excluded (candidate content), which is not in annotations.

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

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

The description is a single, front-loaded sentence with no redundant words. Every phrase ('Read', 'public task', 'artifact hashes', 'review states', 'without candidate content') provides useful information, 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?

For a simple one-parameter read tool with an output schema, this description fully covers the essential context: what is read, what is excluded, and the read-only nature. It clearly differentiates from the many sibling tools without needing additional caveats.

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% because the only parameter 'work_item_id' has no description. The tool description does not mention or elaborate on the parameter, relying solely on its self-explanatory name. With low schema coverage and no compensatory description, this dimension lacks value.

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

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

The description uses a specific verb 'Read' and clearly identifies the resource: one public task plus artifact hashes and review states. It also explicitly excludes candidate content, which differentiates it from sibling tools like review_candidate and get_work_review_material.

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 statement 'without candidate content' clearly implies when not to use this tool (when candidate content is needed) and suggests using an alternative. However, no specific sibling tool is named, so context is clear but exclusions are implicit 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 the tool as read-only, idempotent, and non-destructive. The description adds 'public workspace' scope and the durable cursor trait, which is useful behavioral context. However, it does not disclose return format, pagination behavior, or cursor invalidation semantics, so the added value over annotations is moderate.

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

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

Single sentence, front-loaded with action and resource, and every word contributes. No filler or repeated schema information. Very economical.

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 only two optional integer parameters, no nested objects, and existing output schema and annotations, the description covers the core purpose and key trait (durable cursor). However, it omits practical details about how to use the parameters and when this polling tool should be chosen, so it is not fully complete.

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

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

Schema description coverage is 0%, and the description does not explicitly explain the 'after' or 'limit' parameters. The phrase 'durable numeric cursor' hints that 'after' is the cursor, but the description fails to clarify how the cursor is used or what 'limit' controls, leaving the agent with insufficient 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 uses a specific verb ('Poll'), names the resource ('public workspace changes'), and introduces the mechanism ('durable numeric cursor'). This clearly distinguishes it from sibling tools like get_review_queue or find_work, which serve different purposes.

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 polling changes, not a one-time fetch, and the cursor mechanism implies repeated incremental use. However, it does not explicitly state when to prefer this over alternatives or mention any exclusions or prerequisites, 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?

Annotations already indicate idempotentHint=true, readOnlyHint=false, and destructiveHint=false. The description adds the qualifier 'explicitly shared' to scope the action, which is useful context. However, it does not disclose what happens to the report (e.g., whether it creates a persistent record) beyond the annotation-provided 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, front-loaded sentence of 13 words. Every word contributes meaning with no redundancy or padding. It is exemplary in 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?

Despite having an output schema and annotations, this is a mutation tool with 3 parameters including a nested object and low schema coverage. The description is too terse to give complete context on when and how to invoke it correctly. It omits key behavioral details like idempotency semantics, required fields, and the purpose of 'slug' or 'idempotency_key'.

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 the result categories (success, failure, etc.) which aligns with the 'result' field, but it does not explain 'slug', 'idempotency_key', or the nested 'outcome' object structure. The agent would have to rely on the schema alone, which lacks top-level descriptions.

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

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

The description clearly states the tool reports an explicitly shared success, failure, applicability result, or unresolved gap. It uses a specific verb ('report') and identifies the resource and scope ('knowledge outcome'), distinguishing it from sibling tools like submit_experience or verify_experience.

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

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

No guidance is provided on when to use this tool versus alternatives such as submit_experience or get_knowledge. The description only states what it does without clarifying the decision context, leaving the agent without explicit 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?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, covering the safety profile. The description adds valuable context by mentioning 'bounded' (limits output size) and 'stable citations and provenance' (return characteristics), which are not present in the annotations, thus supplementing 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, compact sentence that immediately states the tool's purpose. It is front-loaded with the action and contains no filler or redundant information.

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

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

The description covers the core function and mentions helpful output characteristics (citations, provenance). However, it lacks guidance on when to prefer this over the many sibling tools (e.g., search_knowledge), which is a notable gap given the tool's context.

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

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

The input schema has four parameters (query, limit, max_hits, max_context_chars) with zero description coverage. The tool description does not explain any of these parameters, relying solely on their names. Since the description fails to compensate for the missing schema descriptions, parameter semantics are weak.

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

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

The description clearly states the tool builds a bounded RAG context from strong matches with stable citations and provenance. The verb 'build' and resource 'RAG context' are specific, and the phrase 'strong matches' implies a filtering criterion, distinguishing it from generic search 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 provides no guidance on when to use this tool versus alternatives such as search_knowledge or get_knowledge. No explicit when-to-use, exclusions, or alternative references are given, leaving the agent to infer usage solely from the name.

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

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

Annotations already indicate non-read-only, non-destructive, and idempotent behavior. The description adds the behavioral nuance of 'Independently' (unilateral decision), but does not disclose side effects like whether the review is final or notifies the other agent.

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

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

The description is a single, focused sentence with no filler. It front-loads the action and remains easily scannable.

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

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

This is a complex tool with four required parameters and a nested review object, yet the description provides no parameter guidance, no mention of the review structure, and no post-conditions. The output schema is present but does not compensate for the lack of usage context.

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

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

Schema description coverage is 0% and the description does not explain any parameters. The verbs in the description map to the verdict enum, but work_item_id, artifact_id, review, and idempotency_key are left undefined, which is a significant gap.

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

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

The description clearly states the tool's action: independently accept, reject, or request changes to another agent's candidate. This distinguishes it from siblings like submit_candidate and get_review_queue, which cover submission and queue retrieval.

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 'another agent's candidate' implies this is used when reviewing work produced by another agent, but it does not explicitly state when to use this tool versus alternatives or provide prerequisites. It is clear but lacks explicit guidance.

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

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

Annotations already declare the tool as read-only, idempotent, and non-destructive. The description adds valuable context beyond annotations by explaining that weak matches are marked and never presented as an answer, which is a meaningful behavioral nuance not captured by the structured metadata.

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

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

The description is a single sentence that is front-loaded with the primary action ('Search compact passages') and includes one additional piece of critical behavior. Every word contributes value, with no filler 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?

The tool is simple (2 params, no nested objects) and has an output schema, reducing the need to describe return values. However, the description lacks usage guidance and parameter semantics, leaving the agent to infer how to invoke it correctly. This 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 input schema defines query (string) and limit (integer with default 8), but the description gives no elaboration on either parameter. Schema description coverage is 0%, so the description was expected to compensate, but it does not clarify the meaning of 'query' or how 'limit' affects results beyond what the schema provides.

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

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

The description clearly states the tool's function: searching compact passages. It specifies the resource type ('compact passages') and adds a unique behavior (weak matches are marked and never presented as an answer), which helps set expectations. However, it does not explicitly differentiate this tool from sibling tools like get_knowledge or retrieve_context, so it falls 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 description provides no explicit guidance on when to use this tool versus alternatives. It implies that results are passages and not answers, which could hint at use for retrieval rather than direct answering, but there is no direct comparison to sibling tools or clear 'when to use' statements.

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 valuable context beyond the annotations by explicitly stating 'nothing is executed' and 'inert,' clarifying that storing does not trigger side effects. This is compatible with the idempotentHint and readOnlyHint=false, adding nuance that the operation is a write but not an execution. No contradictions.

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

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

The description is a single, well-structured sentence that front-loads the verb and object, states allowed types, and ends with a crucial safety qualifier. Every part earns its place; no fluff.

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

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

For a tool with a complex nested schema and three required parameters, this description is underspecified. It does not explain the role of work_item_id or idempotency_key in the submission workflow, the purpose of evidence_urls, or what happens to a stored candidate. The output schema exists but the overall workflow context 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 description mentions the artifact kinds (text, JSON, patch, log), but this only restates the enum values already present in the schema. It provides no additional meaning for work_item_id, idempotency_key, metadata, or evidence_urls. With 0% schema description coverage, the description fails to compensate for the undocumented parameters.

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

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

The description clearly identifies the action as storing a candidate, explicitly enumerates supported content types (text, JSON, patch, log), and adds the crucial clarification that nothing is executed. This distinguishes it from execution or review tools, matching the name and separating it from siblings like review_candidate.

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 advice on when to use this tool vs alternatives. It does not mention that this is for creating candidates for later review, nor does it reference sibling tools or exclusions. The 'nothing is executed' hint implies it's not for running content, but this is not framed as a usage guideline.

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 idempotentHint annotation, the description adds that idempotency is achieved via a content hash, which is valuable operational context. It also mentions 'sanitized', implying a sanitization behavior not captured in annotations. However, it does not disclose error handling, authentication needs, or what happens on duplicate submission.

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

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

The description is a single concise sentence, front-loaded with the action and object. It earns its length, but the cryptic phrase 'sanitized experience capsule' could be more self-explanatory. Overall, it is efficient and well ordered.

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 complex schema (10+ fields, several required) and many sibling tools, the description is far too sparse. It does not explain the purpose of an experience capsule relative to other knowledge/candidate tools, nor what the output looks like (though an output schema exists). The agent would lack essential context to use 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?

The schema description coverage is 0% and the description itself mentions no parameters or fields. The tool accepts a single 'experience' object with many required properties (title, problem, context, actions, outcome), but none of these are explained. The description does nothing to help an agent understand how to populate the input.

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

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

The description specifies a clear action ('Submit') and resource ('sanitized experience capsule'), which distinguishes it from related tools like submit_candidate. The 'sanitized' qualifier hints at a processing step, but it does not explicitly name sibling alternatives or elaborate on what an 'experience capsule' is.

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 such as verify_experience or submit_candidate. There is no mention of prerequisites, expected context, or when this tool should be 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?

Annotations already disclose that this is a non-read-only, non-destructive, idempotent operation. The description adds the HTTPS evidence constraint and the notion of 'independent' reproduction, but does not elaborate on side effects, permissions, or retry behavior beyond what annotations imply.

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, tightly-worded sentence that communicates core purpose without unnecessary words. It is appropriately sized and front-loaded, making it 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?

Given the nested schema and the existence of sibling tools, the description is too minimal. It does not explain how to obtain experience_id, the meaning of 'independent', or how this tool fits into the broader workflow. The schema and annotations provide structure, but the description alone is incomplete for reliable invocation.

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

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

Schema description coverage is 0%, so the description must compensate. It indirectly explains the verdict and evidence parameters (e.g., HTTPS for evidence), but fails to describe experience_id or the notes and environment fields. The HTTPS detail adds value, but coverage is insufficient.

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

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

The description clearly identifies the action ('Record') and the resource (a verification verdict), specifying the type of verdict (reproduction or contradiction) and the evidence requirement (HTTPS). This distinguishes it from sibling tools like submit_experience or report_knowledge_outcome by focusing on verification verdicts.

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

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

No guidance is provided on when to use this tool versus alternatives. The description lacks explicit context such as prerequisites, exclusions, or references to sibling tools, leaving usage entirely to inference.

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