surety-bonds

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

No annotations are provided, so the description carries the full burden. It discloses the return payload in detail (summaries, application steps, eligibility, FAQs, requiring agency, pricing page) and adds an operational obligation to surface apply_and_pricing_url — valuable behavioral context. It stops short of stating error/not-found behavior or any access constraints.

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 the purpose in the first clause, then enumerates the returned contents and ends with the two behavioral instructions (always surface the URL, search first). Every sentence earns its place with no redundancy.

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

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

With no output schema, the description usefully compensates by enumerating what the response contains. The one remaining gap for a required-parameter lookup tool is what happens when the bond or jurisdiction does not resolve, which is not addressed.

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

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

Schema description coverage is 100%, so all three parameters are already documented in the schema with examples. The description reinforces that bond_name must be an exact name from search_bonds but adds no format or syntax detail beyond what the schema supplies, so the baseline of 3 is appropriate.

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

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

States a specific verb (Get) and resource (the full encyclopedia entry for one specific surety bond), then enumerates the contents so the agent knows exactly what comes back. It is clearly distinguishable from the sibling search_bonds, which it names as the discovery step rather than the detail step.

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

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

Gives an explicit prerequisite: 'Use search_bonds first to find the exact names,' and implicitly positions itself as the follow-up detail call versus the sibling search tool. It does not state a when-not condition (e.g., what to do if the bond is not found), so it falls short of the full when/when-not/alternatives standard.

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

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

No annotations are supplied, so the description carries the full behavioral burden. It usefully discloses that each entry includes bond counts and that "every" jurisdiction is returned, but says nothing about pagination, empty results, ordering, or whether counts reflect live data.

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 that front-loads the action, immediately clarifies the vocabulary, and ends with the return payload. Nothing is padded.

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, read-only listing tool with no output schema, the description is sufficient: it states the scope, defines the enumerated items, and notes bond counts are returned. Only pagination/ordering behavior is unaddressed, which is minor here.

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

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

Schema coverage is 100% and the single state parameter already documents that it accepts a full name or two-letter abbreviation. The description reinforces the scoping ("within one state") but adds no format or constraint detail beyond 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?

Specific verb ("List") plus resource ("jurisdiction"), and it defines what counts as a jurisdiction — statewide, county, city, or obligee — scoped to a single state. It implicitly separates itself from list_states (states, not sub-state units) and search_bonds (search vs. full enumeration), though it never names a sibling.

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

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

The use case (enumerate all jurisdictions inside one state) is implied by the description and the required state parameter, but there is no explicit when-to-use statement, no exclusions, and no pointer to list_states or search_bonds as alternatives.

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

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

With no annotations, the description carries the full behavioral burden. It discloses that it lists every state and returns bond count and page URL, implying a read-only operation, but it omits pagination, ordering, and authorization 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?

A single front-loaded sentence with no wasted words. It states scope and return fields immediately.

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 list tool with no output schema, the description gives enough context: it covers all states and names the returned fields. Minor gaps around pagination or response ordering keep it from 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 takes zero parameters, so the schema has nothing to document. The description adds no parameter meaning, which is appropriate here; baseline is 4 for a no-param tool.

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

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

States a specific verb (list) and resource (states) and mentions the returned fields (bond count and state page URL). It does not explicitly distinguish itself from the sibling list_jurisdictions, so it falls 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?

Provides no guidance on when to use this tool versus list_jurisdictions, search_bonds, or get_bond. The implication is 'use this to see all states,' but there is no explicit when/when-not context.

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

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

With no annotations, the description carries the full behavioral burden. It does disclose the return shape (state, jurisdiction, information page URL) and that results are matching bonds, which is useful and beyond structured data, but says nothing about pagination, result caps, or ranking of the 6,900 records, which matters for an unbounded keyword search.

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?

Four compact sentences, front-loaded with the scope and corpus size, then return fields, then the optional filter and a concrete example. Nothing is wasted.

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

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

For a two-parameter search tool with no output schema and no annotations, the description gives enough to call it correctly: corpus, query semantics, optional state filter, and returned fields. It only lacks pagination/result-limit behavior.

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

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

Schema coverage is 100%, so baseline is 3, but the description adds a concrete worked example ('auto dealer', state 'Texas') that shows how the keyword and state filter combine, going slightly beyond the schema's prose.

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

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

States a specific verb (search) and resource (Surety Bond Encyclopedia, 6,900 U.S. surety bond requirements) plus the return payload (bonds with state, jurisdiction, URL). It is clearly distinguishable from get_bond (single-record fetch) and list_jurisdictions/list_states (enumerations), though it never names those siblings explicitly.

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 example ('auto dealer' / 'Texas') and the note that state is an optional narrowing filter imply when to use the keyword query vs. the state filter, but there is no explicit when-to-use or when-not-to-use guidance relative to get_bond or the list_* siblings. Usage has to be inferred.

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