ImpactLine public research

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

Annotations already declare readOnly, idempotent, non-destructive and openWorld, so safety is covered. The description adds genuine provenance context the annotations cannot: candidate matches are not verified law-to-award mappings or fraud determinations, and no private reviews or AI-generated content are included. It does not mention pagination or volume limits.

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

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

Three short sentences with no redundancy, purpose front-loaded and the disclaimers trailing it. Efficient, though the disclaimers occupy space that could have held parameter guidance.

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

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

With no output schema, the description should say more about what comes back; it lists entity categories but not shape or structure. The unglossed program enum is a real gap for a three-parameter detail-read tool, though the read-only profile is adequately covered by annotations.

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

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

Schema description coverage is 0%, so the description must carry parameter meaning, yet it only vaguely gestures at 'law and jurisdiction'. The program parameter (overview/bridges/schoolbus/middlemile) is never explained, nor is the required lawId format, even though both are the main sources of caller error.

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 (read) and a specific set of resources (public source candidates, stages, requirements, coverage) scoped to a law and jurisdiction. It is clearly a detail-read rather than a search, which implicitly separates it from search_public_laws, but no sibling is named 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?

Usage is only implied: the required lawId plus 'existing' signals a lookup for a known law, versus discovery via search_public_laws or scope inspection via read_research_scope. The exclusions given ('No private reviews or AI generation') describe data boundaries rather than when to pick this tool over an alternative.

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?

While annotations confirm it is read-only and idempotent, the description adds the critical behavioral constraint of operating 'without accessing private review records.' This provides vital operational context regarding the data boundaries.

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 definition is highly efficient, using a single sentence to cover the action, the scope, and the limitation, ensuring 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?

Given that the input parameters are empty and annotations are strong, the description is complete. It clearly defines the specific subset of public data the tool interacts with.

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?

Since the input schema has zero parameters, the description cannot add semantic meaning to parameters. The baseline score of 4 is appropriate for zero-parameter tools.

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 purpose is stated clearly with a specific verb ('Read') and defined resources ('supported jurisdictions, programs and evidence limits'). Crucially, it adds scope limitation, which differentiates its function from accessing full or private records.

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

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

The description implies usage by stating what it *does not* access ('without accessing private review records'), serving as a negative guideline. However, it does not explicitly compare its use case against the listed 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 declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false, so the safety profile is covered. The description adds genuinely new behavioral context: a five-year feed window, returned dated coverage, and live/snapshot status, which materially informs how the agent should interpret results. It stops short of describing result shape or pagination 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?

Two tight sentences with zero filler, and the coverage caveat is placed after the core action so the primary purpose 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 read-only search with no output schema, the description does well on coverage and status but leaves the mechanics of the call undocumented. With 0% parameter documentation and no return-value description, an agent knows why to use the tool but not how to tune limit/offset or what fields come back.

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 full burden of explaining the three parameters (limit, query, offset). It says nothing about any of them: no query syntax, no default or max limit, no pagination semantics for offset. The agent must infer everything from bare type constraints.

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

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

The description states a specific verb and resource ('Search enacted public laws') and adds a scope qualifier ('in the existing five-year feed'), so an agent immediately knows what is being searched. It does not explicitly distinguish itself from the sibling read_* tools, which is the only thing keeping it from 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 clause 'newer or unresolved laws may be missing' implicitly tells the agent when results will be incomplete, which is useful guidance. However, it names no alternatives and gives no explicit when-to-use/when-not-to-use routing against read_public_implementation or read_research_scope, leaving usage to inference.

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