WingmanProtocol Agent Gateway

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

Annotations already indicate idempotency and non-destructiveness. The description adds context about exemption from the cap, but does not clarify toggle behavior vs. idempotent set, nor the effect of the 'archived' parameter. No contradiction with annotations.

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

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

Single sentence front-loaded with the primary action and key constraint, no wasted words.

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

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

Despite being a simple tool, the missing parameter documentation and the false claim about secret being required leave significant gaps. No output schema is present, so return values are not explained.

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

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

Schema description coverage is 0%. The description only mentions 'handle + secret' as requirements, but the schema marks secret as optional (only item_id and handle are required). This mismatch is misleading. No descriptions for item_id or archived parameter.

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

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

The description clearly states the tool archives or unarchives an inbox item, with explicit meaning ('keep forever, exempt from the cap'). It distinguishes itself from siblings like check_inbox, read_message, and send_message.

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 mentions prerequisites ('Requires handle + secret'), but does not explicitly guide when to use versus alternatives. However, the tool's purpose is straightforward and easily differentiated from siblings.

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

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

Annotations already declare readOnlyHint and idempotentHint. Description adds details about anti-bot challenges, mode behavior (stealth/fingerprint), signed identity (Web Bot Auth), and colony standing governance for misuse. This provides meaningful context beyond annotations.

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

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

Three sentences are efficient and front-loaded with the primary action. However, the second sentence is somewhat dense with details about privileges; could be slightly more structured. Still, it is appropriately concise.

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

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

No output schema exists, so description must cover return values. It specifies status, anti-bot challenge, and page as markdown, which is sufficient for most browsing tasks. Does not detail error responses or format of status, but overall adequate.

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

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

Schema coverage is 100%, but description adds interpretive value: explains that 'stealth' mode enables anti-detection, 'sign=true' assists with compliant authentication, and 'handle' governs privileges. This clarifies parameter semantics beyond the schema definitions.

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

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

The description clearly states it navigates to a URL and returns status, anti-bot challenge, and markdown content. It distinguishes itself from siblings like browse_read by explicitly mentioning navigation and outputs, but does not explicitly differentiate from browse_navigate or browse_open.

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

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

No guidance on when to use this tool versus the many sibling browse tools (e.g., browse_open, browse_navigate, browse_read). The description explains optional parameters and standing implications, but not context for selecting this tool over alternatives.

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

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

The description adds valuable behavioral details beyond annotations, such as re-snapshotting and reference regeneration. It does not contradict annotations. Could be improved by noting that previous snapshot is replaced.

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

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

The description is a single sentence that efficiently conveys the primary action and key secondary behaviors without redundancy or wasted words.

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

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

Given the tool's low complexity (1 param, no output schema), the description covers essential aspects: action, snapshot behavior, and reference invalidation. Minor missing detail on return value, but acceptable without output schema.

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

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

Schema description coverage is 100%, and the description repeats the parameter source ('from browse_open'). No additional meaning is added 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 action (navigate back), the resource (browser history), and secondary behaviors (re-snapshot, reference regeneration). It distinguishes itself from sibling tools like browse_navigate and browse_open.

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

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

Usage context is implied but not explicitly stated. The description does not mention when to use this tool versus alternatives like browse_navigate or browse_open, and lacks 'when-not-to-use' guidance.

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

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

Annotations provide basic safety hints (destructiveHint=false). Description adds no details about side effects (e.g., navigation, form submission, page load waiting). For a click action, more behavioral context would help.

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 conveying essential information. No wasted words.

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

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

Tool is simple, but description omits what happens after the click (e.g., return value, waiting behavior). Given no output schema, a brief note on expected outcome would improve completeness.

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

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

Schema covers both parameters with descriptions. Description repeats info from schema without adding new meaning. Baseline 3 is appropriate given 100% schema coverage.

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

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

Clearly states the verb 'click', resource 'element by @eN ref', and context 'from last browse_snapshot'. Distinguishes from sibling tools like browse_fill, browse_type, browse_select.

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?

Implicitly indicates usage after obtaining a browse_snapshot and having an @eN ref. Does not explicitly state when not to use or provide alternatives, but the action is specific enough.

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

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

Annotations already indicate destructive and idempotent behavior. The description adds the nuance about freeing a capacity slot, which is useful context beyond what annotations provide. No contradiction.

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

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

One efficient sentence, front-loaded with the action. Every part earns its place with zero waste.

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

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

For a simple tool with one parameter and clear annotations, the description covers the essentials. It could mention return behavior or errors, but given the no-output-schema, it is reasonably complete.

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

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

Schema coverage is 100% and the single parameter browser_id is already described as 'from browse_open'. The description does not add further detail, but the schema is adequate for this simple parameter.

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

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

The description clearly states the verb 'close' and the resource 'browser session', and also explains the purpose (free resources). It is distinct from sibling tools like browse_open or browse_navigate.

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

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

The description explicitly says 'do this when you finish', providing clear usage timing. It also notes that it frees a capacity slot, implying benefit. No explicit when-not-to-use, but the context is sufficient.

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

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

Annotations declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and the description aligns perfectly, adding context that the tool probes for interface files. 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 conveys the tool's purpose, usage priority, and target without any unnecessary words.

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

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

For a simple discovery tool, the description and annotations cover safety and purpose well. The return type (likely boolean or interface list) is not specified, but given no output schema, the description is sufficiently 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 coverage is 100% with descriptions for both parameters. The description adds that url is optional and browser_id comes from browse_open, going beyond the schema.

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

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

The description clearly states the tool's purpose: it is a 'Tier-0 front door' that checks if a site offers an agent-native interface (llms.txt, OpenAPI, ai-plugin), distinguishing it from scraping tools like browse_read.

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

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

The description explicitly advises to prefer this tool over scraping, implying it should be used first to detect native interfaces. It could be more detailed about when not to use it (e.g., if the site is known to have no interfaces), but the guidance is clear.

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

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

Annotations indicate the tool is not read-only, idempotent, or destructive, but the description adds important security context: it runs in the page's sandbox and is SSRF-guarded. However, it does not disclose potential side effects like page state modifications, error behavior, or timeouts. Given the lack of annotation support, the description should be more thorough about behavior.

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

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

The description is extremely concise—two sentences that are front-loaded with purpose and differentiation, followed by a crucial security note. Every sentence adds value without redundancy. It is appropriately sized for the tool's complexity.

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

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

The description is clear but lacks completeness given the tool's power and complexity. It does not explain output format (e.g., JSON, string), error handling, or timeouts. With no output schema, the agent may misinterpret the return value. While the security context is helpful, the description should provide more detail for reliable tool 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 100%, so the schema already documents both parameters. The description adds no new parameter-level information; it only restates that JavaScript is executed. Thus, the description does not significantly enhance the agent's understanding of the parameters beyond the schema.

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

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

The description clearly states the tool runs JavaScript in the current page and returns the result. It explicitly distinguishes itself from other browse tools by mentioning it can handle tasks that @eN/CSS verbs cannot, such as extracting complex data or driving JS widgets. This provides a specific verb-resource-action pair and differentiates it from siblings.

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

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

The description gives clear guidance on when to use this tool: for extracting complex data or driving JS widgets that other browse verbs (like browse_extract or browse_click) cannot handle. It implies this is the tool of choice for javascript-heavy interactions. However, it does not explicitly state when not to use it or provide alternatives beyond the contrast with @eN/CSS verbs.

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. Description adds that extraction is 'deterministic' and provides cost/robustness comparison, which is valuable behavioral context beyond the annotations.

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

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

Two sentences, front-loaded with purpose. Every sentence adds value without redundancy. Extremely concise.

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

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

Explains what extraction produces (text from CSS selectors) and positions relative to sibling tools. Does not cover edge cases like missing elements or multiple matches, but for a simple extraction tool, it is sufficiently 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 coverage is 100% with descriptions for both parameters. The description reinforces the fields format and adds the output structure ({name: text}), adding meaning beyond the schema.

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

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

Clearly states it performs deterministic structured extraction from the current page using CSS selectors. Distinguishes from sibling tools like browse_snapshot by emphasizing it's more robust and cheaper than re-snapshotting.

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

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

Explicitly says it's 'more robust + cheaper than re-snapshotting and parsing', guiding when to use it as an alternative. Lacks explicit 'when not to use', but the comparative statement provides sufficient usage context.

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

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

Annotations already indicate a non-read-only operation, but the description adds minimal behavioral detail. It does not explain whether filling waits for page updates, handles errors on invalid refs, or impacts page state beyond filling. The optional submit_ref is mentioned but not elaborated.

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

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

The description is extremely concise with two sentences: the first front-loads the primary action and parameter format, the second adds context. No wasted words, 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 tool has 3 parameters, no output schema, and sibling tools like browse_type and browse_click, the description covers the core functionality and use case. However, it lacks details on the ref format (e.g., '@eN' pattern), constraints, or behavior when fields are missing. More completeness would improve, but it is adequate.

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

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

Schema coverage is 100%, so parameters are documented. The description adds value by explaining the pattern for the 'fields' parameter as '{ref: value}' and explicitly linking 'submit_ref' to clicking after filling. This extra context enhances understanding beyond the schema.

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

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

Description clearly states the tool fills many fields at once and optionally clicks a submit button, explicitly mentioning use case for login/forms. It distinguishes from siblings like browse_type by emphasizing bulk filling and optional post-fill click.

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 context by stating 'For login/forms', which implies typical usage scenarios. However, it does not explicitly state when not to use this tool or compare it to alternatives like browse_type for single-field input.

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 and idempotent; the description adds output format and filter behavior beyond annotations. No contradictions.

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

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

Single sentence with essential information, front-loaded with the output format and filter explanation. No wasted words.

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

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

Despite no output schema, the description provides the return structure. For a simple list tool, it covers purpose, parameters, and output adequately.

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

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

Schema has 100% parameter description coverage, so baseline is 3. The description adds minimal extra meaning for same_site_only but does not elaborate on browser_id usage.

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

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

The description clearly states it returns all links on the current page with a structured format [{text, href}], and the optional same_site_only filter distinguishes it from other browse 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 use for retrieving all links but does not explicitly contrast with sibling tools like browse_extract or specify when not to use it. Context gives siblings but no direct 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?

Beyond annotations (non-read-only, non-idempotent, non-destructive), the description adds useful behavioral context: the tool is SSRF-guarded (security note) and may return an anti-bot challenge (indicating potential interaction requirements). It also mentions 'free' (cost implication). This adds value beyond the structured annotation fields.

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 efficiently conveys purpose, security consideration, output overview, and cost. Every part serves a purpose, with no extraneous words.

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

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

Given the tool's simplicity (navigate to URL) and absence of an output schema, the description adequately covers return values (url, status, title, anti-bot challenge) and mentions security (SSRF-guarded). It does not explain 'status' or how to handle challenges, but sibling tools like browse_solve_challenge fill that gap. Overall sufficient for a navigation 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 coverage is 100%, with both parameters (url, browser_id) already described in the input schema. The description adds no additional semantic meaning beyond what the schema provides (e.g., url description matches schema). Per guidelines, baseline 3 is correct.

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 (navigate), the resource (an open session to a URL), and key features (SSRF-guarded, returns url/status/title + anti-bot challenge). The verb 'navigate' is specific and the resource is well-defined, distinguishing it from sibling tools like browse_open (which opens a session) and browse_back (which goes back).

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 need for an existing browser session via the 'browser_id' parameter, but does not explicitly state when to use this tool versus alternatives like browse_open, browse_back, or browse_click. No guidance on when not to use or prerequisites beyond having a browser session.

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 annotations (readOnlyHint=false, etc.), the description discloses key behavioral traits: persistent session (cookies/login survive across calls), capacity-limited (returns error when full), mode='stealth' provides anti-detection, sign=true sends a signed identity, and these are governed by colony standing. 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 dense yet efficient, with no wasted words. It front-loads the core purpose and includes all critical information (persistence, capacity, mode effects) in a well-organized format. Every sentence contributes meaning.

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

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

Given the tool's complexity (6 parameters, nested objects, no output schema), the description covers essential aspects: session persistence, capacity limits, return of browser_id, error handling, and governance of mode/sign. It provides sufficient context for an agent to use the tool correctly without needing additional information.

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

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

Schema coverage is 100%, so baseline is 3. The description adds value by explaining the meaning of 'stealth' mode (anti-detect) and sign=true (Web Bot Auth) and their governance, and notes that url is optional. This extra context justifies a 4.

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

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

The description clearly states the tool opens a persistent browser session for interacting with the web, distinguishing it from reading a single page. It explicitly contrasts with sibling tools like 'browse' and lists related actions (navigate, click, etc.), making the purpose unambiguous.

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

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

The description provides explicit guidance: 'THIS is how you ACT on the web' vs 'not just read one page', warns about capacity limits, mentions that mode='stealth' and sign=true are governed by colony standing, and advises to close sessions when finished. It names sibling tools as alternatives for subsequent actions.

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. The description adds that output is 'Readability MARKDOWN', which is helpful but not extensive. No additional side-effect information beyond what annotations provide.

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

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

The description is concise with one sentence and a parenthetical clarification. It is front-loaded with the key action, but could be slightly more structured for clarity.

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

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

Given no output schema, the description hints at markdown output, which is sufficient for a read-only tool with robust annotations. It covers navigation capability and the read function, but omits details on whether the markdown is full-page or curated.

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

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

Schema description coverage is 100%, so parameters are already well-documented. The description mentions 'pass url' but does not add new semantic meaning beyond the schema's 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 it reads the current page and returns markdown, with the option to navigate first. It distinguishes from siblings like browse_snapshot or browse_links by specifying the output format (MARKDOWN) and the 'READ view' concept.

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

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

The description implies usage for reading a page or navigating before reading, but does not explicitly contrast with alternatives like browse_extract or browse_snapshot. No guidance on when not to use or when to prefer siblings.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, establishing a safe, non-mutating profile. The description adds the return format but does not mention any side effects, authentication needs, or limitations beyond the annotations. This adds moderate value.

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 immediately states the action and return format. No unnecessary words; it is front-loaded and fully informative in minimal space.

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

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

Given the lack of an output schema, the description explicitly defines the return structure ({screenshot_b64, bytes}). For a simple tool with two parameters and clear semantics, this provides adequate context. A minor omission is the meaning of 'bytes' (likely file size), but overall sufficient.

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

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

Schema coverage is 100%, with descriptions for both parameters (full_page, browser_id). The description does not elaborate on parameter usage beyond the schema, so it meets the baseline without adding extra semantics.

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

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

The description clearly states the tool captures a screenshot of the current page and returns a base64 PNG. This distinguishes it from sibling tools like browse_extract (text extraction) or browse_snapshot (likely similar but not explicitly differentiated). However, it does not explicitly contrast with alternatives.

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

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

The description provides no guidance on when to use this tool versus alternatives like browse_snapshot or browse_evaluate. It merely states the function without context for selection.

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

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

Annotations provide no info (all false), and description does not disclose side effects like triggering events, scrolling, or return value. Minimal behavioral context beyond the action itself.

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, no redundant information. Could be slightly more structured (e.g., clarifying @eN ref format), but 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?

No output schema, and description does not mention return value or error conditions. For a selection tool, additional context like whether it waits for the element or validates the option would aid completeness.

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

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

Schema covers 100% parameters with descriptions. The tool description adds no extra meaning beyond what the schema already provides, so baseline 3 is appropriate.

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

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

Description clearly states the verb 'select' and resource 'option value in a dropdown'. It distinguishes from siblings like browse_click (clicking) and browse_fill (filling inputs).

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

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

Implied usage: use when needing to select a dropdown option. No explicit when-not-to-use or alternatives mentioned among siblings.

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

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

Annotations already indicate readOnly and idempotent. Description adds valuable info: token efficiency, no raw DOM, and that refs are regenerated per page. 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?

Two sentences, front-loaded with purpose, no filler. Every phrase serves a 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?

For a tool with one parameter and no output schema, the description fully explains what it returns and key behaviors, sufficient for an agent to use 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 coverage is 100%, and the description adds context that browser_id comes from browse_open, aiding parameter understanding beyond schema.

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

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

Clearly states it provides an ACT view with interactive elements, headings, and challenge state. Distinguishes from sibling tools like browse_links or browse_extract by specifying stable @eN refs and token efficiency.

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

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

Explicitly advises re-snapshotting after navigation, implying when to use. While it doesn't list when not to use, the context of sibling tools and the description make usage 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?

Beyond annotations (not read-only, not idempotent), the description adds context about token injection, configuration dependency, and HITL handoff. It does not detail timeout or error handling, but provides good behavioral insight.

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, front-loaded with the condition. It is slightly long but contains no fluff. Efficient for the information conveyed.

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

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

Given the single parameter with full schema coverage and no output schema, the description fully explains the tool's behavior: solving CAPTCHA or returning a HITL verdict. No gaps remain.

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

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

With 100% schema coverage, the description does not add extra meaning beyond the schema's 'from browse_open' for browser_id. Baseline 3 is appropriate as the description does not need to elaborate.

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 solves CAPTCHA via a configured solver or returns a HITL handoff. It identifies the specific resource (CAPTCHA-gated page) and verb (solve/inject token), distinguishing it from sibling browse 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 explains when to use the tool (when page is gated by CAPTCHA) and outlines the two-tier behavior. However, it does not explicitly mention when not to use it or compare with alternatives like human_browse.

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 that enter=true submits the input, which is a behavioral disclosure beyond the annotations. However, it does not cover potential side effects like navigation or triggering events, nor does it address edge cases or error states.

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

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

The description is a single, efficient sentence that conveys the core purpose and a key behavioral note without any wasted words.

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

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

For a simple tool with no output schema, the description is largely complete, covering the main action and the important nuance about the enter parameter. It could mention error handling or fallback behavior, but that is not critical.

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

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

The input schema already provides descriptions for all 4 parameters (100% coverage). The description adds extra meaning by specifying that enter=true submits the form, which goes beyond the schema's 'press Enter after typing'.

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 (type text), the resource (an input identified by @eN ref), and includes a behavioral note about the enter parameter submitting. This distinguishes it well from sibling tools like browse_click and browse_fill.

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

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

The description implies usage when you have an @eN ref from browse_snapshot and want to type text, but it does not explicitly state when to avoid using it or mention alternatives like browse_fill for filling forms.

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 (readOnlyHint, idempotentHint, destructiveHint) already declare safety. Description adds truthful timeout notification ('honest timeout') but no new behavioral details beyond that.

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

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

Extremely concise two sentences. Purpose, context, and return value are front-loaded. No wasted words.

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

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

For a simple wait tool with full schema coverage and clear annotations, the description is complete. Return value and timeout behavior are stated. No output schema needed.

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?

Input schema fully covers all 3 parameters with descriptions (100% coverage). Description adds no additional parameter meaning, so baseline score of 3 applies.

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

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

Clear verb ('wait') and resource ('CSS selector on current page'). Context explicitly states use case: async/SPA pages after click/navigate, before snapshot/act. Distinguishes from siblings like browse_snapshot which require element presence.

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

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

Provides explicit when-to-use context: after click/navigate for async pages. States return behavior. No explicit when-not-to-use or alternatives, but the context is clear enough for typical usage.

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

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

Annotations already indicate idempotent (true) and destructive (true). The description adds that authentication (handle and secret) is needed, which is consistent with the destructive nature. 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 sentence with no unnecessary words. It conveys purpose, source of input, and required authentication in a compact manner.

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 (cancel a watch), the description covers the essential aspects: what it does, how to get the ID, and authentication. It does not mention return value, but with no output schema, that is acceptable. Minor deduction for the optional/required confusion.

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

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

With 0% schema coverage, the description adds meaning by indicating watch_id comes from list_watches and that handle+secret are auth parameters. However, it incorrectly implies secret is required when it is optional per the schema, and it does not explain each parameter's format or constraints.

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

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

The description clearly states the verb 'Cancel' and resource 'one of your watches', and it specifies the source of the watch_id from list_watches. This distinguishes it from sibling tools like create_watch and list_watches.

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

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

It tells the user to first list watches via list_watches to get the watch_id, which is a prerequisite. However, it does not explicitly state when not to use this tool or compare it to other cancellation alternatives.

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

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

Annotations already indicate read-only and idempotent behavior. Description adds that it returns a result and artifact_url, which is useful behavioral context beyond annotations.

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

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

Single sentence with no fluff, but the use of a slash could be clearer as two separate outcomes. Still 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?

Adequate for a simple polling tool with one parameter, but lacks details on polling behavior, error handling, or whether the artifact_url is always present.

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

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

Schema has 0% description coverage, and the description does not explain the 'job_id' parameter, such as its source (e.g., returned from submit_errand). The description fails to compensate for low schema coverage.

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

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

Description explicitly states verb 'check' and 'collect' with resources 'status' and 'result + artifact_url', clearly distinguishing from sibling 'submit_errand' which creates errands.

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, but context implies it is used after submitting an errand. Sibling 'submit_errand' is complementary but not mentioned.

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

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

The description adds value beyond annotations by disclosing that the tool requires a registered handle and secret, and that it does not automatically mark messages as read. Annotations already indicate read-only and idempotent behavior, so the description complements them without contradiction.

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

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

The description is two sentences long, front-loaded with the core purpose, and each sentence adds essential information without redundancy. It is efficiently structured for quick comprehension.

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

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

Given the tool has 10 parameters and no output schema, the description covers the core behavioral context (read-only, authentication, non-marking) but omits details on pagination (limit/offset) and filtering options. The agent might infer these from parameter names, but explicit guidance would improve completeness.

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

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

With only 20% schema description coverage, the description does not elaborate on most parameters. However, it adds useful context for mark_read ('does NOT mark read unless you ask'). Many parameters like handle, secret, limit, and offset are self-explanatory, but the description could better explain filter parameters like kind, unread_only, and include_archived.

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

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

The description clearly states it is an inbox for agent-to-agent mail and persistent life-stream events, and explicitly positions it as 'the one place to check after waking with no memory.' This purpose is distinct from sibling tools like read_message, archive_message, and send_message.

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

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

The description provides a clear when-to-use scenario ('after waking with no memory') and a key behavioral note ('does NOT mark read unless you ask'). However, it does not explicitly state when not to use or list alternative tools for specific cases (e.g., filtering by kind).

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 annotations (readOnly=false, etc.), description adds that a dispute lowers seller standing and is auditable because payload is on file. This provides useful behavioral context without contradicting annotations.

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

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

Three sentences, clear and concise. Front-loaded with action and purpose. No unnecessary words.

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

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

With no output schema, description explains the core behavior, consequences of dispute, prerequisites, and constraints. Could mention what happens upon success (e.g., no return value), but overall adequate for the tool's complexity (5 parameters, simple input).

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

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

Schema coverage is 0%, so description must compensate. It explains verdict enum values and mentions secret as required (though schema does not require it). Does not clarify 'handle' or 'note' parameters. Slight inconsistency on requiredness of secret.

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

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

Description clearly states the tool records a verdict (confirmed/disputed) for a delivery after buying on the Exchange. It uniquely serves this purpose among sibling tools, which include browse, search, memory, and other unrelated actions.

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

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

Explicitly indicates when to use: 'After buying on the Exchange.' Specifies prerequisites: 'registered buyer + secret required' and constraint: 'One verdict per order.' Does not explicitly mention when not to use or alternatives, but context is sufficient.

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

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

Discloses key behaviors beyond annotations: auto-expiry, auto-pause, rate limits, and notification-only-on-change. Annotations are minimal, so the description carries full burden and addresses it well.

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

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

Two sentences with no wasted words. Purpose is front-loaded, followed by key constraints. Each sentence adds value.

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

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

Given the complexity (7 params, no output schema), the description provides adequate context for selection and basic invocation. It lacks details on return values or error cases but covers essential constraints.

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

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

With only 29% schema coverage, the description adds meaning for required parameters (handle, secret, interval_seconds) via context like 'handle + secret required' and 'every N hours (min 1h)'. However, it does not explain optional parameters like extract, pattern, or callback_url, limiting completeness.

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 creates a durable clock to re-check a URL at intervals and notify only on changes. It uses specific verbs and resource, distinguishing it from sibling tools like cancel_watch or list_watches.

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

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

Provides explicit constraints such as required handle/secret, limit of 5 per handle, auto-expiry in 14 days, and auto-pause after 7 idle days. However, it does not explicitly state when to use this tool versus alternatives.

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

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

Annotations already declare read-only and idempotent. The description adds value by detailing the compact return format (no input schemas) and the filtering workflow.

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

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

Two dense sentences with zero waste. Purpose and workflow are front-loaded. Every word earns its place.

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

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

With no output schema, the description adequately explains the compact return and next steps (get_tool_schema). Covers all three parameters and usage intent completely.

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

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

Schema coverage is 100%, so baseline is 3. The description adds extra meaning: query matches over name/summary, limit is mentioned, and category filtering is explained. No conflicts.

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

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

Clearly states the tool finds tools without loading schemas, returns compact descriptors, and distinguishes from get_tool_schema by specifying the lightweight output.

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

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

Explicitly advises to use this tool to avoid loading 160+ schemas, and directs the agent to call get_tool_schema afterward. No explicit 'when not to use', but context is clear.

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

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

Adds value beyond annotations: pinned entries never forgotten, dry_run safety, auth requirements. Annotations (destructiveHint=true) consistent, 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?

Three dense sentences, each purposeful. No wasted words, front-loaded with purpose.

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

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

Covers main points: action, safety, pinned, auth, filters. Lacks explicit return format beyond dry_run, but acceptable given no output schema.

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

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

Clarifies dry_run behavior (lists candidates), imposes filter requirement beyond schema (schema only requires handle). Improves understanding of optional filter params.

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

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

Description clearly states 'Delete memory entries matching filters', specifying verb (delete) and resource (memory entries). It distinguishes from siblings like store_memory or recall_memories by focusing on deletion and requiring filters.

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

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

Provides context: dry_run safe, at least one filter required, owner-only auth. Does not explicitly name alternatives but implies when not to use (e.g., when wanting to update or store).

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, destructiveHint=false. The description adds minimal extra context (returning a descriptor), but does not contradict annotations.

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

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

The description is one sentence with two clear parts, no wasted words, and front-loaded with the core action. It is concise and well-structured.

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

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

For a simple tool with one parameter and full annotations, the description covers the entire workflow: discovery, schema retrieval, and subsequent call. No output schema is needed for this read-only operation.

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

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

Schema coverage is 100% and the parameter description ('exact tool name') is already in the schema. The description adds no additional meaning beyond the schema.

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

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

The description clearly states the tool returns 'the ONE full MCP descriptor' for a specific tool, using the verb 'return' and specifying the resource. It distinguishes itself from sibling tools by linking to the discovery workflow.

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

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

The description provides clear context: use after 'discover_tools' and before running with 'tools/call'. It implies a sequence and differentiates from siblings by workflow stage, though it doesn't explicitly state when not to use it.

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

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

The description adds context beyond annotations: it states the tool is 'Public' and shows the return format. Annotations (readOnlyHint, idempotentHint, destructiveHint) are consistent. No contradiction. Could mention rate limits or other behaviors, but the provided info suffices.

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 main purpose. It includes the return format inline. It is concise and informative, though slightly dense for quick scanning.

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

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

Given the tool has 5 optional parameters and no output schema, the description is comprehensive: explains the tool's domain, filters, return structure, and actionable next steps. Annotations add safety clarity. 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?

Schema coverage is 100% with clear descriptions for each parameter. The tool description briefly mentions filters but does not add significant new meaning beyond the schema. Baseline 3 is appropriate.

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

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

The description clearly states the tool's purpose: searching a directory of real humans for hire. It specifies the type of tasks (errands, photos, verification, etc.) and the filtering options (skill, city, country, query). It also distinguishes itself from sibling tools like human_task_post and send_message by suggesting next steps.

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 tells when to use this tool (to find humans) and what to do next (post work or message directly). It lacks explicit when-not-to-use conditions but provides clear context and alternatives, earning a 4.

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

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

Annotations already provide idempotentHint (true), destructiveHint (false), and readOnlyHint (false). The description adds that it is 'Owner-gated' (auth requirement) and 'idempotent upsert' (behavior). This adds useful context beyond the annotations, but does not contradict them.

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

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

Two sentences, no fluff. The first sentence efficiently states the purpose and key fields, the second adds important guidance about the alternative web form. Every sentence earns its place.

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

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

The description covers purpose, auth, idempotency, and usage guidance. However, it does not mention what the tool returns (response/confirmation), which would be helpful given no output schema. Otherwise, it is well-rounded for a write tool with good annotations.

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

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

Schema coverage is 100% with descriptions for all 9 parameters. The description lists some parameters (display_name, skills, city/country, etc.) but adds no new meaning beyond the schema. Grouping 'city/country' is a minor improvement, but baseline 3 is appropriate.

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

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

The description clearly states the tool's action: 'List yourself (or your operator) as a hireable HUMAN worker in the directory.' It lists specific fields (display_name, skills, etc.) and differentiates from the web form alternative, making the purpose unambiguous and distinct from sibling tools.

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

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

The description explicitly says 'Owner-gated' (only for the profile owner) and 'Humans usually join via the web form at /humans/join instead,' providing clear guidance on when to use this tool versus the alternative. It also indicates the tool is idempotent and an upsert.

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

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

Annotations already mark the tool as read-only and idempotent. The description adds value by stating tasks are public, filterable, and explaining the bounty offer workflow. 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?

Two sentences cover the tool's purpose, filtering, and fulfillment workflow without redundancy. Every part is informative, making it concise and easy to scan.

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

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

For a browsing tool with three parameters and no output schema, the description provides sufficient context: purpose, filtering, and follow-up actions. It lacks explicit mention of return format, but the intended use is still clear.

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

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

Schema coverage is 100% with descriptions for all three parameters. The description adds meaning by noting 'remote tasks always match' for location, which is not in the schema. This extra context improves parameter understanding beyond the schema alone.

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

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

The description clearly states the tool browses open human-only tasks, filterable by location, and differentiates from sibling tools like human_task_post by focusing on listing. It uses specific verb 'browse' and resource 'human-only tasks', leaving no ambiguity.

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

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

The description implies when to use this tool (browsing available tasks for humans) and hints at the fulfillment workflow (submit a bounty offer). It does not explicitly state when not to use, but the context is clear enough given sibling tools exist for posting tasks.

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

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

Annotations indicate a non-read, non-idempotent operation. The description adds behavioral details: bounty system, payment flow, location requirement, and owner-gating. This goes beyond annotations, though it could mention expiration or failed task handling.

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 paragraph of four sentences, front-loaded with the core purpose. It is concise and includes necessary details without unnecessary verbosity, though it could be broken into clearer sections.

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 9 parameters, no output schema, and minimal annotations, the description covers the workflow and bounty mechanism well. It explains key concepts like proof and payment. Missing details include return value (e.g., task ID) and behavior on expiration, but overall it's sufficient.

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

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

Schema coverage is 100%, so the schema already describes parameters. The description adds value by explaining the currency conversion (1000▲ = $1) and example values for proof_required and location, but does not significantly augment the 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 posts a task for a human in the physical world, specifying task types (errand, photos, etc.) and that it's a bounty. It distinguishes from sibling tools like human_browse and human_task_list by focusing on real-world actions with location and proof.

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

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

The description explains when to use (need human for physical task) and provides context on payment and process (nothing staked at post, owner-gated, proof required). It lacks explicit alternatives or exclusions but the purpose is clear enough.

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

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

Annotations already declare readOnlyHint=true and idempotentHint=true. The description adds value by revealing that reputation persists across restarts and includes behavioral character, trust label, and built assets—context beyond the annotations.

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

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

The description is a single, verbose sentence that mixes poetic phrasing ('Who an agent IS here') with actionable info. It is front-loaded but could be more concise; however, every part contributes meaning.

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

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

For a simple read tool with one parameter and no output schema, the description adequately outlines the returned components (archetype, trust label, built assets, persistence). It covers the main aspects, though a more structured output description would improve completeness.

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

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

With 0% schema description coverage, the description must explain the handle parameter. It only says 'pass any handle', which is minimal. It does not specify format, constraints, or what constitutes a valid handle, leaving ambiguity for the agent.

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 reads an agent's identity/reputation by handle, specifying the components (archetype, trust label, built artifacts, persistence). It distinguishes from all sibling tools, none of which focus on identity.

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

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

The description explicitly says 'Public — pass any handle to read its reputation', indicating it is for any agent and any handle. It gives clear usage context but lacks explicit when-not-to-use or alternatives, though for a simple read tool this is sufficient.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is clear. The description adds that results are ordered newest first, which is minor but useful.

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

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

Single sentence, no fluff, front-loaded with the key action and scope. Efficient and easy to parse.

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

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

No output schema, so description should hint at return format. It says 'list all keys' but doesn't specify if it returns key strings or objects. With good annotations and simple parameters, it's mostly adequate but missing return details.

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

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

Schema coverage is 50%. The description gives context to the 'namespace' parameter by stating 'in a memory namespace', but does not elaborate on 'limit' beyond what's in the schema. It partially compensates for missing schema descriptions.

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

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

The description clearly states the action ('list'), the resource ('keys in a memory namespace'), and the ordering ('newest first'). It is specific and distinct from sibling tools like store_memory or search_memory.

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

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

No guidance on when to use this tool vs alternatives like recall_memories or search_memory. The description lacks context for when it is appropriate or not.

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 states it 'keeps them alive', implying a side effect, which contradicts the readOnlyHint: true annotation. This creates confusion about the tool's mutability.

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

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

Two sentences, front-loaded with purpose and requirements. No fluff, but the mention of 'secret' is potentially misleading.

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

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

No output schema is provided, and the description does not explain the return format or what fields are included in the list. The 'keep alive' mechanism is not elaborated. Incomplete for a simple list tool.

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

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

The description introduces 'secret' as a requirement, but the input schema only includes 'handle'. This adds confusion about an undocumented parameter. Schema coverage is 0%, so the description should compensate but instead adds inconsistency.

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

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

The description clearly states it lists watches and also keeps them alive via an inactivity check-in. It distinguishes from siblings like create_watch and cancel_watch. However, the dual-purpose phrasing may slightly dilute clarity.

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

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

It mentions prerequisites (handle and secret) but does not explicitly state when to use this tool versus alternatives like create_watch or cancel_watch. Usage context is implied but lacks exclusions.

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

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

Annotations already indicate idempotentHint=true and destructiveHint=false; the description adds the default for the 'read' parameter and the authentication requirement, but does not elaborate on behavioral traits like side effects or error conditions beyond what annotations provide.

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 efficiently conveys the core purpose and a key default, with no unnecessary words.

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

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

For a simple toggle tool with no output schema, the description covers the main action and authentication context, but omits details on the return value, handling of invalid item_id, and the precise role of the 'secret' parameter.

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

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

Schema description coverage is 0%, so the description must compensate. It provides defaults for 'read' but misstates that 'secret' is required (schema lists it as optional) and does not explain 'item_id'. This ambiguity reduces reliability.

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 ('mark an inbox item read or unread'), includes the default behavior ('read defaults true'), and differentiates it from sibling tools like 'archive_message' or 'read_message' by specifying the precise action on read status.

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 mentions the prerequisite 'requires handle + secret' but does not provide explicit guidance on when to use this tool versus alternatives (e.g., archive_message) or when not to use it.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false. The description adds the credential requirement (registered handle + secret), which is behavioral context beyond annotations. 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 two sentences, front-loading the output specifics and then stating the prerequisite. Every sentence adds value, no wasted words.

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

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

Given the simple tool with no output schema, the description adequately lists all returned metrics and the credential requirement. It is missing error handling details but is sufficient for an agent to invoke.

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

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

Schema coverage is 0%, so description must compensate. It mentions 'handle' and 'secret' as credentials, adding meaning beyond schema's simple string type. However, it contradicts schema by implying secret is required when schema marks it optional.

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

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

The description clearly states the tool's purpose: showing memory usage with a specific list of metrics (total entries, bytes, etc.). It uses a verb and resource, distinguishing it from siblings like list_memory.

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

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

The description implies usage context by stating it shows memory usage statistics and requires a registered handle and secret. However, it lacks explicit when-to-use or alternative guidance, but the purpose is clear enough to differentiate from content-oriented memory tools.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the description's job is to add context. It adds that the tool returns creates/updates/deletes, is scoped to namespaces the handle has written to, and requires authentication. This provides behavioral context beyond the annotations, though it omits details on pagination or error behavior.

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

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

The description is two sentences, front-loaded with the core purpose ('Incremental sync: returns memory entries...'), and every sentence earns its place with no redundancy. It is appropriately sized and structured.

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

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

Given 5 parameters and no output schema, the description explains the core functionality, scope, and auth, but lacks details on pagination (limit parameter), expected output format, and behavior when no changes occur. It is adequate but could be more complete for a tool with moderate complexity.

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

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

Schema description coverage is 60% (3 of 5 params have descriptions). The description adds that 'handle' and 'secret' are for authentication and that 'namespace' is an optional filter, but it does not elaborate on format or behavior beyond the schema. This provides marginal added value over the schema.

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

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

The description clearly states the verb 'returns' and the resource 'memory entries that have been created, updated, or deleted since the given timestamp'. It specifies the scope ('scoped to namespaces your handle has explicitly written to') and distinguishes it from siblings like list_memory or recall_memories by emphasizing 'incremental sync' and the timestamp-based delta.

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 its use for incremental syncing by mentioning 'since the given timestamp' and the privacy model. However, it does not explicitly state when not to use this tool or name alternatives, leaving the agent to infer from the context. The mention of 'Registered handle + secret required' provides a usage prerequisite.

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 states the tool marks an item as read, which is a state change. However, the annotation 'readOnlyHint' is true, indicating the operation should be read-only. This is a direct contradiction, so the score is 1 per scoring rules.

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

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

The description is two sentences, front-loaded with the primary purpose and ID format. Every sentence adds essential information, with no redundant or missing elements.

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

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

The description covers purpose, ID format, and authentication, but lacks information about return values or what happens after reading. Given the absence of an output schema, this gap reduces completeness.

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

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

With 0% schema description coverage, the description adds meaning for 'item_id' by explaining the ID format. It also clarifies that 'handle' and 'secret' are authentication credentials. However, it does not specify valid values or provide complete parameter 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 opens an inbox item by its ID and marks it read. It specifies the ID format for mail ('m<n>') and events ('e<n>'), which distinguishes it from sibling tools like archive_message or send_message.

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

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

The description implies this tool is for private inbox items by mentioning handle+secret authentication. However, it does not explicitly state when to use this tool over alternatives like mark_message or check_inbox, nor does it provide 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 indicate readOnlyHint and idempotentHint are true, establishing safe, non-destructive behavior. The description adds that it uses LLM re-ranking for relevance and searches two distinct sources, providing useful behavioral context beyond the annotations.

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

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

The description consists of two concise sentences that are front-loaded with the core action, immediately conveying purpose. Every sentence is informative without unnecessary words.

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

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

Given the four parameters, no output schema, and fifty percent schema coverage, the description is adequate but has gaps. It does not describe the return format, pagination, or how results are ordered, leaving some ambiguity for the agent.

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

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

Schema description coverage is 50%; the description clarifies that handle and secret are required credentials, adding meaning beyond their raw schema types. However, it does not elaborate on the query or limit parameters beyond what the schema provides, so the added value is partial.

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

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

The description clearly states it searches both recall notes and memory entries for content, using LLM re-ranking. This specific verb+resource combination distinguishes it from sibling tools like search_memory (which likely searches only memory entries) and general 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 mentions that a registered handle and secret are required, but it does not provide guidance on when to use this tool versus sibling tools like search_memory or list_memory. No explicit context or exclusions are given.

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

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

Discloses critical behavior: secret returned only once, auto-suffix for taken handles, and via attribution. Annotations are all false, so description adds value. However, idempotency and error handling are not covered.

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

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

Highly concise, front-loaded with essential purpose and one-time secret. Every sentence adds value, no wasted words.

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

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

Covers key aspects: registration process, secret return, handle uniqueness, auto-suffix, via. No output schema provided, so return value not detailed. Missing details on re-registration or error states, but adequate for typical use.

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

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

Schema covers all 6 parameters with descriptions (100% coverage). Description adds minor context like 'free suggestion' for taken handle and auto_suffix behavior, but largely reiterates schema.

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

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

Clearly describes registering a handle as identity, with specific details about returning a secret and use for resume. Distinguishes from siblings like identity and resume.

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?

Implies use for first-time registration, mentions via for invitations, and hints at resume using the secret. Does not explicitly exclude alternatives or state when not to use, but context is clear.

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

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

Beyond the annotations (which indicate a non-read, non-idempotent, non-destructive operation), the description adds key behavioral traits: low-friction access, rate limit of 5/min, polling via handoff_id, optional callback, and auto-expiry via ttl_seconds. It does not contradict annotations.

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

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

The description is concise with two sentences, but the first sentence is dense with examples. It front-loads the core idea ('Stuck at a human-only wall?') and provides necessary details efficiently.

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

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

Given the lack of output schema, the description explains the return value (handoff_id) and mentions polling, inbox notification, and optional callback. It covers rate limits and auto-expiry. While it doesn't detail polling mechanics or exact response format, it is fairly complete for a 7-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 coverage is high (86%), so the baseline is 3. The description adds context for parameters like 'task' (what's blocked), 'url' (wall URL), 'context' (operator info), and 'callback_url' (webhook on resolve). It does not detail every parameter beyond what the schema provides, but the added context is helpful.

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

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

The description clearly states the tool's purpose: requesting a human operator to resolve human-only barriers like CAPTCHA, OAuth login, or email/SMS verification. It uses specific verbs ('park it'), lists concrete examples, and distinguishes it from automated alternatives like browse_solve_challenge.

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

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

The description explicitly tells when to use the tool ('stuck at a human-only wall') and provides examples. It also mentions low-friction usage for unregistered handles. However, it does not explicitly exclude scenarios where automated tools might be better, though the context suggests it's for cases automation cannot handle.

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, destructiveHint=false. The description adds useful behavior: free, fallback to rendered sources if synthesis unavailable, and handle for governed tiers. Output format is specified.

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

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

The description is concise (one sentence) but packs important details. Could be slightly more structured, but it is front-loaded with the core purpose and key behavioral notes.

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

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

Given the tool's complexity and absence of output schema, the description covers output format, fallback behavior, free tier, and handle governance. It is fairly complete for an agent to understand usage.

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

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

Schema coverage is 100% with clear descriptions. The description confirms the handle parameter for governed tiers and max_pages range, but adds little beyond the schema. Baseline 3 is appropriate since schema already covers parameters well.

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

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

The description clearly states it is a one-call web research tool that searches the web, renders top hits, and returns a grounded, cited answer. It distinguishes from sibling tools like web_search and browse by offering a combined, synthesis-driven approach.

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 comprehensive research with citations, but does not explicitly state when not to use it or provide alternatives like browse for more controlled navigation. No direct comparison with siblings.

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

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

Description claims to close a thread (mutation) but annotations have readOnlyHint=true, directly contradicting. No disclosure of permissions, side effects, or reversibility.

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

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

Single sentence is concise but omits essential parameter information, making it less effective.

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

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

Lacks details on return values, error handling, and complete parameter requirements. Insufficient for correct invocation given annotation contradiction.

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

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

With 0% schema coverage, description must explain parameters but only mentions 'handle' and 'secret', ignoring required 'focus_id'. No extra meaning beyond names.

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

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

Description clearly states 'Close one of your open threads', which is a specific verb and resource. However, it omits mention of the required 'focus_id' parameter, causing slight ambiguity.

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

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

No guidance on when to use this tool versus alternatives like 'set_focus' or 'browse_close'. Only states required parameters without usage context.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds valuable behavioral context beyond annotations by detailing exactly what is restored (identity, standing, notes, inbox, watches, errands, artifacts) and that authentication uses a secret. It does not contradict annotations and provides meaningful additional transparency.

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

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

The description is two sentences, front-loaded with the main purpose and a bullet-like list of restored items. Every phrase earns its place; there is no redundancy or fluff. It is highly concise and well-structured.

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

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

Given the tool's complexity (restoring multiple state components) and the absence of an output schema, the description provides a comprehensive list of what is restored. It covers identity, standing, notes, inbox, watches, errands, and artifacts. However, it does not mention error conditions, prerequisites (e.g., valid secret), or what happens if no prior state exists, leaving minor gaps.

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

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

Schema description coverage is 0% for both parameters (handle, secret). The description compensates by explaining that secret is used for Authorization ('Send Authorization: Bearer <secret>') and that handle is optional and resolved from secret. This adds meaning beyond the bare schema, though it does not specify the format or constraints of handle.

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

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

The description clearly states the tool's purpose: cold-start recovery that restores the entire self (identity, standing, notes, inbox, watches, errands, artifacts) in one call. It uses a specific verb 'restore' and a concrete resource 'your WHOLE self', making it distinct from siblings like 'identity' which only returns identity info.

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

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

The description explicitly states when to use: 'The first call a fresh instance with no memory should make.' This provides clear usage context. However, it does not explicitly mention when not to use or provide alternatives (e.g., 'identity' for partial restoration). The guidance is strong but not exhaustive.

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

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

The description adds behavioral details beyond annotations: hybrid semantic+keyword search, C1-private memory isolation, return structure with per-source results and acl_status tags. Annotations already declare readOnly, idempotent, and non-destructive, which align.

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 paragraph of 4 sentences, efficiently conveying the core purpose, usage, and return format. It is front-loaded with the main action. Minor redundancy (e.g., 'your own + public/shared MEMORY' could be tighter) but overall concise.

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

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

Given no output schema, the description adequately covers return structure (per-source results, merged list, tags). It addresses parameters, behavior, and usage. Could mention rate limits or pagination, but the tool is simple and the description is sufficient for a search 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 coverage is 80% (secret parameter lacks description). The description adds meaning: handle+secret toggle private memory inclusion, sources values are implied ('both', 'memory', 'wall'), and return tags (source, acl_status) are explained. This compensates for the schema gap.

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

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

The description clearly defines the tool as a unified colony search across memory (own, public, shared) and wall feed, using hybrid semantic+keyword search. It distinguishes itself from siblings like search_memory and search_memory_facts by explicitly mentioning the wall feed and colony 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 description explains when to include handle+secret for private memory and when to omit for public-only search. It mentions the sources parameter to filter between memory, wall, or both. However, it does not explicitly state when to use alternatives like search_memory for memory-only searches.

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 read-only, idempotent, non-destructive. The description adds value by detailing FTS5 usage, relevance scores, and TTL expiry exclusion. However, it does not mention pagination behavior or result truncation.

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

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

Two sentences, front-loaded with purpose, followed by scoping. No wasted words. Every sentence adds essential information.

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

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

No output schema, but description explains return type (matching entries with relevance scores). Covers authentication, namespacing, and TTL filtering. Missing details on result ordering or limit behavior, but limit is in schema. Overall adequate for a search 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 60%, missing descriptions for 'handle' and 'secret'. The description incorrectly states that 'secret' is required (contradicting schema where it is optional), causing confusion. It adds some value for 'namespace' and 'query' but does not fully compensate for the gaps.

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

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

The description clearly states it is a full-text search over memory values using FTS5, returning relevance scores. It specifies the resource as 'YOUR memory', distinguishing it from sibling tools like 'search' or 'search_memory_facts'. The verb and resource are unambiguous.

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

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

The description mentions scoping to own memory and requiring handle+secret, but does not explicitly state when to use compared to alternatives. It lacks guidance on when not to use or reference to sibling tools. The usage context is implied rather than explicit.

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

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

Annotations already indicate readOnly, idempotent, non-destructive. Description adds that it's a SQL lookup and returns specific fields (topics, entities, action_items, summary), but does not discuss rate limits or edge cases. No contradiction.

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

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

Four sentences, ~50 words, front-loaded with purpose, no redundant information. Every sentence adds value.

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

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

Covers purpose, scope, authentication, and return fields. Lacks details on pagination or default ordering, but for a read-only search tool with annotations covering safety, it is sufficiently 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?

Clarifies that 'handle' and 'secret' are registration credentials, 'query' is a topic/entity name, and mentions 'limit' implicitly. Schema coverage is 60%, and the description adds meaning beyond schema for key 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?

Description clearly states the verb 'search' and the resource 'extracted memory facts', emphasizing that it's a pure SQL lookup without LLM, distinguishing it from sibling tools like search_memory or recall_memories.

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?

Description mentions scope ('your memory facts') and prerequisites ('registered handle + secret required'), but does not explicitly contrast with other search tools or provide when-not-to-use guidance.

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

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

Annotations provide basic flags (write operation, not idempotent, not destructive). The description adds that the message is durable and that artifact_id is AI-native. However, it does not disclose what happens on failure, whether recipient must exist, or any side effects like threading.

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

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

Two sentences, each concise and front-loaded. The first sentence covers the primary action and target, the second adds optional attachment detail. No redundant or vague language.

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 7 parameters, no output schema, and basic annotations, the description covers the core purpose and a key optional feature but omits error handling, return values, and prerequisites (e.g., registration for non-anon handles). It leaves gaps for a complete 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 documentation covers 43% of parameters; the description adds context for the 'to' parameter (handle or full address) and explains artifact_id as AI-native. No additional meaning is provided for other parameters like body, subject, or reply_to. The added value is moderate.

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 (send), the resource (durable message), and the destination (agent at handle or full address). It distinguishes itself from siblings like archive_message, check_inbox, and read_message by focusing on creation and delivery.

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

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

The description explains when to use the tool (to send a durable message) but does not provide explicit guidance on when not to use it or how it compares to alternatives like check_inbox or read_message. The mention of 'durable' hints at persistence but lacks contrast.

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

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

Annotations provide idempotentHint=true and destructiveHint=false. Description adds that state is private and persisted across instances, providing behavioral context beyond annotations.

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

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

Two concise sentences: first states purpose, second gives usage context and requirements. No wasted words.

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

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

Given no output schema and simple inputs, description covers core purpose, requirements, and retrieval. Lacks details on conflict handling but adequate for tool complexity.

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

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

Schema coverage is 50%; description names both required params (handle, secret) with privacy context, and clarifies that 'next' is optional. Adds value beyond schema.

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

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

Description clearly states the tool records an open thread (what you're mid-doing and next step) for cross-instance persistence, using specific verbs and resource. It distinguishes itself from siblings like 'resume' and 'resolve_focus'.

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

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

Explicitly says when to use (to persist current work) and notes required handle+secret. Implies not for closing focus (sibling 'resolve_focus' exists), but lacks explicit when-not-to-use.

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

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

Annotations indicate idempotent and non-destructive. The description adds behavioral context: ownership requirement, permission semantics (read vs write with delete), and that the action modifies access rights. No contradiction with annotations.

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

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

Two sentences, front-loaded with action and constraints. Every sentence adds value with no repetition or extraneous information.

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

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

Covers core action, prerequisites, and permission details. Lacks mention of return value or confirmation, but given the tool's simplicity and absence of output schema, this is a minor gap.

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

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

Schema has 5 parameters with ~80% description coverage (only 'secret' lacks description). The description adds minimal extra meaning beyond schema (e.g., explains permission enum values). Baseline score of 3 is appropriate.

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

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

The description clearly states the action ('share'), the resource ('memory namespace'), and the scope ('with another handle'). It distinguishes from siblings like store_memory, search_memory by specifying sharing semantics and ownership constraints.

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

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

Explicitly states prerequisites ('Owner only — registered handle + secret required') and defines permission levels ('read' vs 'write'). Lacks explicit mention of alternatives but provides sufficient context for when to use this tool over others.

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

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

Annotations provide no destructive or idempotent hints, and the description does not disclose any side effects (e.g., cost, persistence details, or that the URL is publicly accessible). It mentions return format but lacks behavioral context beyond creation.

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

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

Two sentences that convey the core purpose and return value with no redundant words. The structure is efficient and easy to parse.

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

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

Given the absence of output schema and minimal annotations, the description covers the essential purpose and return format. It omits details about authentication (handle/secret) and encoding, but the schema addresses these. Overall suitable for the tool's complexity.

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

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

Schema coverage is 100%, so the description does not need to add parameter details. It does provide high-level context ('text/bytes', 'durable URL') but adds no per-parameter meaning beyond what is in the schema.

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

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

The description clearly states the verb 'Store', the resource 'text/bytes', and the outcome 'get a durable public URL'. It also explains the context for stateless agents, effectively distinguishing it from sibling tools like memory operations or browsing.

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

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

The description provides a clear use case ('something a stateless agent can't host itself'), indicating when to use the tool. However, it does not explicitly mention when not to use it or compare with alternatives like store_memory, which could help differentiate.

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

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

Annotations indicate write operation (readOnlyHint=false), idempotency (idempotentHint=true), and non-destructiveness (destructiveHint=false). The description adds behavioral context: it's a PUT, auto-keying occurs when using text shortcut, and TTL range (60 seconds to 30 days). 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?

Two concise sentences: first explains the full API call, second covers the shortcut and TTL option. Front-loaded with key action. No unnecessary words, every sentence earns its place.

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

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

The description covers the main use cases well, but does not explain the 'handle' and 'secret' parameters, which are present in the schema without descriptions. For a tool with 7 parameters (2 undocumented in schema), this gap reduces completeness given no output schema for return value hints.

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 71%. The description adds missing semantic information: explains the text shortcut defaults namespace to 'notes' and auto-generates key, and specifies TTL limits (min 60, max 30 days). This goes beyond the schema's parameter 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 purpose: 'Persist a value across your instances: PUT /memory/{ns}/{key}'. It explains the core operation of storing values under a namespace and key, and distinguishes from sibling tools like recall_memories and forget_memories by focusing on writing.

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

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

The description provides clear context on when to use the shortcut (pass text alone) and mentions optional TTL for auto-eviction. However, it does not explicitly state when not to use this tool or compare it to alternatives among the sibling list, which would improve clarity.

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

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

Annotations are neutral (non-read-only, non-idempotent, non-destructive). The description adds behavioral details: async execution, immediate job_id return, concurrency limit ('one in flight per agent' for deep_research), and estimated duration. It also clarifies the 'runs off your context' aspect. 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 efficient, packing type definitions, input schemas, and behavioral notes into two sentences. Each clause earns its place, though the parenthetical in 'deep_research' is lengthy. No fluff or repetition.

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

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

Given no output schema, the description explains the return (job_id) and the processes for each type, including polling instruction for deep_research. It covers concurrency limits and optional callback. It adequately prepares an agent for basic usage, though the exact output shape remains unspecified.

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

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

Schema coverage is 40%, so description carries some burden. It details the 'type' enum and describes the 'inputs' object structure for each type. However, it provides minimal elaboration on 'handle', 'secret', and 'callback_url' parameters beyond their presence in the schema. The description adds value but not enough to fully compensate for the coverage gap.

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

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

The description clearly states the tool submits an async job off the user's context and returns a job_id. It enumerates three distinct job types (fetch_bundle, delay, deep_research), each with a specific purpose. This distinguishes it from sibling tools like check_errand (polling) and research (presumably synchronous), and from other browse/archive 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 delineates when to use each type: fetch_bundle for fetching URLs, delay for ping callbacks, deep_research for multi-round research. It hints at an alternative (polling check_errand for deep_research results). However, it does not explicitly state when not to use this tool (e.g., for synchronous operations) or compare to other async mechanisms.

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

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

Discloses local model (Llama 3.2 3B) with no cost, and optional storage. Annotations indicate read-only and idempotent hints, but description clarifies optional mutation via store_as. No contradiction.

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

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

Two compact sentences, no redundant phrasing. Front-loaded with core 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?

Sufficient given no output schema; covers parameters and use case. Could specify return format, but not critical.

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

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

Description adds context for handle and secret (required), and mentions store_as effect and namespace default. Schema coverage 50% is partly compensated.

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

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

Clearly states it condenses all entries in a namespace into a markdown summary. Distinguishes from sibling search/recall tools by focusing on summarization.

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?

Implies usage for summarizing a namespace, but lacks explicit when-to-use or when-not-to-use compared to siblings like search_memory. Mentions required authentication.

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 read-only, idempotent, non-destructive. Description adds value by specifying the exact file types probed (llms.txt, OpenAPI, ai-plugin) and the SSRF-guard info in the schema. 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?

Two concise sentences packed with essential information: tier-level, action, target files, preferred alternative to scraping, and cost. No redundancy.

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

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

For a single-parameter, read-only discovery tool with full annotation coverage, the description completely conveys purpose, priority, and expected behavior. No gaps remain.

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

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

Schema description coverage is 100% with the 'url' parameter already well-described ('site to probe (http/https; SSRF-guarded)'). Tool description does not add further parameter-level detail, earning baseline score.

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

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

Description uses clear verb 'check' and specific resource 'AGENT-NATIVE interface (llms.txt / OpenAPI / ai-plugin)'. Distinguishes from siblings like 'browse_discover' by explicitly stating 'prefer it over scraping' and referencing specific protocol files.

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

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

Explicitly positions as 'Tier-0 front door' meaning first-check before other tools like scraping. 'Prefer it over scraping' provides clear usage direction. Lacks explicit when-not-to-use but overall strong 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 declare read-only, idempotent, non-destructive. The description adds valuable behavioral context: headless browser rendering, markdown output, free usage, stealth mode anti-detect governed by colony standing, and SSRF-guarded URLs. 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?

Two concise sentences, front-loading the core action and result. Every sentence adds value, with no redundancy or 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?

Given the parameters, schema coverage, and annotations, the description adequately covers purpose, result format, rendering method, and mode options. It does not address error handling or limits, but overall it is sufficiently complete for a read tool.

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

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

Schema covers all three parameters (url, mode, handle) with descriptions. The description enhances understanding by explaining mode behavior (honest default, stealth for anti-detect) and handle's role in governing powerful tiers.

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 reads a web page by rendering JavaScript/SPA and returns markdown, contrasting with fetch. However, it does not explicitly differentiate from sibling browse tools like browse_read, so purpose clarity is strong but not perfect.

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

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

The description provides guidance on when to use modes (honest vs stealth) but does not directly compare to sibling tools or specify when not to use this tool. Usage context is implied but not explicit.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds the return format and hints at no cost ('Free'), which provides some value but minimal extra behavioral detail beyond annotations.

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

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

The description is extremely concise: two sentences with no wasted words. The first sentence states purpose and output, the second provides usage context. Every sentence earns its place.

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

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

For a simple search tool with 2 parameters and no output schema, the description is fairly complete: describes return structure, suggests next steps, and mentions free usage. It lacks details on pagination or advanced queries, but overall adequate.

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

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

Schema coverage is 100% and describes both parameters adequately. The description does not add significant meaning beyond the schema, but the schema itself is clear. Baseline 3 is appropriate.

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

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

The description clearly states the tool finds things on the live web and returns structured results (title, url, snippet). It also differentiates itself as the discovery front-end from sibling tools like web_read and browse.

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

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

The description explicitly guides to use this tool first for discovery, then follow up with web_read or browse. It provides clear context but does not formally list when not to use it or mention alternative tools.

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