Emily Politics — UK Parliament (free)

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

With no annotations, the description carries the transparency burden. It discloses that lookup is by partial title and lists the returned information, which is useful. However, it does not explain behavior for multiple matches, no results, or whether the bill must be currently before Parliament, leaving moderate ambiguity.

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 well-structured sentence that fronts the action and resource, then lists the return fields. Every word 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?

For a simple lookup tool with no output schema and no annotations, the description covers the essential inputs and outputs (stage, sponsor, dates, summary, page). It is nearly complete, though it omits edge-case behavior such as handling multiple partial matches.

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 'title' parameter is documented only by the schema as a string. The description adds that it is searched as a 'partial title', which is meaningful but incomplete; it does not specify matching behavior (case sensitivity, substring rules) or provide examples. With 0% schema coverage of descriptions, more compensation would be needed for a higher score.

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 uses a specific verb ('look up') and names the exact resource ('a bill before Parliament') plus the search method ('by partial title') and the return fields. This clearly distinguishes it from sibling tools like search_divisions or lookup_member, 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?

The description makes the usage context clear: use this when you need the status of a UK bill by its title. It does not explicitly state exclusions or alternatives, but the tool's scope is unambiguous given the title and sibling 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 burden of behavioral disclosure. It discloses what the tool returns (totals plus per-party breakdown), which is helpful, but doesn't mention error handling, data freshness, or any side effects. For a simple read-only operation, this is adequate but not rich.

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 immediately states the purpose and includes the usage hint. It is front-loaded, concise, and contains no redundant information.

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 tool, the description sufficiently covers the input source and output structure (totals plus per-party ayes/noes). It could explain behavior on invalid IDs, but overall it's nearly complete given the lack of output schema and minimal complexity.

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 does so effectively by explaining that division_id comes from search_divisions, which is exactly the semantic meaning needed. It doesn't describe the ID format, but the provenance is the most critical piece and is clearly provided.

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 the full result of a specific division vote, including totals and per-party ayes/noes. It specifically references using the division_id from search_divisions, distinguishing it from the search tool and making its unique purpose explicit.

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 a clear usage hint: use the division_id from search_divisions, implying a prerequisite workflow. It doesn't explicitly state when not to use this tool, but the context strongly suggests it is for retrieving full details after finding a specific division ID.

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 burden of behavioral disclosure. It does not state whether the operation is read-only, what the response format is, whether results are paginated, or any limitations. The phrase 'who ministers have met' is too vague to convey the actual output structure or side effects.

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 very concise—two short sentences with no fluff. It front-loads the topic and quickly covers filters. The first sentence is a grammatical fragment ('Ministerial transparency releases, who ministers have met') but it is still skimmable and efficient. Overall, it is appropriately sized.

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 relatively simple (two optional filters), but with no output schema or annotations, the description should provide more context about the returned data or any constraints. It only offers a vague statement about meetings and does not mention that both parameters are optional or what happens when no filter is provided. The description is incomplete for an agent to fully understand the tool's 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?

The description names both parameters ('minister' and 'organisation') and indicates they are for filtering, adding some meaning to the bare string schema. However, it does not specify whether they are optional, how they interact, or expected value formats. Given the schema description coverage is 0%, the description provides partial compensation but is insufficient.

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's purpose: it deals with ministerial transparency releases and records of who ministers have met. The filter options by minister or organisation further clarify the scope. While it lacks an explicit verb in the description itself, the title 'Search ministerial meetings' and the filter guidance make the purpose clear and distinguishable from sibling tools like search_ministerial_gifts.

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 on when to use this tool versus alternatives, no exclusions, and no prerequisites. The only hint is 'Filter by minister or organisation', which explains how to narrow results but not when this tool is the appropriate choice among siblings. There is no explicit comparison or recommendation.

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 burden of disclosure. It clearly states the tool is a lookup/find operation and enumerates the returned data (party, constituency, current role). It does not describe not-found behavior or name matching nuances, but for a simple read-only lookup this is reasonably 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 one short sentence that front-loads the tool's purpose and immediately lists the key outputs. Every word contributes value; there is no wasted text.

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 lookup tool with no output schema, the description covers the input scope ('by name') and the main output fields. It omits edge-case behavior (e.g., no match found) and does not mention alternatives, but the tool's low complexity makes this adequate. A small addition about what happens when the member is not found would make it 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?

The schema defines a single 'name' parameter with only min/max length, and the description adds just 'by name' without explaining format requirements, whether partial names are supported, or how titles/hyphenated names are handled. Since schema description coverage is 0%, the description should compensate but does not.

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 uses a specific verb ('Find') plus a well-defined resource ('a sitting MP or peer') and specifies the exact output fields (party, constituency, current role). This fully distinguishes it from broader sibling tools like search_parliament or search_member_interests.

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 'Find a sitting MP or peer by name' implies when to use this tool, but there is no explicit guidance about when not to use it or which sibling tool to prefer for historical lookups or partial-name searches. The usage context is clear but not elaborated.

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 provided, and the description does not disclose any behavioral traits such as return format, filtering semantics, authentication requirements, or side effects. It only describes the domain, leaving the agent without critical behavioral information.

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, concise sentence that efficiently captures the domain. It is front-loaded with the 'revolving door' concept and contains no redundant or extraneous information.

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 annotations, no output schema, and 0% schema description coverage, the description must stand alone to guide invocation. It offers only a thematic overview and lacks operational details such as parameter behavior, result expectations, or constraints, making it insufficient for reliable tool usage.

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 (person, organisation) with no property descriptions (0% coverage). The description mentions 'former ministers/senior officials' and 'private-sector roles,' which indirectly hints at the parameters, but it does not explicitly define how person and organisation are used or interpreted in search.

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 title 'Search ACOBA appointments' clearly states the verb and resource, and the description explains the specific subject matter: 'former ministers/senior officials taking private-sector roles and the conditions ACOBA imposed.' This differentiates it from sibling search tools like search_lobbying and search_contracts.

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, no mention of target queries, and no explicit comparison to sibling tools. It only offers thematic context, so usage guidance is effectively absent.

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 provided, so the description must disclose behavior; it only states that the tool provides evidence and filter options, without describing result behavior (e.g., list vs. single item, pagination, or response format). The description doesn't say whether it's a read-only operation (likely, but not disclosed) or any side effects; thus it fails to fulfill behavioral transparency beyond the minimal.

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 packs both the resource and the filter options, with no wasted words. It is front-loaded with the subject 'Evidence given...' which immediately orients the user.

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 relatively simple (2 optional string params, no output schema), and the description covers its core purpose and filtering. However, since no annotations or output schema exist, the description should clarify what the response looks like or any constraints (e.g., whether evidence is full-text searchable), leaving some gaps for a fully self-contained description.

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 description explicitly says 'filter by committee or witness,' which directly maps to the two schema properties, adding meaning beyond the bare parameter names. However, it doesn't provide example formats or further semantic nuances (e.g., exact matching vs. full-text search), so the compensation is minimal.

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 searching committee evidence ('Evidence given to parliamentary select committee inquiries'), and specifies the filtering dimensions ('by committee or witness'). This distinguishes it from sibling tools like search_contracts or search_donations, which search other parliamentary data types.

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 needing committee evidence—and mentions the two filter options, but does not explicitly contrast with sibling tools or provide when-not-to-use guidance. Since the sibling list contains many other search_* tools, the lack of explicit differentiation to other evidence-like searches (e.g., search_parliament) limits the 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?

No annotations are present, so the description must carry the full burden of behavioral disclosure. It only states what data is searched and the filter options, without mentioning read-only nature, result formats, rate limits, or operational constraints. This is minimal transparency for a tool that presumably returns structured 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?

The description is a single concise sentence that front-loads the core purpose and filter criteria. Every word adds value with no redundancy, making it 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?

With four optional parameters and no output schema, this description is too terse to be fully actionable. It lacks information about result types, pagination, filter combination rules, or any limitations, leaving an agent under-informed for a tool of this complexity.

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%, and the description partially compensates by naming supplier, buyer, topic, and minimum value, which map to the schema's supplier, buyer, query, and min_amount parameters. However, it does not clarify parameter formats, constraints, or how 'topic' corresponds to the free-text query field, leaving ambiguity.

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 searching UK government contract awards and lists four filter dimensions (supplier, buyer, topic, minimum value), distinguishing it from sibling tools that handle other parliamentary data types. The verb 'search' is implied by the title and context, making the purpose specific and 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 implies the tool is for filtering contract awards but does not explicitly state when to prefer it over alternatives or mention exclusions. Sibling tools are clearly about other data domains, so the use case is evident by implication, but no direct guidance is 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?

No annotations are present, so the description carries the full burden. It discloses that results include title, date, ayes/noes counts, and division_id, and that both Commons and Lords are searched. It does not mention pagination, ordering, or result count limits, leaving some behavioral gaps.

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 purpose, followed by return-value details. No filler or repetition of schema; every clause adds information.

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 single-parameter search with no output schema, the description covers the essentials: what to send, what comes back, and how to proceed with get_division_results. It omits the list shape and any limits, but overall it is adequate for selection and 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%, but the description supplies the key semantic: the query is a topic for finding division votes. It does not give examples or explain matching behavior, but for a single free-text parameter this is minimally adequate.

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 uses a specific verb ('Find') and identifies the resource ('Commons/Lords division votes by topic'). It also differentiates from siblings by noting it returns division_id for use with get_division_results, so the search tool's scope 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 description provides clear context: use this to search divisions by topic, then pass the returned division_id to get_division_results. It does not explicitly exclude alternatives like search_parliament, so it falls short of full when-not guidance, but the downstream relationship is stated.

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 provided, so the description carries full weight. It adds context by naming the data source and filter capabilities, but it does not explicitly state that this is a read-only search, nor does it describe what the returned data looks like (e.g., a list of records, ordering, pagination, or any limitations). The behavior is largely inferred from the tool's name and the phrase 'records'.

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 that are front-loaded with the resource ('Electoral Commission donation records') and immediately state the filter options. Every word earns its place; there is no redundancy 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?

Given the tool's simplicity (3 optional params, no output schema, no annotations), the description is reasonably complete. It states the data source, the purpose, and the filters. Minor gaps include the absence of a mention of result format, limits, or any special behavior like exact vs. partial matching, which would be useful but not critical for a basic search 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?

The schema has no descriptions for its three properties (0% coverage), so the description must compensate. It does so by explicitly naming all three filters ('recipient, donor, or minimum amount') and clarifying that min_amount is in GBP. However, it leaves gaps such as whether donor/recipient are exact matches or partial, and whether min_amount is inclusive.

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 searching Electoral Commission donation records, with a specific verb ('search'), resource ('political donations'), and data source ('Electoral Commission'). It distinguishes itself from sibling search tools (lobbying, contracts, etc.) by specifying donations and 'who funds which party or recipient'.

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 for donation-related queries via the phrase 'who funds which party or recipient', but it does not explicitly state when to use this tool versus alternatives, nor does it mention any exclusions or prerequisites. Sibling tools like search_lobbying are not referenced for contrast.

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 of behavioral disclosure. It does not mention that the tool performs a search, returns results, or has any other side effects. It only describes the content of the register, not the tool's 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?

The description is extremely short, but it is a sentence fragment without a predicate. It is compact but under-specified, failing to communicate the action. The structure is poor because it lacks a verb and doesn't earn its place as a complete description.

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 absence of an output schema and annotations, the description is insufficient. It does not explain what the tool returns, whether filters are required, or any limitations. An agent would have to infer behavior from the parameter names and title, leading to potential misuses.

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 optional parameters (client, lobbyist) with zero description coverage. The description hints at 'firms' and 'clients', which likely map to the parameters, but it does not explicitly explain which parameter corresponds to which field or how to filter effectively. The description only partially compensates for the lack of schema descriptions.

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 identifies the resource (ORCL register) and the type of data (firms/clients), but it is a noun phrase rather than a statement with an explicit verb like 'searches' or 'lists'. The title provides the verb, but the description itself does not clearly state the tool's action, distinguishing it from siblings only implicitly through the named register.

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 explicit guidance on when to use this tool versus the sibling tools (e.g., search_acoba, search_contracts). The description implies that it is for lobbying register data, but it does not state alternatives, prerequisites, or when not to use 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?

With no annotations provided, the description bears the full burden of behavioral disclosure. It only states the basic search function and does not mention read-only behavior, result format, pagination, or any side effects. This is a minimal disclosure that adds little beyond the tool's basic purpose.

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, efficient sentence that front-loads the core purpose and the key search dimensions. Every word earns its place with no filler or repetition.

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 search tool with three optional parameters and no output schema, the description is minimally adequate. It outlines the search criteria but omits details on result format, default behavior when no filters are provided, and whether filters combine. Given its simplicity, it is acceptable but has clear gaps.

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 zero description coverage, so the description must compensate. It does mention 'by member, keyword, or category,' which maps roughly to the three parameters (member, query, category) and clarifies their roles as search filters. However, it does not explain whether the parameters can be combined or how they interact, leaving ambiguity.

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 specifies the resource (MPs' registered financial interests) and the action (search) with three specific dimensions (member, keyword, category). It distinguishes this tool from sibling search tools like search_contracts or search_donations by focusing specifically on financial interests.

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 the tool (when searching for MPs' financial interests) but does not explicitly mention alternatives or exclusion criteria. It lacks guidance on how this tool compares to other search tools, which would be helpful given the large sibling set.

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 provided, so the description carries the full burden. It indicates the tool searches a register of ministerial declarations, but it does not disclose behavior such as whether results are limited, paginated, or ordered. The verb 'search' implies a read-only operation, but other behavioral traits (e.g., required permissions, output format) are not addressed.

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, front-loaded sentence that states the domain and filter options in a compact way. Every word contributes to the description; there is no redundancy 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?

For a simple search tool with three optional filters and no output schema, the description covers the core domain and filter options. However, it omits details about what records are returned, whether results include full details, or any special behaviors. This leaves some gaps but is adequate for a basic search 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. It lists the three filter dimensions (minister, counterparty, type) but merely repeats the schema property names without adding meaning. For example, 'counterparty' is not defined, and the type enum values are not elaborated. This provides minimal value beyond structured fields.

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 specifies the tool's function: searching gifts and hospitality declared by ministers, with explicit mention of filter dimensions (minister, counterparty, type). This distinguishes it from sibling tools like search_donations or search_contracts, making the purpose 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 implies when to use the tool (when searching ministerial gift/hospitality declarations) but provides no explicit guidance on when not to use it or alternatives. There is no mention of exclusions or comparisons with related search tools, so usage context 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?

With no annotations provided, the description carries the burden of behavioral disclosure. It mentions the return format (titles, dates, excerpts, source links) but does not explicitly state that the operation is read-only, nor does it disclose any limits like pagination or result ordering. This is useful but incomplete for a tool without annotation safety hints.

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 sentences, front-loaded with the primary action and scope, and wastes no words. It is easily parsed and immediately communicates the tool's purpose and output.

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 search tool with one parameter and no output schema, the description is largely complete: it names the content types searched and the fields returned. However, it omits potential context such as read-only assurance, result limits, or how to narrow results, which would be helpful given the absence of annotations and output schema.

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 description for the 'query' parameter (0% coverage), so the description must compensate. It adds the concept of 'keyword search,' which clarifies the parameter's role, but it does not discuss query syntax, examples, or constraints beyond the schema's type and length limits.

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 verb ('keyword search') and resource ('Hansard debates, bills, parliamentary questions, divisions, EDMs, committees, APPGs and GOV.UK consultations'), which distinguishes it from sibling tools that target narrower domains like divisions or committee evidence.

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 a general-purpose search across the parliamentary record, but does not explicitly state when to use this tool over the more specific sibling tools. There is no direct comparison or mention of alternatives, so the agent must 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?

No annotations are provided, so the description carries the full burden. It discloses that petitions are public and ranked by signatures, which is a useful behavioral trait. However, it does not mention side effects, response format, or any access requirements, leaving the agent with limited safety information.

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 concise sentence with no filler. It front-loads the key information (public petitions, ranking by signatures) without wasting words.

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 no annotations, no output schema, and undocumented parameters, the description is too sparse. It does not explain what the tool returns, how min_signatures works, or any usage constraints, leaving significant gaps for an agent.

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 should clarify the parameters. 'By topic' vaguely corresponds to the query field, but min_signatures is never mentioned. The description adds little value beyond what the schema already shows.

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 identifies the resource (public petitions) and the ranking criterion (by signatures), distinguishing it from sibling search tools. However, it uses a noun phrase rather than a verb, so the action is implied by the tool name rather than explicitly stated.

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 on when to use this tool vs alternatives like search_parliament. The phrase 'by topic' hints at querying capability, but it does not explain why this tool is preferred for petitions or when not to use it.

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