Georgia Commons

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

Annotations already mark this as read-only and idempotent, and the description adds meaningful behavioral detail beyond that: the response is windowed by start and max_chars, has a 60,000-character default, and includes a continuation pointer. It does not explain the pointer format, but the added windowing/pagination context is useful.

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 sentence with no filler; the key return type, windowing behavior, default, and continuation mechanism are front-loaded. Every clause 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?

Given no output schema and 0% schema description coverage, the description is a reasonable but incomplete specification. It covers the core text-windowing behavior but omits what the continuation pointer looks like, how bill/session should be supplied, and what exact response shape to expect.

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 bears the burden of explaining parameters. It does explain start and max_chars, including the 60,000 default, but it leaves bill and session unexplained. This is partial compensation, not complete coverage of the four parameters.

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

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

The description clearly identifies the tool as returning the stored text of a bill, which distinguishes it from list/search/lookup siblings even though no sibling is named. It lacks an explicit verb but the tool name and noun-phrase description make the operation unambiguous.

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

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

The description gives no guidance about when to use this tool versus alternatives such as bills_lookup, bills_search, or bills_list. There is only an implicit sense that it is for retrieving bill text; no exclusions, prerequisites, or alternative-selection conditions are provided.

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

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

Annotations already declare readOnly, idempotent, and non-destructive. The description adds valuable behavioral context: default session behavior (newest when omitted), ordering, pagination, and exact return fields. It also explains filter value meanings (status codes, chamber letters), exceeding what annotations provide.

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 sentence that front-loads purpose and then efficiently enumerates filters. Every clause adds semantic value with no redundancy or filler. It is appropriately sized for the tool's complexity.

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

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

Given a read-only list tool with no output schema, the description is complete: it specifies return fields, ordering, pagination, default session, and all filter semantics. Nothing an agent needs to correctly invoke this tool 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?

With schema description coverage at 0%, the description carries full responsibility and succeeds. It explains every filter parameter with allowed values (kind: hb/sb/hr/sr, chamber: H/S, status: codes 1-6, subject: headings search, q: words). It also implies pagination via '25 a page' and default session behavior. No parameter is left unexplained.

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 lists bills of a session, with explicit details on ordering (number order), pagination (25 a page), and return fields (id, title, status, URL). It differentiates itself naturally from siblings like bills_search (search) and bills_get_text (text extraction) by focusing on listing with filters.

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 (listing bills with filters on kind, chamber, status, subject, or q). It does not explicitly name alternative tools or state exclusions, but the filter-based listing purpose is evident. A slight deduction for not explicitly indicating when to prefer bills_search for full-text search.

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

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

Annotations establish a read-only, idempotent, non-destructive operation, but the description adds substantial behavioral context beyond that. It details the exact content returned: frontmatter with specific keys, verbatim text, summaries, and status, and explains how `full` adds history, votes, amendments, and documents. It also clarifies the default session resolution logic. This is valuable behavioral information not present in the annotations.

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

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

The description is dense but every sentence contributes information. It opens with the core purpose and output, then addresses session behavior, then the `full` flag. There is no filler or repetition. It could be slightly better structured with explicit labels, but for the complexity of the tool, the length is warranted and 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?

For a lookup tool with no output schema, the description provides a strong picture of the return value: the Markdown twin with key frontmatter fields, text, summaries, and status, plus the additional data from `full`. It does not cover error cases or edge scenarios, and it does not explicitly differentiate itself from all sibling tools, but the essential details for correct invocation are present. The description is sufficiently complete for an agent to use it effectively.

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 lack of parameter documentation. It does so thoroughly: `bill` is explained with multiple example formats, `session` has its default behavior and special-session naming, and `full` lists exactly what it adds. All three parameters are semantically defined in a way that lets an agent construct valid inputs without opening the schema.

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

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

The description clearly identifies the tool as returning a single bill or resolution by number in various formats, and specifies the output structure (frontmatter, text, summaries, status). It distinctly frames a lookup operation, differentiating from sibling tools like bills_list and bills_search which handle lists or searches. The scope is precise and leaves no ambiguity about the tool's function.

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

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

The description gives explicit instructions on session handling: when no session is supplied, the newest regular session is used, and special sessions require naming (e.g., '2026-special'). It also explains the effect of the `full` flag. While it does not explicitly mention alternatives or exclusions, the context implies this is the comprehensive bill lookup, contrasting with more specific tools like bills_get_text. The guidance is clear enough for an agent to decide when to invoke it.

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

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

Annotations already declare readOnlyHint and idempotentHint, so the description adds value by noting that search matches document words and that in_headings restricts to titles/topics/subjects. However, it does not disclose return format, pagination, or how results are ordered.

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 purpose front-loaded, then a query nuance and a parameter hint. No filler, each 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 search tool with four parameters and no output schema, the description gives enough to start but leaves limit/session semantics and result structure undefined. It is minimally adequate but not comprehensive.

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

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

Schema description coverage is 0%, so the description must explain parameters. It only covers in_headings; limit and session remain unexplained, and the query parameter is only given phrasing advice rather than format or meaning.

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

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

States it performs full-text search over bill text, titles, and labeled summaries, and clarifies direct lookup for bare bill numbers. This distinguishes it from sibling tools like bills_lookup or bills_get_text by emphasizing the full-text scope.

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

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

Provides guidance on query phrasing ('ask in the words the bill would use') and describes the in_headings behavior, but does not explicitly compare to alternatives or state when not to use it. The hint about bare bill numbers implies direct lookup, but no sibling exclusions are given.

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

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

Annotations indicate read-only, non-destructive, and idempotent behavior, so the bar is lower. The description adds that it returns one line per node with counts and citation spans but does not explain side effects or output format details.

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

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

The description is compact and front-loads the key hierarchy levels and examples. It is not verbose, though the phrase 'twin URLs' is ambiguous and could be clarified without much extra length.

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 available sibling tools and no output schema, the description leaves out essential context such as the meaning of 'twin URLs', the exact format of output lines, and how this browsing tool relates to specific lookup tools.

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

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

The single parameter 'node' is shown with default null and a string/null type, but the description only indirectly explains it via examples like '36' and '36-60'. It does not define what values are valid or how null behaves.

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 it browses a hierarchy with titles, chapters, and sections but does not explicitly name the verb as 'browse' nor clarify what 'twin URLs' refers to. It distinguishes from siblings somewhat by mentioning hierarchy levels.

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

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

No explicit guidance on when to use this tool versus alternatives like code_describe_structure, code_find_chapter, or code_get_chapter. The description implies browsing but does not state conditions for selection.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the safety profile is covered. The description adds value by noting it is 'Cheap' (low cost) and by describing the type of information returned, which goes beyond the annotations.

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

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

The description is two short sentences with no wasted words. The critical 'Call first' instruction is front-loaded, followed by a compact list of covered topics. It is highly efficient and 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?

For a no-parameter, read-only tool, the description fully explains what the agent will get: grammar, search strategies, version/status semantics, content scope, and title list. It is complete for an agent to decide to call it first without needing additional context.

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

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

The tool has zero parameters, so the description carries no parameter burden. Per guidelines, the baseline for 0 parameters is 4. The description doesn't need to explain any inputs, and it doesn't contradict the schema.

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

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

The description clearly states a specific purpose: to be the entry point for the Code, providing citation grammar, section-finding strategies, version/status handling, content scope, and title list. This distinguishes it from sibling tools like code_lookup_section or code_search, which are for specific lookups.

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 'Call first for the Code' is an explicit usage directive, telling the agent to invoke this before any other Code tool. It implies alternatives (specific lookup tools) without naming them, but the 'call first' guidance is strong and unambiguous.

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

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

The description discloses what the tool returns (citing section and unit) and the readOnlyHint annotation indicates no side effects. However, it does not mention potential errors, limits, or the exact format of the output, so it is not fully 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 concise but awkwardly phrased as a run-on sentence: 'Laws by the short title the statute states (...): the citing section and the unit the name covers.' It could be structured more clearly while staying brief.

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 read-only lookup with one parameter and no output schema, the description provides adequate context: it states the purpose, the input (short title), and the output (citing section and unit). It lacks explicit details on output format or error handling, but these are not critical for a basic lookup.

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 'name' has no description in the schema, and the schema coverage is 0%. The tool description implies that 'name' is the short title, but this is not explicitly stated, so the parameter meaning is not fully compensated for by the description.

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

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

The description clearly states the tool finds laws by short title, providing concrete examples ('Joshua's Law', 'Georgia Lemonade Stand Act') and mentions the output (citing section and unit). This differentiates it from sibling tools like code_search or code_lookup_section.

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 does not explicitly state when to use this tool versus alternatives, but the specific purpose (searching by short title) is clear enough that an agent can infer when it is appropriate. No alternative tools 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?

The description discloses that the tool searches headings specifically, which is a behavioral detail beyond the readOnlyHint and idempotentHint annotations. It also implies a return format that includes the code_browse call, but it does not explain pagination, limit, or exact matching behavior. Since annotations already cover the read-only and idempotent nature, the description adds useful but limited context.

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

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

The description is a single sentence that front-loads the use case and then specifies the search target and result. It is concise with no filler, though the final clause 'with the code_browse call that lists each' adds a slight ambiguity and could be simplified. Overall it is well-structured and 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?

For a tool with a single parameter and no output schema, the description covers the core purpose and use case, and differentiates from siblings by emphasizing heading searches. However, it lacks details about the output format (other than mentioning code_browse), edge cases, or any limitations, leaving the agent to guess about response structure and exact behavior. It is adequate for a simple tool 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?

With 0% schema description coverage, the description must clarify the single 'words' parameter. It states that headings 'carry the words', indicating that the parameter is a string of terms to match against headings. This gives basic meaning but omits details like case sensitivity, whether it's a phrase or individual words, and how multiple terms are handled. It is better than nothing but not comprehensive.

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 finds titles, chapters, articles, and parts whose headings contain the given words, and that it pairs each with a code_browse call. It is specific about the resource type (legal code components) and the search scope (headings), which differentiates it from siblings like code_search that might search full text. The phrasing is somewhat awkward but the purpose is unambiguous.

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

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

The opening 'For I know the topic but not the citation' provides a clear use case, indicating when to use this tool: when the user has a topic but lacks a citation. However, it does not explicitly mention alternative tools or when not to use it, leaving the choice of sibling tools like code_search or code_find_act to the agent's inference. It gives context but no exclusions or comparisons.

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

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

Annotations already establish read-only, idempotent, non-destructive behavior. The description adds valuable operational details: sections are returned in order, results are windowed by max_sections and max_chars, and the output signals continuation with a pointer or 'End of chapter.' This goes beyond the structured annotations.

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

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

The description is a single dense sentence that front-loads the core behavior, then adds windowing defaults and the termination signal. Every clause earns its place, and there is no redundant or filler content.

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

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

The description explains the output shape, ordering, windowing, and continuation behavior, which is helpful given there is no output schema. However, it omits enough parameter semantics for title, chapter, and start, and provides no guidance on alternatives, leaving the definition adequate but not complete 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 carry the parameter explanation. It explains max_sections and max_chars with defaults and implies start via the continuation pointer, but it does not clarify the meaning or format of title, chapter, or start. With 5 parameters and no schema descriptions, this is a significant gap.

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

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

The description clearly identifies the resource (sections of a chapter) and the operation (returning their text in order), plus the windowing behavior. It does not use an explicit verb, and it does not name sibling tools, but 'every section of a chapter' distinguishes it from more targeted lookup 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 this tool is for retrieving all sections of a chapter in sequence, which gives an agent a reasonable sense of when to use it. However, it does not explicitly state when to prefer this over code_lookup_section, code_lookup_sections, or code_find_chapter, nor does it mention alternatives or exclusions.

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

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

The description explains the return format (frontmatter, verbatim text, notes), the effect of the `version` and `subsection` parameters, and the 404 behavior naming neighboring sections. There is no contradiction with the read-only, idempotent annotations.

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

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

The description is brief, but uses odd phrasing such as 'the twin site serves' and 'notes capped', which can obscure rather than clarify. It is not overly long, but the cryptic style hurts readability.

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 lookup tool, the description covers the main resource, parameters, return content, and error behavior. However, the unclear phrasing and lack of explicit usage scenarios leave some gaps in what an agent needs to confidently invoke it.

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

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

Schema coverage is 0%, so the description must carry the explanatory load. It does explain `version` and `subsection`, but the primary `citation` parameter is left undescribed, and no format or example is provided for any 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 clearly identifies the resource as a single Code section retrieved by citation, and contrasts with the plural sibling `code_lookup_sections`. However, it lacks an explicit verb like 'look up' or 'retrieve', relying on the noun phrase 'One Code section by citation'.

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

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

No explicit guidance is given about when to use this tool versus alternatives. The singular/plural contrast with `code_lookup_sections` is implied but never stated directly, leaving the agent to infer the appropriate selection.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds useful behavioral details: the 40-section and 150,000-character caps, and the trailer that names anything not rendered. These go beyond the annotation metadata.

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

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

One dense sentence that front-loads the purpose ('Several sections at once'), then packs examples, limits, and trailer behavior with zero filler. Every word earns its place.

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

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

For a single-parameter read-only lookup, it explains input syntax, limits, and partial-rendering behavior. It doesn't detail the exact return format of the sections, but with no output schema and a simple read operation, an agent has enough 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 'citations' parameter. It does so thoroughly with examples ('44-7-30, 44-7-31 and 44-7-34' or '44-7-30 through 44-7-35'), plus constraints (up to 40 sections, 150k chars). This fully compensates for the schema's silence.

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 multiple code sections at once, with explicit examples of list and range input formats. It distinguishes from the singular sibling code_lookup_section by the plural 'sections' and the batch nature described.

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 that this tool is for retrieving several sections in a single call, implying it is the right choice when you need a batch. It doesn't explicitly name alternatives or exclusions, but the sibling 'code_lookup_section' is an obvious single-section counterpart.

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

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

Annotations already declare readOnly, idempotent, closed-world, non-destructive, so the safety profile is covered. The description adds genuine behavioral value by explaining result-ranking rules (citations, act names, verbatim passages surface first) and collection scoping via scheme.

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

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

Front-loads purpose, then ranking behavior, then parameter notes. Dense but every clause earns its place; no filler 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?

No output schema exists so return values needn't be explained, and search semantics are well covered. However, with 4 of 6 parameters (title, chapter, limit) unexplained and no sibling routing, the definition is incomplete for a tool sitting among several closely related code-lookup tools.

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 carries the full parameter burden, and it explains only 2 of 6 params — in_headings and scheme (with its values and default). The title, chapter, limit, and query parameters are left undocumented, so it only partially compensates for the 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?

States a specific verb and resource ("Full-text search of the Code") and details what can be searched (words, citation, or both). It stops short of explicitly differentiating itself from siblings like code_lookup_section or code_find_act, so it doesn't reach 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?

Offers real query-formulation guidance ("ask in the words the statute would use") and describes how citation-naming and verbatim-passage queries behave, but never states when to use this tool versus the many sibling lookup/search tools. Usage is implied rather than prescribed.

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

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

The description mentions an output characteristic ('one line each with twin URLs') but it is unclear and does not clearly disclose behavioral traits beyond what annotations already state. No contradictions exist, but the added transparency is minimal and cryptic.

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

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

The description is brief, but the structure is confusing and not front-loaded. It mixes a resource description with unclear output details, making it hard to parse quickly. It is concise in word count but not in clarity.

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

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

Given the tool appears to be a browsing function for constitutions, the description lacks essential context: what constitutes 'articles and sections', what the 'node' parameter represents, how the output is structured, and how it differs from related tools. It is incomplete for effective tool selection.

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

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

The schema has two parameters (node and scheme) with no descriptions. The description only hints at possible values for scheme ('ga' or 'us') without explaining either parameter's meaning or how they affect the operation, leaving the agent without sufficient guidance.

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

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

The description is vague about the action; it describes 'articles and sections of a constitution' but does not state whether this is a browse, fetch, or list operation. The parenthetical '('ga' or 'us')' is ambiguous and the mention of 'one line each with twin URLs' further confuses the purpose.

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

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

No guidance is provided on when to use this tool versus alternatives like constitution_lookup, code_browse, or search. There is no indication of when this tool is preferred or what distinguishes it from 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?

Annotations already indicate read-only, idempotent, non-destructive behavior. The description adds useful output-format information ('Markdown twin with the case annotations capped'), but the phrase is somewhat ambiguous and does not explain pagination, errors, or availability 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?

A single dense sentence with no filler, front-loaded with the resource and supported by examples. The awkward 'Markdown twin with the case annotations capped' phrase slightly hurts clarity, but the overall structure 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?

The tool has no output schema, so the description must explain return shape; it gestures at Markdown output with capped annotations but remains vague. It also does not define what a slug looks like, leaving a meaningful gap for an agent trying to construct a valid request.

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 carries the burden. It explains possible scheme values ('ga' or 'us') and gives concrete citation examples for the citation parameter. It does not fully clarify the slug format, but it provides substantial meaning beyond the bare 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 resource (Georgia or United States constitution provisions as printed in the O.C.G.A.), a lookup action, and accepted identifiers (citation or slug). It is distinct from sibling tools like code_lookup_section, though it does not explicitly contrast itself with constitution_browse.

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 context is implied: use this for constitutional provisions by citation or slug. However, there is no explicit statement of when to prefer this over constitution_browse or other lookup tools, and no when-not-to-use guidance.

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

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

The annotations already declare read-only and non-destructive behavior, and the description adds a performance note ('Cheap'). This is sufficient given the annotations present.

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

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

The description is short but runs multiple items together in a list-like stream without clear sentence structure. It is not as crisp as a two-sentence summary.

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

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

The description covers the expected outputs (site contents, collections, grammar, next-tool guidance) and includes a cost note. It is adequate for an initial discovery tool, though the phrasing is slightly oblique.

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 takes no parameters, so there is nothing to explain beyond the schema. The description does not need to address inputs.

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 lists the tool's content (what Georgia Commons holds, collections, id/URL grammar, next tool, independence statement) but lacks a clear verb like 'describes' or 'returns', making the purpose less explicit than a direct statement.

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

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

The phrase 'Call first' provides a clear directive on when to use this tool, and mentioning 'which tool to call next' indicates it helps navigate the toolset. However, it does not explicitly contrast 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the safety profile is covered. The description adds valuable behavioral context: it returns the same Markdown twin served at url plus .md, includes frontmatter, verbatim text, and summaries under named headings. It also explains the 'full' parameter behavior (adds optional material or first 60,000-character page of notes for Code/constitutions, with frontmatter naming the next page). This goes beyond annotations and helps the agent understand pagination and content structure.

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 well-structured. It front-loads the core purpose (fetch full document for an id), gives concrete id examples, then explains the return format and the 'full' parameter. Every sentence earns its place. It's slightly long but the complexity of the tool (multiple document types, pagination behavior) justifies the length.

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

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

Given the tool has an output schema (which likely describes the returned document structure), the description doesn't need to explain return values in detail. It covers the id format, the full parameter behavior, and the content structure (frontmatter, verbatim text, summaries). The pagination behavior for notes is disclosed. The only missing piece is explicit guidance on error cases or what happens with invalid ids, but that's a minor gap for a read-only fetch 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. The description explains the 'id' parameter format with concrete examples (code:44-7-34, ga-const:art-i-sec-i-para-i, bill:2025-2026/hb136, opinion:S26A0060) and explains the 'full' parameter's effect (adds optional material or first page of notes). This is significant added meaning beyond the bare schema. It doesn't explicitly say id is required, but the schema already marks it required. The only minor gap is not explaining what happens if id is malformed.

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

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

The description clearly states the tool fetches the full Markdown document for an id from search, with concrete examples of id formats and a clear distinction from search. It names the resource (document for an id) and the verb (fetch), and differentiates itself from the search tool by specifying it retrieves the full document rather than performing a 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?

The description implies when to use this tool: when you have an id from search and need the full document. It doesn't explicitly state when not to use it or name alternatives, but the context of 'from search' and the sibling list (search, lookup tools) makes the usage context clear. It could be improved by explicitly saying 'use search first to get an id, then use fetch'.

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

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

Annotations already cover readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is well established. The description adds the useful behavioral note that the data is 'computed from the stores now,' implying a live/current snapshot. However, it does not disclose return shape, pagination, errors, or cost, so its contribution beyond annotations is modest.

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 one tight sentence with no filler. It front-loads the key idea ('Exactly what is loaded') and then compresses the output content into a compact list, earning its place entirely.

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 read-only tool, the description is fairly complete: it names the substantive output components and the live-computation behavior. However, with no output schema it leaves the response container shape (e.g., object vs. list) and count semantics unspecified, so it is not a 5.

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 with an empty properties object, giving 100% schema coverage. A zero-parameter tool gets the baseline 4; there are no parameter semantics for the description to clarify.

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 ('coverage') and enumerates its contents: coverage sentences, corpus versions, counts, sessions, years, dates, licenses. It is specific about what the tool addresses, but it lacks an explicit verb like 'retrieves' or 'computes' and does not contrast itself with 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?

There is no guidance about when to use get_coverage instead of the many sibling list/lookup/search tools. The description simply states what is loaded/computed, leaving selection criteria entirely 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?

Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, so the description does not need to repeat safety. It adds value by disclosing the windowing behavior (start, max_chars) and the continuation pointer, which are behavioral traits not captured by annotations or schema defaults alone. No contradiction with annotations.

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

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

The description is a single sentence that front-loads the core purpose and includes essential details (windowing and continuation) without any redundant words. It is highly efficient and well-structured.

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

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

For a simple tool with three parameters and no output schema, the description covers the main behavioral aspects: text retrieval, windowing, and continuation. It does not specify the exact format of the continuation pointer or any pagination limits, but these are minor given the tool's simplicity. The annotations cover safety, so the description is largely 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?

With schema description coverage at 0%, the description must compensate. It explains start and max_chars as windowing controls and notes the default 60,000, but does not elaborate on the opinion parameter beyond its role as the required identifier. The 'pointer to continue' hints at output semantics but does not detail parameter usage further. Partial compensation, but opinion semantics are obvious from context.

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

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

The description states the tool returns the stored text of an opinion, specifying the windowing parameters and continuation pointer. It is clear and specific, though it does not explicitly distinguish itself from sibling tools like opinions_lookup or opinions_search. The verb is implied (retrieve), but the resource and scope are 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 description provides no guidance on when to use this tool versus alternatives. It does not mention situations where another tool (e.g., opinions_lookup for metadata, opinions_search for discovery) would be more appropriate. The usage context is only implied by the description's focus on text retrieval.

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

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

The description adds behavioral details beyond annotations: default year (newest when omitted), ordering (filing order), and page size (25). It doesn't mention error handling or rate limits but covers key execution behavior for a read-only listing tool.

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

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

The description is a single, dense sentence with no redundant words. It packs all key information (purpose, fields, ordering, pagination, filters) efficiently without sacrificing clarity.

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

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

For a simple listing tool, the description covers essential context: output fields, default year, ordering, pagination, and filter options. It omits explicit parameter semantics for limit/start, but the tool is straightforward enough that this is 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 schema has 5 parameters, all optional. The description explains q, year, and case_type, but fails to explicitly describe limit and start. The mention of '25 a page' implies a default for limit, but start (offset) is not mentioned at all, leaving its semantics unclear.

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

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

The description clearly states the tool returns opinions filed in a given year, with explicit field listing (docket, date, case name, case type, URL), ordering (filing order), pagination (25 per page), and filtering options. No ambiguity.

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

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

The description mentions filter options (case_type, q) but does not explicitly compare against sibling tools like opinions_search or opinions_lookup. There is no direct 'use this when...' guidance, leaving the choice to inference from the tool name and 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?

Annotations already declare readOnly, idempotent, and non-destructive, so the bar is lower. The description adds notable behavioral detail: it returns a Markdown twin with a specified frontmatter structure, verbatim opinion, and summaries, and it explains the tie-breaking rule when dockets are shared and what `full` adds. That goes beyond what the annotations provide.

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 single long paragraph is dense and front-loads the key information, but it packs multiple clauses about formats, output structure, tie-breaking, and the `full` flag into one breath, making it harder to scan than a structured list would be.

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 read-only lookup with no output schema, the description covers input formats, return structure, and the `full` extension well. It leaves a small gap regarding how the returned Markdown is delivered or paginated, but overall it is nearly sufficient 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 description coverage is 0%, so the description must carry the parameter meaning. It does this well by enumerating accepted formats for `opinion` (docket, reporter citation, record id, case name) and explaining that `full` adds summarized reasoning, checked quotes, and upstream records. The 4 rather than 5 reflects that some specifics, e.g. exact record-id syntax for cluster ids or the ga- prefix format, remain only illustrative.

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 (lookup) and resource (Supreme Court of Georgia opinion), and enumerates the four access keys, which is distinctive. It does not explicitly contrast itself with sibling tools like opinions_search or opinions_get_text, so it falls short of a 5 on sibling differentiation.

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

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

Usage is implied by the input options (docket, citation, record id, case name) and the `full` flag, but there is no explicit when-to-use guidance or mention of alternatives such as opinions_search for thematic queries or opinions_get_text.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, covering the safety profile. The description adds that search matches literal words of the document (not semantic meaning) and that in_headings scopes to case names, legal areas, and case types. This adds some behavioral context beyond annotations, but does not disclose pagination, result format, or other operational details.

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

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

The description is three sentences, front-loaded with the primary purpose, followed by a direct-lookup note and a query tip. Every sentence adds relevant information without waste. The structure is logical and easy to scan, though it could be slightly more compact.

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

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

With no output schema and 0% parameter coverage, the description is the only source of guidance. It does not describe what results look like, how pagination works, or how to combine parameters effectively. Given the tool's complexity (5 params, no output schema), this is inadequate for an agent to invoke it correctly without further discovery.

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 mentions query implicitly via the search behavior and explains in_headings, but does not describe year, limit, or case_type. While these parameter titles are somewhat self-explanatory, the description fails to clarify their allowed values or how they interact, leaving the agent with insufficient guidance for a 5-parameter 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 states the tool performs full-text search over opinion text, case names, and labeled summaries, and explicitly differentiates it from a direct lookup. This is a specific verb-resource pair that distinguishes it from siblings like opinions_lookup and opinions_list, leaving no ambiguity about its core function.

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

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

The description offers a query-formation tip ('ask in the words the court would use') and notes that a bare docket or citation is a direct lookup, but it does not explicitly state when to prefer this tool over siblings like opinions_lookup or opinions_list. No exclusions or alternative-selection guidance is provided, leaving the agent to infer usage context.

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

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

Beyond the readOnly and idempotent annotations, the description reveals ranking behavior (citation/bill/docket first), lexical matching semantics, the result limit, output format, and the recommended follow-up fetch(id). This is rich behavioral context that substantially aids invocation.

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

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

Every sentence earns its place: scope and output, ranking priority, matching behavior, query advice, and follow-up action. The description is front-loaded with the core purpose and contains no redundant text 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, with one required parameter dump, and the description covers scope, constraints, output shape, ranking, and usage nuance. The output schema handles return details, so nothing critical is missing for an agent to call this 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?

With 0% schema description coverage, the description fully compensates by defining the accepted `collection` values (code, bills, opinions) and explaining how the `query` should be phrased for effective matching. This adds meaning well 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 states a specific verb and scope ('Search every loaded collection...'), explains the optional collection filter, and specifies the output shape as up to ten {id, title, url} results. This clearly distinguishes the general search tool from collection-specific siblings like bills_search or code_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 provides clear context: searches all collections by default or one via `collection`, and offers query-formulation guidance ('Ask in the words the document would use'). However, it does not explicitly name sibling tools as alternatives or state when not to use this tool, so the agent must infer that distinction.

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

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

Beyond the read-only and idempotent annotations, the description discloses determinism and the normalization rules (quotes, dashes, whitespace, [T]he-style alterations). It does not specify the exact return value (e.g., boolean vs. error), but the core 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, focused sentence with no fluff. It efficiently conveys the purpose, normalization details, and determinism in a compact form.

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 two-parameter signature and the presence of an output schema (not shown), the description covers the essential aspects. The return type is implied ('whether'), and the context of use is clear enough 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?

The schema provides no parameter descriptions, so the tool description must compensate. The names 'id' and 'quote' are reasonably self-explanatory, and the description implies their roles, but the mapping is not explicitly stated. This leaves some ambiguity for an agent.

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

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

The description clearly states the tool's function: verifying whether a quote appears verbatim in a document's text. It distinguishes itself from sibling tools by being the only verification tool, and the normalization details further clarify its exact behavior.

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

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

The description explicitly advises using this tool before relying on a quotation, providing a clear usage context. It does not enumerate alternative tools, but the unique purpose makes the appropriate use evident.

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