ai-netcafe

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

Annotations already establish read-only and idempotent behavior. The description adds valuable behavioral details: parsing robots.txt per user-agent group (not keyword-matched), checking for specific files, calculating real text without JavaScript, and returning an ordered list of fixes. This goes beyond annotations without contradicting 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 two sentences: the first enumerates the audit components, the second states the output. It is front-loaded with the core purpose and contains no redundant or filler content.

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

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

The description fully covers what the tool checks (robots.txt, visibility files, text accessibility) and what it returns (score + fixes). With an output schema present, additional return-value detail is unnecessary. The description is complete for a complex audit 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 sole parameter 'url' is fully documented in the schema with 'Page to audit'. The description doesn't add additional meaning beyond the schema, but with 100% coverage, a 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 tool's purpose: 'Audit a URL for AI visibility' with specific resources (robots.txt, llms.txt, sitemap, JSON-LD, canonical). It distinguishes from sibling tools like fetch_page or web_search by detailing the audit's unique checks and output (score + fixes).

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 makes the use case clear: determine which AI crawlers can access a site and what visibility signals exist. It does not explicitly mention when not to use it or name alternatives, but the specificity of the audit itself provides clear 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 are all false, providing no safety or side-effect signal, so the description carries the burden. It does add the behavioral detail of 'exact cost in USD' (implying billing), but it doesn't disclose other potential side effects, rate limits, or data handling. This is informative but incomplete.

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 plus a concrete example URL. It is front-loaded with the action, efficient, and every part earns its place. The example URL is slightly long but adds practical 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?

The output schema exists, so return values need no explanation. The description covers purpose, use cases, and an example, while the schema handles parameter details. Minor gap: it doesn't mention list_models for available model IDs, but that's covered in the schema, so overall it's nearly 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%, so the schema already documents all four parameters. The description's example URL illustrates the prompt and model parameters concretely, but it adds minimal semantic meaning beyond the schema's own descriptions. 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+resource+output: 'Send a prompt to one specific large language model and get the answer plus its exact cost in USD.' The 'one specific' qualifier clearly distinguishes it from sibling tools like compare_models, and the cost detail differentiates it from generic model-call 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?

Provides clear use cases ('second opinion from a different model, or a cheaper model for a bulk subtask') that help an agent decide when to invoke it. However, it does not explicitly name alternatives or state when not to use it, stopping short of full when/when-not guidance.

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

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

The description adds significant behavioral context beyond annotations: the operation is async ('poll with check_job'), deploys to managed hosting with HTTPS, returns a public URL in ~1-2 minutes, and lists the app. This complements the annotations (readOnlyHint=false, destructiveHint=false) without contradiction, though it does not detail auth requirements or rate limits.

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 (four sentences) and front-loaded with the core action and result. It includes the example and polling instruction without redundancy, making every sentence earn 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 the output schema exists, the description does not need to explain return values. It covers the full workflow: create, deploy, get URL, poll with check_job, and best-use guidance. The example ties it together. This is complete for a tool with this complexity and sibling context.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds value through the example ('a tip calculator web app') and the phrase 'plain-language description,' which clarifies the primary parameter. It also implicitly explains 'refine' by noting it modifies an existing app, though that detail is in the schema. Overall, it slightly enhances parameter 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?

The description clearly states the core action: 'Turn one plain-language description into a LIVE single-page web tool' with specific details about deployment and URL return. It distinguishes itself from siblings like check_job (polling) and get_app/list_apps (retrieval) by focusing on creation, and the example reinforces the purpose.

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

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

Explicitly suggests the best use case: 'Best for tool-style apps: calculators, converters, checklists, timers, generators, small games.' It also provides the async workflow with check_job and a concrete example. However, it does not explicitly state when not to use it or mention alternatives like get_app/refine, so it is clear 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?

Annotations declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds operational behavior not covered by annotations: polling frequency, response fields like retry_after_seconds and next_action, and preference for structured_result. It also includes a concrete example URL, making the tool's behavior very transparent.

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 and front-loaded: the first sentence states the core purpose, the second gives actionable polling and handling instructions, and the final example URL is a compact illustration. Every sentence contributes, with no redundant content.

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

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

For a simple tool with one required parameter, an output schema, and strong annotations, the description covers purpose, usage, and behavioral details. It explains the job lifecycle (pending vs. complete) and how to respond, making it complete for the tool's complexity and context.

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

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

The schema already fully describes the only parameter (job_id) with 100% coverage. The description adds value by indicating the job_id originates from specific job-starting tools ('job started by deep_research, translate_pdf, or make_slides') and showing its use in the example URL. This enhances understanding beyond the schema, though not excessively.

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

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

The description clearly states the tool's function: 'Get the status or result of a job started by deep_research, translate_pdf, or make_slides.' It uses a specific verb and resource, and names the sibling tools that initiate jobs, distinguishing it from those tools.

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

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

The description provides explicit usage guidance: it names the exact tools that start the jobs to check, gives a polling interval ('Poll every 15-30 seconds'), and describes how to handle pending vs. complete states ('follow retry_after_seconds and next_action', 'prefer structured_result'). This goes well beyond basic intent.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds valuable context about the real-China egress method and the measurement nature (instead of a guess). It doesn't mention potential delays or limitations, but for a simple read-only operation this is acceptable.

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. The opening sentence delivers the core verb and resource, the second sentence adds the 'why' context. This is economical 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 simplicity (one parameter, no nested objects, output schema present), the description fully covers purpose, methodology, and use case. It does not need to explain return values because an output schema exists.

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

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

The schema describes the only parameter (url) with a full example, achieving 100% coverage. The description adds no additional parameter meaning beyond what the schema provides, so 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 a specific verb ('Fetch a URL') and resource (mainland-China egress), and explains the output (HTTP status, latency, DNS resolution). It uniquely distinguishes itself from sibling tools by targeting China reachability, making the purpose 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 explicitly explains when to use it ('is my site/API usable from China?') and why it's not substitutable by a VPS abroad. It provides a clear use case and implies exclusion of generic fetch tools, but does not name a specific alternative like fetch_page, 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 already declare read-only, idempotent, and non-destructive behavior. The description adds substantial behavioral context: it returns a cleaned CSV plus a report of changes ('rows in, rows out, duplicates removed, cells trimmed per column'), and it verifies row arithmetic, explicitly stating it reports inconsistencies instead of returning an unchecked table. This goes well beyond the annotations, which only cover safety.

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 detailed but every sentence serves a purpose: listing operations, describing the report, explaining verification, additional transformations, and the use case. It's front-loaded with the main function and not wasteful, though it is a bit long due to the tool's multiple capabilities.

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, operations, return value, verification, and use case, which is complete for an agent to select and invoke the tool correctly. The output schema and annotations fill remaining gaps (exact return structure and safety profile). No significant missing context, though it doesn't address edge cases like conflicting parameters.

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 all six parameters are already documented in the input schema, including valid ops values. The description reinforces the purpose of split_column and wide_to_long but doesn't add meaningfully new parameter-level semantics beyond what the schema provides, so 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 tool's function: 'Tidies a spreadsheet export' and enumerates specific operations (removes duplicate rows, trims whitespace, unifies empty values, splits columns, transposes, unpivots). It distinguishes itself from sibling tools like diff_tables or extract_tables by focusing on cleaning and transforming CSV data for analysis.

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: 'Use when a CSV came out of Excel or an export and needs cleaning before analysis.' It also explains why wide_to_long is useful ('long format analysis tools expect'), but it doesn't explicitly mention when not to use the tool or name alternative tools for exclusions, so it's a 4 rather than 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 only include false hints, so the description must carry the transparency burden. It does so by disclosing parallel execution, real measured cost/latency, and providing a concrete example. It does not mention potential rate limits or cost implications beyond the phrase 'real measured cost,' which implies actual API usage. This is 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 is concise and front-loaded with the core function in the first sentence. The second sentence adds practical context, and the example URL demonstrates usage without unnecessary verbosity. Every sentence earns its place, with 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?

Given that an output schema exists and parameters are fully described in the schema, the description does not need to explain return values. It covers the main use case, parallel behavior, and cost/latency data. Minor gaps include no mention of model selection constraints or margin for errors, but overall it is complete enough for an agent to select and invoke the tool correctly.

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

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

Schema description coverage is 100%, so the baseline is 3. The description does not add parameter-specific details beyond what the schema already provides; it focuses on the overall behavior and use case. Since the schema already documents prompt, models, and system clearly, the description's lack of parameter elaboration is acceptable but does not elevate the 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?

The description clearly states the tool's function: 'Run one prompt across multiple LLMs in parallel and return every answer side by side with its real measured cost and latency.' It identifies a specific verb (run), resource (multiple models), and outcome (side-by-side answers with cost/latency). This distinguishes it from siblings like ask_model (single model) and model_costs (cost data only).

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 for when to use: 'useful before committing a long job to an expensive model' and positions it as answering 'which model should I actually use for this kind of task?' This implies a comparison use case but does not explicitly name alternatives or state when not to use. Sibling tool names like ask_model and model_costs are not mentioned, so the guidance is good but not fully 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 this is not read-only, not idempotent, and not destructive. The description adds valuable behavioral context: 'you do not keep anything running', 'only notifies you when the result actually changes', and the need for a workspace token. This goes beyond the annotations and helps the agent understand the operational model.

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 long and information-dense. The use of a 'Kinds:' list makes it scannable. There is slight redundancy with the title ('Schedule a recurring task' vs 'Create a task that runs on a schedule'), but overall it is concise and avoids unnecessary verbosity.

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 that an output schema exists, the description need not explain return values. It covers the main aspects: the different task kinds, the server-side scheduling model, the notification behavior, and the auth requirement. It does not mention edge cases or rate limits, but for a tool of this complexity it is sufficiently complete for an agent to select and invoke it correctly.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds meaning by explaining that 'input' is either a URL or a question depending on the kind, and it elaborates on the possible values of 'kind' with concrete examples. This clarifies parameter usage beyond the schema's terse 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 begins with 'Create a task that runs on a schedule in our cloud', providing a specific verb and resource. It clearly lists three concrete kinds (watch_page, daily_answer, watch_reachability) with explanations, distinguishing it from sibling tools like delete_task and list_tasks.

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 use cases for each kind, such as 'Watch a web page and report when its content changes' and 'Track whether a site stays reachable from mainland China'. It implies server-side execution and notification-only-on-change behavior, but does not explicitly name alternatives or state when not to use the 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 indicate destructive and idempotent behavior, but the description adds useful context: it also removes run history and stops the task, implying termination of active runs. 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, direct sentence that immediately conveys the action and scope. 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 delete tool with one parameter, output schema, and annotations covering safety, the description is complete. It explains the action and the additional effect on run history, leaving no critical 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 coverage is 100% with task_id described as 'From list_tasks.' The description adds no additional parameter meaning, 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 clearly states the verb 'remove' and the resource 'scheduled task', and further specifies scope by mentioning 'run history'. This distinguishes it from siblings like create_task and list_tasks.

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

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

No explicit when-to-use or alternative guidance is provided. The description implies usage for stopping and removing a task, but does not state exclusions or reference sibling tools. The schema hint 'From list_tasks' is a minor prerequisite hint, but the description itself lacks 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 readOnly, idempotent, and non-destructive. The description adds valuable behavioral detail: the exact three output categories and that it names the differing column with both values. It does not contradict annotations and provides context beyond what structured fields 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 two sentences, front-loaded with the core function and outputs, and includes a useful comparison to a sibling tool. Every sentence contributes value; 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?

Given the simplicity of the tool, presence of an output schema, and rich annotations, the description is complete. It clarifies purpose, usage, output categories, and fits into the sibling landscape without unnecessary elaboration.

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 parameters are well-documented. The description adds a little context by explaining the 'key' column's role and the CSV input options, but largely repeats schema info. Baseline 3 is appropriate since the schema carries the parameter documentation burden.

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

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

The description clearly states the tool's function with a specific verb ('Matches rows across two CSVs on a key column') and enumerates the three report categories. It also distinguishes itself from sibling tools by explicitly referencing reconcile_ledger and covering a broad range of use cases.

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 contrasts with reconcile_ledger ('Unlike reconcile_ledger this needs no amount column') and provides a rich set of example applications (name lists, inventory counts, permission tables, matching exports). This directly tells the agent when to choose 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?

Annotations already assert readOnly, idempotent, non-destructive. The description adds meaningful behavioral context: computation is deterministic (LCS) and not based on model guessing, which affects trust in output. It also clarifies output includes line numbers, complementing 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 core behavior and algorithm, then usage context. No wasted 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?

Given the tool's simplicity, the description covers purpose, usage, and algorithmic behavior. An output schema exists (not shown) to handle return details, so the description does not need to explain output structure. It is complete for an agent to select and invoke correctly.

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

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

Schema description coverage is 100% with each parameter described as 'first (before) text' and 'second (after) text.' The description does not add further parameter-level detail, so baseline 3 is appropriate; the schema fully handles 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 description states a specific verb ('Returns') and resource ('which lines were added and which were removed, with line numbers'), clearly distinguishing it from siblings like diff_tables. It also clarifies it uses longest-common-subsequence, not a model, reinforcing its specific function.

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 use cases: 'compare two versions of a config, a document, or any command output' and explicitly contrasts with 'asking an LLM to eyeball two blobs.' This gives clear guidance on when to choose this tool over an alternative approach.

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 provides rich behavioral detail beyond the readOnlyHint and idempotentHint annotations: arithmetic validation (net+tax=gross), independent batch total re-addition, flagging misread rows with the exact difference, and deliberately omitting batch totals for mixed currencies to avoid accounting errors. It also specifies CSV encoding (UTF-8 with BOM) for Excel compatibility.

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 well-structured and front-loaded, starting with the action and constraint ('Give it up to 20 invoice URLs...'). Every sentence contributes essential information: input/output, validation logic, currency behavior, and CSV format. It is appropriately sized for the tool's complexity with no redundant 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 moderate complexity and the existence of an output schema, the description covers all necessary context: input constraints (URLs, PDF/images, up to 20), processing behavior (arithmetic checks, error flagging), handling of mixed currencies, and output format (table fields, CSV encoding). It leaves no significant gaps in 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?

The schema already documents the only parameter 'urls' with details (comma-separated, array, up to 20 per call), achieving 100% coverage. The description adds meaning by specifying acceptable input formats (PDF or page images), which is not present in the schema, thus providing extra value beyond the structured definition.

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 ('extract') and clearly states the input (invoice URLs) and output (a ledger-ready table with number, date, seller, buyer, net/tax/gross, currency). It distinguishes itself from siblings like extract_tables by focusing on invoice-specific arithmetic checks and ledger readiness.

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

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

The description clearly conveys the use case: batch-processing invoices into a ledger-ready table. It doesn't explicitly name alternatives or exclusions (e.g., 'use extract_tables for non-invoice tables'), but the context is unambiguous and sufficient for an agent to decide when to invoke 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?

Beyond the annotations (read-only, idempotent), the description reveals the reconciliation behavior: it checks opening+credits-debits against closing balance, reports the exact difference, and identifies the first breaking row. This is valuable behavioral context not present in annotations.

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

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

The description is two sentences, with the core function front-loaded in the first sentence and the reconciliation detail/limitation in the second. No redundancy with schema/annotations.

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 input, output format (JSON+CSV), built-in validation logic, error reporting (exact difference, breaking row), and the scan limitation. With an output schema present and annotations covering safety, this is fully complete.

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

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

The input schema already fully documents the single 'url' parameter as 'Public URL of the statement PDF.' The description adds the text-layer limitation and type of PDF, but no additional parameter semantics beyond the schema's 100% 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 converts a bank statement PDF into a JSON/CSV transaction table and performs a reconciliation check. This specific verb+resource+behavior distinguishes it from siblings like extract_tables (generic) and convert_to_pdf (opposite direction).

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 specifies the target input (bank statement or transaction PDF) and clearly states a limitation: text-layer PDFs only, scanned images not supported. This gives clear when-to-use and when-not-to-use context, though it does not explicitly name alternative 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?

Discloses non-obvious behaviors: uncertain rows are flagged rather than guessed, and only text-layer PDFs are supported. Annotations already cover read-only/idempotent/non-destructive, so this description adds substantial value 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?

Four succinct sentences, each carrying unique information: output format, schema alignment usage, uncertainty handling, and text-layer limitation. 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?

With rich annotations, complete schema, and output schema present, the description covers all essential aspects: purpose, key parameters, a critical limitation, and behavioral nuances. Nothing significant is missing for a tool of this 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 parameters are documented. Description adds contextual meaning to 'fields' by explaining the alignment use case, going beyond the schema's mechanical description.

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 'Extract tables from a PDF into structured rows (JSON + CSV)', giving a specific verb and resource with output format. It distinguishes from sibling PDF tools by focusing on table extraction and schema alignment.

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 clear context: use for PDF tables needing consistent schema alignment, and pass 'fields' to force fixed columns. States text-layer requirement, but does not explicitly name alternatives or exclusions.

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

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

Annotations already declare readOnlyHint and idempotentHint, so the safety profile is covered. The description adds behavioral details beyond annotations: it uses Crawl4AI, handles JavaScript pages, and outputs clean Markdown, which is useful for the agent's expectations.

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

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

The description is front-loaded with the core purpose, includes usage guidance, and a single illustrative example. Every sentence adds value, with 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 tool's simplicity (single parameter), explicit annotations, and an output schema, the description is complete. It covers what, when, and how, without needing to detail return values since the output schema is available.

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 a basic description of the url parameter. The description adds meaning by specifying 'public URL' and provides an example demonstrating the exact query parameter format, going beyond the schema's generic description.

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 fetches any public URL and returns LLM-ready clean Markdown, with a specific verb (fetch) and resource (web page). It distinguishes from sibling web_search by focusing on reading a specific URL rather than searching.

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 it after web_search to read a source or ingest a page, naming the alternative tool. It doesn't provide explicit when-not-to-use exclusions, but the 'public URL' constraint implies a boundary.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds valuable context about the return content (benchmark scores, source repo, human URL), which enriches understanding 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?

The description is a single, information-dense sentence followed by a concrete example. Every phrase earns its place, listing exactly what details are returned and how to invoke the tool. 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?

The tool is simple (one required parameter, no nested output schema) and benefits from rich annotations and an output schema. The description covers the tool's purpose, input provenance, and return content, making it fully adequate for an agent to select and invoke correctly.

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

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

The schema already provides 100% coverage with a clear description for the single slug parameter. The description reinforces that it comes from list_apps and gives an example URL format, adding marginal value 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 uses a specific verb ('Get details') with a clear resource ('one hosted application') and enumerates the specific detail categories returned. This clearly distinguishes it from sibling tools like list_apps, which likely returns a summary list rather than full details.

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

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

The description implies the tool is for fetching full details of a single app and explicitly references the slug from list_apps, giving the agent a clear workflow. It lacks an explicit 'when not to use' statement or alternative comparison, but the context and example are sufficient for correct 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 readOnlyHint=true, idempotentHint=true, and destructiveHint=false, indicating a safe read operation. The description adds behavioral context about what the runs include (returned value, change detection, cost), which is useful for the agent without duplicating annotations.

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

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

The description is a single concise sentence that front-loads the core purpose ('Recent runs of one scheduled task') and delivers key output details without waste. It pairs well with the title.

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

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

The tool is simple (2 params, one required) and has an output schema along with annotations that establish safety. The description covers the essential output dimensions and is sufficient for an agent to select and invoke the tool correctly.

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

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

Schema description coverage is 100% because both parameters have detailed descriptions (task_id, limit with max and default). The tool description adds no parameter-specific meaning beyond the schema, 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 clearly states the tool's function: 'Recent runs of one scheduled task' with specific output aspects (what it returned, result changed, cost). It uses a specific verb ('get') and resource ('task runs'), distinguishing it from siblings like list_tasks or check_job.

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

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

The description implies the tool is for inspecting a specific scheduled task's run history, but does not explicitly name alternatives or exclusions. However, the context is clear enough given the sibling list, which includes create_task and list_tasks for other purposes.

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, and the description adds auto-detection and error-handling behavior: a parse failure returns the parser message rather than producing plausible-looking output. This is valuable beyond structured data.

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

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

Three tight sentences, front-loaded with the main verb, and no filler. Each sentence adds either the conversion scope, the auto-detect behavior, or the error guarantee.

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 conversion tool, the description covers purpose, usage context, error behavior, and auto-detection. With annotations and output schema present, 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 covers both parameters with descriptions, so baseline 3. The description adds that `to` is optional and direction is auto-detected, and clarifies the role of `text` as the content to convert, enhancing 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?

Clearly states a specific verb+resource: converts between JSON and YAML in either direction. The auto-detection detail distinguishes it from tools like validate_json, establishing a unique 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?

Provides explicit use cases: 'config, a CI file, or a Kubernetes manifest needs to be in the other format.' It doesn't name alternatives or exclusions, but the context is clear enough 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 already declare readOnlyHint and idempotentHint, and the description adds a critical behavioral caveat: the signature is NOT verified, and the response explicitly says so. This goes beyond the structured annotations and gives essential security context.

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 well-structured sentences: the first states the core function, the second provides vital security guidance. Every sentence earns its place, 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?

For a single-parameter, read-only tool with an output schema and strong annotations, the description fully covers purpose, usage boundaries, and the key caveat about signature verification. There are no meaningful 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?

The schema already provides 100% coverage with the parameter description 'The JWT string.' The description does not add significantly new semantic detail about the parameter itself, only restating that it is a JWT. 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 uses a specific verb 'Decodes' and clearly states the resource (JWT header/payload) and scope (reports issued-at/expiry as readable timestamps and seconds remaining). It distinguishes itself from sibling tools, none of which are JWT-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?

Explicitly states when to use: debugging a token you already hold, and when not to: never treat values as proof; verification needs the secret and belongs in your own service. This gives clear context and an alternative path.

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 behavior. The description adds context about the tools being pre-configured and normally requiring local setup, plus an example endpoint. It doesn't disclose any side effects or rate limits, but given strong annotations, the bar is met and slightly exceeded.

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 and well-structured: purpose, context, usage examples, exclusions, and an example URL, all in a compact format with 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 parameter set, rich output schema, and clear annotations, the description is complete. It provides enough context for an agent to select and invoke the tool correctly without needing to infer 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 the 'category' parameter fully described. The description does not add additional parameter context, so it meets the baseline but does not exceed it.

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 open-source AI applications hosted at AI NetCafé, with a specific verb ('list') and resource. It distinguishes itself from sibling tools by explicitly naming alternatives like compare_models and translate_pdf, and explains the unique value (pre-configured, no local setup needed).

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 when-to-use guidance with concrete examples ('find a tool for translating a PDF...') and when-not-to-use guidance by naming the direct task tools (compare_models, translate_pdf, etc.). This is exactly the kind of clear usage direction the dimension looks for.

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 behavior. The description adds a focus on cost but does not disclose additional behavioral details such as response format or pagination. Given annotation coverage, this is a baseline 3.

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 concise sentence that front-loads the core functionality. The included example URL is slightly extraneous but does not detract much from 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?

With only one optional parameter and a full output schema, the description adequately explains the tool's purpose and cost focus. It could mention how the tier filter affects results, but the schema handles that. Overall, it's complete for this simple 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 single 'tier' parameter is fully documented in the schema with an enum and description (100% coverage). The description adds no extra parameter information, so the 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?

Clearly states the tool lists all callable models with their input/output prices, with the specific purpose of cost-based selection. This distinguishes it from generic listing tools and is a specific verb+resource.

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

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

Provides clear context ('so you can pick by cost as well as capability') but does not explicitly mention alternatives or when not to use. No exclusions are stated, so it falls short of a 5.

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

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

Annotations already declare the operation as read-only and idempotent, so the safety profile is clear. The description adds valuable context about the returned data, specifically execution count and cost, which is behavioral information beyond what annotations provide. It does not need to disclose destructive actions or side effects, as none exist.

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 immediately states the action and resource, then lists the specific returned fields. Every word earns its place, with no filler, redundancy, or unnecessary detail.

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

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

For a zero-parameter, read-only listing tool with an output schema, the description completely covers the tool's behavior and scope. It explains what will be shown and within which context (workspace). The output schema presumably details the exact return format, so the description does not need to elaborate further.

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

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

The tool has zero parameters, and the description adds no parameter-specific details, but none are needed. With an empty input schema, schema coverage is trivially 100%, meeting the baseline of 4 for tools without parameters. The focus on output content does not detract from 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 description uses the verb 'Show' and identifies the specific resource 'scheduled tasks' on the workspace, distinguishing it from siblings like create_task or delete_task. It further specifies the output contents (next run, run count, cost), making the tool's function precise and 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 clearly establishes when to use the tool: to view all scheduled tasks and their key metrics in the current workspace. However, it does not explicitly mention alternatives or exclusion scenarios, such as using get_task_runs for run-level details, so it lacks the 'when not to use' guidance that would earn 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?

Beyond the annotations (readOnly, idempotent, non-destructive), the description discloses critical behaviors: headers need not match, columns are unioned with blanks for missing columns, rows never shift silently, and row counts are reported and validated against the sum. This adds substantial value 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?

Three sentences, perfectly front-loaded with the main purpose, followed by behavioral detail and then use cases. Every sentence earns its place with no redundancy or 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?

For a tool with simple inputs (two optional params) and an output schema, the description covers the core functionality, edge cases (drifting headers), validation behavior, and typical use cases. It is complete enough for an agent to select and invoke correctly.

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

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

The schema already covers both parameters (urls and texts) with descriptions, so the baseline is 3. The description doesn't add much parameter-specific detail beyond what the schema provides, though it reinforces the 'at least two' constraint for urls implicitly via 'up to 20 CSVs'.

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 combines up to 20 CSVs into a single table, with a specific verb and resource. It also differentiates from sibling tools like clean_table or extract_tables by emphasizing multi-file merging with column unioning and row count verification.

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 use cases: 'monthly exports, per-store sheets, or any set of files with the same subject but drifting headers.' It does not explicitly mention when not to use it or alternatives, but the context is clear enough to guide selection.

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

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

Annotations already mark it as read-only and idempotent; the description adds behavioral insight by explaining the measurement methodology (identical prompt to all models), the contrast between standard_bench and production_mixed, and licensing (CC BY 4.0). This goes beyond the structural hints.

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 opening sentence delivers the core message in one line; subsequent sentences expand with rationale, example, and licensing. While slightly wordy, it's efficient 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?

The description covers the measurement context, comparability caveats, and provides a concrete example endpoint. With an output schema present, return values are already specified, so no further detail is needed. The warning about production_mixed prevents misuse.

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

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

The only parameter, 'days,' is fully documented in the schema with its default, and the description does not add extra detail about parameter semantics. Since schema coverage is 100%, a 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 tool's function: it reports 'what one call actually costs on each model, measured.' It specifies the resource (per-call cost across models) and differentiates from simple list-price comparisons, making its purpose distinct among 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 explicitly instructs to use the standard_bench data 'to choose a model before bulk work' and warns that production_mixed is 'NOT comparable across models,' providing a clear conditional usage rule. It does not name alternative tools but gives sufficient contextual direction.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds behavioral details: text-layer PDFs are read exactly (fidelity) and cost less, while images go through a vision model. This gives practical context about performance and output quality, though it does not detail failure modes or limits.

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. The second sentence adds a concise cost/processing note. No redundant phrasing.

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

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

Given the single parameter, clear annotations, and presence of an output schema, the description covers the core functionality and important behavioral traits. It lacks explicit alternatives or error scenarios, but those are outside the core completeness for a simple conversion 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 100% of the single parameter (url) with a clear description. The tool description adds context about processing modes (vision model vs exact text) but does not add new parameter syntax or format details 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 uses a specific verb ('Convert') and resource ('PDF or scanned page image') and specifies output ('clean Markdown') and key features (headings, lists, tables, multi-column reading order). This clearly distinguishes it from sibling tools like extract_tables and extract_statement.

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 PDF-to-Markdown conversion but does not explicitly state when to prefer this tool over alternatives such as extract_tables. It provides input-type guidance (text-layer vs image) and cost note, but no exclusions or comparative 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 readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds valuable context beyond that: it notes the need for 'a workspace/key for durable memory' (auth requirement), provides a concrete example URL, and explains the purpose of retrieved content (decisions, fixes, preferences). This goes beyond the 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?

The description is two sentences plus a compact example, with the main action stated first. Every sentence contributes: purpose, use case, example, and auth requirement. There is no redundancy or 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?

For a simple read-only retrieval tool, the description covers all essential aspects: what it retrieves, when to use it, how to filter, an example call, and an auth prerequisite. Combined with the complete input schema and output schema, the agent has sufficient information to invoke it correctly.

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

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

The input schema provides 100% coverage with descriptions for all three parameters (limit, query, project). The description only mirrors this by mentioning 'filtered by search query and/or project' and gives an example URL placeholder, but adds little beyond what the schema already states. 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 opens with 'Retrieve previously stored memories', which is a specific verb+resource pair that clearly distinguishes this from sibling tools like 'remember' (store) and 'forget' (delete). It also specifies the scope (filtered by query/project), leaving no ambiguity about the tool's function.

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 context: 'Call at the start of work on a known project to restore context'. It also describes the optional filters. However, it does not explicitly state when to use an alternative tool (e.g., 'remember' for storing), so it falls 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?

The description goes well beyond the readOnly/read-only annotations by explaining the integer-cent precision ('0.1 + 0.2 never invents a phantom difference') and the built-in arithmetic proof ('the listed differences are re-added and must equal the gap'). These are valuable behavioral details not present in annotations.

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

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

The description is front-loaded with a clear purpose and then provides useful details. The final sentence about VLOOKUP, while informative, is slightly rhetorical and could be seen as non-essential, but overall the structure is clean and purposeful.

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 moderate complexity (6 params, output schema present, rich annotations), the description fully covers the behavioral contract: what inputs do, how matching works, what the output looks like (three lists), and the verification step. No significant 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?

Input schema covers all six parameters with descriptions (100% coverage), so the baseline is 3. The description adds semantic meaning by explaining that the 'key' parameter is for row matching and 'amount' is compared in integer cents, plus clarifies the relationship between url/text inputs for each side.

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

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

The description clearly states the tool's function: 'Reconciles two sets of records' and details the matching and comparison logic, returning three specific lists. The title also frames it as an alternative to VLOOKUP, distinguishing it from sibling tools like diff_tables or merge_tables.

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 when-to-use scenarios: 'Use for month-end close, platform payouts vs orders, or any "these two numbers should agree and do not" problem.' It does not explicitly mention alternative tools or when-not-to-use, but the VLOOKUP comparison implies the manual alternative.

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

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

Annotations already declare the tool read-only, idempotent, and non-destructive. The description adds value by disclosing that it returns every match with positions and capture groups, and implies it accounts for escaping through JSON and shell. This is useful behavioral context beyond the structured 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 two sentences with no filler. The first sentence front-loads the action and output, the second gives a clear use case. Every word earns its place.

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

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

For a simple utility with a full output schema and robust annotations, the description provides adequate context: purpose, usage, and output highlights. It could reference regex flavor or error behavior, but these are not critical for this scope, so a slight deduction from 5 is warranted.

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 covers all three parameters with complete descriptions, including flags and the default value. The description adds no parameter-specific semantics beyond what the schema already provides, so the 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?

The description uses a specific verb ('Runs a regular expression') against a specific resource ('sample text'), and explicitly states the output (every match with position and capture groups, including named groups). This clearly distinguishes it from sibling text tools like diff_text or validate_json.

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 use the tool 'before wiring a pattern into code' and contrasts it with 'guessing whether the escaping survived'. This gives clear context for when to use it, though it does not name alternative tools or provide when-not-to-use scenarios, stopping 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?

Beyond the annotations (readOnlyHint=false, etc.), the description discloses important behavioral traits: write/persist semantics, small per-network pool for anonymous callers vs. large shared pool for key callers, cross-machine sharing, and the constraint against storing secrets/raw logs. This adds significant context beyond the structured 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 front-loaded with the core purpose, followed by key sharing behavior and a security constraint, then a practical example. Every sentence earns its place; it is dense with useful information without being verbose.

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 3-parameter tool with full schema coverage, an output schema, and annotations, the description covers purpose, usage guidelines, behavioral details, and security constraints. There are no critical gaps that would prevent an agent from using the tool correctly.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds value by providing a concrete content example ('Deploy key rotates monthly') and elaborating on content types, which reinforces the 'self-contained' requirement from the schema. It does not repeat all parameter descriptions but enriches understanding of expected content.

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-resource pair ('Persist a durable memory') and enumerates concrete examples (architecture decision, user preference, bug fix, discovery). It clearly distinguishes from the sibling 'recall' tool by framing this as storage, and the phrase 'recalls the same memories' reinforces the complementary relationship.

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 guidance by listing appropriate memory types (decision, preference, bug fix, discovery) and provides a clear exclusion: 'Do not store secrets or raw logs.' It also explains the key-based vs. anonymous usage scenarios, helping agents decide whether to send an AllRouter key 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?

Annotations already indicate read-only, idempotent, and non-destructive behavior. The description adds contextual details beyond annotations: it uses 'self-hosted Kroki' and returns a hosted URL for embedding, which informs the agent about the tool's backend and response format.

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, front-loaded with the purpose, and includes a concrete example. Every sentence provides useful information without 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 presence of an output schema and comprehensive parameter descriptions, the description is sufficiently complete. It covers purpose, supported formats, return behavior (URL), and even an example request. No critical aspects are missing for the agent to invoke the tool.

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

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

The schema covers all three parameters, so the baseline is 3. The description adds value by showing an example GET URL with 'source' and 'format' parameters, and by elaborating on the 'type' parameter's many options ('and 20+ more'). This helps the agent understand the parameter syntax and flexibility.

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

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

The description clearly states the tool's function: 'Turn diagram-as-code into an image' and lists supported languages (Mermaid, PlantUML, Graphviz/DOT, etc.). It distinguishes itself from sibling tools by describing a unique rendering capability and its output as a hosted URL.

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 usage—when you have diagram-as-code and want an image. It does not explicitly name alternatives or exclusions, but given the tool's unique scope among siblings, the implied usage is adequate.

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, idempotentHint, destructiveHint), the description adds a significant behavioral trait: it is a deterministic parser (sqlglot), not an LLM, ensuring identical output for identical input and precise syntax error reporting with line/column. This enriches the agent's understanding of the tool's behavior and reliability.

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 every clause earns its place—covering dialects, determinism, error handling, and use cases without 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 tool's complexity (many dialects), the description is complete: it states what it does, when to use it, and its deterministic/error behavior. An output schema exists, so return values are covered by that structured field. No critical information is missing for an agent to select and invoke this tool correctly.

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

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

Schema description coverage is 100%, so the baseline is 3. The description does not add parameter-specific semantics but does provide a broad list of dialects for the 'write' parameter, which slightly augments the schema examples. This is helpful but not a major addition since the schema already documents each parameter.

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

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

The description clearly states the tool converts SQL between dialects and enumerates a comprehensive list of supported dialects. The verb 'Convert' with the resource 'SQL statement' and the scope 'from one dialect to another' unambiguously identifies the tool's function, and it distinguishes itself from sibling tools by its specific SQL 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?

The description explicitly says 'Use it when migrating queries between databases or debugging dialect-specific syntax,' which provides clear context for when to use the tool. However, it does not mention alternatives or exclusions, though no sibling tool appears to compete with this functionality.

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, which cover safety. The description adds useful behavioral context beyond annotations: 'Returns the specific violations, not just true/false' and 'Checks required + types only — not full JSON Schema.' This clarifies output format and scope limitations, adding value beyond the structured metadata.

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

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

The description is three sentences, each earning its place: first states the core function, second describes the return type, third explains scope limitations and usage. It is front-loaded with the most important information and contains 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?

For a tool with 2 simple parameters, an output schema, and strong annotations, the description is complete. It explains what the tool does, what it returns, what it deliberately does not do, and when to use it. No critical information 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 description coverage is 100%, so both parameters (text and schema) are already documented in the schema. The description reinforces the optional nature of the schema parameter ('optionally that required keys are present') but does not add significant 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 clearly states the tool's function: 'Checks that text parses as JSON, and optionally that required keys are present with the right top-level types.' It also distinguishes itself from a full JSON Schema validator by explicitly saying 'not full JSON Schema.' This is specific and differentiates from siblings like json_yaml or regex_test.

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 usage context: 'Use before feeding generated JSON into something that will fail on it.' It also gives a clear when-not by stating it does not perform full JSON Schema validation. It does not name a specific alternative tool, but the guidance is actionable and sufficient for most cases.

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 it read-only and idempotent; the description adds that it aggregates dozens of engines with no tracking and returns titles, URLs, and snippets, providing useful behavioral context without contradicting 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 two sentences plus a concise example, front-loading the action and including only essential output and usage information.

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

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

For a simple two-parameter search tool with an output schema and read-only annotations, the description covers what it does, when to use it, what it returns, and an example, making it complete for an agent to invoke correctly.

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

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

Both parameters are fully described in the input schema (query and max_results), so the schema carries the semantic burden; the description does not add extra parameter-level detail beyond noting an example query.

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 searches the live web via SearXNG meta-search, names its output (titles, URLs, snippets), and distinguishes it as a no-tracking aggregator, making its purpose distinct from sibling tools like fetch_page or deep_research.

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 instructs to use when current information or sources are needed, giving clear context. However, it does not name alternatives or exclusions, so it falls short of full when/when-not guidance.

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

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

The description adds valuable behavioral context beyond annotations: it calls no model, costs nothing, never runs out of quota, and is deterministic. This complements the readOnly and idempotent hints and helps agents understand side-effects (none), cost implications, and reliability.

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

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

The description is four sentences, each with a distinct purpose: core function, recipe capability, determinism/cost, and usage guidance. It is front-loaded with the primary behavior and has no fluff or redundancy.

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

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

The description covers what the tool does, when to use it, key behavioral traits, and parameter semantics. Combined with the rich annotations and output schema, this gives an agent all necessary context to select and invoke the tool correctly.

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

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

The schema already documents the single 'task' parameter with examples. The description adds the crucial detail that the task can be in 'any language' and provides more example domains (invoices, bank statements, CSV). This enhances understanding of what the parameter accepts.

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 specific function: it takes a plain-language task and returns which server tools can do it, including example calls and multi-step recipes. This distinguishes it from sibling tools like list_models or ask_model, which either list tools or answer questions.

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 'Call this FIRST when you are not sure what this server offers,' giving a clear when-to-use. It also says 'instead of reading the whole catalogue and guessing,' which is a when-not-to-use, but it does not name a specific alternative tool like ask_model. 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.