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

With no annotations provided, the description carries the burden of disclosing behaviors. It discloses that the tool fetches fresh papers, picks passages, highlights, and verifies verbatim, and that tags default to the claim. This is substantial behavioral context. It doesn't mention potential costs (e.g., network calls) or error conditions, but the main behaviors are transparent.

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

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

The description is a single, densely packed sentence that communicates the core value proposition and key actionable steps. It could be improved by breaking into two sentences for readability, but it is efficient and front-loads the main purpose. No filler words.

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

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

Given the tool's moderate complexity (2 params, no enums, has output schema), the description covers the main behavior, parameter semantics, and usage instructions. The output schema likely conveys return value structure, so the description doesn't need to explain that. A minor gap is not specifying what happens when no new cards are found or how the 'verification verbatim' works in practice, but overall it's complete enough for an agent to use correctly.

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

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

Schema description coverage is 0%, so the description must compensate. It explains that 'claim' is the claim to find evidence for, and 'max_new' is the maximum number of new cards to auto-cut. However, it doesn't detail the format of 'max_new' (e.g., default 4) beyond the schema's default, and it doesn't explain the relationship between existing and new cards further. The description adds some meaning but not exhaustive.

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 ('find evidence'), a resource (already-cut library cards plus auto-cut new cards), and the multi-step process it automates. It distinguishes itself from siblings like 'search_cards' and 'suggest_cut' by combining retrieval and new card creation in one step.

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 you have a claim and want evidence in one step, combining existing and new cards. It also gives guidance on how to use the results (rewrite tags, check quals). It does not explicitly mention alternatives like 'search_cards' or 'suggest_cut' as separate options, but the immediate context is clear.

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

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

With no annotations, the description carries the disclosure burden, and it does well: it reveals background execution, one-time/resumable semantics, estimated durations, and library contents. It does not mention authorization requirements or whether a rebuild overwrites existing data, but the core behavioral traits are clearly disclosed.

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 key purpose and monitoring signal are front-loaded, and there is no filler. The mode explanation is dense and encoded in a long parenthetical, but it remains compact and information-rich.

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

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

For a single-parameter background setup tool with an output schema, the description covers the essential operational details: one-time nature, resumability, progress via library_status, mode options, duration, and scope. Nothing critical is missing for correct invocation.

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

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

The schema only defines mode with a default and no description or enum, so the description must compensate. It fully defines the three mode values, the default, and the practical difference between them, giving the agent everything needed to choose 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 operation: install/build the card library, and distinguishes it from siblings like search_cards and library_status. It also names the concrete modes (download, quick, full), so an agent understands exactly what resource is affected and how.

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

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

The description gives explicit usage context: it is one-time and resumable, progress should be checked via library_status, and the mode choices are explained with tradeoffs (prebuilt vs raw dataset, minutes vs hours). This tells the agent when to use this tool and which mode fits the need.

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 burden. It explains that the tool imports cards as new cN ids, implying mutation of the library, but does not disclose side effects such as whether it modifies existing cards, requires network access, or is idempotent. This is a moderate disclosure, but gaps remain.

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, compact sentence that front-loads the primary action ('Download an open-source .docx from OpenCaselist') and efficiently adds source guidance. No unnecessary fluff; though it packs multiple clauses, it remains readable.

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 input (one string) and presence of an output schema, the description covers the core purpose, path sourcing, and outcome. It does not mention error handling or prerequisites like network connectivity, but these are minor given the output schema will convey 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?

The only parameter 'path' has 0% schema coverage, so the description must add meaning. It does by specifying the path comes from caselist_team or a search 'download_path', giving practical guidance. However, it does not specify the path format (e.g., URL vs. file path), leaving some 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 clearly states the action: download a .docx from OpenCaselist and import its cards as cN ids. It specifies the resource (OpenCaselist) and the outcome (cards you can read, analyze, re-cut, or export), which distinguishes it from siblings like search_cards (search) and get_card (retrieve existing).

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

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

It provides context on where to get the path (caselist_team or search 'download_path') but does not explicitly state when to use this tool versus alternatives like get_card or export_doc. The intended use is implied by the download/import action, but no explicit when-not-to-use guidance is 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?

No annotations are provided, so the description must carry the full burden. It discloses the return contents ('disclosed or not, round count, recent open-source doc paths... and cite titles') and input formats, but does not explicitly state that the operation is read-only, mention any authentication requirements, rate limits, or error behavior. It adds useful output details but lacks a full behavioral profile.

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

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

The description is two sentences with the primary purpose front-loaded. It packs essential information (input format, output highlights, follow-up instruction) without excessive verbosity. It could be slightly more structured (e.g., separating input and output), but it is efficient and readable.

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

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

Given the existence of an output schema, the description need not detail return values beyond what it does. It covers the core purpose, input format, and workflow context, but the unexplained 'caselist' parameter is a notable gap. Overall, it provides sufficient information for an agent to decide when and how to call the tool correctly, but not exhaustive.

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 thoroughly explains the 'entries' parameter (CSV export format or one-line-per-team example), which is critical since schema coverage is 0%. However, the optional 'caselist' parameter is not mentioned at all, leaving its purpose and format unspecified. This partial compensation gives it a middle score.

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

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

The description states a specific action ('scout a whole tournament field') and resource ('every entry to its caselist page') in one call. It clearly distinguishes from siblings like caselist_search (single team lookup) and caselist_download (specific doc retrieval) by emphasizing batch matching of tournament entries.

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

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

The description provides clear context for when to use this tool: when you need to process a full tournament field. It also mentions a follow-up workflow ('Then follow pf-scout "Prep out a tournament"') and indicates that the output feeds into caselist_download. However, it doesn't explicitly state when NOT to use it or name alternatives like caselist_team, leaving some room for inference.

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

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

With no annotations, the description carries the behavioral burden and does so well: it discloses the rate limit (4/min), the default scope, and the accepted search types. It does not describe result shape, but an output schema exists to cover that.

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

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

Three sentences with no filler. The primary action and search options are front-loaded, the default behavior is stated, and the rate limit is appended cleanly.

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

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

For a two-parameter search tool with an output schema, the description covers the essential decision points: what to search, which caselist, default behavior, and rate limiting. The only gap is lack of explicit mention of matching behavior or empty-result handling, but this is minor.

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 explains query as a team, debater last name, or argument text, and caselist as an optional slug with a concrete example. This is useful, though it leaves minor details like query syntax 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?

States a specific verb ('Search') and resource ('OpenCaselist'), and names three concrete search dimensions: team, debater last name, or argument text. The phrase 'disclosed cases' clarifies scope and differentiates it from sibling tools like fetch_source or caselist_download.

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

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

Provides clear context by noting the default current HS PF caselist and how to target older ones via a slug. It does not explicitly name alternatives or exclusion conditions, so it stops short of a 5.

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

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

With no annotations provided, the description must carry the full burden of disclosing behavior. It only says what the page contains (rounds and cites) and implies a read operation by calling it a 'page', but it does not disclose any side effects, auth requirements, error behavior, or whether the data is publicly accessible. 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 two sentences with no filler, front-loading the resource and its content before the use case. Every piece of information (page contents, purpose) is relevant, though it could be slightly tighter by merging the final clause, but overall 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?

Given no output schema and no annotations, the description should explain the return structure and parameter behavior. It lists the fields present (tournament, side, opponent, etc.) but does not cover how parameters filter or shape the result, what the optional 'caselist' does, or any edge cases. It is only partially complete for a simple retrieval 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%, so the description must compensate for three undocumented parameters. It only implies that school and team identify the team, and does not explain the 'caselist' parameter or its default null behavior. The description adds minimal value beyond the raw schema.

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

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

The description clearly identifies the tool as returning a team's caselist page with specific content (rounds and cites). It is highly specific about the resource, but it lacks an explicit verb like 'fetch' or 'get' and does not directly contrast with sibling tools such as caselist_search or caselist_download.

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 states a clear use case ('Use for scouting and building blocks against their case'), which gives context for when to call it. However, it does not mention alternatives, when not to use it, or how it differs from sibling tools like caselist_search or caselist_download, leaving the guidance implied 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 behavioral burden. It explicitly discloses that quotes must be verbatim, which characters are normalized, that mismatches are rejected with a hint, and how highlight/underline defaulting works. It doesn't describe side effects of re-cutting an existing card, but the core validation behavior is transparent.

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

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

The description is a single dense paragraph with no wasted sentences; every rule earns its place. It could be improved with structured parameter formatting, but it remains readable and front-loads the most important semantic definition of the body quote.

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 13-parameter tool with no annotations and an output schema present, the description covers the critical selection, validation, and re-cutting behavior. It is missing definitions for some required metadata fields, but the agent has enough to invoke the tool correctly in the main workflow.

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%, so the description must compensate. It does explain start_quote, end_quote, highlight, underline, source_id, and paragraph well. However, it leaves several required parameters—especially tag and quals—undefined, forcing the agent to infer their meaning from names alone.

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

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

The description states a specific action ('Cut an evidence card') and defines what that means: preserving exact source text from start_quote to end_quote. It clearly differentiates this from sibling tools like fetch_source, search_cards, and get_card by describing a card-creation/recutting operation.

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

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

It gives concrete usage context: source_id comes from fetch_source, and a card id (cN, lib:N) can be used to re-cut an existing card. It does not explicitly say 'use this instead of search_cards/get_card', but the intended workflow and alternatives are reasonably clear from 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 carries the full burden and does well: it explains what the file contains, how each format/version behaves, and that it returns the file path. It stops short of disclosing side effects like overwriting behavior or where the file is written, which is a minor 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 dense but organized: item syntax first, then format options, then version options, then return value. Every sentence adds useful information, though the compact notation may require careful parsing.

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

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

Given the tool's complexity and the absence of annotations, the description covers the essential call path: how to construct items, what formats/versions do, and what is returned. The main missing piece is behavior around 'filename' and potential overwrites, but the overall guidance is sufficient 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 description coverage is 0%, so the description must compensate. It thoroughly explains the 'items' array format, including valid dict shapes, verbatim headings, retagging syntax, and the meaning of 'format' and 'version'. It does not explicitly define 'filename' or 'title', though those are relatively self-evident from the schema.

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

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

The description opens with a specific verb and resource: 'Write a speech doc / case / block file.' It then details the item structure, formats, and versions, making it easy to distinguish from sibling tools like read_speech, cut_card, or caselist_download.

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

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

The description gives clear when-to-use guidance for formats ('docx' for Verbatim, 'gdocs' for Google Docs users) and versions ('full' for the email-chain file, 'read' for speaking from). It does not explicitly name alternative tools or state when not to use this tool, but the context is strong.

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 behavioral burden. It discloses that output is formatted as 'clean numbered paragraphs + citation metadata' and explains paging behavior via start_paragraph. This is meaningful context beyond the schema, though it stops short of covering error or access behaviors.

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

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

Three sentences, each earning its place: the core purpose and output format, pagination guidance, and a directive about cut_card quote fidelity. The most important information is front-loaded and there is no filler.

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

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

The tool is simple and the description covers the core behaviors, input modes, and pagination. An output schema exists, so return-value details are not required. The only notable gap is the lack of guidance on relationship to sibling source-finding tools, but the description remains sufficient 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 description coverage is 0%, so the description must compensate for the bare parameter names. It does so fully: url_or_id is explained as either an article/PDF URL or a fetched-source id, and start_paragraph is explained as the pagination continuation mechanism. Both parameters are semantically clear.

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 ('Fetch') and resource ('article/PDF' or a previously fetched source by id), and describes the output as numbered paragraphs plus citation metadata. It does not explicitly differentiate from sibling tools like find_sources, so it falls just short of 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 description gives clear operational context: fetching a source, re-opening a fetched source, and paging long sources. However, it does not explicitly state when to prefer this tool over sibling tools such as find_sources or search_cards, nor does it provide 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 behavioral burden. It discloses that the tool is 'Free and keyless', that busy services are reported as 'skipped', and that results are recent and enriched with affiliations and PDF links. This goes beyond the bare schema, though the exact return structure and broader failure modes remain implied.

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

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

The description is three tight sentences that front-load the main purpose and then add operational details about kinds, free/keyless access, skipped services, and the next workflow step. It is slightly dense but contains no wasted sentences.

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 three-parameter tool with no annotations and no output schema, the description covers the essential selection and invocation context: result substance, defaults, auth requirements, busy-service behavior, and the subsequent fetch/cut workflow. The main remaining gap is the 'limit' parameter.

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 does define 'kinds' and its default ('papers', 'news' default both), but it gives no explicit semantics for 'query' or 'limit'. The query's meaning is inferable from the tool's purpose, but 'limit' is left 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?

Description states a specific verb and resource: 'Find NEW evidence to cut: recent scholarly papers (with author affiliations for quals and free PDF links) and current news articles.' It also references the downstream workflow with fetch_source, which helps distinguish it from search-oriented siblings, though it does not explicitly contrast with search_cards or caselist_search.

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

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

It gives clear context for when to use the tool: as the first step in finding new evidence to cut, followed by 'fetch_source a result's url and cut it.' It also explains the behavior of the 'kinds' parameter and the 'skipped' case. However, it stops short of explicitly stating when not to use it or naming alternative tools.

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

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

No annotations are provided, so the description carries the burden. It discloses that 'read' view omits text (skipped marks), 'full' returns the whole body, and highlights how highlighted/underlined text is represented. This is meaningful behavioral detail beyond the schema.

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

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

The description is compact and front-loaded with the core purpose, then explains the two views efficiently. Every sentence adds value, and the formatting with view labels is scannable.

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 (2 params, no enums) and the presence of an output schema, the description covers the key decision (which view to use) and the identifier format. It doesn't mention error cases or return structure, but the output schema likely covers that, and the description is sufficient 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%, so the description must compensate. It explains the 'view' parameter's two values and their effects, and implies card_id format (lib:N or cN). It doesn't detail the exact string format for card_id beyond examples, but the core semantics are covered.

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

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

The description clearly states the tool retrieves a card by ID and distinguishes two views: 'read' (compact) and 'full' (whole body). It names the resource (card) and the identifier format (lib:N or cN), making the purpose specific and actionable.

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

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

The description explains when to use each view: 'read' for compact reading, 'full' for judging context, finding indicts in unhighlighted text, or recutting. It doesn't explicitly name alternatives among siblings, but the view guidance provides clear context 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. It does not state whether the operation is read-only, whether it triggers any side effects, or what the exact return format is. For a status tool this is acceptable, but the lack of any behavioral disclosure beyond the content list is a 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?

A single, efficient sentence that front-loads the main purpose and lists the key details. It is concise without being 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 parameterless status tool, the description covers the main information it returns (built status, per-event counts, years, progress). No output schema exists, so the description compensates adequately. It could mention return format, but for a status tool this is minor.

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?

There are zero parameters, so the baseline of 4 applies. The schema is empty and the description correctly implies no inputs are needed. Nothing more is required.

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 resource (the local card library) and the kind of information it provides (status, counts, coverage, progress). It is clear and distinct from siblings like build_library (which builds) and search_cards (which searches), 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?

No guidance on when to call this tool versus alternatives. It does not mention that it is a pre-build check or that it complements build_library. The agent must infer its role.

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 behavior. It usefully discloses the reading order and the topical structure, including the parenthetical clarification that pf-blockfile means team block files. However, it does not explicitly state that invoking the tool with a particular 'name' returns that guide's content, nor does it describe any error or fallback 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 compact, front-loaded with the core purpose, and every element contributes information. The reading order, task guides, and references are each presented as short lists with no redundancy or filler.

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

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

The tool is simple: one optional parameter with a default, an output schema is present, and no annotations are needed for a read-only knowledge-reference tool. The description names the default guide and all available guides, which is enough to select and invoke it. The only gaps are the implicit name-to-guide mapping and the lack of explicit sibling-tool routing, but these are minor given the low complexity.

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

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

The schema has 0% description coverage, so the description must compensate, and it does. It effectively enumerates the valid values for the single 'name' parameter: pf-debate, the task guides, and the reference topics. It does not explicitly say 'name accepts one of these values,' but the list serves as the defacto parameter vocabulary.

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 identifies a specific, recognizable resource: PF debate knowledge, and enumerates its task guides and references. It is clearly distinct from sibling tools like cut_card or caselist_search because those work with cards/caselists while this provides guides and reference material. It lacks an explicit verb like 'retrieve' but the resource and content list make the purpose clear.

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 instruction 'Read "pf-debate" first' gives a clear starting point and the task-guide list implies which guide to select for a given task. However, it never explicitly says when to use this tool instead of sibling tools like cut_card, get_card, or caselist_search, nor does it state when not to use it. Usage guidance is implied rather than directly contrasted with 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 behavioral burden and it pays off: it states counting is exact, never estimate, explains that a card counts tag/short cite/highlighted words only, and notes highlighting cannot be seen in pasted text. It doesn't explicitly state side-effect behavior, but the read-and-return framing makes the read-only nature reasonably clear.

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

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

The opening sentence states purpose, then each parameter is explained in its own compact block with no filler. Despite covering detailed counting rules, it stays readable and every sentence contributes actionable 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?

An output schema exists, so return-format detail is not required. The description covers when to call it, how to shape inputs for both card-based and plain-text cases, the valid speech names and their timing, and the meaning of wpm. This is complete for an agent to invoke the tool correctly.

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

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

Schema coverage is 0%, so the description must compensate, and it does fully: items is defined with the export_doc list format plus card-counting and plain-text rules; speech lists the four named speech types with durations; wpm gives pace guidance and defaults. Every parameter is given meaning beyond its title/schema.

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

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

The description names a specific verb and resource: 'Time a speech exactly and return its read-ready script', and immediately ties it to checking fit before export and deciding what to trim. This distinguishes it from export_doc and trimming tools without needing to open their schemas.

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

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

'Use it to check a case fits before exporting, and to see what to trim' gives clear invocation context, and the plain-text note explains how to pass pasted cases. It doesn't explicitly list when-not-to-use or name an alternative tool, but the context is strong enough for an agent to select it appropriately.

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

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

With no annotations, the description carries the full burden and it does a good job: it explains hybrid vs keyword search behavior, library vs mine scope semantics, and that 'popular' is a quality signal for impact cards. It doesn't explicitly state the operation is read-only or mention rate limits, but for a search tool the behavior is clearly disclosed.

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 purpose is front-loaded in the first sentence, and the parameter list is dense and readable. Every sentence adds useful context, though the scope line could be tightened slightly.

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

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

The description covers most parameters and gives strong guidance for effective searching, but it omits year_from and limit documentation and never addresses alternative tool selection. Since an output schema exists, the lack of return-format explanation is acceptable, but the missing parameter semantics keep it from being complete.

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

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

Schema description coverage is 0%, so the description must compensate. It explains mode, scope, sort, side, and event with concrete values and meanings. However, limit and year_from are left undocumented, and the query parameter is only implied by the intro sentence, leaving a noticeable 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 clearly states 'Search already-cut debate cards' with a specific verb and resource, and immediately clarifies that plain English and debate shorthand work. However, it doesn't explicitly distinguish itself from the sibling caselist_search, relying on the word 'already-cut' to imply the difference.

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

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

The description gives useful context about search modes, scope, and sort meaning, plus a tip to try alternate phrasings. But it never explicitly says when to prefer this tool over caselist_search or other siblings, and there are no when-not-to-use 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?

No annotations are provided, so the description must carry the behavioral disclosure. It mentions the output fields (start_quote, end_quote, etc.) and says it returns exact source text, but it does not explicitly state whether the tool mutates anything or requires special permissions. The word 'suggest' implies non-mutating, but this is not made explicit, so the disclosure is partial.

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

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

The description is two sentences, front-loaded with the core purpose ('Suggest a card for claim from a fetched source'), then explains the output and next step. No fluff or redundant details; every sentence earns its place.

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

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

For a 2-parameter tool with an output schema (though not shown), the description covers the workflow, input source, output fields, and how to use the result. It could mention that the source must already be fetched, but that is implied by 'from a fetched source'. It is sufficient for an agent to call it correctly.

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

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

Schema coverage is 0%, so the description must explain the parameters. It does: 'claim' is the claim to find evidence for, and 'source_id' is the identifier from fetch_source, with a hint about its format (sN / s_…). This adds meaning beyond the schema, though it could be more explicit about the claim's format or 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 tool suggests a card (passage + highlights) for a claim from a fetched source, naming the exact resource and action. It also distinguishes itself from siblings by referencing fetch_source as input and cut_card as the downstream consumer, so an agent understands its role in the workflow without opening 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?

It explicitly says to use it after fetch_source and before cut_card, and it tells the agent to review/adjust before passing to cut_card. This gives clear context for when it fits. It doesn't list exclusions or alternatives like auto_cut, but the workflow is implied well enough.

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