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

Annotations establish readOnlyHint and openWorldHint; the description goes beyond them by disclosing the asynchronous nature (1–5 minutes), the three-stage pipeline, and the return shape (summary plus structured_data conforming to the schema). Nothing contradicts 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?

Five short sentences front-load the core purpose, then cover latency, usage conditions, and output shape. Every sentence carries distinct information; examples are parenthetical and do not bloat.

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

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

For a complex multi-stage tool, the description covers purpose, when to choose it, async behavior, and output format. The input schema and output schema supply parameter/return detail, so nothing essential is missing for 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 explains prompt, schema, and useBrowser. The description adds only the link between a supplied schema and the structured_data output; that is useful but does not materially deepen parameter semantics.

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

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

The opening verb "Run multi-source deep research" plus the pipeline description (search the web, scrape citations, LLM-structure results) identifies a distinct capability from search/scrape/crawl. The "when one URL or a flat search result will not answer the question" clause further separates it from single-source 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?

It explicitly states the triggering condition and gives concrete use cases (comparative analysis, multi-jurisdictional research, market intelligence). It also implies the negative case: if one URL or a flat search result suffices, this tool is overkill. It calls out async latency so the agent can weigh 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 reveals important behavior beyond the annotations: async execution, polling to completion, typical 1–2 minute duration, per-source billing, free failed sources, and the large size of full content. This is exactly the operational context an agent needs for a non-trivial async tool.

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

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

Four dense sentences, each earning its place: purpose and output, asynchronous behavior, use cases, and billing/full-content caveats. The most important information is front-loaded, and the structure is easy to parse despite the level of detail.

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

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

Given the tool's complexity — async, multi-source, billed, with a detailed output — the description covers all non-obvious aspects: timing, polling, cost, failure handling, and the large-response caveat. The output schema handles return-value documentation, so nothing critical 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%, so the baseline is 3. The description adds value by warning to set include_full_content=true only when the raw full answer is needed and noting that it is large, plus clarifying the country parameter's role in geo-specific answers. This goes slightly 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 states a specific verb and resource: 'Ask multiple AI answer engines (ChatGPT, Gemini, Google AI Overview) the same question and compare their answers.' It also details the output shape and clearly distinguishes this from general search tools by naming the engines and the comparison/consensus angle.

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?

Explicit use cases are given: brand/AI-SEO visibility checks, answer comparison, and geo-specific AI answers. The description does not name sibling alternatives like search or agentic_search, nor does it state when NOT to use this tool, but the use-case guidance is clear and actionable.

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

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

The readOnlyHint annotation already signals a safe read operation. The description adds value by disclosing that results represent enabled engines and that slugs are the values to pass as `sources`, which is useful behavioral context beyond the annotation.

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

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

Two sentences with no filler. The first sentence states what the tool returns, and the second states when to call it. Information is front-loaded and every clause earns its place.

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

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

For a parameterless read-only list tool with an output schema available, the description is complete: it defines the resource, the output fields, how they relate to a sibling tool, and the call context. Nothing needed for correct invocation is missing.

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

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

The input schema is empty, so the description carries the full burden. It explains the semantic relationship between the output slugs and the `sources` parameter of ai_visibility_search, giving an agent actionable 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 uses a specific verb ('List'), names the exact resource ('AI answer engines available to ai_visibility_search'), and clarifies what each entry contains (slug and display label). It clearly distinguishes this tool from sibling ai_visibility_search, which performs the actual search.

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

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

It explicitly states when to call this tool: when needing to query a subset of engines or check what is currently enabled. This gives an agent concrete decision criteria without requiring inference.

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

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

Annotations already signal openWorldHint and destructiveHint, so the description doesn't need to restate those, but it adds important behavioral context: async polling up to ~5 minutes, refusal to execute payments or transfer funds, and the use of session_id for login without exposing secrets. It also notes the output includes run metadata. This goes beyond the annotations and clarifies limitations and operational details.

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 efficiently packed, with each sentence earning its place. It front-loads the core purpose and examples, then systematically covers usage conditions, async behavior, authentication, output schema, restrictions, and return format. No filler or redundancy; it reads well and is 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 tool's complexity (six parameters, async behavior, security constraints, output schema), the description is remarkably complete. It covers purpose, selection criteria, operational details (timeout, polling), authentication, structured output, limitations (no payments), and the return payload. An agent has everything needed to invoke it correctly without further research.

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% for all six parameters, so the baseline is 3. The description adds practical value beyond the schema: it explains how to use session_id (from session_list) for authenticated sites, advises against putting passwords in the prompt, mentions that url can be omitted to let the agent follow URLs from the prompt, and notes that output_schema yields structured JSON. These enrich the parameter meaning and guide correct 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 opens with a clear statement of what the tool does: 'Run a natural-language task in a real cloud browser driven by an AI agent' followed by a concrete list of actions (navigates, clicks, types, scrolls, extracts) and two illustrative examples. It distinguishes itself from siblings by explicitly contrasting with scrape and Wire actions, so an agent knows exactly when this tool applies.

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

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

The description gives explicit when-to-use guidance: 'Use when scrape cannot do the job (multi-step flows, interactions, complex navigation) and no Wire action covers the site (check wire_discover first — Wire actions are faster and cheaper).' It also instructs to pass session_id for authenticated tasks and warns against putting passwords in the prompt. This fully covers selection criteria and prerequisites.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so safety is covered. The description adds value by disclosing the return format ('array of pages each with markdown and per-page status') and hinting at scoping behavior, which goes 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 compact—two sentences plus a clause—and front-loads the core purpose and when to use it. Every sentence earns its place: purpose, usage scenario, scoping advice, and return format are all covered without redundancy.

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

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

For a tool with 9 parameters and an output schema, the description covers the key aspects: purpose, bulk use case, scoping advice, and return format. It doesn't mention performance or rate limits, but those are not critical given the annotations and output schema. It is sufficient for an agent to decide and call 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%, so parameters are already documented. The description adds meaningful guidance on how to use includePatterns/excludePatterns to scope URLs, which is not fully captured by the schema's individual descriptions. This elevates it slightly above baseline 3.

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

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

The description states a specific action ('Bulk-fetch markdown across a site') and clearly distinguishes it from single-page tools like 'scrape' by emphasizing bulk use cases. The mention of 'catalog ingestion, site-wide RAG corpus' makes the intended scope unmistakable.

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

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

It explicitly says 'Use this when an agent needs the contents of many pages at once' and advises pairing with include/exclude patterns, which gives clear operational context. It doesn't explicitly contrast with alternatives, but the bulk-vs-single distinction is enough to guide an agent.

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

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

The description adds useful behavioral context beyond the readOnlyHint and openWorldHint annotations: it returns internal/external link lists and counts, and it honors depth/limit parameters. However, 'Returns lists of ... external links' is slightly imprecise because includeExternalLinks defaults to false, so the tool only collects external links when explicitly enabled.

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 with no filler: the first states what it does, the second says when it is useful, and the third describes output and parameter behavior. The key purpose is front-loaded and every sentence earns its place.

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

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

For an 8-parameter tool with full schema coverage, annotations, and an output schema, the description provides enough high-level orientation for an agent to select and invoke it. It does not mention SPA handling or subdomain options, but those are fully described in the input 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 coverage is 100%, so the schema already documents all 8 parameters. The description only reinforces depth and limit, which adds no new meaning beyond what the schema provides. 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 states a specific verb and resource: 'Discover all reachable URLs under a given site.' It also distinguishes itself from sibling tools by framing the tool as pre-crawl reconnaissance and as a way to find sub-pages to scrape, which separates it from crawl/scrape 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?

Gives two concrete use contexts: understanding a domain's structure before crawling, and finding sub-pages an agent should scrape. This makes when-to-use fairly clear, but it does not explicitly name alternatives or state when not to use it, so it stops short of a 5.

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

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

Annotations already flag readOnlyHint=true, so the safety profile is known. The description adds meaningful behavior: entries represent differences from the previous check and include a diff/summary, plus an AI summary when aiMode is on. This goes beyond the annotation without contradicting it.

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

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

Two sentences, front-loaded with the tool's purpose, then detail about entries and the prerequisite. 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?

Given a single parameter, rich annotations, and an output schema, the description covers the essential workflow (monitor_list first) and the meaning of entries. Minor missing details like pagination or error behavior are not critical for correct invocation.

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

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

The input schema already fully describes the id parameter (coverage 100%), including its source. The description only reiterates the need to get the id from monitor_list first, which is more usage guidance than new parameter semantics. 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?

States a specific verb 'Get', a resource 'changes for a monitor', and defines entries as recordings of content differences from previous checks. It clearly differentiates from sibling monitor_list/monitor_create by focusing on change history.

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 instructs to call monitor_list first to obtain the monitor id, giving a clear prerequisite. It doesn't explicitly exclude alternatives, but the context is unambiguous for a read-only retrieval tool.

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

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

The description goes well beyond annotations by disclosing concrete side effects: pause stops scheduled checks, resume may hit the active-monitor cap, run_now is billed like a normal check, and delete permanently removes the monitor and history. The destructiveHint annotation is fully supported and enriched by the description.

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 information-dense and front-loads the core purpose, but the single paragraph with multiple quoted actions and side-effect clauses is slightly harder to scan. Each phrase earns its place, though structured bullets would improve readability.

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 output schema exists and annotations declare destructive behavior, the description covers everything needed to choose and invoke the tool correctly: action semantics, consequences, billing, cap risks, and id sourcing. There are no meaningful gaps for correct 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?

Although schema coverage is 100%, the description adds substantial meaning to the action parameter by explaining the behavior and consequences of every enum value. It also reinforces the id parameter's source by telling the agent to use monitor_list, complementing the schema's brief reference to monitor_list or monitor_create.

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

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

The description states 'Control an existing website monitor' and enumerates the four concrete actions (pause, resume, run_now, delete), making the operation unmistakable. It also distinguishes itself from siblings by emphasizing 'existing' and pointing to monitor_list for finding the id, which separates it from monitor_create and monitor_list.

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 operational context for each action and explicitly instructs the agent to 'Use monitor_list to find the id.' It does not explicitly name monitor_create or monitor_changes as alternatives, but the 'existing monitor' qualifier and the listed actions imply when this tool is appropriate.

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

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

Beyond the annotations (destructiveHint, openWorldHint), the description discloses per-check credit costs, active-monitor plan caps (Free 5, Pro 20, Scale 100), auto-pause on expiresAt, and the forced useBrowser=true when sessionId is set. This is substantial behavioral context that annotations alone do not 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 long, but for a 24-parameter tool with three scopes and two watch modes, it is tightly packed and front-loaded with the core behavior. Every sentence contributes either a definition, a constraint, a cost, or a cross-reference; there is no filler.

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

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

Given the tool's complexity, the description covers the essential behavior, scopes, modes, costs, plan limits, required-parameter relationships, and related tools. An output schema exists, so return-value documentation is unnecessary, and the description fully equips an agent to configure a correct monitor creation call.

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

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

Even with 100% schema description coverage, the description adds cross-parameter constraints and semantics: outputSchema is required when watchMode='specific_data', wireActionId is required in wire scope, useBrowser is forced true with sessionId, and credit costs differentiate watchMode/aiMode. These relationships are not present 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 opens with a specific verb+resource: 'Create a scheduled website monitor that checks a URL every intervalMinutes...'. It clearly differentiates this from one-off fetching tools like scrape or crawl by emphasizing scheduled/recurring behavior, and the scope/watchMode variants are all explained.

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 provides strong contextual guidance: scope options, watchMode selection criteria ('ideal for price/stock/status tracking'), and when a browser is needed ('JS-heavy pages'). It references related tools (session_list, wire_discover, wire_identities), though it stops short of explicitly saying when NOT to use monitor_create in favor of a sibling like scrape.

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

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

Annotations already declare readOnlyHint=true, and the description complements this by disclosing the dual list/fetch behavior and the type of data returned (next/last check time, active state, credit cost, alert settings). No contradiction exists.

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

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

Two sentences with no filler. The core behavior is stated first, followed by the optional parameter behavior and a practical usage hint. 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 what the tool returns, how the single optional parameter changes behavior, and why an agent would use it. An output schema exists, so detailed return-value documentation is not required here.

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 the `id` parameter clearly. The description adds some context about the single-monitor result being 'full configuration and status', but does not add substantial parameter-level meaning beyond that.

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

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

The description states a specific verb ('List') and resource ('website monitors'), and additionally covers the single-monitor variant when an `id` is passed. This distinguishes it from related siblings like monitor_control and monitor_changes.

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 tells the agent to use this tool to find a monitor's id before calling monitor_changes or monitor_control. This provides clear routing context for when the tool should be used relative to its 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 and openWorldHint=true, so the safety profile is covered. The description adds useful behavioral context: output type depends on generateJson, browser rendering is slower and more expensive, and the default path is the fetch-based approach. It does not contradict 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?

Three sentences, each earning its place: default behavior, optional structured output, and browser-mode guidance. The most important fact ('fetch a single URL... markdown by default') is front-loaded, and there is no filler or repetition.

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

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

Given 100% schema coverage, existing output schema, and readOnly/openWorld annotations, the description is complete enough for an agent to select and invoke the tool correctly. The description covers the main behavioral branches (markdown vs. JSON, fetch vs. browser), while the schema handles the remaining parameter details like country, session, and caching.

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

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

Schema description coverage is 100%, so the baseline is 3. The description references generateJson and useBrowser, but the parameter descriptions in the schema already explain those fields with comparable detail ('Have AI extract structured JSON...' and 'Required for SPAs and dynamic content'). The description adds only mild extra meaning by tying generateJson to the return format and useBrowser to cost/expense.

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

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

The description opens with a specific verb + resource: 'Fetch a single URL and return clean markdown by default.' It also distinguishes itself from likely siblings by emphasizing 'single URL' and by explaining the two key modes (default fetch vs. useBrowser, markdown vs. generateJson). This makes it easy for an agent to separate scrape from crawl, search, or browser_task.

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 conditional guidance: use useBrowser=true for SPAs and JS-heavy sites, and only when needed due to cost/speed; use generateJson=true for structured data. It doesn't explicitly compare against sibling tools like search or crawl, but 'Fetch a single URL' provides enough scoping to imply the tool is for one-off page fetches rather than site-wide operations.

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 openWorldHint. The description adds that it is synchronous (returns immediately, no polling) and describes the result array fields (url/title/snippet/date), which are behavioral details 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 three sentences, each contributing value: purpose, behavior, and usage. No redundancy, and the key info is front-loaded.

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

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

For a simple tool with two parameters, an output schema, and read-only annotations, the description fully covers purpose, usage context, synchronous behavior, and return format. 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 both parameters (prompt and limit) already described. The description doesn't add extra meaning to the parameters, so it stays at the baseline of 3 for high 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?

The description clearly states the tool performs an AI web search and returns URLs, titles, and snippets. It uses a specific verb ('Run') and resource ('web search'), and the mention of 'discover pages' distinguishes it from siblings like scrape and crawl.

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 to use this tool when the agent needs to discover pages before scraping, providing a clear use case. It doesn't name alternatives like agentic_search, but the context is sufficient for typical 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 already declare destructiveHint=true, but the description adds substantial context: it deletes encrypted login data, is irreversible, requires re-login, and breaks references from monitors/requests. This goes well beyond the annotation and fully discloses the impact.

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

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

The description is three sentences, each earning its place: the action, the irreversible consequence with impact, and the id source. It is front-loaded and contains no redundant wording.

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 destructive one-parameter tool with annotations and an output schema, the description covers the essential warnings, the impact on other entities, and how to obtain the id. Nothing needed for correct invocation is missing.

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

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

The input schema already describes the id parameter as 'The session ID to delete (from session_list).' The description repeats the source of the id without adding new details about format or constraints. With 100% schema coverage, the baseline 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: 'Permanently delete a saved browser session and its encrypted login data.' It names the specific resource and the verb, and it distinguishes from siblings like session_list (which lists sessions) by specifying deletion. The scope is unambiguous.

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

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

The description explains the irreversible nature and the consequence that monitors/requests lose authenticated access, implying caution. It also directs the user to session_list for finding ids. However, it does not explicitly state when not to use the tool (e.g., if a session is needed later), but the destructive warning makes the intended 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?

Annotations already declare readOnlyHint=true and openWorldHint=false. The description adds that sessions are encrypted login states and that creation must happen interactively, which is useful. It does not contradict annotations and provides modest additional context beyond 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?

The description is compact and front-loads the purpose, then explains the id usage and limitation. A few sentences but each earns its place; no fluff.

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

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

For a simple listing tool, the description covers the main use case, filtering, and the creation limitation. An output schema exists, so return values are covered elsewhere. Nothing critical is missing.

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

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

The single parameter, domain, is fully described in the schema (100% coverage). The description restates the filtering behavior but adds no new semantics; it's essentially redundant. 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 lists saved browser sessions and immediately ties the session id to usage in scrape/crawl, monitor_create, and browser_task, distinguishing it from siblings. The verb 'list' and resource are specific.

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 explains when to use the tool (to obtain a sessionId for other operations) and how to filter by domain. It also notes the interactive creation flow cannot run from here, but it doesn't explicitly state when not to use it—though the context 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?

Beyond the annotations (destructiveHint, openWorldHint), the description reveals critical behaviors: it is asynchronous, returns a build_request with an id and 'pending' status, lists skipped items on completion, and mentions credit charges with automatic refunds on failure. It also discloses that login builds cost more. This is rich, non-obvious information that annotations alone do not convey.

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 longer than average but earns its length given the tool's complexity (8 parameters, nested credential object). It front-loads the primary purpose and then logically covers parameters, async behavior, cost, and usage condition. Each sentence adds information; there is no redundancy. A slightly tighter structure would be ideal, but it remains 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?

With an output schema present, return values are already specified. The description covers the essential context: when to use (after discovery), async nature, tracking via build_status, credit implications, refund policy, and the skipped list on failure. It also explains the credential variations and the force flag. Nothing an agent needs to invoke this tool correctly is missing.

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

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

Schema coverage is 100%, so parameters are already documented. The description adds meaningful semantics: for goal it notes 'the builder synthesizes the scraper from this,' for actions it says 'each becomes its own action,' for country it explains 'built and tested through an exit IP in that country,' and for credential it details the plain/vault distinction and that passwords are never stored. This goes beyond the schema, though the schema already carries the 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 opens with a precise purpose: 'Request brand-new Wire actions for a website that isn't in the catalog yet — a full catalog build.' It names the verb (request/build), the resource (Wire actions), and the condition (not in catalog). It explicitly distinguishes itself from siblings by referencing wire_discover / wire_catalog as prerequisites, making the tool's role unmistakable.

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

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

The description gives explicit when-to-use guidance: 'Only use this after wire_discover / wire_catalog confirm no existing action covers the site.' It also directs the agent to track progress with wire_build_status and notes that similar existing actions cause rejection unless force is set. This provides clear context for choosing this tool over alternatives like wire_discover or wire_read_action.

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 (readOnlyHint, destructiveHint), the description reveals that the tool is read-only and spends no credits, that pending/processing statuses require polling, that delivery may be partial (skipped list must always be checked), and that include_events produces a verbose log. This is significant behavioral context not found in the annotations. No contradiction with annotations.

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

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

A compact three-sentence paragraph front-loads the core purpose and mode distinction before detailing output fields and caveats. Every sentence adds information—no filler, and the structure makes the detail/list branching easy to follow.

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, combined with a full output schema and annotations, covers both operation modes, status polling behavior, the skipped-list caveat, and the next-step routing to action execution tools. Nothing an agent needs to call it correctly is missing, even though page/limit details are left to the schema.

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

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

Schema description coverage is 100%, so the baseline is 3. The description's mention of id provenance ('from wire_build's build_request') largely duplicates the schema's 'from wire_build's response,' and status examples mirror the schema. It adds little beyond the schema for parameters like page, limit, and include_events, though it does contextualize the output statuses.

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

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

The description opens with a specific verb ('Check on') and resource ('Wire builds started with wire_build'), and clearly separates detail mode (pass id) from list mode (omit id). It names related sibling tools (wire_read_action/wire_write_action) and disambiguates by stating the tool only checks status, not runs actions. This is unambiguous and distinct 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?

It provides explicit conditions: pass the id from wire_build's build_request for detail; omit id to list recent builds; poll after ~30s while pending/processing; always check the skipped list. It also points to wire_read_action/wire_write_action as the correct tools for running published actions, signaling what this tool is not for. However, it does not explicitly state 'use wire_build to start a new build instead,' so the exclusion is implied rather than spelled out.

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 include readOnlyHint=true, and the description aligns by describing read-only operations ('Browse', 'list'). It adds value by detailing the returned content: action lists, schemas, types, auth modes, credit costs, and login fields. No contradictions; it enriches the read-only annotation with specifics about what the agent will receive.

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, front-loaded with the core purpose, then detailing the behavior with a slug and the use case. It's dense but not bloated; every sentence contributes. The structure is logical and easy to scan.

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

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

The description covers what the tool does, what it returns, how to invoke it (with and without slug), and how it fits with sibling tools. Since an output schema exists (as per context), return details are already structured. No critical gaps remain for an agent to call it correctly.

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

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

The schema already documents the single parameter 'slug' with the same semantics (omit to list all). The description repeats the examples but adds no new meaning beyond the schema. Since schema coverage is 100%, a baseline of 3 is appropriate; the description doesn't fail to compensate because nothing is missing.

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

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

The description clearly states the tool's purpose: browse the Wire catalog, listing all sites with no args, or a specific site's actions with a slug. It uses specific verbs like 'Browse' and 'list' and distinguishes itself from execution tools by explicitly noting it's used 'before running' wire_read_action or wire_write_action.

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

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

The description gives explicit guidance on when to use it: to inspect a site's capabilities before executing actions. It names the alternative tools (wire_read_action, wire_write_action) and frames the catalog as a precursor. It doesn't explicitly state exclusions, but the context is clear that this is for discovery, not execution.

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

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

Beyond the readOnlyHint annotation, the description discloses valuable behavioral details: results are ranked, each candidate includes action_id, type, params, credit cost, and auth requirement, and the read/write distinction is explained with concrete examples. This gives the agent an accurate model of what the tool returns and how the results should be used.

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

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

The description is front-loaded with the core purpose and remains dense but well-structured: catalog context, read/write taxonomy, auth note, applicability, return contents, and follow-up actions. Every sentence contributes useful selection or invocation guidance, with no filler or redundancy.

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

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

For a discovery tool, the description covers purpose, when to use it, result contents, and next steps, and the presence of an output schema covers return-shape details. The only minor gap is lack of explicit differentiation from sibling discovery-related tools such as wire_catalog or agentic_search, but this does not materially hinder correct use.

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

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

Schema description coverage is 100%, and the q parameter is already described as natural-language intent with examples, while limit has a default and bound in the schema. The description reinforces the intent-based nature of q but does not add significant parameter-level meaning beyond what the schema already provides.

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

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

The description opens with a specific verb and resource: 'Find Wire actions for a task from a natural-language intent.' It fully clarifies that this is a discovery tool over Wire's catalog, and the examples of READ and WRITE actions make the scope explicit without depending on the tool name alone.

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

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

It clearly states when the tool is applicable: 'when a task may be achievable on a specific known site, for data extraction as well as interactions.' It also tells the agent how to proceed after discovery by routing to wire_read_action or wire_write_action, though it does not explicitly name discovery alternatives or when to avoid using this tool.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, covering the safety profile. The description adds useful behavioral context by explaining the relationship between credential `id` and `credential_id` for auth_mode="required" actions, and by warning the agent to check for 'active' rather than 'expired' status. This is meaningful additional 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 front-loaded with the core purpose and then gives necessary context about how credentials are used. It is slightly longer than strictly needed for a simple list tool, but every sentence earns its place by connecting the tool to the broader action workflow.

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 only one optional parameter, a rich description, a true output schema, and safety annotations, nothing essential is missing. The description fully explains why the tool exists, how to filter it, and how its output feeds into subsequent auth-required actions.

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 the single optional catalog_id parameter already described in the schema as 'restrict to identities for a single catalog'. The description repeats this as 'Optionally filter by catalog_id' without adding new syntax or format details, so the baseline of 3 applies.

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

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

The description opens with a specific verb ('List') and a clear resource ('your saved Wire identities and their credentials'), and it differentiates this tool from wire_read_action/wire_write_action by explaining that the credential `id` is the `credential_id` passed to those tools. This lets an agent immediately know what the tool returns and how it fits into the action flow.

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

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

The description gives explicit guidance: use this tool before running an auth-required action to find an existing credential and verify its status is 'active'. It also mentions the optional catalog_id filter. It does not explicitly name alternatives to avoid or when-not-to-use conditions, so it falls just short of a 5.

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

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

Annotations declare destructiveHint and openWorldHint, but the description adds valuable context beyond them: the password is never stored, only the encrypted session is kept, and the resulting credential_id is immediately usable. It doesn't exhaustively describe session lifecycle side effects, but it complements the annotation coverage 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?

The description is compact and front-loaded with the core purpose and outcome. Each sentence earns its place: purpose, required inputs, security behavior, and explicit usage boundaries. No filler or repetition of schema details.

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

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

Given the 5-parameter schema, output schema, and annotations, the description covers the key operational context: when to use the tool, what to provide, how password data is handled, and which alternative flows exist. The few remaining details such as source_id/source_ref semantics are already documented in the input 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 coverage is 100%, so a baseline of 3 applies. The description adds meaning by explaining that `params` must follow the catalog's login_input_schema and giving a concrete example (email/password). This helps the agent understand that `params` is not arbitrary but schema-driven.

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

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

The description states a specific verb and resource: 'Sign in to a credentials-mode site' and names the direct outcome, 'get a credential_id usable immediately with wire_read_action / wire_write_action.' This clearly differentiates it from sibling tools like wire_catalog and the read/write action 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?

It explicitly says when this tool is needed ('Only needed for actions whose auth_mode is "required"'), and when it is not needed ('cookie-based sites use the dashboard connect flow instead'). It also directs the agent to wire_catalog's login_input_schema for the exact param shape, providing concrete routing 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 the annotations' readOnlyHint=true, the description adds that the tool EXTRACTS data and does not change state, and that it 'transparently polls the async job to completion and returns the extracted data.' It also discloses auth behavior. It does not contradict the annotations, though it omits failure or timeout behavior, so it is not a 5.

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

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

The description is front-loaded with purpose, then flows through discovery, params, auth, and the write-action alternative. The example list is slightly long but each clause carries meaningful guidance; there is no filler, though some redundancy with the readOnly annotation could be trimmed.

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 generic action runner, the description covers discovery, type confirmation, param matching, auth, async polling, and sibling routing. With a rich output schema present, it does not need to describe return values. It omits identity_id as an alternative auth path, but the schema covers that, so this is largely complete.

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

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

The input schema has 100% description coverage and already documents action_id, params, identity_id, and credential_id with conditional auth semantics. The description adds that most read actions need no auth and that params must match the action's schema, but this largely restates the schema. Baseline 3 is appropriate because the schema does the heavy lifting.

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

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

The description states 'Run a Wire READ action' and enumerates concrete examples (search listings, fetch category products, get price/specs/reviews, read profile, pull metrics), making the operation and resource unambiguous. It also distinguishes from the closest sibling by explicitly routing state-changing actions to wire_write_action.

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

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

It gives explicit when-to-use steps: discover action_ids first with wire_discover or wire_catalog, confirm the action's type is 'read', and ensure params match the action's schema. It also directly states the when-not case—'For state-changing actions (type "write") use wire_write_action instead'—and provides auth prerequisites for actions with auth_mode 'required'.

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 flag destructiveHint=true and openWorldHint=true; the description adds genuinely useful behavioral context on top: it 'transparently polls the async job to completion and returns its result' and refuses payments/transfer actions. It reinforces the state-changing nature consistently with destructiveHint, but doesn't add nuance about irreversibility or failure behavior — hence not a 5, but clearly above baseline.

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?

Five information-dense sentences, front-loaded with the purpose and examples before moving to preconditions, auth, async behavior, and exclusions. Every sentence earns its place, though there is slight redundancy in stating the action type is 'write' both in the opening and in the discovery confirmation instruction.

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 an output schema exists (so return values are covered), the description covers the essentials: discovery preconditions, auth handling, async polling behavior, prohibited payment actions, and sibling routing. Minor gaps remain — what 'refused' looks like at the API level and whether write actions are idempotent — but nothing an agent needs to invoke it correctly is missing.

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

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

Schema coverage is 100% and each parameter already has a rich description (auth_mode conditions for credential_id, identity_id as alternative, source from wire_identities/wire_login). The description mostly restates what the schema says — 'params must match that action's parameter schema' and credential sourcing — adding only the general framing that 'most write actions need auth'. Baseline 3 is appropriate since the schema carries the semantic weight.

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

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

The description opens with a specific verb+resource ('Run a Wire WRITE action') and clarifies what 'write' means with concrete examples (submit a form, add an item to a cart, post content, update account settings). It explicitly differentiates from its sibling wire_read_action by stating that read-type, non-state-changing extraction belongs there.

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?

Gives explicit preconditions: discover action_ids with wire_discover/wire_catalog and confirm the type is 'write'. It also states when auth is needed (pass credential_id from wire_identities or wire_login) and when to choose the alternative tool ('For data extraction that does not change state (type "read") use wire_read_action instead'). No ambiguity remains about when this tool applies.

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