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

No annotations are provided, so the description carries the full burden and does well: it discloses the isolated AST evaluator, the no-unsafe-execution model, and that the tool is pure, deterministic, and idempotent. It stops short of describing error behavior for malformed expressions, which keeps it below 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?

Three compact sentences, front-loaded with purpose and the safety claim, then capabilities, then the usage trigger. There is slight redundancy between 'Safely...without unsafe execution' and 'Pure, deterministic, and idempotent', but nothing meaningfully wasteful.

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

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

For a single-parameter pure tool with no annotations and no output schema, the description covers purpose, supported operations, safety model, and when to call it. A brief note on the return value or error handling would round it out.

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

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

Schema coverage is 100% and the single expression parameter is documented with an example, so the schema does most of the work. The description adds value by listing supported functions (sin, cos, tan, log, sqrt, factorial) that indicate valid expression syntax, but no format or quoting rules.

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

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

States a specific verb (evaluate) and resource (mathematical and scientific expressions), and enumerates supported operations. It is clearly distinguishable from siblings like web_search or summarize, which cannot perform exact arithmetic.

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

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

Gives explicit when-to-use guidance: 'Use whenever exact numeric precision is required to avoid arithmetic hallucinations.' No exclusions or named alternatives, but no sibling is a plausible substitute for arithmetic evaluation, so the routing guidance is sufficient.

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

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

With no annotations supplied, the description takes on the safety burden itself and does so by declaring the operation 'Read-only and idempotent', which is the key fact an agent needs before calling. It also enumerates the returned data fields, though it omits rate limits and invalid-IP error behavior.

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

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

Two sentences, zero redundancy: the first defines the returned data, the second defines usage and safety. Returned fields are front-loaded ahead of the softer usage 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 one-parameter tool with no output schema, listing the returned fields fills the gap that the missing output schema would otherwise leave. Coverage is nearly complete; only the shape of the response (e.g. field formats, failure modes) is left unstated.

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

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

Schema coverage is 100% and the single 'ip' parameter is fully documented in the schema, including the empty-value behavior for caller IP lookup. The description adds nothing about parameter meaning beyond what the schema already states, so the 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?

Opens with a specific verb ('Retrieve') and resource ('geolocation, country, city, geographic coordinates, ISP, and timezone metadata for an IP address'), so the agent knows exactly what the tool returns. No sibling in the list overlaps, so differentiation is unnecessary.

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 names three use cases—inspecting IP locations, detecting regional origins, and resolving server IP information—which gives clear selection context. It stops short of stating when NOT to use it or naming an alternative, but no plausible alternative exists among the 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?

With no annotations supplied, the description carries the full behavioral burden, and it does deliver the safety profile directly: 'Read-only and idempotent,' which tells the agent it can retry freely without side effects. It also implies no auth is needed by citing the public Google News RSS feed. It omits other relevant traits such as rate limiting, result freshness/ordering, or behavior when the feed returns nothing, which is why it lands at adequate rather than strong.

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 short sentences in a sensible order: capability first, then triggering context, then the safety properties. Nothing is padded or repeated. Slightly shy of 5 only because the RSS-source clause and the read-only note could be folded more tightly, but no sentence is wasted.

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

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

For a simple two-parameter read tool with no output schema, the description covers what is returned (headlines, summaries, sources, timestamps) and the safety posture, which is the essential information. Minor gaps remain around empty-result and volume behavior, but an agent could invoke this correctly from what is stated.

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

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

Schema description coverage is 100%, so both `topic` and `max_articles` are already documented with examples and bounds. The description adds only marginally by broadening the notion of a topic to 'any topic or keyword,' and it never mentions `max_articles` in prose. Baseline 3 applies when the schema does the explanatory work.

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 names a specific verb ('Fetch') plus the exact resource and payload: 'current news headlines, summaries, sources, and publication timestamps for any topic or keyword via Google News RSS.' It also identifies the underlying source, so an agent knows precisely what it gets back. No sibling tool covers news, so no differentiation is required.

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

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

It gives concrete triggering contexts: 'monitoring breaking news, market updates, or industry trends.' That is clear when-to-use guidance with no misleading exclusions. It stops short of naming when-not-to-use or pointing to a nearby alternative (e.g. web_search for non-news queries), so it is not a full 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?

No annotations are supplied, so the description carries the full burden; it does state 'Read-only and idempotent,' which covers the safety profile and is the most important disclosure. It omits unit conventions (Celsius vs Fahrenheit, km/h vs mph), behavior for an unresolvable location string, and whether the Open-Meteo call needs a key or has rate limits — meaningful gaps for a data-fetch 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?

Two sentences, front-loaded with the capability and returned fields, followed by the usage trigger and the read-only guarantee. No filler or redundant restatement of the tool name.

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

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

For a simple two-parameter read tool with a fully documented schema and no output schema, the description covers purpose, source, returned fields, and usage context adequately. The main omission is the unit system of the returned values, which matters for interpreting the response.

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

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

Schema description coverage is 100%, so both parameters (location formats, forecast_days range 1-7 with default 3) are already fully documented in the schema. The description only restates 'any city or geographic location worldwide' without adding format nuance, 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?

States a specific verb ('Get') plus the exact resource ('current weather conditions ... and multi-day daily forecasts'), enumerates the returned fields, and names the upstream provider (Open-Meteo). An agent knows precisely what comes back without opening a schema, and the tool is clearly distinct from unrelated siblings like get_news or 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?

Gives explicit when-to-use guidance: 'Use when answering weather queries or trip planning.' That is a clear context trigger with no ambiguity about the tool's domain. It does not name exclusions or alternatives, but the sibling set contains no competing weather tool, so there is little to route against.

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?

With no annotations supplied, the description carries the full burden; it does disclose the self-declared read-only/idempotent profile and the added cross-field validation (subtotal + tax == total), which is real behavioral value. It omits what happens when the math fails to reconcile, which of the three input modes takes precedence, and any failure/auth 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?

Front-loaded with the verb and the extracted field set, then usage guidance, then the safety profile — a sensible order with no filler sentences. The parenthetical field list is dense but justified given there is no output schema.

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?

Because there is no output schema, listing the returned fields is necessary and the description does it. Remaining gaps — precedence between url/raw_text/file_base64 and behavior on failed math verification — are modest but real for a 4-param extraction tool.

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

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

Schema coverage is 100%, so all four parameters (url, raw_text, file_base64, currency_hint) are already documented in the schema, which sets the baseline at 3. The description adds nothing about mutual exclusivity or precedence among the three optional input sources, which is the main semantic risk for this tool.

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

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

States a specific verb (extract) plus the exact resource and output fields (vendor, invoice #, PO #, line items, subtotal, tax, total, currency), and scopes it to invoices/receipts/bills. The 'do not use for generic documents' line separates it from the pdf_extract sibling.

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

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

Gives both a positive trigger ('processing accounting documents or receipts') and an exclusion ('do not use for generic documents'). It stops short of naming the sibling an agent should fall back to for generic PDFs, so the routing is clear but not fully resolved.

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?

With no annotations, the description carries the full behavioral burden and does well by declaring the operation read-only and idempotent. It also lists what is returned (per-page text, outlines, metadata, token estimates), though it omits details like file-size limits, rate limits, or pagination behavior beyond the schema.

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 tightly written sentences, front-loaded with the action and outputs, followed by usage context and safety traits. No filler or redundant restatement of the name or schema.

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 no output schema, the description usefully enumerates the returned artifacts (text, outlines, metadata, token counts). It leaves out input-mode selection guidance and size or rate constraints, but the core extraction contract is clear enough 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%, so URL, base64, max_pages, and start_page are already fully documented in the schema. The description adds no parameter-level guidance such as when to prefer URL versus file_base64, so the baseline 3 is appropriate.

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

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

States a specific verb (extract) and concrete resources (text per page, outlines, metadata, token counts) from PDFs. This clearly distinguishes it from sibling tools like web_reader or summarize, which are not PDF-specific extraction tools.

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

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

Provides clear usage context: ingesting multi-page reports, whitepapers, contracts, or legal documents. It does not explicitly name alternatives or exclusions, but the document-type guidance is sufficiently specific to route most calls correctly.

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?

With no annotations supplied, the description carries the full burden and does meaningful work: "Pure, deterministic, and idempotent" effectively declares a no-side-effect, repeatable read operation, which is exactly the property an agent would otherwise want from annotations. The method (term-frequency scoring, extractive rather than abstractive) further sets expectations about output fidelity, though error behavior on oversized input is left to the schema.

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

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

Three sentences, each load-bearing: the first defines method and output, the second gives the use case, the third states behavioral guarantees. The purpose is front-loaded and there is no filler or repetition of schema content.

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

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

For a low-complexity, two-parameter tool with no annotations and no output schema, the definition covers method, use case, and side-effect profile. The only modest gap is that it does not describe the shape of the returned result (e.g., ordered list of sentences), which matters slightly since no output schema exists.

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

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

Schema description coverage is 100%, with both 'text' (50,000-char cap) and 'num_sentences' (1-10, default 3) fully documented in the schema, so the baseline is 3. The description adds only the notion of "most informative, central sentences" as the selection criterion, without extra detail on the optional parameter beyond what the schema states.

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 names a specific verb and resource: extractive summarization of long articles/documents based on term-frequency scoring, and clarifies it returns central sentences rather than abstractive rewrites. That is far more precise than a restatement of the name. It does not, however, reference any sibling tool (e.g., web_reader or pdf_extract as upstream sources), so it stops short of full differentiation.

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 offers one explicit usage cue: "Use to compress long context into key points." That tells the agent a triggering condition but gives no when-not guidance, no input-size prerequisite beyond the schema's 50,000-character cap, and no mention of how it relates to siblings that fetch or extract long text.

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?

With no annotations supplied, the description does the heavy lifting: it discloses the read-only, idempotent safety profile and explains what the tool strips (headers, footers, ads, navigation menus) and what it returns (Markdown for token efficiency). It omits failure behavior — blocked, paywalled, or JavaScript-rendered pages — which an agent calling a scraper would benefit from knowing.

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

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

Two sentences with zero padding; the core action and transformation lead, and the usage guidance plus safety profile follow compactly.

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 three-parameter fetch tool with no output schema and no annotations, the description covers action, scope, output shape, and safety. The remaining gap is error/edge-case behavior, which is not covered anywhere else in the structured data.

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

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

Schema description coverage is 100%, so all three parameters are already documented in the schema with defaults and ranges. The description adds only indirect context ('LLM token efficiency') that motivates the length limit, without further clarifying parameter behavior, so the 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?

States a specific verb ('fetch') and resource (a public webpage URL) plus the transformation performed ('extract clean, structured Markdown'), which cleanly separates it from the sibling web_search tool that locates pages rather than reading them.

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

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

Gives a clear usage context ('reading articles, blog posts, documentation, or public web pages') and implicitly scopes out non-public/authenticated pages via 'public webpage URL'. It does not name an explicit alternative or state when not to use it, so it stops short of full routing guidance.

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

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

With no annotations supplied, the description carries the burden and does disclose key traits: read-only, idempotent, and that results are snippets rather than full page content (which matters for choosing web_reader). It omits rate limits, empty-result behavior, and whether snippets are truncated.

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 short sentences, front-loaded with the action and engine, then the use case, then the safety profile. No filler or repetition; 'read-only and idempotent' earns its place precisely because no annotations exist.

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 two-parameter search tool with no output schema, the description covers purpose, trigger conditions, and the shape of returned results. The remaining gap is minor: it does not say what to do when results are insufficient (e.g., escalate to web_reader, which the sibling list suggests exists).

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

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

Schema description coverage is 100%, so both 'query' and 'max_results' (with its 1-20 bound and default 5) are already fully documented structurally. The description adds no syntax, format, or query-construction guidance beyond what the schema provides, 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?

Specific verb+resource+engine: 'Search the live web using DuckDuckGo' and it enumerates what comes back (titles, URLs, text snippets). It does not name a sibling (e.g., web_reader for full-page content, get_news for curated feeds), so the boundary with the closest alternative is left to inference.

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?

'Use when you need current facts, external references, or breaking information not in your training data' gives a clear positive trigger tied to data staleness. No when-not guidance or pointer to web_reader/get_news for full content or curated headlines, so the exclusion side is missing.

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