Tools for Agents

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

With no annotations provided, the description carries the full burden of behavioral disclosure, but it reveals nothing about side effects, read-only nature, prerequisite conditions, or response formatting. The agent cannot infer what invoking this tool actually does.

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 very short and front-loaded, which is efficient, but it omits critical details. It is under-specified rather than genuinely concise, lacking structure or sectioning to convey meaningful 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?

The tool lacks an output schema, has no annotations, and its description is minimal. For a tool that presumably advises on workflows and cost estimates, the description does not explain expected inputs, outputs, or behavior, making it inadequate for an agent.

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

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

Schema description coverage is 0%, and the description does not explain any parameters. Terms like 'goal' and 'optimizer' are left undefined, leaving the agent without sufficient information to select and invoke the tool correctly.

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 hints at the tool's function ('workflow + cost estimate') but is vague, lacking a specific verb or clear resource. It does not distinguish this tool from sibling tools like 'plan' or 'estimate_cost'.

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

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

No usage context is provided; the description does not state when to use this tool or how it differs from alternatives. The parenthetical '(free)' is not guidance on usage.

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

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

The description discloses the sequential workflow (search, extract, summarize), which is a useful behavioral trait. However, with no annotations, it does not mention any side effects, costs, rate limits, or error behavior, so transparency remains limited.

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

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

The description is a single concise sentence that effectively communicates the high-level process without unnecessary words. It is well-structured and 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 is too sparse for a tool with no annotations and no output schema. It does not explain the output format, how many sources are used, or how the parameters control the pipeline, leaving significant gaps 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 input schema has two parameters with no descriptions, and the description provides no explanation of 'query' or 'max_sources'. With 0% schema coverage, the description fails to compensate, leaving the agent without meaningful 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 clearly states the tool's function as a research pipeline (search → extract → summarize), which distinguishes it from single-step tools. However, it does not explicitly differentiate it from the similar sibling tool 'research_topic'.

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

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

No guidance is provided on when this tool should be chosen over alternatives like research_topic or a combination of web_search, extract_url, and summarize_text. The description lacks any contextual cues for usage.

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

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

No annotations are provided, so the description carries the full burden of explaining behavior. It only states the core action; it does not disclose how invalid base64 is handled, whether whitespace or URL-safe variants are supported, character encoding assumptions, or error behavior.

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

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

The description is a single, clear sentence with no wasted words. 'Decode base64 to text' is front-loaded and immediately conveys the essential function, earning a perfect conciseness score.

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 decode tool, the description covers the core purpose, and the schema fully documents the parameter. However, with no annotations and no output schema, it lacks any mention of error behavior, edge cases, or return format, leaving some gaps in context 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?

The input schema already describes the sole parameter 'encoded' as 'Base64 string to decode', and schema description coverage is 100%. The description adds no additional meaning beyond that. It does not specify format details or edge-case handling, so it meets the baseline without adding value.

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 'Decode base64 to text' uses a specific verb (decode), names the resource (base64), and states the output (text). This clearly distinguishes it from the sibling tool base64_encode and other parsing/extraction 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 no guidance on when to use this tool versus alternatives. It does not mention exclusions, prerequisites, or sibling tools like base64_encode. The only implied usage is from the tool name and one-line 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?

No annotations are provided, so the description should disclose behavioral traits. It does not mention standard vs URL-safe base64, handling of Unicode, padding, or output format. The behavior is predictable but under-documented.

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

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

Single sentence, no filler words, front-loaded and direct. The description is as concise as possible while conveying the full purpose.

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

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

For a simple encode tool with one parameter, the description and schema together are sufficient. No output schema exists, but return value (base64 string) is implicitly expected.

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 already describes 'text' as 'Plain text to encode' (100% coverage), and description adds no additional meaning beyond the schema. Parameter semantics are adequately handled by the input schema.

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

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

Description uses specific verb 'Encode' and resource 'text to base64', clearly distinguishing from sibling tool base64_decode which decodes. The purpose is unambiguous and the tool name aligns exactly with the description.

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

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

No explicit guidance on when to use vs alternatives, and no mention of when not to use. The purpose is implied by the description, but it does not name the companion decode tool or any edge cases where a different encoding tool would be needed.

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 burden. It discloses one trait: 'async', but says nothing about the operational behavior—whether it returns a job ID, requires polling, invokes a webhook, what the output is, or any limitations. This is insufficient for an async batch operation.

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

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

The description is extremely brief ('Batch extract URLs (async).'), bordering on under-specification. While not verbose, it lacks the structural detail needed to be useful; this brevity is not effective conciseness.

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

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

For an async tool with a webhook parameter and no output schema, the description leaves out essential context: processing semantics, return behavior, and callback usage. It is inadequate for an agent to fully understand the tool's operation and side effects.

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

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

Schema description coverage is 0% and the description adds no parameter meaning beyond implying 'urls' is the batch input. The 'webhook' parameter is completely unexplained, leaving a critical gap for correct invocation.

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 'Batch extract URLs (async)' names a specific verb ('extract') and resource ('URLs') and distinguishes itself from siblings via 'batch' and 'async'. However, it is ambiguous whether it extracts content from URLs or extracts URL strings from a source, and it does not clearly differentiate from 'extract_url' beyond mentioning batching.

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

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

No guidance is provided on when to use this tool versus alternatives. The description does not mention any exclusions, prerequisites, or comparisons to sibling tools like 'extract_url' or 'extract_links', leaving the agent without directional context for selection.

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

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

With no annotations, the description carries the full burden of explaining side effects, prerequisites, and execution behavior. 'Playwright browser automation' reveals none of this: it doesn't mention that it launches a browser, executes a sequence of steps, may have performance implications, or what happens on failure. This is a significant transparency gap.

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?

While the description is concise in word count, it is under-specified rather than appropriately concise. It consists of a single vague phrase that provides no usable information. The calibration examples treat extreme under-specification as a 2, not a 5.

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 3 parameters (including a complex 'steps' array) and no output schema, this description is grossly incomplete. It fails to describe the input format, execution model, or return value. The tool's behavior is entirely opaque.

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

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

Schema description coverage is 0%, and the description adds no meaning beyond the schema. 'steps' is an array of objects, but the description never explains what those objects contain or how they drive the automation. 'timeout' and 'url' are also unexplained. The description fails to compensate for the undocumented parameters.

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

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

The description is a near-tautology: 'Playwright browser automation' restates the tool's name without specifying what 'interact' means (e.g., clicking, filling forms, navigating). It provides no verb or resource details and does not distinguish it from sibling tools like crawl or screenshot.

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

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

No guidance is given on when to use this tool versus alternatives. The description does not mention contexts requiring multi-step browser automation, nor does it exclude simpler alternatives like read_url or screenshot. There is no when-to-use or when-not-to-use advice.

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 burden. It discloses only the cost behavior ('0 units on hit') but fails to explain what happens on a cache miss, what the actual output format is, or whether any side effects or rate limits apply. The term 'extract' itself is undefined.

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

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

The description is extremely short (six words) and front-loaded, but it is under-specified rather than efficiently concise. It omits critical details about the tool's core behavior, making the brevity a drawback rather than a strength.

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 only one parameter and no output schema, the description still fails to explain its fundamental purpose, expected return value, or relationship to the many sibling tools. The mention of caching and cost is useful but insufficient for an agent to select and invoke the tool correctly.

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

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

The schema has one parameter 'url' with no description (0% coverage). The description does not mention the parameter at all. While the parameter name is self-explanatory from the tool name, the description adds no semantic value beyond what the schema's field name already implies.

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 'Cached extract' indicates the tool performs an extraction operation on a URL with caching, but 'extract' is vague and does not specify what is being extracted (HTML, text, links, etc.). It does not distinguish itself from the many other extract-* sibling tools.

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

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

No guidance is provided on when to use this tool versus alternatives like extract_links, extract_pdf, or read_url. The description does not mention any context, prerequisites, or exclusionary conditions.

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 provided, the description carries the full burden of disclosing behavior. It fails to mention that chunks are sized and overlapped via configurable parameters, nor does it specify the chunking strategy (e.g., character vs. token-based). The minimal phrasing leaves user expectations unclear.

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

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

The description is a single, front-loaded sentence with zero waste. It efficiently conveys the core function without redundant phrasing.

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

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

The tool has 3 parameters and no annotations or output schema. The description is too minimal to fully specify behavior: it does not explain chunk semantics, parameter effects, or use context. Users would likely need additional documentation to configure the tool correctly.

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

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

Schema description coverage is 0%, and the description adds no information about the three parameters. The names 'text', 'overlap', and 'chunk_size' suggest their roles, but the description does not explain how overlap or chunk_size affect output, which is essential for correct invocation.

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 'Split text into RAG chunks' uses a specific verb ('split'), resource ('text'), and outcome ('RAG chunks') that clearly differentiates it from sibling tools like line_split or generic split. The acronym 'RAG' provides immediate context for retrieval-augmented generation use cases.

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

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

No guidance is provided about when to use this tool versus alternatives. The description implies RAG-related usage but does not mention alternatives like line_split or specify exclusions, leaving the agent to infer appropriate contexts.

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 must carry the full behavioral burden. It only says 'Compare two texts or URLs' without disclosing whether URLs are fetched, whether it returns a similarity score, a diff, or a boolean, or any other behavioral traits.

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

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

The description is a single, direct sentence with no filler words. It front-loads the verb and resource, making it highly concise and structurally efficient.

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

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

Given there is no output schema and no annotations, the description is too incomplete. It does not mention the return format, clarify parameter pairing, or differentiate from similar sibling tools, leaving the agent with insufficient information to invoke the tool 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 0%, so the description must compensate for the undocumented parameters. The phrase 'texts or URLs' hints at two groups (text_a/text_b and url_a/url_b) but does not clarify that users must provide both of the same type or explain each parameter's role.

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 compares two texts or URLs, which identifies the action and resource. It does not explicitly differentiate from siblings like text_diff or text_similarity, but the mention of 'texts or URLs' broadens its scope and provides a distinct identity.

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

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

The description offers no guidance on when to use this tool instead of specialized siblings such as text_diff, text_similarity, or diff_url. It does not state scenarios where a generic comparison is preferred or provide any 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?

No annotations are provided, so the description must carry the full burden of behavioral disclosure. It does not mention return format, determinism, or side effects, leaving the agent without essential information about what the tool actually does.

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 very short (four words), but it is under-specification rather than appropriate conciseness. A proper one-sentence description should state the function and key behavior without being verbose.

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

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

For a simple 2-parameter tool with no output schema, the description should explain the return value and usage context. It fails to do so, leaving the agent to infer the tool's purpose and behavior.

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

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

Schema coverage is 50%; the description adds no parameter semantics beyond the schema's terse 'Input text' and enum list. It does not clarify hash output format, encoding, or how the algorithm parameter affects the result.

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 is a noun phrase 'Content fingerprint sha256/md5' rather than a clear verb phrase. It does not explicitly state that the tool computes a hash, and it does not differentiate from the sibling tool 'hash_text'.

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

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

No guidance is provided about when to use this tool, when not to use it, or alternatives. There is no mention of use cases or comparison with other sibling tools like hash_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 provided, the description carries the full burden of behavioral disclosure. It mentions 'async,' which gives a clue about execution model, but it doesn't disclose whether the operation is read-only, how many pages it will crawl, whether it follows pagination, or any side effects or rate limits.

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

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

The description is very brief, but this is under-specification rather than conciseness. It spends its few words on a near-tautology and an acronym, without conveying substantive information that would help the agent.

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

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

Given the lack of annotations, no output schema, and only two parameters, the description is severely incomplete. It fails to explain what the tool does, what the expected output is, how max_pages works, or any behavioral details, making it nearly useless for an agent deciding to invoke it.

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

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

Schema description coverage is 0%, and the description provides no parameter explanations. The schema defines 'url' and 'max_pages' with a default, but the description doesn't clarify their semantics, leaving the agent to guess how these parameters affect behavior beyond their names.

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

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

The description 'Crawl site (async)' essentially restates the tool name with minimal added meaning. It doesn't specify what the crawl produces, what the scope of 'site' is, or how it differs from sibling tools like map_site or read_url, though the verb is somewhat specific.

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

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

There is no guidance on when to use this tool versus alternatives such as map_site, browser_interact, or read_url. The description doesn't provide context for appropriate use cases or any 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?

No annotations are provided, so the description carries full burden. It only states 'improves discovery ranking (free)' and does not disclose side effects, permissions, or whether it is destructive/read-only. The 'free' note is helpful but insufficient.

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

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

The description is a single concise sentence, but it sacrifices necessary detail for brevity. It is not front-loaded with critical information like required parameters.

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 6 parameters (4 required), no output schema, and no annotations, the description is grossly incomplete. It does not explain return values, parameter semantics, or behavioral implications of submitting feedback.

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 6 parameters and 0% schema description coverage, the description adds no meaning beyond the schema. It does not explain the purpose of any parameter, such as 'outcome' enum values or the 'cost_usd' and 'latency_ms' fields.

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

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

The description clearly states it is for CRP post-execution feedback and that it improves discovery ranking. It is specific about the verb ('feedback') and resource ('CRP'). However, it does not distinguish from sibling tools like 'crp_resolve', which may be related but is not mentioned.

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

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

No guidance on when to use this tool versus alternatives is provided. The description implies it is for after CRP execution but does not specify when to choose it over 'crp_resolve' or other feedback mechanisms. No exclusions or contextual advice.

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 provided, and the description only mentions 'free', which is minimal. It does not disclose behavioral traits like side effects, authorization needs, rate limits, or what happens on failure. The description is insufficient for understanding the tool's behavior.

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

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

The description is a single, efficient sentence with no wasted words. It front-loads the purpose. However, it could benefit from slightly more detail without losing conciseness.

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

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

Given no output schema and moderate complexity (nested objects), the description lacks completeness. It doesn't explain what 'ranked routes' or 'invocation JSON' are, nor does it cover error handling, prerequisites, or typical use cases.

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

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

Schema coverage is 100%, so the description does not need to add much. It adds the context of output (ranked routes + invocation JSON) but does not explain parameters beyond schema descriptions. Baseline 3 is appropriate.

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

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

The description clearly states the tool resolves a goal to ranked routes and invocation JSON, which is a specific verb and resource. However, it doesn't fully explain what 'routes' and 'invocation JSON' entail, leaving some ambiguity. It distinguishes itself from sibling tools by being a capability discovery 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 provides no guidance on when to use this tool versus alternatives. No context, prerequisites, or exclusions are mentioned, making it hard for an agent to decide when to invoke 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?

No annotations are provided, so the description must fully disclose behavior. It only lists categories and does not mention side effects, permissions, return behavior, or operational details. This offers no transparency into the tool's actual behavior.

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

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

The description is brief and contains no filler, but it is a fragment rather than a well-formed sentence. It is concise in length but under-specifies the tool's functionality, so it earns a middle score.

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

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

With no output schema and no annotations, the description must provide sufficient detail to use the tool. It only mentions categories, leaving all operational context (e.g., parameters, return values, workflows) undefined. This is inadequate for a tool handling cryptographic operations.

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

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

The input schema has only 'operation' and 'params', both vaguely named, with 0% schema description coverage. The description does not clarify valid operation values, the structure of params, or relationships between them. It fails to compensate for the schema's lack of detail.

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 domain (cryptographic operations) and lists example areas (BIP39, wallets, signatures, hashes), but lacks a specific verb or resource. It does not clearly distinguish from sibling tools like hash_text or content_hash, which also cover hashing. The purpose remains ambiguous.

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

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

No guidance is provided on when to use this tool versus alternatives. The description does not mention any context, preconditions, or exclusions. Given overlapping sibling tools, the lack of usage direction is a significant gap.

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 provided, so the description carries the full burden of behavioral disclosure. It only states the high-level action and does not mention delimiter handling, header behavior, quoting, output structure, or error handling, leaving the agent with significant unknowns.

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

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

The description is a single, front-loaded sentence with zero wasted words. It efficiently communicates the core purpose without redundancy.

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

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

Given no output schema and no annotations, the description is too sparse. It doesn't specify the return format (e.g., array of arrays vs. array of objects), how 'has_header' influences output, or any edge cases like empty lines or custom delimiters. The tool needs more context to be invoked reliably.

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

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

The schema describes 'text' and 'delimiter' but not 'has_header'. The description adds no parameter-specific meaning—it doesn't clarify how 'has_header' affects parsing or what 'records' means. With moderation schema coverage (67%), the description fails to compensate for the missing parameter info.

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 'Parse' with a clear resource 'CSV/TSV' and outcome 'rows and records'. It distinguishes this tool from other parsing siblings like json_parse or xml_parse by naming the exact format.

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

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

The description implies usage for parsing CSV/TSV text, but offers no explicit guidance on when to use it versus alternatives, nor any exclusions or preconditions. It's a basic implied usage scenario.

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 burden of behavioral disclosure. It states the action but does not explain what 'near-duplicate' means, how the threshold parameter affects behavior, whether order is preserved, or what the output looks like. The mutation/destructive nature of 'remove' is not elaborated.

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

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

The description is a single, efficient sentence that front-loads the core purpose. It is appropriately concise, though its brevity borders on under-specification, missing worthwhile behavioral details.

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

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

Given two parameters, no annotations, and no output schema, the description is too sparse to fully equip an agent. The threshold behavior is not explained, and the return format is not indicated, making it incomplete for a tool that performs a specific algorithmic operation.

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

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

Schema description coverage is only 50%: 'texts' is described as 'List of text passages', but 'threshold' has no schema description and the tool description does not explain it. The phrase 'near-duplicate' hints at a similarity threshold but does not define units or interpretation, leaving the threshold parameter semantically underdocumented.

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 'Remove near-duplicate passages' uses a specific verb ('remove') and resource ('near-duplicate passages'), clearly distinguishing it from sibling tools like compare_texts or text_similarity, which likely compare or measure similarity rather than deduplicate.

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

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

No guidance is provided about when to use this tool versus alternatives such as text_similarity or compare_texts. The description implies usage only by its name and phrase, but there is no explicit context, prerequisites, or exclusions.

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

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

With no annotations, the description carries the full burden of disclosing behavior. It does not mention whether it fetches the live page, how caching works, whether it requires network access, or if it has any side effects. The comparison behavior is implied but not elaborated.

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

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

The description is a single, efficient phrase with no wasted words. It is front-loaded and easy to parse, but the extreme brevity contributes to the lack of detail in other dimensions.

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

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

Given the tool's simplicity, one might expect a slightly more detailed description. The lack of output schema and annotations means the description should explain what 'cached' means, how the comparison is performed, and what the return value looks like. It fails to do so, leaving significant gaps.

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

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

Schema description coverage is 0%, and the description does not explain the meaning of the 'url' parameter beyond the tool's name. It does not clarify whether the URL refers to the cached resource, the live page, or both, leaving the parameter's role ambiguous.

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 'Compare cached vs live page.' clearly identifies the action (compare) and the two resources involved (cached version, live page). It distinguishes itself from siblings like compare_texts or text_diff by focusing on URL-level 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?

No guidance is provided on when to use this tool versus alternatives such as cache_url, read_url, or text_diff. The description only states the basic purpose with no context about prerequisites (e.g., whether a cached version must exist) or when not to use it.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It does not mention that this triggers a network request, what the output format looks like, or any potential errors (e.g., domain not found, timeout). The description adds no extra context beyond the operation itself.

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

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

The description is extremely concise and front-loaded, stating the tool's essence in five words. While it is terse, it is appropriate for a simple lookup tool and avoids unnecessary 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 a simple schema but no output schema and no annotations. The description does not explain what the tool returns (e.g., IP addresses, TTL, record list), nor any network-related caveats. For an agent to use the tool effectively, more context 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 description coverage is 100% for both parameters (domain and record_type), so the baseline is 3. The description 'A/MX/TXT' partially echoes the record_type parameter's description but adds no meaningful semantics beyond what the schema already provides.

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

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

The description 'DNS A/MX/TXT lookup' clearly identifies the tool as performing DNS record lookups for specific record types (A, MX, TXT). It distinguishes from sibling tools like ssl_check or validate_domain, though it could be more explicit about the verb ('perform a lookup').

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

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

No guidance is provided on when to use this tool versus alternatives (e.g., validate_domain, ssl_check). There is no mention of use cases, prerequisites, or scenarios where other DNS-related tools would be more appropriate.

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

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

No annotations are provided, so the description carries the full burden. It only says 'Probe URL' and '(free)', giving no details about network behavior, what the probe actually does, side effects, or what response is expected. The agent is left with no behavioral expectations beyond a vague sense of a free pre-check.

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

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

The description is a single, front-loaded sentence with no filler. It conveys the core purpose and a helpful cost hint, fitting for a simple tool.

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

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

For a simple tool with one parameter and no output schema, the description should clarify what the probe returns or how it succeeds/fails. It does not, leaving the agent without enough context to correctly use the result or judge if the tool completed successfully.

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 zero schema description coverage and no additional explanation in the description, the parameter 'url' is only defined by its name. The description's use of 'URL' merely echoes the parameter name and adds no meaning about format, validation, or expected 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 uses the specific verb 'Probe' with the resource 'URL', and the phrase 'before extract' indicates a pre-extraction check, distinguishing it from extraction tools like extract_url. However, 'probe' is somewhat vague about what exactly is checked, which prevents a 5.

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 phrase 'before extract' clearly signals when to use this tool – as a preliminary step to extraction. It does not explicitly name alternatives or exclusions, but the context is clear enough for an agent to infer the primary use case.

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 present, so the description must carry the full burden. It only states the action and doesn't disclose output format, model behavior, or any side effects. It adds minimal behavioral context beyond the name.

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

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

The description is a single, concise sentence but is under-specified. It's efficient but lacks necessary detail, earning a middle score.

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 annotations and no output schema, the description should explain return values and usage constraints. It does neither, leaving the user to infer everything from the schema.

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

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

Schema description coverage is 0%, and the description does not explain the 'text' or 'model' parameters. It adds no semantic meaning to the schema's parameter definitions.

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

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

The description uses the specific verb 'generate' with the resource 'text embeddings,' clearly stating the core function. It doesn't explicitly distinguish from sibling tools like text_similarity or rerank_docs, but the action is unambiguous.

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

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

No guidance is provided on when to use this tool versus alternatives like text_similarity or rerank_docs. No context or exclusions are mentioned.

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

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

No annotations are present, so the description bears the full transparency burden. It clearly states the types of entities extracted, which is the core behavior, but it does not disclose output format, deduplication behavior, or handling of edge cases. This is a minimum-viable disclosure.

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 short sentence, front-loaded with the action verb and entity types. Every word adds value, with no redundant or filler content.

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

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

The tool has no output schema, and the description does not explain the return format or any limitations. Given the tool's simplicity, the description is too minimal to be fully self-contained; the agent must infer the output structure.

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 the sole parameter 'text' as 'Input text' with 100% coverage. The description adds no additional semantic information about the parameter, 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?

The description uses a specific verb 'Extract' and enumerates the entity types (emails, URLs, phones, dates), clearly defining the tool's scope. This differentiates it from single-type siblings like extract_emails and extract_url.

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

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

No guidance is provided on when to use this tool versus the many specialized extractors listed as siblings (e.g., extract_emails, extract_url). The context is implied by the listed entity types but no explicit alternatives or exclusions are given.

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

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

There are no annotations, so the description carries the full burden of behavioral disclosure. It only adds that the tool is free, which is a relevant cost trait, but it does not disclose what inputs trigger computation, whether it makes network requests, or what the output represents. This is insufficient for a tool with no structured metadata.

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

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

The description is extremely short (five words) and front-loaded, with every word earning its place. It is not bloated, but it may be too telegraphic to be fully self-explanatory. As a purely structural score, it is efficient.

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

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

With no output schema, no annotations, and only a three-parameter schema with zero descriptions, the description must explain the tool's complete behavior, including return values, parameter roles, and edge cases. It only states that it estimates API units for free, leaving the operational contract almost entirely unspecified. The tool's complexity is low but still requires more context to be usable safely.

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 defines `tool`, `text`, and `count` but provides no descriptions; schema description coverage is 0%. The description does not mention any of these parameters, leaving all semantic meaning to be inferred. Since the description fails to compensate for the low coverage, parameter semantics are essentially undocumented.

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 'Estimate API units (free)' uses a clear verb-resource structure, indicating the tool estimates cost in API units. It hints at a cost-related purpose but does not specify for which API or how the estimate is computed, limiting its distinctiveness. None of the sibling tools are named similarly, so it is relatively unique.

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

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

No usage guidance is provided. The description does not explain when to prefer estimate_cost over sibling tools like `advisor` or `dry_run`, nor does it state any prerequisites or alternatives. The word 'free' implies a cost-related benefit, but not 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?

No annotations are present, so the description carries the full burden of behavioral disclosure. It only states the action without mentioning output format, handling of duplicates, or any edge cases, leaving the agent to infer behavior.

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

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

The description is extremely concise at four words and front-loads the key verb and object. It is appropriately sized for a simple tool, though a slightly more detailed description could improve clarity without becoming verbose.

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

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

For a tool with a single parameter and no output schema, the description does not specify the return type or how emails are extracted (e.g., regex behavior). The completeness is insufficient for an agent to fully understand what will be returned.

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 'text' with description 'Input text', achieving 100% coverage. The tool description adds no new meaning beyond the schema; it simply states the overall purpose, which is already implied by the parameter name and description.

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

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

The description 'Extract email addresses' uses a specific verb ('extract') and resource ('email addresses'), clearly distinguishing it from sibling tools like extract_phones and extract_links. The purpose is unambiguous.

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

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

The description implies usage when one needs to extract email addresses from text, but it does not explicitly state alternatives or when-not conditions. No exclusions or comparisons to sibling extraction tools are provided.

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 provided, the description must carry the full burden of behavioral disclosure. It only states the output type and does not mention error handling, network behavior, security considerations, or response format, making the tool's runtime behavior opaque.

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

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

The description is extremely concise, consisting of just four words, which makes it easy to read. However, it is a fragment rather than a complete sentence and lacks any structural breakdown of the tool's behavior, though it does convey the core idea efficiently.

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

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

For a tool that performs network requests, more context is needed—such as expected URL format, response details, and potential error conditions. With no output schema and no annotations, the description is too sparse for an agent to fully understand usage and expectations.

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 'url' parameter is self-explanatory by name, but the description does not clarify whether the URL should point directly to a raw JSON file or a web page containing embedded JSON. With schema description coverage at 0%, the description fails to compensate for this ambiguity.

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 'Structured JSON from URL' clearly indicates the tool fetches a URL and produces a JSON result. It distinguishes from siblings like json_parse by specifying the URL source, though it lacks an explicit verb and is more of a fragment than a full sentence.

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

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

No guidance is provided on when to use this tool versus alternatives like read_url, extract_url, or json_parse. The description gives no context, exclusions, or examples, leaving usage entirely to inference from the name.

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 burden. It only says 'list links' and provides no details on output format, relative vs absolute URLs, handling of redirects, or whether it is a read-only operation. This is minimal behavioral disclosure beyond the name.

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

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

The description is extremely short, but this is under-specification rather than good conciseness. It is so terse that it provides no value beyond the tool name, failing to earn its place.

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

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

The tool has no output schema and no annotations, so the description should explain return values and edge cases. It does not mention what the output looks like (e.g., array of strings) or any limitations, making it incomplete 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 0%, so the description must compensate. It fails to explain the 'url' parameter or the 'same_host' boolean, leaving the agent without any guidance on how to fill these parameters correctly.

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 action (list) and the resource (links from page), which is clear. However, it does not distinguish between this tool and similar siblings like page_links_external or crawl, so scope and differentiation are lacking.

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?

There is no guidance on when to use this tool vs alternatives. It does not mention prerequisites, such as needing a valid URL, or when to prefer this over page_links_external or crawl. The description implies usage but offers no exclusions or alternatives.

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

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

No annotations are provided, so the description carries the full burden. It only mentions the output (H1–H3 outline + word count) without disclosing whether it fetches the URL, whether it is read-only, or any other behavioral traits such as network requests or parsing details.

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

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

The entire description is a single concise sentence, 'Page outline H1–H3 + word_count,' with no redundant words or filler. It front-loads the core function and is appropriately sized for a simple tool.

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

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

With no output schema and no annotations, the description is too sparse. It does not specify the structure of the outline, ordering of headings, or how max_headings affects results, leaving important context missing for correct invocation and interpretation.

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

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

Schema description coverage is 0%, and the description does not explain the parameters. The 'url' parameter is self-explanatory, but 'max_headings' is not described, leaving the agent without insight into how it limits the output or its effects.

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 exactly what the tool does: extracts H1–H3 headings and word count from a page. It clearly differentiates from sibling extraction tools by specifying the exact output fields, 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 implies usage: use this tool when you need a page's heading outline and word count. However, it provides no explicit guidance on when to choose this over similar tools like extract_url, page_metadata, or read_url, nor does it mention any exclusions or alternatives.

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

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

With no annotations provided, the description carries full responsibility for behavioral disclosure. It states the action but does not describe the return format, limitations (e.g., scanned PDFs), or error handling, leaving significant ambiguity.

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

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

The description is a single sentence with no redundant words. It is perfectly concise and front-loaded, making it easy to grasp quickly.

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, but the description lacks mention of return format, limitations (e.g., scanned PDFs), or error conditions. While adequate for basic use, it leaves gaps for a tool with no output schema or annotations.

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

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

Schema description coverage is 0%, so the description must compensate. It adds meaning by specifying that the url must point to a PDF, which is not in the schema. However, it does not elaborate on URL format, accessibility, or constraints, so compensation is only partial.

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

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

The description clearly states the action ('extract text') and the target resource ('a PDF URL'), giving a specific verb and resource. It does not explicitly differentiate from sibling tools like ocr_url or pdf_split, which prevents a perfect score.

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

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

No usage guidance is provided. The description does not specify when to use this tool over alternatives such as ocr_url, pdf_metadata, or read_url, nor does it mention any exclusions or prerequisites.

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

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

With no annotations, the description carries full disclosure burden, but it only states the core function. It does not mention return format, handling of malformed numbers, or any behavioral traits beyond extraction.

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

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

The description is concise with no filler, but it lacks structure or additional clarifying details. It's appropriately short for a simple tool, though somewhat under-specified.

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 annotations and no output schema, the description fails to convey what output to expect or edge cases. It's too brief to be fully contextual.

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

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

Schema coverage is 100% for the single 'text' parameter, so the schema fully documents the input. The description adds no additional parameter semantics, but 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 a specific verb 'extract' and resource 'phone numbers', clearly stating the tool's function. However, it lacks context about input/output format or sibling differentiation, so it's clear but minimal.

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

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

No guidance is provided on when to use this tool versus alternatives like validate_phone or extract_emails. The intended use is implied by the name but not explicitly stated.

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 burden of behavioral disclosure. It only states a generic action and fails to mention network requests, failure modes, or output structure, leaving the agent ill-informed.

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

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

The description is a single concise sentence and is front-loaded, but it is under-specified, omitting parameter details and usage context. It is not wasteful, but it could earn its place with more informative 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?

With no output schema and no annotations, the description is the sole source of context. It does not describe the return format, how the page is fetched, or any edge-case behavior, making it incomplete for a QA tool.

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

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

Schema description coverage is 0%, and the description does not explicitly explain the 'url' and 'query' parameters beyond their names. It implies 'query' is the question but provides no format, constraints, or additional semantic detail.

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 'Answer a question using page content' states a specific verb and resource, but it is vague about what constitutes a 'question' and how answers are derived. It does not differentiate from sibling extraction tools like batch_extract or extract_json.

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

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

No guidance is provided on when to use this tool versus alternatives such as read_url or batch_extract. The description lacks any context about prerequisites, intended use cases, or exclusions.

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

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

With no annotations and no behavioral disclosure, the description provides zero transparency about side effects, return format, or operational behavior. It doesn't even state that it fetches a URL or extracts JSON-LD content.

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 short but under-specified, not effectively concise. It is a sentence fragment that omits critical information, so it fails to earn its place as 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?

Given no annotations, no output schema, and a single parameter, the description is wholly inadequate. It leaves the agent without any understanding of inputs, outputs, or usage context.

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

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

The only parameter 'url' is completely undocumented in the schema and the description adds no meaning. With 0% schema description coverage, the description fails to clarify what URL is expected or how it is used.

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 'Structured fields from JSON-LD.' is a vague fragment that barely restates the tool name. It lacks a clear verb+resource structure and fails to distinguish this from siblings like json_ld, extract_json, or extract_url.

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

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

There is no guidance on when to use this tool versus alternatives. No context, prerequisites, or exclusions are provided, leaving the agent to guess whether this is appropriate for a given task.

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 burden of behavioral disclosure. It does not mention network fetching behavior, supported content types, error handling, or any side effects. It only states the basic action without disclosing underlying behavior.

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

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

The description is a single, front-loaded sentence with no wasted words. However, given the tool has four parameters and no other documentation, this brevity feels like under-specification rather than effective conciseness.

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 relatively complex with four parameters, no annotations, and no output schema. The description only covers the basic purpose and omits crucial details about return formats, parameter semantics, and operational behavior, making it incomplete for an agent to select and invoke correctly.

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

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

Schema description coverage is 0%, and the description adds no meaning to the parameters. It does not explain mode (fast vs full), format options, or include_links. The description completely fails to compensate for the lack of parameter documentation.

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 extracts main content from a webpage URL, with a specific verb and resource. However, it does not differentiate from closely related sibling tools like read_url or readability, which likely serve similar 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?

There is no guidance on when to use this tool versus alternatives, nor any mention of appropriate contexts or limitations. The description provides no usage context beyond the basic action.

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

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

With no annotations, the description must disclose behavioral traits, but it only mentions the order of attempts (primary then fallbacks). It does not explain error handling, side effects, termination conditions, or how results are returned, leaving significant behavioral ambiguity.

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 short sentence, but it is under-specified rather than genuinely concise. It omits crucial details that would be needed for the description to earn its place, making it more a placeholder than a useful specification.

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 tool has nested objects, two parameters, no annotations, and no output schema. The one-sentence description is completely inadequate to guide an agent on how to construct inputs, interpret results, or handle failures. It provides no context on return values or edge cases, making it insufficient for reliable 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 coverage is 0% and the parameters are nested objects. The description adds minimal meaning beyond the parameter names: it indicates that 'primary' is a tool and 'fallbacks' are tools, but it does not explain the structure of these objects, how to specify tool names or arguments, or the semantics of the fallback array.

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 tries a primary tool and then fallbacks, giving a basic sense of its behavior. However, it lacks specificity about what kind of tools are involved, how fallback selection works, and the scope of the operation, and it does not distinguish it from siblings like run_chain or workflow_stateful.

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?

There is no guidance on when to use this tool versus alternatives. It does not mention any particular context, prerequisites, or exclusions. The description simply says what it does without indicating appropriate usage 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?

No annotations exist, so the description carries full burden. It only states the action, but does not disclose that the tool likely fetches the URL, what the output structure is, error handling, or limitations. Minimal disclosure beyond the literal function.

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, clear sentence with no unnecessary words. It is well-structured and 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?

With no output schema, the description does not explain what the parser returns (e.g., parsed items, feed metadata). It also omits potential caveats like network dependencies or error responses. Minimal but not comprehensive.

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

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

Schema description coverage is 0%, and the description does not explain the 'url' parameter beyond its name. The URL is implicitly the feed location, but no details about format, validation, or expected scheme are provided.

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 'Parse RSS/Atom feed' uses a specific verb and resource, clearly identifying the tool's function. It distinguishes from sibling parse tools (e.g., xml_parse, json_parse) by naming the specific feed format.

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

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

Usage is implied by the tool's name and description: use it when you need to parse an RSS/Atom feed. However, there is no explicit guidance on when to choose this over alternatives like read_url or xml_parse, nor any 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?

With no annotations, the description must disclose behavioral traits, but it only names the algorithms. It does not state output format, whether it returns both hashes or a single encoded value, or any side effects. This is minimal beyond what the tool name already implies.

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?

At three words, the description is extremely concise and front-loaded with key algorithm names. It avoids filler but is borderline under-specified, though the simplicity of the tool allows for this brevity.

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, but the description omits essential context like return value structure (e.g., separate fields for sha256 and md5, hex encoding). Without an output schema or annotations, the agent is left guessing how to interpret results, making the description incomplete for effective invocation.

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

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

The schema already fully describes the single 'text' parameter with 100% coverage. The description mentions SHA256 and MD5, which are relevant to the parameter's use but adds no new semantic meaning about the parameter itself. Baseline of 3 applies.

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

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

The description states the specific algorithms (SHA256 and MD5) and the implied action (hashing), which clarifies the tool's function beyond the name. However, it does not differentiate from sibling tools like content_hash or crypto_invoke, which might also perform hashing.

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

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

No guidance is provided on when to use this tool versus alternatives such as content_hash or crypto_invoke. The description gives no context for selection or exclusions, leaving the agent without direction.

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

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

With no annotations provided, the description bears full responsibility for behavioral disclosure. It only says 'Strip HTML to clean text', which indicates tag removal but doesn't explain handling of scripts, entities, or formatting. This is insufficient for an agent to predict all behaviors and side effects.

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

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

The description is a single concise sentence with no redundant words. It efficiently conveys the core operation without any fluff, earning a top score for conciseness.

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 and single parameter, the description is minimally adequate but lacks specifics about output format or edge cases. The absence of an output schema and annotations increases the need for more detail, yet the basic operation is straightforward enough for a 3.

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 'html' is already fully documented in the schema with description 'Raw HTML', and schema coverage is 100%. The description adds no additional semantic detail beyond the schema, 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 uses the specific verb 'Strip' and identifies the resource 'HTML' with the outcome 'clean text', clearly stating the tool's function. However, it does not explicitly differentiate from the sibling tool html_to_markdown, which also processes HTML into a text-based format, so it falls short of a perfect score.

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

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

No guidance is provided about when to use this tool versus alternatives like html_to_markdown or readability. The description lacks context on use cases, prerequisites, or exclusions, leaving the agent to infer appropriate usage.

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

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

No annotations are provided, so the description carries full responsibility for behavioral disclosure. It only states the conversion without mentioning how it handles edge cases (e.g., malformed HTML, script removal, link preservation, or whether it's lossy). This is a significant gap for a conversion 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, direct sentence that is front-loaded and free of fluff. It earns its place by stating the core purpose without wasting words.

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

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

For a simple tool with one parameter and no annotations or output schema, the description is minimally viable: it states the conversion purpose. However, it lacks any guidance on behavior or usage edge cases, making it incomplete for an agent to fully anticipate outcomes.

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

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

Schema description coverage is 0%, meaning the description must compensate for parameter understanding. It does not add any detail beyond the property name 'html' – no format expectations, encoding, or examples. While the parameter name is intuitive, the description adds no extra value.

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 (Convert) and resource (HTML to Markdown), clearly differentiating it from related tools like html_clean or markdown_parse. Even without reading the tool name, the purpose is unambiguous.

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

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

There is no guidance on when to use this tool vs alternatives. No mention of exclusions (e.g., 'for cleaning HTML use html_clean' or 'for parsing markdown use markdown_parse'). The description provides no context for selection.

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

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

With no annotations provided, the description must shoulder the burden of behavioral disclosure. It only mentions '(vision)' without explaining output format, model limitations, or any side effects. This is a minimal disclosure that leaves significant unknowns.

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, short sentence that is appropriately concise. It front-loads the core purpose ('Describe image') and adds a brief qualifier ('vision'), but it might be too sparse for the complexity of the tool.

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

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

Given the lack of annotations and output schema, the description should provide more context about what the tool returns, typical usage, and limitations. The current text is too thin, leaving the agent without enough information to fully understand expectations.

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 has one parameter 'url' with no description, and the schema coverage is 0%. The tool description does not mention 'url' at all, so it adds no meaning beyond the parameter name. The description fails to compensate for the missing schema 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 'Describe image (vision)' clearly states the verb (describe) and the resource (image), and the parenthetical '(vision)' hints at the method. It is distinguishable from siblings like ocr_image (which extracts text) and screenshot (which captures), but it lacks specificity on the type of description generated.

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

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

No guidance is provided on when to use this tool versus alternatives such as ocr_image or ocr_url. The description does not mention use cases, prerequisites, or contexts where this tool is preferred.

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 burden. It implies a non-mutating read operation via 'poll', but does not disclose behavior such as whether the job must exist, what happens if the job is not ready, rate limits, or any side effects. This is a significant gap.

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 short sentence, but this is under-specification rather than conciseness. It lacks necessary detail and leaves the agent guessing about almost everything.

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 no annotations, no output schema, and a minimal description. It fails to convey return values, error cases, polling semantics, or how the job relates to other async tools. The description is fundamentally inadequate for safe and correct invocation.

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

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

Schema description coverage is 0% and there is one parameter (job_id) with no additional explanation in the description. The description does not compensate by explaining job_id format, provenance, or expectations, offering no value beyond the schema itself.

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 'Poll async job' uses a specific verb (poll) and resource (async job), making the core purpose clear. It does not explicitly distinguish from sibling tools, but no sibling is obviously similar, so it effectively identifies the tool's role.

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

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

No guidance is provided on when to use this tool, when to avoid it, or what alternatives exist. The description gives no context for usage decisions.

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 provided, the description carries full responsibility for behavioral disclosure. It does not explain how arrays are handled, whether keys are merged, or any side effects. The phrase gives only a superficial hint of functionality.

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 short and to the point, with no unnecessary words. However, it is too terse to be genuinely helpful; it reads more like a placeholder than a properly informative description.

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

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

Given the lack of an output schema and annotations, the description should explain what the flattened output looks like, but it does not. The tool's simplicity does not excuse the omission of return format and edge case behavior.

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

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

Schema coverage is 50%; only 'data' is described. The 'prefix' parameter lacks a description in the schema, and the tool description does not compensate by explaining its purpose or effect. This leaves a significant gap for agents trying to use the parameter correctly.

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 'Flatten nested JSON' uses a clear action verb and resource, distinguishing it from siblings like json_parse and extract_json. However, it does not fully specify the output format or flattening convention (e.g., dot notation), which leaves slight ambiguity.

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

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

The description provides no guidance on when to use this tool versus alternatives such as json_parse or json_ld. It merely states what it does without any context, prerequisites, or exclusions.

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

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

No annotations are present, so the description must carry the burden of behavioral disclosure. It only states the tool works with a URL and JSON-LD, but does not indicate whether it is a read operation, how it handles failures, what the output structure looks like, or any side effects. This is nearly no behavioral information.

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?

At only four words, the description is extremely concise but at the expense of usefulness. It is a fragment, not a sentence, and omits critical details. This is under-specification rather than efficient conciseness, as seen in the LOW calibration example.

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

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

With no output schema, no annotations, and a single undocumented parameter, the description is completely inadequate. It does not explain what JSON-LD is returned (single object, array, etc.), what prerequisites exist, or how it relates to sibling tools. The tool is simple, but the description still fails to provide enough context for correct invocation.

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

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

Schema coverage is 0%, and the description does not explain the 'url' parameter beyond the schema's own name. It adds no detail about the expected format, whether it must point to a specific type of page, or any constraints. The description repeats what the schema already shows without adding value.

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 'JSON-LD from URL' is a fragment that implies the tool retrieves or extracts JSON-LD from a given URL. It names the resource (JSON-LD) and source (URL) but lacks an explicit verb, making the operation somewhat vague. It does distinguish from siblings by naming a specific data format, but the purpose is not fully articulated.

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?

There is no guidance on when to use this tool vs. alternatives like read_url or extract_schema. No context, exclusions, or alternative tool references are provided, so the description gives the agent no basis for choosing this tool 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It states the operation but does not clarify what happens on invalid JSON, what the return format is, or how errors are signaled, which is a significant gap for a validation 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, front-loaded sentence with no wasted words. It is appropriately concise for a tool of this simplicity.

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

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

Given the tool's simplicity, the description is not severely incomplete, but the lack of an output schema and annotations means it should explain the return/error behavior for validation. The description leaves some ambiguity, so it is adequate but not complete.

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

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

The input schema fully describes the 'text' parameter, and the description does not add additional parameter-level meaning beyond reiterating that the input is JSON text. With 100% schema coverage, the baseline of 3 is appropriate.

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

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

The description clearly identifies the action (parse and validate) and resource (JSON text), which is specific and understandable. However, it does not explicitly distinguish it from sibling tools like json_flatten or extract_json that also operate on JSON, so it misses the top score.

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?

There is no guidance on when to use this tool versus alternatives, no prerequisites, and no exclusions. The single sentence provides no context for tool selection, leaving the agent to infer usage.

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

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

With no annotations, the description carries the full burden. 'Top keywords by frequency' reveals nothing about preprocessing (e.g., stop word removal), output format, case sensitivity, or language handling, leaving the agent without behavioral expectations.

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

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

The six-word description is concise but under-specified. It omits essential details about the tool's operation, making it too sparse to be considered 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 simple schema and absence of annotations/output schema, the description should still cover expected output and edge cases. It only indicates result type (keywords by frequency), leaving the tool's behavior largely undefined.

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

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

Schema coverage is 50%: 'text' has a tautological description and 'top_k' has none. The description adds no parameter context, failing to explain that top_k controls the number of keywords returned or any format requirements.

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 conveys the tool returns top keywords sorted by frequency, but lacks a clear verb or resource structure. It doesn't differentiate from sibling extraction tools like extract_emails or entity_extract, making the purpose somewhat implied.

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

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

No guidance is provided on when to use this tool vs alternatives like word_stats or extract_query. The intended use case is implicit from the name and description, with no exclusions or context.

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

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

With no annotations, the description must carry the full transparency burden. It only reveals that detection is heuristic, but does not disclose the output format, supported languages, confidence thresholds, or behavior with empty or multi-language text.

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

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

The description is extremely compact and front-loaded, with zero wasted words. While it is terse, the core purpose is immediately evident, and the brevity is not the primary issue—missing context is.

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 and no annotations, the description fails to specify the return format (e.g., ISO codes, language names), and offers no context about when this tool is appropriate relative to the diverse sibling set. The information provided is insufficient for an agent to fully predict its behavior.

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 'text' parameter already has 100% schema coverage with a description in the input schema. The tool description adds nothing beyond the schema, which is acceptable given full parameter documentation.

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 identifies the verb 'Detect' and resource 'language' with a heuristic qualifier, distinguishing it from foreign-language tools like translate_text. However, it stops short of explicitly stating the input is the 'text' parameter, which is clear only from the 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?

No guidance is given about when to use language_detect instead of sibling tools, nor any exclusions or preconditions. The description states only the core function, leaving the agent without decision criteria.

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 provided, so the description carries full responsibility for behavioral disclosure. It only states the basic action and fails to describe how lines are determined (e.g., newline handling, empty lines, trimming) or the effect of 'min_length'. This leaves significant behavioral ambiguity.

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 concise single sentence that directly conveys the core function. It is appropriately sized for a simple tool, with no wasted words, though it could be slightly more informative without becoming verbose.

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

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

For a simple text-splitting tool, the description is minimally adequate but incomplete. It lacks explanation of the 'min_length' parameter and edge-case behavior (e.g., empty lines, trailing newlines), which would be important for correct invocation. The absence of an output schema increases the burden on the description to set expectations.

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

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

Schema description coverage is 50%: 'text' is described as 'Input text', but 'min_length' has no description and the tool description does not clarify it. The description adds minimal meaning beyond the schema, leaving 'min_length' undefined and its default behavior unclear.

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 'Split text into lines' uses a specific verb ('Split') and resource ('text into lines'), clearly stating the tool's purpose. It distinguishes from sibling tools like 'chunk_text' by focusing on lines rather than arbitrary chunks.

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

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

The description provides no guidance on when to use this tool versus alternatives such as 'chunk_text', 'compare_texts', or other text-processing tools. It does not mention exclusions, prerequisites, or contexts where this tool is preferred.

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 bears full responsibility for behavioral disclosure. It states the operation is listing (read-only) but gives no details about return format, pagination, side effects, or permissions. The examples of recipe categories add slight context but insufficient behavioral depth.

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

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

The description is a single concise sentence that is easy to scan and front-loads the core function. No wasted words, earning high marks for efficiency.

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 two optional parameters and no output schema, the description is too minimal to be fully actionable. It lacks parameter explanations and return value details, making it incomplete for an agent to invoke with appropriate arguments.

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

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

The input schema has two parameters (`goal`, `domain`) with zero schema description coverage, and the description does not mention either parameter. The agent is left without any guidance on what these parameters control, such as filtering or sorting, which is a significant gap.

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

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

The description uses the specific verb 'List' and resource 'tool chain recipes' with examples (PDF, web, OCR, video), clearly distinguishing it from sibling tools like `run_chain` and `list_tools`. It effectively conveys the tool's function.

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

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

The description implies usage via the verb 'List' but provides no explicit guidance on when to use this tool over alternatives, nor any exclusion criteria. For example, it doesn't contrast with `run_chain` or `list_tools`. This is minimal but provides implied context.

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

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

No annotations are provided, so the description carries the full burden. 'List' implies a read-only operation, but the description does not explicitly state side-effect safety, authentication needs, or rate limits. It adds minimal behavioral context beyond the action itself.

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

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

The description is a single, front-loaded sentence with no redundant words. 'List REST API tools and pricing' is concise and directly states the purpose.

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

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

Given the simplicity (no parameters, no output schema), the description is largely complete: it states what the tool lists. It might benefit from stating the return format or that it is read-only, but the tool's simplicity keeps the information sufficient.

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

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

The tool has zero parameters and the schema is empty, so there are no parameters to clarify. The description adds no parameter-specific meaning, but the baseline for zero parameters is 4, and there is nothing missing.

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

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

The description uses a specific verb ('List') and resource ('REST API tools and pricing'), clearly distinguishing it from sibling tools like list_chains. The scope is explicit and unambiguous.

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

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

The usage is implied by the description: use this to see available tools and their pricing. However, it does not explicitly mention alternatives or exclusions (e.g., 'for chains, use list_chains'), so guidance is only implicit.

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 burden of behavioral disclosure. 'Discover site URLs' gives no insight into whether this is a read-only operation, whether it follows pagination, how many URLs it returns, or any rate limits or side effects.

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?

While extremely brief, this is under-specification rather than effective conciseness. The description provides no structure, headers, or additional context, and every word is generic.

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 2 parameters, no output schema, and no annotations. The description fails to explain what the tool returns, how parameters interact, or any behavioral context, making it completely inadequate 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?

The schema description coverage is 0%, and the description does not explain what 'url' or 'max_urls' mean beyond their names. The default of 50 for max_urls is unexplained, and the purpose of the tool in terms of parameter usage is completely unspecified.

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 phrase 'Discover site URLs' gives a vague verb+resource but does not specify the method or scope. It fails to distinguish from sibling tools like crawl, sitemap_parse, or extract_links, which all overlap with discovering site URLs.

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

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

No guidance is provided on when to use this tool versus alternatives. There is no mention of prerequisites, limitations, or comparison with sibling tools such as crawl or sitemap_parse.

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 should disclose the return format or edge-case behavior. It only says 'Split' without explaining whether the output is a JSON object, array, or plain text, nor how missing or malformed frontmatter is handled.

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

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

The description is extremely brief and contains no filler words, making it easy to read at a glance. However, the brevity comes at the cost of missing necessary behavioral details, so a 4 is appropriate rather than a 5.

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 parsing tool with no output schema and no annotations, the description is insufficiently complete. The agent cannot infer what output structure will be returned or how the splitting is performed, leaving a significant gap in context.

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

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

The schema already fully describes the sole parameter 'text' as 'Markdown document', so the description adds little beyond implying the input is Markdown. 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 uses the specific verb 'Split' and names three concrete Markdown components (frontmatter, headings, links), clearly indicating the parsing behavior. This distinguishes it from sibling tools like extract_links that focus on only one component, though it could be more explicit about the output structure.

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

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

No guidance is given about when to use this tool over alternatives such as extract_links or html_to_markdown. The description simply states what it does without indicating suitable use cases or exclusions.

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

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

With no annotations provided, the description alone must disclose behavioral traits, but it only states the action without detailing outcomes, error conditions, or operational nuances (e.g., what happens on no results, session requirements, or performance implications). This falls short of transparency expectations for a tool with no annotation support.

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

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

The description is extremely concise—a single short sentence—which is structurally simple and front-loaded. However, it is under-specified, lacking essential detail, making it more of a tautology than an informative description. Conciseness is present but at the expense of utility.

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 three parameters and no output schema, the description should explain what the tool returns and how the parameters affect behavior. The one-line description does none of this, making it grossly incomplete for an agent to use effectively. No context about session memory or search semantics is provided.

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

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

Schema description coverage is 0%, and the description does not explain any of the three parameters (session_id, query, limit). The tool name and description simply say 'search memory,' leaving parameter semantics entirely unexplained, which is insufficient for effective invocation.

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 'Search session memory' clearly identifies the action (search) and the resource (session memory), effectively distinguishing it from sibling tools like memory_store. It is specific enough for basic disambiguation, though it could elaborate on the scope of 'session memory'.

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

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

The description implies usage for querying session memory but provides no explicit guidance on when to use this tool versus alternatives. The sibling memory_store suggests a contrast, but it is not mentioned. No exclusions or conditions are stated, leaving usage inferred rather than explicit.

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

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

With no annotations, the description carries the full burden of behavioral disclosure. It only says 'store', which implies a mutation, but does not mention whether it overwrites existing values, if it is idempotent, requires any authentication, or what the response looks like. This is a significant gap for a write operation.

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, short sentence that is immediately clear and front-loaded. It contains no unnecessary words or repetition. It is appropriately concise for a tool with a simple purpose, even if that conciseness trades off completeness.

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 3-parameter tool with no output schema and no annotations, the description should still provide behavioral context and return information. It does not mention whether the store is an upsert, how to retrieve it (though memory_search exists), or any error conditions. The agent lacks essential information to invoke this tool properly in complex scenarios.

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

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

Schema description coverage is 0%, so the description must compensate for all three parameters. It does not explicitly describe any of the parameters; the names (session_id, key, value) are somewhat self-explanatory, but the description does not clarify format, uniqueness, or semantics beyond the obvious. The agent has to guess at the intended usage of each field.

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 what the tool does: it stores a memory note in a session. The verb 'store' and resource 'session memory note' are specific enough to distinguish from the sibling memory_search, which retrieves. However, it lacks details about whether this is an insert/update or how it differs from other potential memory 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?

There is no explicit guidance on when to use this tool versus alternatives. The sibling memory_search is different, but the description does not mention it or explain usage context, prerequisites, or when not to use this tool. The agent is left to infer based on the name.

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 does not disclose key behavioral aspects such as join type (inner vs outer), duplicate key handling, order preservation, or possible mutation of inputs. With no annotations provided, the description carries the full burden and fails to provide transparency beyond the basic operation.

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

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

The description is a single, concise sentence that front-loads the action and resource. There is no redundancy or filler; it earns its place perfectly.

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

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

Given the complexity of a join operation (join semantics, unmatched records, duplicate keys, output format), the one-sentence description is inadequate. No output schema or annotations exist to supplement, leaving the agent without essential information about behavior and results.

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 only 33% (key is described, records_a and records_b are not). The tool description does not compensate: it doesn't explain the roles of records_a vs records_b, expected list structure, or how the key relates to the nested objects. The description merely restates the schema's 'key' notion without adding semantic clarity.

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 'Join record lists by key' uses a specific verb (join) on a specific resource (record lists) with a specific mechanism (by key). It clearly distinguishes from siblings as no other tool focuses on joining/merging records, making the core 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 implied usage is to combine two sets of records on a common key, but no explicit when-to-use guidance, exclusions, or alternatives are given. The context is inferred solely from the tool 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?

With no annotations, the description carries the full burden of behavioral disclosure. It only states 'URL change monitor' without revealing how monitoring works, whether it requires webhooks, what triggers alerts, or what the output represents. This is minimal and insufficient.

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?

While the description is extremely short, this is under-specification rather than conciseness. The single phrase fails to convey necessary operational 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?

For a tool with 3 parameters, no annotations, and no output schema, the description is severely inadequate. It does not explain behavior, return values, or parameter semantics, leaving the agent with insufficient information to invoke it correctly.

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

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

The input schema has 0% description coverage, and the description does not explain the meanings of 'webhook' or 'interval_hours'. 'url' is implied, but the other two parameters are entirely undocumented in both schema and description.

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

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

The description 'URL change monitor' identifies the tool's function as monitoring URL changes, but it lacks a specific verb and scope (e.g., polling frequency, notification mechanism). It is distinguishable from siblings like diff_url but does not clearly state the monitoring behavior.

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

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

No guidance is provided on when to use this tool versus alternatives such as diff_url, cache_url, or read_url. The description offers no context for appropriate use cases or exclusions.

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

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

No annotations are provided, so the description must carry the full burden. It does not state whether the tool returns the full text with dates replaced, a list of normalized dates, or how it handles invalid or ambiguous date formats. The minimal description leaves significant ambiguity.

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 exceptionally concise at six words, with the core action and target in the front. Every word earns its place, with no filler or 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 one-parameter tool with no output schema, this is minimally viable but incomplete. The description does not explain the return value format (e.g., modified text vs. extracted dates), which is essential for an agent to use the result correctly. It is adequate for low complexity but lacks edge-case handling.

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 100% of parameters, and the 'text' parameter is described as 'Text containing dates'. The description adds only the normalization context, which is already implied by the tool name. Baseline 3 is appropriate since 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 'Find and normalize dates to ISO' uses a specific verb ('find and normalize') and a clear resource ('dates'), converting them to a standard format. It distinguishes itself from sibling tools like extract_emails or extract_phones by targeting dates specifically.

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

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

The description implies usage when text contains dates, but provides no explicit guidance on when to choose this over alternatives or any exclusions. It is adequate but under-specified relative to the sibling toolset.

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 provided, so the description is the sole source of behavioral context. It only states the action without mentioning output format, error behavior, limitations, or authentication requirements. For a tool with no annotations, this is a significant gap.

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

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

The description is a single concise sentence that immediately states the tool's purpose. There is no waste, and the key information is front-loaded. This is exemplary in terms of brevity.

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

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

For a simple tool with one parameter and no output schema, the description covers the core purpose but omits return value details and potential use cases. It is adequate for basic understanding but leaves gaps in context, such as what the output looks like and when to prefer this over ocr_url or ocr_table_url.

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 has a single 'url' parameter with no description (0% coverage). The description adds the context that the URL must point to an image, which provides some meaning, but it does not clarify required URL formats, accessibility, or other constraints. This is minimal compensation for the lack of schema descriptions.

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

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

The description 'OCR text from an image URL' clearly states the action (OCR) and the resource (image URL), making it easy to understand. It implicitly distinguishes from ocr_table_url by specifying 'image', but does not explicitly contrast with sibling tools like ocr_url, preventing a perfect score.

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

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

The description implies when to use this tool (when OCR text from an image URL is needed) but provides no explicit guidance on alternatives or exclusions. Given sibling tools like ocr_table_url and ocr_url, explicit differentiation would be valuable, but the usage is still inferable.

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 burden for behavioral disclosure. It only says 'OCR table from image URL' and does not mention return format, failure modes, supported image formats, or side effects, which is insufficient for a tool with no structured annotations.

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

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

The description is a single five-word sentence, front-loaded with the action and subject. There is zero redundant information, making it highly efficient.

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

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

While the tool is simple (one parameter, no output schema), the description does not compensate for the absence of annotations or explain expected outputs or use cases. Given the large number of sibling tools with overlapping functionality, this description is not sufficient for confident 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?

The schema has one parameter 'url' with no description and 0% coverage. The description adds that this is an 'image URL', providing minimal but useful semantic context beyond the raw schema. It does not clarify format, size limits, or other constraints.

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

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

The description clearly states the action (OCR) and the resource (table from an image URL), which is specific enough to convey the core purpose. However, it does not distinguish itself from close sibling tools like ocr_image, ocr_url, or ocr_table_url, so it doesn't fully separate from alternatives.

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

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

No guidance is provided about when to use this tool versus the many sibling OCR and table extraction tools. The description only says what it does, leaving the agent to infer the appropriate context without exclusions or alternatives.

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

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

With no annotations, the description carries the full burden of behavioral disclosure, but it only states the operation. It omits details about output format, potential errors, whether the image is downloaded, or any rate limits or side effects.

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

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

The description is a single, front-loaded sentence with no extraneous words. For a one-parameter tool, this is appropriately concise.

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

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

There is no output schema, so the description should explain return values, but it does not. It also lacks usage context and alternative references, making it incomplete for a tool that ostensibly returns extracted table 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%; the url parameter is already documented as 'Image URL with table'. The tool description adds no extra semantic detail beyond repeating the source. 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 'OCR table from image URL' uses a specific verb (OCR) and resource (table) plus source (image URL), clearly distinguishing it from sibling tools like ocr_image, ocr_table, and ocr_url. It precisely communicates the tool's scope.

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

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

No guidance is provided on when to use this tool versus alternatives. It does not mention related tools like ocr_table, ocr_url, or table_extract, nor any exclusions or prerequisites.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states the function without detailing side effects, input constraints, output format, or any safety characteristics. The read-only nature is implied but not stated.

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, making it highly concise and front-loaded. The '(for chains)' note adds minimal value but does not detract significantly. Every word earns its place.

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

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

For a one-parameter tool with no output schema, the description provides minimal context. It does not explain the return format or limitations, though 'OCR text' implies the output is extracted text. Given the absence of annotations, more detail could be expected, but the tool's simplicity keeps it viable.

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% for the 'url' parameter, so the baseline is 3. The description does not add semantic nuance beyond the schema; it merely restates 'image URL'. No additional parameter explanation is needed given the schema's completeness.

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

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

The description clearly states the tool performs OCR on an image URL with a specific verb and resource. It distinguishes from sibling tools like ocr_image and ocr_table_url by the URL-based input, though it does not explicitly name alternatives.

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

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

The description provides no explicit guidance on when to use this tool versus alternatives. The parenthetical '(for chains)' hints at intended use in a chain pipeline but lacks contextual direction or exclusions. Usage must be inferred solely from the tool name.

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 must carry the burden of behavioral disclosure, but it offers none. It does not state whether the tool fetches the page, classifies links as internal/external, returns only external links, or exhibits any side effects or response behavior.

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

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

The description is extremely short but under-specified. It is not a well-structured summary but a bare phrase, so it does not earn its place despite being concise.

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

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

The tool has no annotations, no output schema, and two parameters, yet the description provides no context about return values, link classification semantics, or operational behavior. It is completely inadequate for an agent to select and invoke the tool correctly.

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

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

The description adds no meaning to the input schema. Schema coverage is only 50% (the 'timeout' parameter lacks a description), and the description does not mention either parameter or clarify how they affect tool behavior.

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 'Internal vs external links' is a fragment that restates the tool's name rather than stating what the tool does. There is no verb or explicit resource/action, and it does not differentiate the tool from siblings like extract_links or page_metadata.

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

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

The description provides no guidance on when to use this tool versus alternatives such as extract_links or page_metadata. There is no mention of intended use cases, exclusions, or prerequisites.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure, but it reveals nothing about whether the tool fetches the page, the output shape, error behavior, or whether it returns only OpenGraph tags or all meta tags.

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 short, but this is under-specification rather than conciseness. A single vague fragment ('OpenGraph / page metadata.') earns its place no better than the tautological 'Process' example.

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 1-parameter tool with no annotations and no output schema, a description like 'Returns OpenGraph and other meta tags from the HTML head of the given URL' would be complete. This description provides only a vague label and leaves the agent to guess the tool's behavior and return value.

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

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

Schema description coverage is 0%, so the description must compensate for the undocumented 'url' parameter. Although the parameter's purpose is loosely inferable from the tool name, the description adds no detail about expected URL format, restrictions, or how the URL is used.

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 'OpenGraph / page metadata' is a noun phrase that restates the tool name ('page metadata') with only the narrow hint of 'OpenGraph' added. It lacks a verb, so an agent cannot tell whether the tool fetches, extracts, or validates metadata, and it does not distinguish the tool from siblings like read_url or extract_url.

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

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

No guidance is provided on when to use this tool versus related siblings such as read_url, pdf_metadata, extract_url, or cache_url. There are no conditions, prerequisites, or exclusions stated.

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 provided, so the description must carry the full transparency burden. It only mentions 'cheap' and lists outputs, but does not disclose whether it performs a network request, potential side effects, failure behavior, or how the data is gathered. This is a significant gap for a tool that likely hits external URLs.

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

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

The description is a single concise line that gets to the point immediately, using a leading adjective ('Cheap') and a focused list of outputs. Every word counts and there is 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 has no annotations and no output schema, the description should provide richer context about behavior, return format, and parameter semantics. It only offers a high-level summary, leaving the agent uncertain about how to use it correctly or interpret its results.

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

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

Schema description coverage is 0% and the description adds no meaning for the parameters. While 'url' is self-evident, 'peek_bytes' is completely unexplained. The description's listed items are outputs, not parameter details, so it fails to compensate for the schema's lack of descriptions.

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

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

The description clearly states a specific verb ('preflight') and resource ('URL'), and lists concrete data points (title, h1, js_hint, recommended_mode) that it returns. This distinguishes it from a full fetch like read_url, but it does not explicitly compare to siblings.

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

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

The term 'cheap' implies use for lightweight quick checks, but there is no explicit guidance on when to use this tool vs alternatives like read_url, crawl, or page_metadata. No exclusions or alternative names are provided, leaving the agent to infer usage context.

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

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

There are no annotations, so the description carries full responsibility for behavioral disclosure. It only says 'PDF metadata without full extract', which does not detail what metadata is returned, whether the operation is read-only, or any error/limit behavior. This is a significant gap in transparency.

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

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

The description is extremely brief, using only five words, and is front-loaded with the key purpose. It is concise without unnecessary filler, though the terseness might sacrifice some clarity.

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

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

With no output schema, no annotations, and a very short description, the tool lacks enough context to understand what metadata will be returned or any side effects. The single parameter is documented, but the description does not compensate for the missing output information, leaving the tool incomplete for effective use.

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

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

The input schema fully describes the single parameter 'url' with 'PDF URL', providing 100% schema coverage. The description does not add additional meaning to the parameter, such as accepted formats or validation rules, but since the schema is sufficient, a 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 'PDF metadata without full extract' clearly indicates the tool retrieves metadata from a PDF, distinguishing it from the sibling tool 'extract_pdf' that likely performs full extraction. However, it lacks an explicit verb like 'extract' or 'get', making it slightly less direct.

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 phrase 'without full extract' implies the tool is suitable when only metadata is needed, but it does not explicitly state when to use it instead of alternatives such as 'extract_pdf'. No exclusions or alternative tool names are mentioned.

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

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

With no annotations provided, the description bears the full burden of behavioral disclosure. It only states the core action (extracting text) but does not mention side effects, requirements (e.g., internet access for URL), limitations (e.g., page bounds), or return behavior. This is insufficient for a tool that likely performs file downloads and processing.

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

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

The description is a single concise sentence that front-loads the core purpose. There is no redundancy or wasted words, making it easy for an agent to quickly understand the tool's basic function.

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

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

Given the tool has 3 parameters, no output schema, and no annotations, the description is far too sparse. It does not explain return format, error conditions, or how page ranges are validated. This is a minimal viable description at best; for a tool of this complexity, more context 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 67%, with descriptions for url and end_page but not start_page. The description's phrase 'page range' adds context connecting start_page and end_page, but it doesn't explain the default behavior of start_page (covered by schema default) or the meaning of 'inclusive' beyond the schema. It partially compensates but adds limited value.

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 'Extract PDF page range text' clearly specifies the action (extract text) and the resource (PDF page range), distinguishing it from generic PDF extraction tools like extract_pdf. However, it doesn't explicitly differentiate from siblings such as pdf_metadata or ocr_url, leaving some ambiguity about the exact output format.

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

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

The description provides no guidance on when to use this tool versus alternatives like extract_pdf or pdf_metadata. It does not mention prerequisites, use cases, or exclusions, leaving the agent without context for choosing this tool.

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

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

No annotations are present, so the description must carry the full burden of behavioral disclosure. It mentions redaction but does not explain whether it mutates input, what the output structure is, or any security implications, leaving significant gaps.

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

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

The description is extremely concise with no filler words, making it quick to parse. However, it is under-specified, trading important context for brevity, which is not ideal for the tool's complexity.

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

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

There is no output schema or annotations, so the description must provide complete context. It only covers the core function, missing PII categories, redaction behavior, return value details, and any usage nuance, making it insufficient for an 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?

The schema only describes 'text' while 'redact' lacks a description. The description's 'optional redact' adds minimal nuance beyond the schema's default, but does not clarify how redaction affects the output or how text should be formatted. Since schema coverage is only 50%, the description should compensate but doesn't.

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 detects PII and optionally redacts it, using a specific verb and resource. It distinguishes itself from sibling tools like extract_emails or extract_phones by covering PII broadly, but lacks detail on what PII types are included.

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

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

The description provides no guidance on when to use this tool versus alternatives, no prerequisites, and no exclusions. It is a bare statement of function with no usage context.

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

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

No annotations are provided, so the description must disclose behavioral traits. It only says 'Plan workflow steps for a goal (free).' It does not indicate whether this is a read-only operation, what the output looks like, whether it requires further actions, or any side effects. The '(free)' hint is about cost, not behavior.

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

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

The description is a single, concise sentence with no filler, which is efficient. However, it is under-specified, failing to include necessary context about usage, output, or parameters. It is not egregiously terse like 'Process', but it falls short of effective communication.

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

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

For a tool with one parameter, no output schema, and no annotations, the description should provide enough context to understand its behavior and output. It does not explain what 'plan workflow steps' means in terms of return value, whether it is a one-time generation or a stateful plan, or how it relates to workflow execution tools. The description is largely inadequate.

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

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

The input schema has one parameter 'goal' with no description (0% coverage). The description mentions 'for a goal,' which maps to the parameter and indicates its purpose, but it does not explain expected format, constraints, or examples. This minimal compensation is insufficient for an agent to know how to fill the parameter correctly.

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: 'Plan workflow steps for a goal.' It uses a specific verb (plan) and resource (workflow steps for a goal). However, it does not explicitly distinguish itself from sibling tools like 'run_mission' or 'workflow_stateful', which also deal with workflows or goals.

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