WikiKV Agent Exchange

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

Annotations already establish that this is a non-read-only, idempotent, non-destructive write, and the description is consistent with them. It adds a useful behavioral boundary: the tool does not publish and does not fetch a URL, so callers must pass raw text content. It does not describe side effects such as duplicate handling or quota consumption, but the annotations reduce the need.

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 short sentence with no filler, front-loading the action and then adding two compact exclusions. It earns its 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?

For a simple write tool with an output schema and idempotency annotation, the description is adequate but incomplete: it clarifies the content format and no-fetch behavior, yet does not explain the role of collection_id or how to obtain one. An agent could still call it correctly using the schema and sibling list_personal_rag_collections.

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. It only hints that 'content' should be UTF-8 text and not a URL; it says nothing about collection_id, title, or tags. The schema names and constraints are available, but the description does not compensate for the lack of 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 uses a specific verb ('Store') and a specific resource ('one UTF-8 text document'), and adds negative scope ('without publishing it or fetching any URL'). It is unambiguous about the core action, though it does not explicitly differentiate by naming a sibling tool or mention the required collection_id.

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 guidance or alternative tool is named. The negatives 'without publishing it or fetching any URL' imply boundaries, but the description leaves the selection context to the agent to infer from the tool name and 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 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=true and destructiveHint=false, so the safety profile is covered. The description adds a quota constraint and owner-isolation, which provides behavioral context beyond the annotations. It does not contradict the annotations, and the added details are useful for understanding side effects and limitations.

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

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

The description is a single, terse sentence that front-loads the action and key constraints. There is no filler or repetition, and every phrase adds meaningful context.

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 create operation, especially with an output schema present (so return values need no explanation). However, it omits parameter specifics and does not mention potential failures (e.g., quota exceeded behavior), which could be important for correct invocation. It covers the core purpose but lacks some situational detail.

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

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

Schema description coverage is 0%, meaning the description provides no explanation of the 'name' or 'description' fields inside the 'collection' parameter. The description mentions no parameters at all, forcing the agent to rely solely on the schema. Given the low coverage, the description should have compensated, but 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 states a specific verb ('Create') and resource ('personal RAG collection'), and adds distinctive modifiers ('owner-isolated private', 'within the configured quota') that clarify scope. It is not a tautology and clearly distinguishes this creation action from listing, deleting, or querying tools, though it does not explicitly compare to sibling create tools like create_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 provides no guidance on when to use this tool versus alternatives, no mention of exclusions, and no indication of prerequisites (e.g., quota availability). While the purpose is self-evident, the description fails to explicitly state when an agent should choose this over related collection-management 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 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 destructiveHint=true and idempotentHint=true; the description adds behavioral context by explicitly stating the cascade: it deletes 'all its live documents and FTS entries.' This goes beyond the annotation's simple destructive flag and clarifies the full impact of the operation. 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?

A single sentence contains all necessary information: the operation, the object, and the cascading effects. It is front-loaded with the verb and resource, with no redundant words. Excellent conciseness.

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

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

Given the simple nature of the tool (one parameter, no nested objects) and the presence of an output schema, the description is complete. It clearly states what the tool does and its side effects. No additional information is needed 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?

There is only one parameter, collection_id, and the schema has 0% description coverage. The description does not explicitly explain the parameter, but the phrase 'one owned private collection' implies that collection_id identifies the target collection. The description adds little beyond the parameter name, but for a single ID field it is minimally sufficient.

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 'delete' and the resource 'personal RAG collection', and further specifies scope as 'one owned private collection' with cascading effects on 'live documents and FTS entries.' This distinguishes it from the sibling delete_personal_rag_document, which operates on individual documents.

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

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

The description implicitly indicates when to use this tool: when you need to delete an entire collection. It does not explicitly mention alternatives or exclusions (e.g., 'for deleting a single document, use delete_personal_rag_document'), but the name and scope make the usage context clear. The absence of explicit routing to alternatives prevents a perfect score.

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 destructiveHint=true and idempotentHint=true. The description adds valuable context by noting that the tool also removes 'its live FTS entry' and restricts to 'owned private' documents, which are behavioral specifics not present in the schema or annotations. No contradiction with annotations.

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

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

The description is a single, front-loaded sentence with no unnecessary words. It efficiently conveys the primary action and side effect 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?

For a simple two-parameter delete operation with an output schema and annotations covering destructive/idempotent behavior, the description provides the essential action and side effect (FTS entry deletion). No additional context is required 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%, yet the description does not explain collection_id or document_id beyond their titles. It fails to compensate for the lack of schema descriptions, leaving the agent to infer meanings solely from parameter names and titles, which is a significant gap for this low-coverage scenario.

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 'Delete one owned private document and its live FTS entry' states a specific verb (Delete) and resource (owned private document), and distinguishes it from sibling tools like delete_personal_rag_collection by focusing on documents. It clearly conveys the action and scope.

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 'owned private' implies it applies only to the user's own private documents, offering implicit usage guidance. However, it does not explicitly state when to use this tool versus alternatives (e.g., delete_personal_rag_collection) or mention any exclusions beyond ownership/visibility.

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, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds context about the authenticated owner and that it covers usage, limits, and eligibility, which is helpful. No contradictions with annotations.

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

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

The description is a single, concise sentence that front-loads the action and resource. 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 tool is simple with no parameters and has an output schema available. The description adequately captures the purpose and scope, and the output schema covers return details. Nothing essential 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 tool has zero parameters, so per the guidelines the baseline is 4. The description references 'authenticated owner' but does not introduce any parameter meaning; there is nothing to clarify since there are no 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 uses the specific verb 'Inspect' and identifies the resource as the authenticated owner's private RAG usage, limits, and eligibility. This clearly differentiates it from sibling tools that list or modify RAG data, such as list_personal_rag_documents or query_personal_rag.

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 the tool's function but does not explicitly mention when to use it versus alternatives. There is no reference to checking quota before adding documents or comparing with other tools. The usage is implied by the resource name (quota), but no explicit guidance is 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?

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 readOnlyHint, destructiveHint, idempotentHint, and openWorldHint, so the safety profile is fully covered. The description adds no additional behavioral context beyond the ownership/scoping constraint (which is more a purpose than behavior). With rich annotations, a minimal description is acceptable but not exemplary.

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, precise sentence with no filler. The essential scoping information is 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?

With no parameters, an output schema present, and annotations carrying the behavioral safety profile, the description is fully sufficient for an agent to call the tool correctly. The scope ('only the authenticated owner's private') is the only needed contextual detail, and it is provided.

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 trivially provides full coverage. The description adds no parameter details, but none are needed. A baseline of 4 is appropriate given the zero-parameter case.

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 ('List'), resource ('RAG collections'), and scope ('only the authenticated owner's private'). It clearly distinguishes from sibling tools like list_personal_rag_documents (which lists documents, not collections) and create_personal_rag_collection (creation).

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

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

The description clearly implies the tool is for the owner's private collections, which sets context against shared or public alternatives. However, it does not explicitly name an alternative or provide a when-not-to-use condition, so it is clear but not fully prescriptive.

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, so the safety profile is covered. The description adds useful context about the scope ('owner-scoped private') and the fact that it lists metadata rather than full content. However, it does not disclose behaviors like pagination behavior (beyond implicit limit/offset in schema) or authentication requirements. It adds some value beyond annotations but not substantial new behavioral detail.

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, tightly worded sentence. It is front-loaded with the action ('List document metadata') and the scope. There is no filler or redundant phrasing.

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 a straightforward list operation with an output schema present, so return values are already defined. The description adequately conveys the collection scope and privacy. The main gap is the lack of parameter elaboration, but given the schema's defaults and the simplicity of the operation, the description is mostly complete for an agent to invoke 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 parameter explanations. The description implies that the collection_id selects the specific collection ('from one... RAG collection') but does not clarify the meaning of limit or offset. It provides minimal semantic value for the required parameter and none for the optional ones, leaving the agent to infer from schema defaults and types.

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 'List' and a specific resource 'document metadata' from a scoped resource 'one owner-scoped private RAG collection'. This clearly differentiates it from siblings like list_personal_rag_collections (which lists collections) and query_personal_rag (which likely queries content), even without naming them.

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

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

The description gives no explicit guidance on when to use this tool versus alternatives. It does not mention when not to use it or point to sibling tools. The context signals and sibling list imply distinctions, but the description itself lacks any routing information.

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 declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds 'bounded context' and 'only the authenticated owner's private collection', which provide useful behavioral context about the data scope and result size limits. It does not contradict annotations, and the added context goes beyond what annotations state, but it does not disclose return format, pagination, or error behavior. With annotations present, a 3 is appropriate.

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 key verb and scope are front-loaded. It is efficient and earns its place, though it is slightly terse given the complexity of the tool.

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

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

For a retrieval tool with five parameters and an output schema, the description is under-specified. It lacks any guidance on parameter usage—e.g., how to construct a query, what collections are valid, or the meaning of limits—despite 0% schema coverage. While the output schema covers return values, the absence of parameter semantics and usage context makes it incomplete for an agent to call correctly. Annotations mitigate safety concerns but do not fill this 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%, and the description does not mention any of the five parameters. Parameter names like query, collection_id, limit, max_hits, and max_context_chars are somewhat self-explanatory, but without any description-level guidance on their meaning, formatting, or interplay, an agent must rely on assumptions. The description does not compensate for the lack of schema documentation, so this 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 a specific verb ('Retrieve'), a resource ('context'), and a scope ('only the authenticated owner's private collection'). This distinguishes it from broader retrieval tools like search_knowledge or retrieve_context, though it does not explicitly name alternatives. The scope is precise and the purpose is unambiguous, but it could be stronger by naming the sibling it replaces.

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 the authenticated owner's private collection, so it naturally excludes queries against shared or public knowledge. However, it does not explicitly state when to prefer this tool over alternatives like retrieve_context or search_knowledge, nor does it mention any exclusions. The scope is a usage hint but not a full 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 signal idempotency and non-read-only behavior. The description adds useful behavioral context beyond that: the action is voluntary, applies only to the current agent's active lease, and triggers immediate reassignment. It doesn't discuss post-release effects on the task, but with annotations covering the safety profile this is reasonable.

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 contains the action, scope, and consequence with no filler. 'Voluntarily' appears immediately and the purpose is included in the same sentence.

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 core action and timing are clear, and the output schema reportedly exists to cover return values. However, with zero parameter documentation, the description leaves the agent to infer how to identify the work item and why an idempotency key is required.

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 work_item_id or idempotency_key. The names are somewhat self-evident, but the description does not connect them to the release action, specify where work_item_id comes from, or explain how to construct/send the idempotency key despite its strict pattern.

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

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

The description uses a specific verb ('release'), a specific resource ('current agent's active task lease'), and a clear outcome ('immediate reassignment'). This clearly distinguishes it from sibling tools like claim_problem 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 phrase 'voluntarily release the current agent's active task lease' conveys the intended use: an agent that currently holds a lease and wants to give it up. It does not explicitly name alternatives or state when not to use the tool, but the contrast with claim/heartbeat siblings is fairly clear.

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

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

Annotations already 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.