perfect-world

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

With no annotations, the description carries the full behavioral burden. It discloses important traits: no charge, no upload, and non-authoritative results. However, it promises to explain 'what happens when a file fails' but never actually explains it, and it omits any mention of required permissions or response characteristics.

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

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

Three compact, front-loaded sentences: the offer and scope, the usage instruction, and the behavioral caveat with an alternative. Every sentence earns its place, and there is no redundant or filler wording.

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 two defaulted parameters and no output schema, the description explains the purpose, safety, and primary alternative. But it never states what the tool returns or the exact limits being checked, leaving the agent to guess at the response shape. This is a notable gap given there is no output schema to fill 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%, so the description must compensate. It explicitly ties both parameters to their purpose: file_count and total_mib are used to check limits against the job. This adds meaning beyond the schema names and types. It doesn't explain default behaviors or constraints, which keeps it from a 5.

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 resource: a $49 bulk legacy-file conversion offer, and its function: checking limits for a job based on file_count and total_mib. It distinguishes itself from the FREE preflight, making its scope clear. However, it lacks a single crisp verb like 'estimate' or 'quote', and the opening sentence is more of an agenda than a function statement.

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

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

Explicitly says to provide file_count and total_mib for limit checks and contrasts itself with the authoritative FREE preflight. It also clarifies that this tool never charges or uploads, preventing misuse. It does not name the exact sibling tool for preflight, but the alternative is clearly referenced.

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 behavioral disclosure. It does disclose that output is bounded by max_chars and that the full text is available elsewhere, which is useful. It does not mention error behavior, response format beyond 'text', or what happens when max_chars is exceeded.

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

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

Two sentences with the core purpose front-loaded and no fluff. The phrase '(free)' is slightly ambiguous and adds limited value, but overall the description is compact 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?

For a simple two-parameter retrieval tool with no output schema, the description covers the essential behavior: returns extracted text, bounded by max_chars, with the full text available elsewhere. It leaves minor gaps around exact truncation and error cases, but is reasonably 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 references max_chars as a bound and document_id via the /api/documents/{id}/text endpoint, giving partial meaning. However, it does not explicitly explain that document_id selects which document or define max_chars precisely.

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 resource: extracted text of archived agenda, packet, or minutes. It conveys a retrieval action even without an explicit verb, and the scope distinguishes it from broader search/meeting tools in the sibling 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 implies when to use the tool: when a bounded portion of extracted text is sufficient, with the full text available at a direct API endpoint. However, it does not explicitly name alternatives or state 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?

With no annotations, the description carries the full burden of explaining side effects and call semantics. It states price and contents, but does not disclose whether the tool is read-only, whether calling it initiates a purchase, or what the caller actually receives as a result.

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

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

The description is compact and front-loaded with the distinctive price and pack name. It has no filler, though the phrase 'today's real desk capacity' is unexplained and could have been clarified within the same concise format.

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 agent knows neither the return value nor the tool's place in the evidence-pack workflow. The description reads like a product blurb rather than an API contract, leaving the agent unsure of the outcome of invoking the tool.

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

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

The tool has zero parameters and the schema has complete coverage, so there is no parameter ambiguity for the agent. The description adds useful context about what the pack contains, though the mention of a 'narrow civic/infrastructure question' could imply an input that is not actually captured by 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 identifies a specific resource, the $149 reviewed Evidence Pack, and summarizes its contents, but it never states the tool's action. There is no verb such as 'returns,' 'offers,' or 'creates,' so an agent must infer the purpose from the tool name rather than from 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 guidance is given for when to call this tool versus alternatives such as evidence_pack_submit or document_text. The description distinguishes the product by price and contents, but it does not state a condition like 'use this to present the offer; use evidence_pack_submit to accept 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?

With no annotations, the description carries the burden and does well: it discloses cost (free), human mediation ('A person reviews it'), and possible outcomes (acceptance, narrower scope, quote). It does not mention latency or asynchronous behavior, but core behavioral traits 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?

Compact and front-loaded with the most decision-relevant facts (FREE, human review, outcome types). The parameter lines are scannable with no redundant prose.

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 covers the workflow, the required fields, and the optional sources field. The only notable omission is source_pages; overall an agent has enough to call 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%, but the description provides meaningful glosses for question, subject, jurisdiction, reply_to, and sources. source_pages is left unexplained, which is a minor gap given it is optional and has a default.

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 (submit) and resource (one question to the Evidence Pack desk), and clarifies it is a free, human-reviewed request. It is clearly distinguishable from general-purpose tools, though it does not explicitly contrast with the sibling evidence_pack_offer.

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?

Implied by 'submit one question to the Evidence Pack desk': this is for requesting a human research/evidence determination. It does not explicitly state when to prefer it over evidence_pack_offer or other siblings, and there are no exclusions or prerequisites. This is adequate but not explicit routing.

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 characterizes the data ('the 64 legacy municipal file formats') rather than the tool's behavior, and does not state that the tool returns the list, is read-only, or has no side effects. This is acceptable for a simple constant but still lacks explicit behavioral 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 a single sentence with no filler; it states the count, domain, and representative examples. The word order is slightly awkward, but every element 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 zero-parameter, no-output-schema tool, the description is mostly sufficient, but it does not explicitly state what calling the tool returns. The agent can infer it yields the list of formats, yet a clearer 'returns X' statement would close the gap.

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

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

The tool has zero parameters and an empty schema, so there are no parameter semantics to document. Per the zero-parameter baseline, this is adequate; the description does not need to compensate for schema gaps.

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 the tool's resource: the fixed set of 64 legacy municipal file formats, with examples such as WordPerfect, Lotus, dBASE, and .msg. It is not a tautology and is clear, but it lacks an explicit action verb such as 'lists' or 'returns,' so it stops 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 offers no guidance on when to use this tool or how it relates to alternatives. It does not mention any exclusionary conditions or sibling tools, leaving the agent to infer usage from the name and noun phrase.

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 only markets with meeting records are included and that q filters by slug or name, but it does not state the return shape, pagination behavior, or matching semantics. It is acceptable but not thorough.

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 one short, front-loaded sentence that states the resource, the relevant condition, and the filtering parameter without wasted words.

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

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

For a simple one-parameter list tool, the description is mostly complete, but the absence of an output schema and annotations means an agent still lacks details about the response format, fields, and any pagination or sorting behavior. It is sufficient for basic invocation but not fully complete.

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

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

The schema provides only a default q string with no description, so the description adds meaningful semantics by stating that q filters by slug or name and is optional. It could clarify whether matching is exact or partial, but it compensates well for the 0% schema description coverage.

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

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

The description clearly identifies the resource as markets (cities/counties) with meeting records, and the tool name provides the 'list' action. It is distinct from siblings like search_meetings or search_officers because no other sibling covers market listing, though it could be more explicit about returning a list.

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

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

Usage is implied: use this tool when you need markets that have meeting records. However, there is no explicit guidance about when to prefer this over a sibling tool, no alternatives are named, and no exclusions are 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?

There are no annotations, so the description carries the burden of explaining behavior. It does disclose useful output details, including the permanent /file URLs for archived documents, but it does not explicitly state that the operation is read-only, how errors are handled, or any authentication requirements. For a simple fetch tool this is acceptable but not complete.

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 with no filler. It front-loads the core resource and includes specific, useful details about what the response contains. 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 retrieval tool, the description is mostly adequate and names the expected response contents. However, with no output schema and no annotations, it leaves unstated how meeting_id is obtained, whether this is a read-only operation, and how this tool relates to search_meetings. An agent could call it correctly with inference, but the description alone is not fully complete.

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

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

Schema description coverage is 0%, and the description never mentions meeting_id, its format, or how to obtain valid values. The schema property title 'Meeting Id' is self-explanatory, so an agent can infer the parameter selects the meeting, but the description adds no additional meaning or context for the parameter.

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

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

The description names the resource ('one meeting') and its key contents (body, video, archived documents with permanent /file URLs), making it clear this is a detail-retrieval tool. It is not tautological, but it lacks an explicit verb such as 'get' or 'fetch,' so the operation is implied rather than stated.

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 presence of a required meeting_id and the phrase 'one meeting' imply this is for looking up a specific meeting, possibly after a search. However, the description does not explicitly say when to use this tool instead of search_meetings or other siblings, and no alternatives 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?

With no annotations, the description carries the behavioral disclosure burden. It adds useful context beyond the schema: conduct record inclusion depends on the state publishing one. It also implies a read-only lookup, but it does not describe response format, exact-match behavior, or potential limitations.

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 with no filler and front-loads the core lookup purpose. The first clause is a fragment rather than a complete sentence, which slightly hurts clarity, but the overall economy is strong.

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

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

For a simple two-parameter lookup tool with no output schema, the description covers the main selection criteria and one important output nuance (conduct record availability). It lacks explicit return-format or error details, but the low complexity keeps this from being a major gap.

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

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

Schema description coverage is 0%, so the description must compensate. It clarifies that cert_number is the certification number and state is a narrowing code, naming NM, TX, and AZ. This gives both parameters meaningful semantics beyond their bare labels, though it does not specify formats or validation rules.

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

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

The description identifies a specific resource (certified officer) and lookup key (certification number), and adds scoping via state code. However, it is telegraphic ('A certified officer...') and does not explicitly differentiate itself from the sibling tool search_officers.

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

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

The description implies the use case: look up an officer when you have a certification number, optionally narrowed by a state code. It provides examples of valid state codes, but it does not state when to prefer this over search_officers or mention 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 carries the burden of explaining behavior. It discloses that the verification concerns an append-only hash chain anchored to the Wayback Machine, which provides useful context. However, it does not state whether the operation is read-only, what it returns, or whether any external network dependency is involved.

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

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

A single, front-loaded sentence that states the action and key context without waste. Every phrase earns its place, and the parenthetical clarifies the technical scope 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 zero-parameter tool, the description is sufficient to identify the operation, but it omits expected outcomes such as whether the result is a success indicator, a report, or an error. Given no output schema and no annotations, a bit more explanation of the verification result would make it fully complete.

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

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

The tool has zero parameters, so there is no parameter semantics burden to carry. The description is not required to explain inputs; the baseline of 4 applies because no parameter documentation is needed.

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 ('Re-verify') and a clear resource ('the Public Register's hash chain'), with an explanatory parenthetical about append-only receipts and Wayback Machine anchoring. It clearly distinguishes this tool from the document/search-focused 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?

The description implies the tool is for verifying the integrity of the register, but it does not explicitly state when to use it versus alternatives or provide any usage context beyond the action. No 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 carries the full burden of behavioral disclosure. It only lists output categories and does not state whether the operation is read-only, how recent the latest reading is, what happens for an invalid slug, or any data-freshness details. This is thin for a tool with zero annotation coverage.

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 fragment with no filler. The core idea of 'one reservoir' is front-loaded, and the examples earn their place by clarifying the slug parameter.

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 lookup, the high-level output description is passable, but the absence of an output schema and annotations leaves gaps around units, series date range, and error behavior. An agent could invoke it correctly but would still have limited understanding of the full response.

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

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

The schema only provides a 'Slug' title with 0% description coverage. The description compensates by giving concrete example slugs (lake-mead, elephant-butte) and indicating that the slug selects one reservoir. It does not enumerate all valid slugs or specify formatting rules, but it adds meaningful value for the only required parameter.

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

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

The description identifies the resource as a single reservoir and lists what is returned: capacity basis, latest reading, and series. The singular 'One reservoir' distinguishes it from the sibling 'reservoirs' tool, though it lacks an explicit verb like 'get' or 'retrieve'.

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 phrasing 'One reservoir' implies this tool is for a specific reservoir rather than a list, and the examples hint at valid slugs. However, it does not explicitly name alternatives or state when not to use it, leaving usage guidance mostly 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 provided, the description carries the full burden of disclosing behavior. It only states the data content and does not explicitly say the tool returns data, describe side effects, mention read-only status, pagination, or freshness/update 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 nine-word sentence with no filler words. The core subject, '45 metered reservoirs,' is front-loaded, and every word contributes meaning.

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 list tool, this is nearly complete: it identifies the full set of items and the key attribute returned. It could be more explicit about return format or point to the singular 'reservoir' tool for detail, but no invocation-level information is missing.

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

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

The input schema has zero parameters, so the baseline is 4. There is nothing for the description to add about parameters, and it correctly does not invent irrelevant parameter details.

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

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

The description names the exact resource (45 metered reservoirs) and the data returned (latest levels), so an agent can tell this is a list/collection tool rather than a detail tool. It lacks an explicit verb like 'list' or 'get' and does not explicitly differentiate from the sibling 'reservoir' tool, so it misses 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?

No guidance is given on when to use this tool versus the singular 'reservoir' tool or any other alternative. The plural phrasing implies a collection overview, but the description never states an exclusion, prerequisite, or recommended choice.

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 present, the description carries the behavioral disclosure burden. It clearly reveals that q performs full-text matching against titles, transcripts, agendas, packets, and minutes, which is meaningful search behavior. It does not mention pagination or response shape, but the core query semantics 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 compact sentence that front-loads the resource and scope, then packs the exact search fields into the remaining clause. It contains no filler or redundancy.

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

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

For a simple search tool with no output schema or annotations, the description covers the core object and search surface. However, it omits how results are paged/returned and does not disambiguate from search_transcripts, leaving some context gaps for an agent deciding and invoking 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 needs to compensate. It explains q's semantics in detail and implies market_slug through the 'in a market' scoping, but page is left entirely to the schema and q's optional/default behavior is not described.

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 the resource as meetings scoped to a market and specifies exactly which text fields q matches (title, transcript, agendas, packets, minutes). It is more specific than the tool name alone, though it does not explicitly contrast itself with sibling search_transcripts.

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 about when to use this tool versus alternatives such as search_transcripts or meeting. The only implied context is that it searches meeting documents in a market, and no exclusions or conditions are 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 must carry behavioral disclosure, but it only states the search modes. It does not mention result format, pagination behavior, whether the query is case-insensitive or exact, or how multiple supplied criteria are combined.

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, scannable sentence that front-loads the verb and resource, then lists the search dimensions. There is no redundant wording 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 has no output schema and no annotations, so the description should convey result shape and calling conventions. It provides no pagination semantics, no response format, and no handling for the defaulted optional parameters, leaving an agent uncertain about what the tool returns.

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?

Given 0% schema description coverage, the description compensates partially by clarifying that q is a name, state is a state code, and agency is an agency slug, and that name matching is whole-word. However, the page parameter is not explained at all, leaving a coverage 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 a search verb, the target resource ('officer roster'), and the accepted search criteria (whole-word name, state code, agency slug). It does not explicitly distinguish this tool from the sibling officer_lookup, so it stops 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?

No guidance is given on when to prefer this tool over alternatives like officer_lookup or search_meetings. The description implies use for officer-roster searches but provides no exclusions, fallbacks, or comparison with sibling 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 full burden of behavioral disclosure. It only identifies the basic operation and target corpus; it does not mention pagination behavior, query syntax, rate limits, authentication, or what fields the results contain.

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 or repetition. It is appropriately concise for a simple two-parameter search tool, though it sacrifices some behavioral detail.

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

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

For a straightforward search tool, the essential scope is stated, but with no output schema and no annotations, the description omits return value structure and any usage caveats. It is minimally complete but leaves notable gaps for an agent trying to predict 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%, so the description needs to compensate, but it only implies that 'q' is the search query. The 'page' parameter is not addressed at all, and meaning is mostly inferred from property names and the default value rather than described.

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 (full-text search) and a clear resource (archived video transcripts), making the tool's purpose immediately clear. It also distinguishes itself from sibling tools like search_meetings and search_officers by targeting transcripts 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 the tool is for finding content within archived video transcripts, giving a clear context of use. However, it does not explicitly state when to prefer it over alternatives such as search_meetings or search_officers, nor does it mention exclusion 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?

With no annotations provided, the description carries the full behavioral disclosure burden. It indicates this is an informational, read-only overview and hints at output content via 'machine-readable entry points,' but it does not state return format, whether the content is static, or other operational details. Some useful context is present, but more explicit behavior would help.

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 filler or repetition. It front-loads the tool's purpose and itemizes the key content areas 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 zero-parameter overview tool with no output schema, the description covers the essential content categories and points users toward machine-readable entry points. It is slightly spare on the exact return representation, but the low complexity of the tool makes this a minor gap.

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

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

The tool has zero parameters and an empty input schema, so there is no parameter ambiguity. The description adds meaningful context about what the tool conveys, which satisfies the informational burden for a parameterless tool.

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

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

The description clearly defines the tool's scope as a site-level overview and lists specific content categories: site nature, free vs paid content, and machine-readable entry points. It is distinguishable from sibling tools that target specific data domains, though it lacks an explicit verb like 'provides' or 'returns'.

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 strongly implies use for initial orientation and entry-point discovery, but it does not explicitly say when to use this tool versus a more specific sibling tool, nor does it state exclusions. The usage context is clear but left to 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?

No annotations are provided, so the description carries the behavioral disclosure burden. It communicates that the result is one site, keyed by SEMS ID, and includes milestones, but it does not disclose response shape, error behavior, or any edge cases.

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, tightly worded sentence with no filler. The key resource, lookup key, and included milestone data are all front-loaded and easy to parse.

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 lookup tool, this description is minimally adequate: it identifies the resource and what is returned. But with no output schema and no annotation context, it leaves details about SEMS ID format, milestone structure, and how this tool relates to sibling tools underspecified.

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 0% schema description coverage, the description must compensate for the parameter documentation, but 'by SEMS id' largely restates the parameter name 'sems_id.' It confirms that the parameter is the lookup key, but it does not define what a SEMS ID is, provide a format, or give an example.

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 that the tool returns a single Superfund NPL site identified by SEMS ID and that milestones are included. It is specific enough to distinguish the tool from a general overview or summary, though it lacks an explicit verb like 'get' or 'retrieve.'

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 'by SEMS id' implies this tool is for single-site lookups when a SEMS ID is available. However, it never explicitly says when not to use it or names alternatives such as site_overview or superfund_summary, so the guidance is only 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 full burden, and it does disclose the tool's core behavior: returning national counts grouped by status and state. This is a simple parameterless read-only aggregation, so no side-effect warnings are necessary; only a richer response-format description is absent.

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?

One short sentence contains the key facts: scope, resource, and grouping dimensions. Every word earns its place and the most important information is front-loaded.

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

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

For a parameterless summary tool with no output schema, the description gives enough information for an agent to select and invoke it correctly. It could be slightly more explicit about the expected response shape or status values, but nothing critical is missing.

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

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

The tool has zero parameters, and the schema confirms this. Per the baseline rule for parameterless tools, the description need not explain parameters; it correctly focuses on the output instead.

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 output verb ('counts') and resource ('National Superfund') with clear grouping dimensions ('status and state'). Its aggregate nature distinguishes it from more specific sibling tools like superfund_site and site_overview.

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 the tool should be used—when national Superfund count aggregates by status and state are needed—but it provides no explicit when-not-to-use guidance or alternatives. The usage context is inferable rather than 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 and does disclose a key behavioral trait: the catalog identifies HTTP endpoints that require payment via an HTTP 402 handshake, and the agent is expected to pay them. It does not explain consequences of not paying, whether this is a read-only lookup, or what the actual response looks like, but the payment requirement is explicit enough to warn an agent that using this tool involves monetary/access implications.

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 every phrase is loaded with meaning: prices, rails, 402 handshake, sold to agents, and the imperative to pay. It is front-loaded and has no filler. It loses a point because the compression sacrifices clarity—words like 'rails' and 'handshake' may require domain knowledge to parse.

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 zero parameters, the description is the only context an agent gets. It is incomplete: it never defines what is being sold, what an 'open rail' is, how the 'HTTP 402 handshake' works, what 'pay' means in practice, or how this catalog relates to siblings like trading_post_ledger. A cryptic two-sentence summary is not enough for a tool that is essentially a gateway to purchases.

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 is empty, so there are no parameters to explain. The description correctly avoids inventing parameter details and the caveat about high schema coverage does not apply since no parameters exist. A baseline of 4 is appropriate because nothing about parameter semantics is missing or misleading.

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 resource: prices and endpoints for things sold to agents, and indicates the tool names HTTP endpoints that require payment. However, it relies on jargon ('open rails', 'HTTP 402 handshake') and never uses a direct verb like 'list' or 'retrieve', so an agent unfamiliar with the domain may not understand exactly what the tool returns. It is not a tautology, but it is less clear than a straightforward 'catalog of purchasable items and their endpoints.'

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 only guidance is 'Pay the HTTP endpoints it names,' which is an action to take after using the tool rather than a condition for when to call it. There is no mention of when to prefer this over sibling tools like trading_post_ledger or list_markets, nor any explanation of the context in which this catalog is relevant.

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. 'Public' indicates accessibility and 'totals only' discloses that itemized transaction details are not returned, which are useful constraints. However, it omits details like response format, data freshness, or any rate limiting.

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. Every word contributes meaning: 'public' gives access scope, 'sales ledger' identifies the resource, and 'totals only' sets output expectations.

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

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

For a zero-parameter, simple read-oriented tool, the description covers the essential points: what resource is involved and what kind of data to expect. It does not specify formatting or exact return fields, but 'totals only' gives enough orientation for an agent to invoke it appropriately.

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, so the baseline is 4 per the rubric. There is no parameter documentation burden, and the description does not need to compensate for schema gaps.

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 resource as the public sales ledger and adds the scope 'totals only,' which distinguishes it from catalog-like siblings. It lacks an explicit verb such as 'retrieve' or 'return,' so it stops short of a perfect 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 'sales ledger — totals only' implies this tool is for aggregated sales data, but there is no explicit statement of when to use it over alternatives. None of the sibling tools are mentioned, and no when-not-to-use guidance is provided.

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