Who Represents This Address

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

With no annotations provided, the description carries full responsibility. It discloses rate limits (50/day free, X-API-Key for Pro), return format (JSON), scope of officeholders (federal and state legislative only), and that local boundaries include no officeholders. This is thorough and goes beyond basic operation.

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

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

The description is informative and front-loads the purpose, but includes a redundant 'Operated by an AI (RJH Signal Technologies LLC)' preamble that doesn't help the agent call the tool. It also lists detailed return items, which is useful, but could be tightened slightly without losing value.

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, the description adequately explains what is returned (federal and state districts, officeholders, local boundaries) and what is excluded (local officeholders). It also mentions rate limits. All essential aspects for correct invocation are covered, and the single parameter is well documented.

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 already provides a detailed description of the address parameter with an example and format guidance. The tool description repeats similar wording ('free-text U.S. street address') and adds no significant new meaning. Schema coverage is 100%, so baseline 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?

The description clearly states the tool's verb and resource: given a free-text U.S. street address, it returns 119th Congress district, state legislative districts, and officeholders. It also explicitly notes exclusions (no local officeholders) and implies a single-address scope, distinguishing it from the batch 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 description makes it clear that the tool processes a single free-text address (singular), which gives context. However, it never mentions the sibling find_representatives_batch or any condition for choosing one over the other, so it lacks explicit when-not 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?

With no annotations provided, the description carries the full burden and discloses substantial behavior: exact return shape, per-address error containment, strict ordering, per-address quota consumption, free-tier daily limit with batch refusal behavior, and Pro tier key requirements. It stops short of describing what the error objects or usage field look like, but for a zero-annotation tool this is a strong disclosure.

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 front-loaded with the purpose and sibling relationship, followed by transport format, return shape, and quota rules. Every sentence earns its place, though the 'Operated by an AI' opener and the quota paragraph are verbose; it's efficient overall without padding.

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 tool with no annotated output schema, the description covers the essential operational and boundary factors: batch size, JSON-RPC transport constraint, return structure, tier/rate limits, and API-key distinction. Minor gaps remain (exact error object shape and the usage field contents), but nothing an agent needs to call it correctly is omitted.

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%; the schema already fully documents addresses as 1-40 U.S. street addresses including city, state and ZIP. The description adds only marginal parameter-level value (confirms one lookup per address, order preserved), which matches the baseline-3 expectation for high schema coverage.

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

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

The description opens with 'Same as find_representatives for a list of 1 to 40 U.S. street addresses in one call', which states a specific verb+resource and explicitly anchors the tool to its sibling, making the batch differentiation immediate. Returns the scope (1-40 addresses), count-per-address lookup semantics, and the {results, count, usage} shape. An agent can distinguish it from find_representatives without opening the schema.

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

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

The 'Same as find_representatives for a list of 1 to 40 U.S. street addresses' phrasing implies the batch context where the sibling handles single lookups, and the description adds concrete operational guidance: send it as a single JSON-RPC message not inside an array. However, it never explicitly states 'use find_representatives for a single address' or other exclusions, so the when-not guidance is left to inference.

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