AI NetCafé

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

Beyond the annotations (readOnly, idempotent, non-destructive), the description adds rich behavior: robots.txt is parsed per user-agent group rather than keyword-matched, specific files are checked, and text measurement excludes JavaScript execution. These details provide crucial context for agent decision-making and avoid common misinterpretations.

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

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

The description is two sentences, front-loaded with the primary action, and every clause adds specific value without redundancy. It avoids filler and precisely communicates scope and output.

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, an output schema exists (so return details are handled), and the description covers input, behaviors, output summary, plus a clear distinction from siblings. No critical context is missing; it is complete for an agent to use correctly.

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

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

The schema covers the single parameter (url) with a description and example, so baseline is 3. The description does not add further parameter semantics, but none are necessary given the schema's clarity and the tool's simple input.

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

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

The description opens with a specific verb+resource: 'Audit a URL for AI visibility' and enumerates concrete checks (robots.txt parsing per user-agent group, existence of llms.txt/sitemap/JSON-LD/canonical, text accessibility without JS). This clearly distinguishes it from sibling tools like fetch_page or web_search, which have different purposes.

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

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

The description clearly implies when to use this tool—when you need to audit a URL's AI accessibility. It does not explicitly name alternative tools or exclusions, but the context is unambiguous enough for an agent to select it appropriately alongside the sibling list.

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?

All annotations are false, so the description carries the full burden. It does disclose the cost aspect, which is a useful side effect. However, it does not explicitly mention that this triggers a live external API call, may incur charges before you see the cost, or that outputs can be non-deterministic. No contradiction with annotations is present.

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: two sentences plus a short example URL. It is front-loaded with the core function, and the example earns its place by demonstrating the parameter format. No filler or 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?

Given that an output schema exists, the description does not need to explain return values. It covers purpose, usage scenarios, and provides a concrete example, which is sufficient for a moderately simple tool. Minor gaps like rate limits or error behavior are not disclosed, but these are not critical for selection.

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

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

Schema description coverage is 100%, so the schema already documents all four parameters. The description adds an example URL showing how prompt and model map to a request, and indirectly mentions the default model, but it does not add substantive semantics beyond the schema. This 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 action: 'Send a prompt to one specific large language model and get the answer plus its exact cost in USD.' This is a specific verb+resource pair that distinguishes the tool from siblings like compare_models, list_models, and model_costs, especially by emphasizing 'one specific' model and the cost output.

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

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

The description gives concrete use cases: 'Useful when you want a second opinion from a different model, or a cheaper model for a bulk subtask.' This is clear context for when to use the tool, though it does not explicitly mention when-not or name alternative tools like compare_models or list_models.

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 offer no safety info (all false), so the description carries the burden. It transparently discloses async behavior ('Async — poll with check_job'), latency ('~1-2 minutes'), deployment details (managed hosting with HTTPS), and listing. It does not mention failure modes or resource limits, which would warrant a 5.

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

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

The description is three sentences long, front-loaded with the primary action and outcome, then usage guidance, and finally an async note with a concrete example. Every sentence earns its place with no unnecessary filler or repetition.

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

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

Given the availability of an output schema, the description appropriately focuses on the lifecycle: what it does, what you get, time estimate, async workflow, and ideal use cases. It covers the key aspects an agent needs to decide and invoke correctly, including an example call.

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

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

Schema descriptions cover 100% of parameters, so the baseline is 3. The description adds only a single example invocation for the 'description' parameter and does not elaborate on 'name', 'refine', or 'visibility'. It does not meaningfully enhance the schema's parameter explanations.

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 one plain-language description into a LIVE single-page web tool' and details the outcome (code generated, deployed to HTTPS hosting, listed, public URL). It distinguishes itself from siblings by specifying its niche ('Best for tool-style apps') and the async polling pattern with 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?

Provides explicit usage context: best for 'calculators, converters, checklists, timers, generators, small games' and instructs to poll with check_job after invocation. However, it does not explicitly say when not to use or name alternative tools like get_app for existing apps, so it lacks explicit 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?

The description discloses key behaviors beyond the annotations: it is a polling endpoint with a recommended poll interval, it returns status/result with special fields (retry_after_seconds, next_action, structured_result), and it references the job-starting tools. This adds valuable context that annotations alone do not convey, such as the expected polling loop and preference for structured_result.

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 yet information-dense. Each sentence adds value: purpose, polling guidance, response handling, and an example endpoint. It is well-structured, front-loaded with the core purpose, and contains no filler or repetition.

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

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

Given that this is a polling tool for async jobs, the description covers all essential aspects: what triggers the job, how to poll, what to do while pending, and how to handle completion. The existing output schema likely documents return values, so the description doesn't need to repeat them. It is complete for an agent to correctly use 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 already describes job_id as 'The job_id returned when the task was started,' which is clear. The description adds an example URL showing how to embed the job_id, reinforcing that the value comes from a job-starting tool. This is a modest improvement over the schema baseline, which would be 3, so a 4 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: 'Get the status or result of a job started by deep_research, translate_pdf, or make_slides.' It uses a specific verb ('get') with a well-defined resource ('job'), and explicitly names the sibling tools that create jobs, distinguishing it from other tools in the list.

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

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

The description provides explicit usage instructions: 'Poll every 15-30 seconds until status is "done" or "error"' and 'follow retry_after_seconds and next_action; when complete, prefer structured_result when present.' This gives clear when-to-use and how-to-use guidance, including response handling, which is more than sufficient.

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

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

Annotations already declare the tool as read-only, idempotent, and non-destructive. The description adds valuable behavioral context beyond annotations: it uses a real mainland-China network egress and reports specific metrics (HTTP status, latency, DNS resolution), which is not inferable from annotations alone. 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 two sentences, front-loaded with the core action, and every word adds value. It efficiently conveys the purpose, the measurement results, and why this tool is unique without any 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?

Given the tool's simple single-parameter interface, explicit output schema, and clear annotations, the description is fully complete. It covers the operational context (mainland-China egress), the question it answers, and the key advantage over alternatives, leaving no important gaps for an AI agent to resolve.

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 provides 100% coverage for the single parameter 'url' with a clear description ('Full URL to test, e.g. https://example.com'). The tool description adds minimal extra parameter semantics, only implicitly suggesting that the URL should be a complete URL. This meets the baseline for high schema coverage but doesn't 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 states a specific verb ('Fetch') and resource ('a URL from a real mainland-China network egress'), clearly differentiating it from general-purpose fetching tools like fetch_page. It also explains the output (HTTP status, latency, China DNS resolution), making the tool's purpose unambiguous.

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

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

The description explicitly frames when to use the tool ('Answers "is my site/API usable from China?"') and contrasts it with a VPS abroad, implying this is the only way to get China-specific measurements. It doesn't explicitly name sibling tools as alternatives, but the context is clear enough for an AI agent to select it appropriately.

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 annotations by disclosing the return format ('Returns the cleaned CSV plus exactly what changed: rows in, rows out, duplicates removed, cells trimmed per column') and an important integrity check ('The row arithmetic is verified in code — if in − removed ≠ out, the response says so'). It also adds contextual details about handling Chinese full-width whitespace and various empty-value representations, which are not present in 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 slightly longer than strictly necessary but every sentence adds value. It front-loads the main purpose, then details operations, return behavior, and a use case. The structure is logical and readable, though it could be tightened without losing critical 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 tool with 6 parameters, an output schema, and read-only/idempotent annotations, the description is highly complete. It explains what operations are available, what the output reports, and even the self-verification mechanism. The presence of an output schema means it doesn't need to detail return values, but it does anyway, adding a layer of confidence for the agent.

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

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

With 100% schema description coverage, the schema already documents each parameter. The description adds extra meaning by illustrating the 'unify_blank' operation with examples (NA / null / - / 无) and by explaining the split_column and wide_to_long operations in a user-oriented way. This enriches the ops parameter beyond the schema's brief listing.

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 with a specific verb and resource ('Tidies a spreadsheet export') and enumerates concrete operations (removes duplicate rows, trims whitespace, unifies blank values, drops empty rows/columns, splits columns). This distinguishes it from sibling tools like diff_tables or merge_tables, which focus on comparison or combining rather than cleaning and reshaping.

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.' This is explicit and contextual. However, it does not explicitly mention alternatives or when not to use the tool, so it falls just short of the 5-point threshold.

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?

All annotations are false, so the description carries the full burden. It adds meaningful behavioral context: runs in parallel, returns real measured cost/latency, and the example URL shows a GET-style invocation. It doesn't explicitly disclose external API calls or charges, but 'real measured cost' implies them.

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

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

Two dense, information-rich sentences plus a useful example URL. No fluff or repetition. The most important information (what it does and when to use it) is front-loaded.

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

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

The description covers purpose, use case, and parallel execution. With an output schema present and full parameter coverage, the missing pieces (explicit side-effect disclosure, failure modes) are minor. It's complete enough for an agent to select and invoke confidently.

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

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

Schema description coverage is 100% and each parameter has a clear description. The description doesn't add parameter-level details beyond what the schema already provides, so the baseline score of 3 is appropriate.

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

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

The description clearly states the tool runs one prompt across multiple LLMs in parallel and returns answers side by side with measured cost and latency. This specific verb+resource combination distinguishes it from sibling tools like ask_model (single model) and list_models (catalog).

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

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

It explicitly says this is 'useful before committing a long job to an expensive model', providing a concrete use case. It doesn't name alternatives or exclusions, but the purpose is so distinct that an agent can infer when to use it over siblings.

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

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

Given annotations only give false hints, the description carries the transparency burden and adds meaningful behavior: it only notifies when results change, nothing is kept running locally, a workspace token is required, and pipeline runs leave proof-carrying work orders. It does not mention failure/retry behavior or notification payload shape, but it provides substantial 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 main purpose and uses a compact semicolon-separated kind list rather than prose blocks. It is moderately long because it covers four distinct kinds, but every sentence contributes useful guidance.

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 4 parameters, 2 required ones, an output schema, and minimal annotations, the description adequately covers scheduling behavior, kind-specific selection, notification-on-change semantics, and the auth requirement. It leaves some gaps around pipeline input semantics and failure handling, but it is otherwise complete enough for selection and invocation.

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

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

Schema description coverage is 100%, so the baseline is 3; the description does add some context by tying 'input' to URL/question and by explaining pipeline relative to create_pipeline. However, it does not fully define what the pipeline kind expects in 'input' and adds little beyond the schema for notify_url or interval_seconds.

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-plus-resource statement ('Create a task that runs on a schedule') and then enumerates the four task kinds with one-line objectives each. It clearly distinguishes create_task from siblings like delete_task and list_tasks, and from create_pipeline by describing pipeline as scheduling an existing production line.

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 kind-by-kind guidance (watch_page, daily_answer, watch_reachability, pipeline) and communicates when to use the managed/scheduled model ('you do not keep anything running'); it also explains the workspace token need for later management. It does not explicitly contrast this with one-off sibling checks such as china_reachability, so it stops short of a 5.

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

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

Annotations already mark destructiveHint and readOnlyHint, but the description adds that run history is also removed and that the task is stopped, which is useful context beyond the annotations. No contradiction found.

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

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

A single, front-loaded sentence that conveys the core action and scope with no filler 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 with one parameter and an output schema. The description covers the primary effect and a behavioral nuance (run history removal). With annotations handling safety expectations, this is adequately complete for the tool's complexity.

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

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

Schema coverage is 100% with a clear description 'From list_tasks.' The tool description itself adds no parameter details, but the schema fully documents the single parameter, so baseline 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 specific verbs 'Stop and remove' with a clear resource 'scheduled task and its run history', distinguishing 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?

The description clearly implies the tool is used for deleting a task, but it does not explicitly state when to use it versus alternatives or mention exclusions such as the task needing to exist. The schema hint 'From list_tasks' is helpful but lives outside the description.

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. The description adds behavioral context beyond these by explaining the exact matching semantics and that it reports which column differs and both values. No contradictions with annotations.

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

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

The description is two sentences, front-loaded with the core purpose, then followed by usage guidance. Every sentence earns its place, with no filler or repetition.

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

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

The tool has an output schema, so return values are already specified. The description provides all necessary operational context: the matching algorithm, output categories, and appropriate use cases. It is fully complete for the tool's complexity.

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

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

Schema description coverage is 100%, with each parameter clearly described (e.g., 'Column that identifies a row', 'Link to the first CSV'). The tool description does not need to add parameter-level detail since the schema already does the heavy lifting.

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

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

The description clearly states the verb 'Matches rows across two CSVs on a key column' and specifies the exact three outputs (keys only in A, only in B, and mismatches with column names and values). It also distinguishes itself from the sibling reconcile_ledger by explicitly noting it needs no amount column.

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 'Unlike reconcile_ledger this needs no amount column' and lists appropriate use cases ('name lists, inventory counts, permission tables, and any "these two exports should match" check'). This provides clear when-to-use guidance and names an 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 mark the tool readOnly and idempotent. The description adds valuable behavioral context by disclosing the LCS algorithm and emphasizing that results are deterministic ('not guessed by a model'). This goes beyond the structured 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?

Two sentences, front-loaded with the primary outcome, then the use case and rationale. Every sentence contributes essential information with zero 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 two-string tool with full schema coverage, rich annotations, and an output schema, the description provides complete context: what it returns, how it computes it, and when to use it. No additional explanation of return values is needed given the output schema.

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

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

Schema coverage is 100%, with each parameter explicitly described as 'first (before) text' and 'second (after) text'. The description reinforces the directional comparison but adds little new parameter-level meaning beyond the schema already provides.

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

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

The description opens with 'Returns which lines were added and which were removed, with line numbers', clearly specifying the verb and output. The phrase 'computed with a longest-common-subsequence, not guessed by a model' and title 'line by line' differentiate it from sibling tools like diff_tables and from ad-hoc LLM comparison.

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: 'Use to compare two versions of a config, a document, or any command output'. It also names the alternative to avoid: 'instead of asking an LLM to eyeball two blobs and hoping it notices', which gives both a positive use case and a clear avoid-this-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?

Beyond the annotations (read-only, idempotent), the description discloses important behaviors: arithmetic validation (net+tax=gross), independent batch total checking, flagging of misread rows with exact differences, and deliberate omission of batch totals for mixed currencies. It also explains CSV encoding for Excel compatibility. No contradictions with annotations.

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

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

The description is compact, front-loaded with purpose, and every sentence adds value: purpose, validation details, edge-case handling, and output format. No fluff or repetition of 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?

Given a single parameter, high schema coverage, and the presence of an output schema, the description fully covers input format, validation logic, edge cases, and output encoding. It provides enough context for an agent to select and invoke the tool correctly without needing additional information.

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

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

The schema already provides full coverage for the 'urls' parameter. The description adds meaning by specifying accepted input types (PDF or page images) and reinforcing the 20-item limit, which goes slightly beyond the schema but is not redundant.

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: take up to 20 invoice URLs and return a ledger-ready table with specific fields (number, date, seller, buyer, net/tax/gross, currency). This distinguishes it from siblings like extract_statement or extract_tables, which target different document types.

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 use case (invoice extraction) and provides constraints (up to 20 URLs, PDF or page images, mixed-currency behavior). It does not explicitly name alternative tools or state when not to use it, but the context is clear enough for an agent to decide.

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 reveals the reconciliation logic, exact difference reporting, first breaking row, and the text-layer-only constraint. This adds substantial behavioral context not already covered by 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 paragraph of three sentences, each carrying essential information: extraction, reconciliation check, and limitations. It is front-loaded with the core action and avoids redundancy. No irrelevant details.

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

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

With only one parameter and an output schema present, the description fully explains the tool's scope: input format, processing, validation, expected output (JSON+CSV, difference, break row), and known limitation (scanned images). It is complete for the tool's complexity.

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

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

The schema only says 'Public URL of the statement PDF.' The description adds that the URL must point to a text-layer bank statement or transaction PDF, clarifying the content expectations. Since schema coverage is 100% and the description enriches the parameter meaning, a 4 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 ('Turn a bank statement or transaction PDF into a clean transaction table') and resource scope, distinguishing it from siblings like extract_tables (generic table extraction) and csv_to_qbo (CSV conversion). It also names the output formats (JSON + CSV) and the reconciliation check.

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

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

The description gives clear context (for bank statement processing) and an explicit exclusion ('Text-layer PDFs only (scanned images not yet supported)'). It does not name an alternative tool or explicitly say when not to use it beyond the scanned-image limitation, 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?

Beyond the readOnlyHint and idempotentHint annotations, the description discloses that uncertain rows are flagged rather than guessed, which is a key behavioral detail affecting output trust. It also explicitly limits input to 'text-layer PDFs only', a critical constraint not captured by annotations.

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

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

The description is three succinct sentences: core function, optional parameter use case, and a caveat. It is front-loaded with the primary action and no redundant wording. Every sentence contributes useful 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?

Given the tool has only two parameters, both fully described, an output schema, and annotations covering safety, the description covers purpose, optional behavior, and a key constraint. It appropriately relies on the output schema for return value details, so no additional explanation is needed.

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

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

Schema coverage is 100% with descriptions for both parameters, providing a solid baseline. The description adds semantic meaning to 'fields' by explaining its purpose in aligning differently-named headers into a consistent table, going beyond the schema's generic 'target columns' description. The 'url' parameter is self-explanatory.

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

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

The description begins with a specific verb and resource: 'Extract tables from a PDF into structured rows (JSON + CSV).' It clearly distinguishes the tool from siblings by highlighting 'schema alignment' and 'text-layer PDFs only', which narrows its scope uniquely among similar tools like 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 provides a clear context for use: extracting tables from PDFs, with an optional 'fields' parameter to force consistent columns when documents have varying headers. It also states the text-layer restriction, which serves as a prerequisite. However, it does not explicitly name alternative tools or state when not to use this tool, but the guidance is sufficient for basic 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 establish read-only, idempotent, non-destructive behavior. The description adds value by mentioning Crawl4AI rendering and JS-handling capability, as well as the clean Markdown output, which are useful behavioral traits not covered by 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 concise sentences cover purpose, usage, and an example. Front-loaded with the core action and no redundant information.

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

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

For a simple one-parameter tool with an output schema, the description is complete: it specifies input, output format, rendering behavior, and a common use case. No gaps for the intended scope.

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 fully describes the url parameter, so the baseline is 3. The description adds the constraint 'public' and provides a concrete example, slightly enhancing the schema's semantic 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 fetches a public URL and returns LLM-ready clean Markdown. It distinguishes itself from sibling tools like web_search by specifying its role as a post-search reader or page ingestion tool.

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

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

Explicitly advises to use after web_search and for ingesting a page for analysis, providing clear context. However, it lacks explicit when-not-to-use guidance or alternative tool mentions beyond the sequential relationship with web_search.

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, lowering the burden. The description adds value by enumerating the exact details returned (what it does, usage, benchmark scores, source repository, URL) and provides an example endpoint, which is useful behavioral 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?

The description is two sentences, front-loaded with the core purpose, and includes a concrete example without extraneous information. 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?

With a single parameter, an existing output schema, and thorough annotations, the description fully covers what the agent needs to know. The example also clarifies URL construction, making the tool self-contained.

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 slug parameter with a description including its source (list_apps). The description's example reiterates this but adds no new semantic meaning beyond what the schema provides.

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

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

The description clearly states it retrieves full details of one hosted application, naming specific content areas (what it does, usage, benchmark scores, repo, URL). It distinguishes from list_apps by focusing on a single application rather than a list.

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

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

The example explicitly references list_apps to obtain the slug, implicitly guiding the agent to list first then get details. However, it doesn't explicitly state when not to use this tool or mention alternative tools for other scenarios.

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 establish readOnly, idempotent, and non-destructive behavior. The description adds context about the specific data returned (return value, result change, cost), which is valuable beyond annotations. It does not discuss rate limits or pagination details, but these are not critical for this read-only tool.

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

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

The description is a single sentence, front-loaded with the core purpose, and every word adds value. It is concise and well-structured.

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

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

This is a simple read-only tool with complete schema documentation, safety annotations, and an output schema. The description fully covers what the tool does and what it returns, so nothing essential is missing.

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

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

Schema description coverage is 100%; both parameters have clear descriptions. The main description implies the task_id parameter but does not add significant semantic detail beyond the schema. Baseline 3 is appropriate.

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

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

The description clearly states the tool retrieves recent runs of a scheduled task, specifying the output details (returned value, change status, cost). This distinguishes it from sibling tools like check_job or list_tasks, making the purpose unambiguous.

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

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

The description provides clear context: it is for inspecting runs of a specific scheduled task identified by task_id. It does not explicitly name alternatives or exclusion criteria, but the context is strong enough to infer when to use it.

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

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

While annotations already indicate readOnlyHint and destructiveHint, the description adds valuable behavioral context: auto-detection of direction and safe error handling (returns parser message instead of silently producing wrong output). This goes beyond the structured data.

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

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

The description is four sentences, each serving a purpose: action, auto-detection, error behavior, and use cases. It is front-loaded and free of redundancy.

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

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

For a simple conversion tool, the description covers the operation, auto-detection, error handling, and example use cases. With output schema present and annotations covering safety, nothing significant is missing.

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

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

Schema coverage is 100%, so baseline is 3. The description adds meaning by explaining that 'to' is optional because auto-detection handles the direction, and it clarifies that 'text' contains the content. This supplements the schema effectively.

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 'Converts JSON to YAML or YAML to JSON' with a specific verb and resource. It also distinguishes itself from sibling tools like validate_json by focusing on conversion rather than validation.

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: 'Use when a config, a CI file, or a Kubernetes manifest needs to be in the other format.' It does not explicitly mention alternatives, but the context is clear and sufficient 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 readOnly/idempotent, but the description adds crucial context: the signature is NOT verified, the response explicitly says so, and decoding should not be treated as proof. This goes beyond basic annotations and is valuable for safe usage.

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: the first states the core function, the second adds the critical limitation, and the third reinforces safe usage. No wasted words and information is front-loaded.

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

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

Given the simple one-parameter schema and presence of an output schema, the description fully covers the tool's behavior including output contents (timestamps, seconds remaining) and the security caveat. It is complete for a debugging 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 already provides 100% coverage with a clear description for the single token parameter. The description does not add further parameter-level detail, 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 decodes JWT header and payload, reports timestamps and seconds remaining, and explicitly notes the signature is not verified. This is specific and distinguishes it from any other sibling tool.

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 decoding is fine for debugging a token you already hold, and warns never to treat values as proof, directing verification to a service with the secret. This provides clear when-to-use and when-not-to-use context without needing a named sibling.

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/non-destructive, so the bar is lower. The description adds valuable context: apps are pre-configured and normally require local setup, which explains the hosting environment and reduces user surprise. It also shows an example endpoint. It does not contradict annotations and provides extra behavioral context beyond the structured 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 description is well-structured, front-loaded with the core action, then adds context, usage guidance, and an example. Every sentence is informative — there is no fluff. The length is justified given the need to disambiguate from several siblings and provide clear usage rules.

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 a single optional parameter, full schema coverage, strong annotations, and an output schema present, the description is complete for an agent to select and invoke the tool. It covers purpose, when to use, when not to use, and an example, 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 description coverage is 100% (the 'category' param is described as an optional filter with examples). The description does not add any parameter-specific meaning beyond the schema, but since the schema already fully covers it, a baseline 3 is appropriate. No extra detail is needed here.

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 ('List') and resource ('open-source AI applications hosted and ready to run at AI NetCafé'), and differentiates from siblings like list_models (models vs apps) and get_app (specific app details) by emphasizing discovery of runnable tools. The concrete use cases (translating PDF, generating slides) reinforce 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?

The description explicitly tells when to use the tool ('Use this to find a tool for a task like...') and provides explicit exclusions with named alternatives ('Do not call this first when the request already clearly matches compare_models, translate_pdf, deep_research, or make_slides; call that task tool directly'). This is excellent guidance 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?

The annotations already declare the tool as read-only, idempotent, and non-destructive. The description adds useful behavioral context by showing an example HTTP GET request and stating that it lists 'every model', clarifying the scope and method. It does not contradict the annotations and supplements them with a concrete endpoint example.

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

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

The description is a single sentence with a clear main clause, a purpose clause, and an example. It is concise, front-loaded with the action, and every part adds value without unnecessary words.

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

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

The tool is simple (one optional parameter) and has an output schema. The description explains what the tool returns and why it would be used, which is sufficient for the tool's complexity. No additional information is needed.

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

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

The schema description covers the 'tier' parameter fully, including enum values and their meanings. The description does not add any parameter-specific details, but since schema coverage is 100%, the baseline score of 3 is appropriate.

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

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

The description clearly states the verb 'List' and the resource 'models callable through AI NetCafé', and specifies the return value as input/output price per million tokens. It is specific and useful, but it does not explicitly differentiate from the sibling tool 'model_costs', though the mention of 'every model' and the pricing detail help distinguish it.

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 usage context: 'so you can pick by cost as well as capability.' This tells the agent when to use this tool. However, it does not mention alternatives or exclusions, such as when to use 'model_costs' instead, which would have made the guidance stronger.

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. The description adds behavioral context by specifying the exact fields returned (next run, run count, cost), which goes beyond the structured annotations. No contradictions, but it could mention pagination or sorting if applicable.

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

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

A single, front-loaded sentence that conveys all essential information without any filler. Every word earns its place.

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

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

With no parameters and an output schema provided, the description is sufficient. It explains what the tool does and what information it returns, making it complete for its simple scope.

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 schema coverage is 100% (vacuously). The description does not need to explain parameters. Per the rubric, 0 params yields a baseline of 4, and the description adds no unnecessary parameter details.

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 'Show' and specifies the exact resource ('scheduled tasks on this workspace') and the information included (next run, run count, cost). This clearly distinguishes it from siblings like get_task_runs (individual task runs) and create_task/delete_task (mutations).

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 the tool: to list scheduled tasks and see their run details and costs. It does not explicitly name alternatives or exclusions, but the context is unambiguous enough. A slight deduction for not mentioning when not to use it (e.g., for individual task runs).

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 safe annotations (readOnly, idempotent), the description discloses key behavioral traits: columns are unioned, missing columns contribute blanks, rows never shift silently, and row counts are verified programmatically. This is rich, non-obvious context that helps an agent predict tool behavior.

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

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

Three sentences efficiently cover function, detailed behavior, and use cases without redundancy. The first sentence front-loads the core action, and every subsequent sentence adds value.

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

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

With an output schema present, the description doesn't need to explain return values. It covers inputs, constraints, merging semantics, and appropriate scenarios comprehensively, leaving no obvious gaps for an agent to resolve.

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 with clear descriptions, but the description adds a critical constraint (up to 20 CSVs) and clarifies the purpose of the merge operation. This goes beyond the schema's basic field explanations.

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 unioned columns, which is a specific verb+resource action. It distinguishes itself from sibling tools like 'clean_table' or 'extract_tables' by focusing on merging and column-union behavior, reinforced by the title.

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 ('monthly exports, per-store sheets, or any set of files with the same subject but drifting headers'), making it clear when to apply. It doesn't explicitly name alternative tools or exclusions, but the context is strong enough to guide an agent.

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

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

Annotations already declare readOnly and idempotent, so the safety profile is known. The description adds crucial behavioral context: the measurement method (identical prompt across models), why costs differ, and the non-comparability of production_mixed. This goes beyond annotation hints and helps the agent trust the data.

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

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

The description is fairly concise for the amount of context packed in, covering purpose, methodology, dataset comparability, and licensing. It's slightly dense and includes an example URL, but every clause serves a purpose. Not maximally succinct, but 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 there's a single optional parameter with full schema coverage and a documented output schema, the description completes the picture by explaining what the data represents, how it was measured, and how to interpret it. The agent can correctly select and invoke this tool with confidence.

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

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

The single parameter 'days' is fully described in the schema (100% coverage), so the description doesn't need to add detail. Baseline 3 applies. The description does not conflict or add extra meaning beyond the schema, but also doesn't need to.

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 the tool measures the actual per-call cost on each model, using the specific resource 'model costs'. It distinguishes from sibling tools like compare_models or list_models by focusing on measured cost data, with datasets standard_bench and production_mixed clearly named.

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

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

Explicitly tells the agent when to use this data: 'use that to choose a model before bulk work'. It also warns that production_mixed is NOT comparable across models, giving clear guidance on how to interpret the two datasets and avoid misuse.

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

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

Annotations already provide read-only and idempotent hints, lowering the transparency bar. The description adds valuable behavioral context: cost differences for text-layer PDFs vs. images, use of a vision model for images, and multi-column reading order handling. This goes beyond what annotations state.

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

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

The description is two sentences, front-loaded with the core purpose and followed by efficiency/processing details. Every word contributes meaning 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?

Given the existence of an output schema (which covers return values), the description sufficiently addresses scope, input types, output characteristics, and processing nuances. It is complete for the tool's complexity.

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

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

Schema coverage is 100%; the url parameter description already explains PDF and page image formats. The description reinforces this by mentioning both input types but does not add novel parameter semantics 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 a specific verb ('Convert') with a resource ('PDF or scanned page image') and output ('clean Markdown'), while explicitly noting preservation of headings, lists, tables, and multi-column reading order. This distinguishes it from siblings like extract_tables and fetch_page.

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

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

The description provides clear context on when to use the tool (for PDFs/scanned pages) and differentiates between text-layer PDFs (cheaper, exact) and images (vision model). It does not explicitly name alternatives but implies the appropriate use case, which is strong guidance.

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

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

The annotations already declare readOnlyHint, idempotentHint, and destructiveHint, covering the safe read nature. The description adds the prerequisite 'needs a workspace/key for durable memory' and the notion of durable storage, which goes beyond the annotations. No contradictions 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 two concise sentences plus an illustrative example. It front-loads the core function, then provides use case and a practical URL. Every sentence adds value with no redundancy.

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

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

Given the tool's simplicity (3 optional params, no required fields), the output schema covers return values, and annotations cover safety. The description adds the auth prerequisite and usage context, making it sufficiently complete for an agent to invoke correctly.

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

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

Schema coverage is 100% and all parameter descriptions are present, so the description only loosely summarizes the filtering options. The example URL adds a practical illustration, but it does not materially enhance understanding beyond what the schema already 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 uses the specific verb 'Retrieve' with a clear resource 'previously stored memories' and states the optional filters. It distinguishes itself from siblings like remember and forget by being the retrieval counterpart, and the title aligns with the description without being tautological.

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: 'Call at the start of work on a known project to restore context.' This gives clear context for appropriate usage, though it does not explicitly exclude alternatives or name sibling tools, 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 readOnly, idempotent, and non-destructive, and the description adds meaningful detail: amounts are compared in integer cents to avoid floating-point phantom differences, and the response proves correctness by re-adding differences to equal the total gap. This goes well 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 four sentences, each earning its place: function, precision handling, proof mechanism, and usage scenarios. It is front-loaded with the action verb and remains free of 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?

The tool has an output schema and strong annotations, and the description covers all necessary context: what it does, how it handles numeric precision, what the output looks like (three lists plus proof), and when to use it. No important behavioral aspect 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 all 6 parameters, so the baseline is 3. The description adds semantic context by explaining that 'key' is the column to match on, 'amount' is the column to compare, and url_a/url_b/text_a/text_b represent the two sides (e.g., books vs statement). This reinforces the schema descriptions and gives real-world meaning.

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 'Reconciles two sets of records' and specifies exactly what happens: matching rows on a key column, comparing an amount column, and returning three named lists. It clearly distinguishes from sibling diff tools by emphasizing the arithmetic proof element.

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 states concrete use cases ('month-end close, platform payouts vs orders, or any "these two numbers should agree and do not" problem') and frames it as the automated replacement for manual VLOOKUP/groupby. However, it does not explicitly name sibling tools as alternatives or list when not to use it, so it stops short of a 5.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=false, idempotentHint=true, destructiveHint=false, covering safety. The description adds behavioral detail about the return output: every match with position and capture groups, including named groups. This goes beyond annotations and provides useful context 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?

Two sentences, each earning its place. The first states the core action and output; the second gives a concrete usage scenario. No redundant phrasing or padding.

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 modest complexity, the description covers purpose, usage, and returns. An output schema exists to document the return structure, and annotations cover side-effect safety. The description is sufficient 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 input schema provides descriptions for all three parameters (pattern, text, flags) with 100% coverage, including notes like 'without surrounding slashes' and default for flags. The description does not need to add much parameter-level detail, so a baseline of 3 is appropriate. It does hint at escaping concerns, but that's usage guidance, not 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 starts with a specific verb ('Runs') and identifies the resource ('regular expression against sample text') and outcome ('returns every match with its position and capture groups'). The title 'Does this regex match — and what does it capture?' reinforces the purpose and distinguishes this from sibling tools like diff_text or extract_*.

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: 'Use before wiring a pattern into code, instead of guessing whether the escaping survived the trip through JSON and the shell.' It provides clear context and a concrete use case, though it does not name an alternative tool explicitly. This is sufficient guidance for an AI agent.

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

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

The description discloses significant behavioral nuance beyond the annotations: anonymous callers get a small per-network pool, while authenticated callers with an AllRouter key get a large cross-machine/cross-agent shared pool. It also warns against storing sensitive data. This is rich contextual detail that annotations alone would not convey.

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

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

The description is three tight sentences plus an example, front-loaded with the primary purpose, then key behavioral distinctions, then a critical exclusion. Each sentence adds essential 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?

The description covers the tool's primary use, edge cases (anonymous vs. keyed callers), cross-machine sharing, and exclusions. The output schema and parameter schema already cover return values and parameter details, so the description fills the remaining behavioral and usage context comprehensively.

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 new semantic meaning about the parameters; it merely repeats the content length and kind enum that are already in the schema. The example illustrates usage but does not extend parameter understanding.

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 phrase 'Persist a durable memory' and enumerates concrete use cases (architecture decision, stable user preference, verified bug fix, important discovery). This clearly distinguishes the tool from sibling tools like recall (retrieval) and other task/storage 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 clear when-to-use guidance by listing appropriate content types and explicitly states a limitation ('Do not store secrets or raw logs'). However, it does not explicitly direct users to the sibling tool 'recall' for retrieval or mention alternatives, so it falls short of full explicit when/when-not/alternative guidance.

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

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

Annotations already declare the tool as read-only, idempotent, and non-destructive. The description adds behavioral context beyond annotations by specifying that it returns a hosted URL and supports a self-hosted Kroki backend, which helps the agent understand the output format and service dependency.

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 (two sentences plus an example) and front-loaded with the primary verb and purpose. Every sentence adds value, and the example is practical. There is no fluff or repetition.

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

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

Given the tool's simplicity (3 params, 1 required, output schema present), the description is complete for an agent to select and invoke it correctly. It explains the return format, supported diagram languages, and embedding use case—covering all necessary 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%, with each parameter having a description. The tool description adds minimal additional meaning—only an example of the 'source' parameter and a note on format types, which are already present in the schema. The schema carries the heavy lifting.

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

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

The description clearly states the tool's function with a specific verb ('Turn diagram-as-code into an image'), lists supported formats (Mermaid, PlantUML, Graphviz/DOT, C4, Excalidraw, etc.), and explains the return value (a hosted SVG/PNG URL). This distinguishes it from sibling tools, which focus on text, data, or model operations.

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: it is for converting diagram-as-code into an image for embedding in Markdown/HTML. It offers an example GET request but does not explicitly exclude alternatives or compare to other tools. Since sibling tools are thematically distinct, the intended usage is obvious.

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, not destructive), the description adds valuable behavioral context: it is a deterministic parser (sqlglot), not an LLM, guaranteeing same input/output, and reports syntax errors with exact line and column. This transparency helps set expectations for users. It doesn't cover every edge case but provides meaningful insight.

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

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

The description is three sentences, front-loaded with the purpose, then crucial behavioral notes, then usage context. Every sentence earns its place with no redundancy or filler. It is concise and well-structured.

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

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

Given the presence of an output schema, a well-annotated safety profile, and a comprehensive parameter schema, the description covers the essential aspects: what it does, when to use it, and its deterministic error-reporting behavior. For a conversion tool, this is complete and leaves little room for confusion.

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

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

The schema already provides 100% coverage with descriptions for all parameters, including examples. The tool description lists dialects and mentions determinism but adds no additional parameter-specific semantics beyond what the schema provides. Baseline of 3 is appropriate as the schema does the heavy lifting.

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

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

The description clearly states the tool's function with a specific verb ('Convert') and resource ('SQL statement'), and lists numerous target dialects, making its scope unmistakable. It distinguishes itself from sibling tools by focusing on dialect conversion, which none of the siblings do.

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

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

The description explicitly states when to use the tool ('when migrating queries between databases or debugging dialect-specific syntax'). It does not mention when not to use it or alternatives, but given the tool's unique role, this is a minor gap. The guidance is clear and actionable.

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

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

Beyond the read-only/idempotent annotations, the description discloses important behavior: it returns specific violations rather than a boolean, and explicitly states the scope (required + types only) while disclaiming full JSON Schema support. This adds substantive context not captured by 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?

Four sentences, each with a distinct purpose: what it does, what it returns, its limitations, and when to use it. No wasted words; the information is front-loaded and efficiently delivered.

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 a full output schema, so the description does not need to explain return values. It covers the essential behavioral aspects (parsing, optional key/type checks, violation reporting, and scope limitations) adequately for an agent to use it correctly.

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

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

The schema already provides 100% coverage for both parameters, with descriptions for 'text' and 'schema' including details about required[] and properties[].type. The description adds only a mild restatement of the schema's functionality ('required keys are present with the right top-level types'), not significantly new meaning, so it meets the baseline of 3.

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

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

The description uses a specific verb ('Checks that text parses as JSON') and clearly states the resource (text) and optional key/type validation. It distinguishes itself from siblings like json_yaml by specifying it validates JSON and explicitly scopes to required keys and types, not full JSON Schema.

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 an explicit use case ('Use before feeding generated JSON into something that will fail on it') and a clear limitation ('not full JSON Schema'), implying when not to use it. However, it does not name an alternative tool for full schema validation, so it falls short of the full when/when-not/alternatives guidance.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is established. The description adds context about being self-hosted, aggregating dozens of engines, no tracking, and returning titles/URLs/snippets, which enrich the behavioral understanding 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 two sentences plus an example, with the main verb 'Search' upfront. No redundant wording; the example is useful.

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 annotations covering safety and the description covering purpose, usage, and return format, the tool is adequately specified. Given the output schema is indicated (though not shown), the description doesn't need to elaborate further. Could mention error handling, but not necessary 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 schema already describes both parameters with 100% coverage. The description's example shows usage but does not add new semantic details about parameters, so baseline 3 is appropriate.

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

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

The description starts with 'Search the live web' – a specific verb and resource – and 'meta-search' clarifies it aggregates dozens of engines. This clearly distinguishes it from sibling tools like fetch_page or deep_research by focusing on live web search.

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

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

It explicitly says 'Use when you need current information or sources,' giving clear context for when to employ it. However, it does not mention exclusions or alternatives, 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?

Beyond the readOnly/idempotent annotations, the description adds valuable behavioral traits: it is deterministic, free, calls no model, and never runs out of quota. It also clarifies the return includes examples and recipes, which is useful behavioral context without contradicting annotations.

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

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

Every sentence earns its place: purpose, recipes, determinism/cost, and when-to-use. The description is front-loaded with the core function and avoids redundant statements, making it concise and well-structured.

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

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

With a single parameter, full schema coverage, and an output schema, the description gives sufficient context for selecting and invoking the tool. It doesn't cover edge cases like ambiguous tasks, but the output schema and example usage likely fill that gap.

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

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

The schema already covers the 'task' parameter at 100%, but the description enriches its meaning by specifying 'plain language' and 'any language,' guiding how the user should phrase the request. This adds semantic value beyond the schema's brief 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 clearly states the tool's function: given a plain-language task, it returns matching tools with ready-to-run example calls, and multi-step recipes for chained tasks. It distinguishes itself from siblings like list_models or ask_model by positioning itself as a meta-tool that avoids catalog browsing.

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

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

Explicitly instructs to 'Call this FIRST when you are not sure what this server offers,' providing a clear when-to-use directive. It also frames itself as an alternative to reading the whole catalogue, indirectly naming the alternative approach.

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