Gov Relations

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

Annotations already establish read-only, idempotent, non-destructive, closed-world behavior. The description adds useful scope context by enumerating what data is returned, but lacks auth, pagination, or freshness 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?

One dense sentence that front-loads the resource and enumerates the main returned data without 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?

For a read-only, single-parameter tool with no output schema, the description covers what the agent needs: scope, accepted identifier, and the types of return data. It is complete enough 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 100%, and the single client parameter is documented with examples. The description adds no new syntax or format detail beyond restating that it accepts a slug or name.

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 the resource and returned data (firms, payments, quarterly/past-year spending, issues, lobbyists) with enough specificity to distinguish an organization-level lookup from firm/lobbyist/agency siblings. It does not explicitly name an alternative tool, so it falls just short of the 5 criterion.

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 only the input format ('slug or name') and no when-to-use, prerequisites, or exclusions relative to siblings like get_firm or who_lobbies_agency. Usage must be inferred from the resource description.

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, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds that data is 'current' and 'latest reported', implying a freshness characteristic, but says nothing about return format, pagination, or lookup failure 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?

One sentence, front-loaded with the resource and its returned data, with the input-format note last. No 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?

For a single-parameter, read-only lookup with no output schema, the description adequately tells the agent what the call surfaces. The remaining gap is routing guidance among the many sibling tools, which is a usage concern more than a completeness one.

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 there is a single parameter whose schema description already documents 'Firm name or slug'. The description's 'Accepts a Gov Relations slug or a name' adds only marginal specificity about which slug namespace is expected, so baseline 3 applies.

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 (a lobbying firm) and enumerates exactly what the call returns: clients with latest fees, quarterly lobbying income, main issues, and lobbyists. That is specific and distinguishes it from single-entity siblings like get_client and get_lobbyist, though it never names an alternative 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?

There is no statement of when to use this tool versus get_client, get_lobbyist, or the who_lobbies_* siblings. The only guidance is about the input form ('slug or a name'), which is parameter information rather than 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?

Annotations already establish the safety profile (readOnly, idempotent, non-destructive, closed-world). The description adds useful return scope—'clients in the past year' and 'government positions they disclosed'—but does not cover error behavior, authentication, or rate limits, which is a moderate addition beyond structured fields.

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 no filler. The content list is front-loaded and the input acceptance is brief, making it appropriately sized for a simple lookup tool.

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

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

For a simple one-parameter lookup with rich annotations and no output schema, the description adequately covers what the tool returns and what input it expects. It omits edge cases like unknown identifiers, but nothing critical to correct invocation 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?

Schema coverage is 100%, so the single parameter is already documented. The description adds the namespace 'Gov Relations slug' beyond the schema's 'Lobbyist name or slug', but otherwise largely repeats the schema and provides no additional syntax or handling details.

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

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

Names a specific resource (registered federal lobbyist) and enumerates the returned attributes (current firm, clients in past year, main issues, disclosed government positions). This clearly distinguishes it from generic search tools, though it does not explicitly differentiate from siblings like get_client or get_firm.

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 alternatives like get_firm, get_client, or state_lobbying. It only states accepted input formats ('Gov Relations slug or a name'), leaving routing decisions entirely to the agent.

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, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description's real contribution is describing the shape of the result (top orgs, combined spending, top firms by client count), which is valuable given no output schema, but it says nothing about sorting limits, time granularity beyond '12 months', or data sources.

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 front-loaded sentence that leads with the primary output and ends with the no-argument fallback; nothing is padded. Slightly dense with three parallel list items but still 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?

With no output schema, the description usefully enumerates what comes back (organizations, combined spending, firms with most clients), which is the main gap it needs to fill. An agent can call it correctly; only edge details like result limits or ranking criteria are absent.

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% and the single parameter is fully documented with examples, so the baseline is 3. The description's 'call with no industry' note duplicates what the schema already states, adding no syntax or format detail beyond it.

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?

Names a specific resource and scope: an industry's federal lobbying over 12 months, the top-spending organizations, combined spending, and leading firms. This distinguishes it from the entity-level siblings (get_client, get_firm, get_lobbyist) by making 'industry' the aggregation axis, though it never explicitly names those alternatives.

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 one concrete usage condition: 'Call with no industry to list the industries available,' which resolves the zero-required-parameter ambiguity. It offers no when-not guidance or explicit routing against siblings like who_lobbies_on, so it stays short of a 5.

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=false, so the safety profile is covered. The description adds useful context that results reflect filings 'as they post to lda.gov' (a live freshness source), but says nothing about ordering, result caps beyond the schema's limit, or update cadence.

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 front-loads the resource and source, then lists contents and filters. It is efficient with little waste, though the trailing field enumeration ('with client, firm, amount, issues and lobbyists') runs long.

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 pre-announces the returned fields (client, firm, amount, issues, lobbyists) and the data source, giving the agent enough to call it correctly for a read-only, filterable list tool. Ordering of results is the only notable omission.

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 the baseline applies. The description's mention of filtering by kind, issue code, or a name maps directly onto documented parameters without adding syntax, defaults, or format detail beyond what the schema already provides.

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 resource (newest federal lobbying disclosures) with its source (lda.gov) and enumerates the filing kinds it returns (new registrations, terminations, quarterly reports, amendments), plus the fields included. This clearly distinguishes it from siblings like search_lobbying or state_lobbying, though 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?

The phrase 'as they post' implies this is a freshness/latest-feed tool, and the optional filters are mentioned, but there is no explicit when-to-use guidance or exclusion telling the agent when to prefer search_lobbying or another sibling instead. Usage is only implied.

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, closed-world and non-destructive, so the safety profile is covered. The description adds useful behavior of its own — the composed payload (rankings plus YoY change) and the default-quarter resolution — but says nothing about freshness, caching, or how the default quarter is determined.

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, front-loaded with what the tool returns and ending on the default behavior. The enumeration is dense but every item is a real output component, so 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?

With a read-only, optional-parameter tool and no output schema, the description usefully enumerates the return payload and the no-argument default, which is close to sufficient. The remaining gap is parameter semantics, which neither schema nor description fills.

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% (only min/max bounds, no descriptions), so the description must carry the parameter burden. It only implies that year/quarter are optional via the default statement; it never explains what quarter means, accepted values, or how out-of-range or future quarters are handled.

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 and enumerates exactly what is returned: total lobbying spending, top firms by income, top spenders, busiest issues, plus year-over-year change. That is far more concrete than a tautology, though it never names or contrasts a sibling like industry_lobbying or state_lobbying to steer selection.

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 supplies a default-quarter behavior ('Defaults to the latest quarter whose reports are due'), which tells the agent it can call with no arguments, but gives no explicit when-to-use versus alternatives in a sibling set full of site-specific lobbying 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 cover the safety profile (readOnlyHint, idempotentHint, destructiveHint=false, openWorldHint=false), so the bar is lower. The description adds real behavioral value: results are ranked by recent lobbying activity, and each record includes the current firm plus the matching former positions. It stops short of detail on result volume or pagination, but it meaningfully supplements 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?

Three tightly packed sentences with no filler: the core dataset is front-loaded, the enumeration of office types clarifies scope, and the optional issue narrowing comes last. Every clause carries information the agent needs.

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 takes on the burden of describing returns and does so adequately (ranking, current firm, matching former positions). Combined with annotations that cover safety and a fully documented two-parameter schema, the definition is close to complete, missing only minor details like result limits.

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 both office and issue are already documented with examples in the schema. The description adds only light framing ('Optionally narrow to lobbyists active on one issue') without new syntax, matching rules, or format guidance, so the 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 states a precise resource and scope: registered federal lobbyists who previously worked for a named government office (member, committee, chamber, White House, agency). The 'revolving door' framing and the phrase 'disclosed working for a given government office' clearly separate this former-employment lookup from sibling tools like who_lobbies_agency or who_lobbies_on, which concern current lobbying activity.

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 its use case by defining the dataset (people who moved from government to lobbying) and notes an optional issue narrowing, but it never states when to choose this tool over alternatives such as get_lobbyist or who_lobbies_agency, nor any exclusions or prerequisites. Usage must be inferred.

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, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered elsewhere. The description adds only that matches come back with their Gov Relations page, and says nothing about result limits, ranking, or behavior when no match is found. Useful but thin 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?

Two sentences, front-loaded with the resource enumeration and followed by the routing instruction. No filler and nothing buried.

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 search with no output schema and full schema coverage, the description covers what it searches and how the result is used downstream. The only gap is the shape of the result set (count, ordering, empty-result behavior), which keeps it short of 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?

Schema coverage is 100% and the schema itself documents both parameters, including the type enum and query examples. The description adds the concept of slug resolution as the output's purpose, but no additional syntax or matching semantics (partial vs exact, case sensitivity) beyond the schema. 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?

States a specific verb (Find) and enumerates the exact resource types searched (lobbyists, firms, clients, issues, agencies, bills) with parenthetical clarification of what a client is. This distinguishes it clearly from the get_* siblings, which retrieve a single known entity rather than searching by name.

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

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

Explicitly instructs 'Use it first to turn a name into a slug for get_firm, get_client or get_lobbyist,' naming the alternatives and the condition that selects them. The ordering relationship (search first, then fetch) is stated without inference.

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

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

Annotations already declare readOnly/idempotent/non-destructive, so the safety profile is covered. The description adds non-obvious operational context: coverage is partial and growing, the result enumerates available states, and pay is only returned where a state discloses it.

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 sentences, each mapping to a distinct mode, with the core resource identified first. Dense but every sentence carries information; only minor tightening is possible.

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 the description appropriately describes return values per mode (counts and top clients/firms, matches plus who-lobbies-for-whom, or the set of states). With no required parameters, the remaining gap is only the absence of an explicit alternative-tool pointer.

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%, setting a baseline of 3, but the description goes further by explaining the semantics of the query/state interaction and how the combination changes the meaning of the result, including that query matches organizations, firms, or lobbyists.

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 resource (state-level lobbying registration records) and breaks the tool's behavior into three concrete input/output modes keyed on which parameters are supplied. This lets an agent distinguish it from siblings like search_lobbying or get_lobbyist without opening a 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?

Explicitly tells the agent what each parameter combination produces ('With a state only… With a state and a name… With a name only…'), which is effectively invocation guidance. It does not name an alternative sibling or state when-not-to-use, so it stops short of a 5.

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 the safety profile (readOnly, idempotent, non-destructive), so the bar is lower. The description earns credit by disclosing the ranking basis, the 12-month lookback window, and that spending figures are attached to each organization — behavioral context not present in the annotations. It stops short of noting result limits or pagination.

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 but well-formed sentence carries the core definition, followed by a short examples sentence. The scope, ranking, and returned fields are front-loaded. Slightly run-on, but 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?

With no output schema and only one parameter, the description carries the burden of describing the return shape — and it does, naming the firms/organizations, the ranking metric, and the spending field. Full annotations cover safety. Minor gap: no mention of result size or ordering ties.

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 the single 'agency' parameter is already documented with examples in the schema. The description reinforces what counts as an agency (including chambers and the White House) but adds no syntax or formatting rules beyond what the schema provides — baseline 3.

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+resource: who lobbies a given federal agency, over what window (past 12 months), with what ranking (number of reports naming it) and what extra data (past-year lobbying spending). The examples (FDA, EPA, DoD, Treasury, FCC, Senate) make the resource unambiguous, and the phrase 'agency or chamber' distinguishes it from bill-level siblings like who_lobbies_on_bill.

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

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

The description implies the use case (find which firms/orgs lobby a given agency) but never states when to pick this over siblings such as who_lobbies_on, who_lobbies_on_bill, or industry_lobbying. No exclusions or prerequisites are given, so routing 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.

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

Annotations already declare readOnly, idempotent, non-destructive, and closed-world (openWorldHint=false). The description adds real behavioral context beyond that: the 12-month lookback window and the ranking methodology by disclosed activity count. It does not describe pagination or result size limits, so it stops short of a 5.

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, front-loaded with what the tool returns, followed by what the issue parameter means. No redundant restatement of the title or annotations.

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 tool with no output schema, the description conveys the result shape (ranked firms/lobbyists), the time scope, and the parameter domain. Missing only edge behavior such as result limits or handling of unknown issue values.

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 the baseline is 3, and the description goes further by explaining that issues are 'LDA general issue areas' and enumerating representative values (Health Issues, Defense, Taxation, Energy). This clarifies the domain of the otherwise loosely constrained issue string.

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 resource (lobbying firms and lobbyists), a specific dimension (a policy issue), a time window (past 12 months), and a ranking basis (number of disclosed lobbying activities). An agent can distinguish this from who_lobbies_agency and who_lobbies_on_bill, which address agencies and bills rather than issue areas.

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 description (use it to find who is active on a policy issue), but there is no explicit when-to-use/when-not guidance and no routing to alternatives like industry_lobbying or search_lobbying. Adequate but leaves selection to inference.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint=false and destructiveHint=false, so safety is covered. The description adds useful substance beyond that: it enumerates what the response contains (lobbying companies, their firms, bill title, sponsor, latest action), which is valuable given there is no output schema.

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, front-loaded with the result set before the input formats. Every clause earns its place given the absence of an output schema, though the return-content enumeration makes the first sentence fairly dense.

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 what is returned and how to supply the required identifier, and annotations cover the safety profile. The 'congress' parameter's default behavior is left only to the schema, 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?

Schema description coverage is 100%, so both parameters are already documented. The description reinforces the 'bill' parameter's accepted formats but adds no syntax beyond the schema's own examples, and says nothing about the 'congress' parameter or its default. 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?

States a precise verb+resource: the companies and organizations whose lobbying reports name a specific bill, plus the firms each uses on it and bill metadata (title, sponsor, latest action). This is clearly distinguishable from siblings like who_lobbies_agency and who_lobbies_on, which target different entities.

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 concrete input guidance by showing accepted bill identifier forms ('H.R. 1', 'S. 1582', 'HR 4366') and title-word forms ('GENIUS Act', 'farm bill'), which tells the agent the tool works with either. It does not name when to prefer this over sibling lookup tools or state any exclusions, so it stops short of a full routing rule.

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