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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and non-destructive behavior. The description adds useful behavioral context not in annotations: it discloses that links appear and that an example row is optional, and it does not contradict any annotation.

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 tightly worded sentence with no filler. The core behavior is front-loaded, and the purpose is attached immediately, making it easy for an agent to scan and act on.

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 read-only introspection tool with only two parameters, strong annotations, and no output schema, the description covers what the tool returns and why to use it. Nothing necessary for correct invocation or interpretation 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 description coverage is 100%, so the schema already documents both parameters thoroughly. The description's mention of 'optionally one example row' echoes the include_sample parameter but adds little beyond the schema, though the $expand context is helpful.

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 ('Show') and identifies the exact resource: a table's fields, types, links for $expand, and optional example row. This clearly distinguishes it from siblings like list_tables (table names only) and query (data retrieval), while stating its goal of enabling correct query construction.

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 'so you can write a correct query' establishes the intended use context: call this before writing a query when you need schema or relationship information. It does not explicitly name alternatives or state when not to use it, so it falls just short of full 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?

Annotations already cover read-only, idempotent, and non-destructive behavior. The description adds what the response contains (matches' Ids, latest faction, served Knessets), which is useful because there is no output schema. It does not discuss pagination or match limits, but this is a minor gap.

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 primary action and input condition are front-loaded, and the return-value guidance follows immediately. Every sentence 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?

For a simple two-parameter lookup with full schema coverage and safety annotations, the description covers the essential return shape and downstream usage. No important information an agent needs to invoke it correctly 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 description coverage is 100%, so the schema fully documents name and current_only, including an example. The description adds no parameter-specific 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?

The description names the action ('Find'), the resource ('MKs and ministers'), and the search key ('Hebrew name'). It also distinguishes itself from get_person by explaining the returned Id can be chained into get_person, get_person_votes, and search_bills.

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 clearly states when to use the tool: to find people by Hebrew name before fetching their details or votes. It gives downstream routing, though it does not explicitly state when not to use it or mention alternatives like query/get_record.

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 readOnlyHint, idempotentHint, openWorldHint, and non-destructiveness, so the description does not need to restate those. It adds value by describing the aggregate, hub-like nature of the response and connecting to get_vote for deeper vote detail. There is no contradiction with 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?

The description is a single dense sentence that leads with the core purpose and then packs every meaningful content type into a readable list. The parenthetical routing to get_vote earns its place and the whole definition is efficient despite its breadth.

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 getter with rich annotations, the description fully enumerates the return categories an agent needs to anticipate: status, history, sessions, votes, and document links. It also covers the natural follow-up path to get_vote. Nothing essential 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%: bill_id is described as 'KNS_Bill Id' and is required. The description adds no new semantic detail about where to find or format the bill_id, but at full schema coverage the baseline of 3 is appropriate.

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

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

The description uses a specific verb plus resource: it retrieves 'everything about one bill,' then enumerates the concrete data categories included (status, initiators, history, sessions, votes, documents). This clearly distinguishes it from siblings like search_bills and get_vote by emphasizing that this is the comprehensive single-bill endpoint.

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 scope clear: use this when you need comprehensive details about one bill. It also provides a useful routing cue by directing the reader to get_vote for per-MK/party vote breakdowns. It does not explicitly state when not to use it versus search_bills, but the context is strong enough to select correctly.

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, openWorldHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds only output scope, not behavioral details like pagination, output size, or long-career warnings; no contradiction exists.

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

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

A single front-loaded sentence with enumerations; every clause adds information and there is 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?

With no output schema, the description does a good job of saying what the profile contains (roles and bill count). It does not mention identity fields or how to handle long career outputs, and the usage guidance gap slightly reduces completeness.

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 fully documented (person_id source and knesset_num filtering behavior). The description adds no parameter-level meaning beyond the schema, matching the baseline of 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?

Description names a specific resource ('a person's profile') and enumerates the returned content (roles over time, bill count), so an agent knows what the tool returns. It does not explicitly differentiate from siblings like find_person or get_person_votes, which keeps 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 description gives no explicit when-to-use guidance or alternatives; an agent cannot tell whether to pick get_person over find_person for a search task. The schema's 'from find_person' hint is external to the tool description and does not count toward this dimension.

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 the tool read-only, non-destructive, and idempotent, so the description need only add behavioral context. It adds ordering ('newest first') and content scope ('what each vote was about'), which is useful. It does not mention pagination or result limits, though top/skip parameters hint at them.

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 short, purposeful sentences with no filler. The core behavior is front-loaded, and the sibling distinction is delivered succinctly in the second sentence.

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?

This is a 5-parameter tool with pagination and date filters and no output schema. The description covers purpose and ordering but leaves pagination behavior, result shape, and date-filter usage largely implicit. The schema helps for some parameters, making this minimally adequate but not 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 provides descriptions for person_id, since, and until, but top and skip have only titles, defaults, and ranges. The description adds no direct parameter explanations, though 'newest first' gives some ordering context for pagination. Overall it does not significantly supplement the schema.

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

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

The description clearly states the tool's function: showing how one MK voted in the plenum, newest first, with the subject of each vote. It distinguishes itself from get_vote by pointing out that get_vote shows how everyone else voted for a specific VoteID.

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 explicitly tells the agent when to use get_vote instead ('Pass a VoteID to get_vote to see how everyone else voted'), giving both the alternative and the condition that selects it. The intended use for this tool is also clear from the first sentence.

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, and destructiveHint=false. The description adds useful scope context ('any table') and the linked-record option, but it does not disclose not-found behavior, error handling, or expand semantics. No contradiction with 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?

A single, front-loaded sentence contains the operation, the resource type, the key constraint, and the optional behavior. No filler or redundant phrasing.

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 fetch tool with robust annotations and a fully documented schema, the description is nearly complete. An agent can invoke it correctly. A small gap is the lack of response/not-found behavior, but that is not essential for selecting or calling the 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 100%, so all three parameters are already documented. The description adds only the idea of optional linked records, which lightly reinforces the expand parameter but does not materially enrich parameter understanding beyond the schema.

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

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

The description states a specific verb and resource: 'Fetch one record from any table by its Id', which clearly identifies the operation. It is implicitly distinguished from sibling get_* tools by the phrase 'any table', though it does not explicitly contrast itself with the more generic query tool.

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 a clear context: use when you need a single record by ID, optionally with linked records. However, it does not explicitly say when to prefer this over alternatives like query or the dedicated get_person/get_bill tools, nor does it mention exclusions.

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 that the operation is read-only, idempotent, and non-destructive. The description adds useful content context, such as the inclusion of protocols and votes only for plenum sittings, but it does not disclose behavioral details like error handling or what happens when the session is not found.

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 compact phrase with no redundant words. It is front-loaded with the core entity and uses a colon to efficiently enumerate the returned contents.

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 two-parameter read-only lookup tool, the description, schema, and annotations together provide sufficient context to select and invoke the tool. It could be strengthened by mentioning where to obtain session_id or clarifying the committee/plenum disambiguation, but nothing critical is missing for basic 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 input schema already documents both parameters with 100% coverage, including the enum values for kind. The description largely restates the kind distinction and adds that plenum sittings include votes, but it does not meaningfully expand on session_id or how the parameters interact.

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 resource as a plenum sitting or committee meeting and enumerates its contents (time, committee, agenda, documents, votes), which distinguishes it from sibling tools like get_person or get_bill. It lacks an explicit verb such as 'retrieves' or 'returns', but the intent 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?

Usage is implied: if you need the details of one plenum sitting or committee meeting, this tool is appropriate. However, the description does not explicitly state when to prefer this over related tools like get_vote or get_record, nor does it provide exclusions or alternative 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 disclose readOnlyHint, openWorldHint, idempotentHint, and destructiveHint, covering the safety profile. The description adds the return content (voted on, totals, faction breakdown, MK names), which is useful context about what to expect. However, it does not mention potential errors, null returns, or any other behavioral traits, but this is partially mitigated by 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?

The description is a single, compact sentence that front-loads the tool's purpose ('One plenum vote') and immediately details the output. There is no filler or repetition; every phrase contributes information about the response content.

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 retrieval tool with one well-documented parameter and safety annotations, the description is fairly complete. It lists the key output dimensions the agent needs. It does not describe exact formatting or error handling, but with no output schema, it provides sufficient expectation of what is returned.

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% for the single parameter vote_id, including its exact source and type. The description adds no additional parameter semantics; it relies entirely on the schema. Since the schema fully explains the parameter, a 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 indicates the resource (a single plenum vote) and the specific information it provides: what was voted on, totals, faction breakdown, and MK names. It implies a retrieval action though it lacks an explicit verb. It distinguishes itself from siblings through its singular focus on one vote, differing from get_bill or get_person_votes, but the differentiation is implicit rather than 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 no guidance on when to use this tool versus alternatives. It does not state 'use when you have a vote ID' or recommend sibling tools like get_person_votes for listing a person's votes. The only usage hint appears in the schema's parameter description (source of vote_id), not in the tool description itself, so the agent receives no direct routing information.

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=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, covering safety. The description adds that results are grouped by topic and include what each table holds, which is useful context but not rich behavioral detail beyond that (e.g., pagination or output format absent). This aligns with the moderate bar for read-only list tools.

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 redundancy. The purpose is front-loaded, and the usage hint follows immediately. Every word contributes to clarity.

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 read-only list operation with no parameters, the description fully covers what the tool does, how to use it, and when to use it. No output schema exists, so no return format is required. The description provides enough for an agent to invoke correctly.

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

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

The tool has zero parameters, so the schema provides no semantics to add. The baseline for 0-param tools is 4, and the description doesn't need to elaborate on parameters since none exist. It does imply a global listing without filters, which is sufficient.

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 purpose: 'List every Knesset table, grouped by topic, with what each one holds.' It specifies a distinct action (list) and resource (Knesset tables), and differentiates from siblings by noting it's a discovery tool to use before describe_table and query.

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 guides when to use: 'Use this to find the right table before describe_table and query.' This names the alternatives and the correct sequence, leaving no ambiguity about selection.

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 description doesn't need to restate safety. It adds valuable behavior: a 200-row cap, next_skip pagination signal, Hebrew text fields, and OData v4 syntax, going beyond annotation coverage.

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 dense sentences plus one compact example carry all the key operational details. There is no filler, and the most important constraints (row cap, pagination, language) are 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 generic OData query tool with no output schema, the description covers pagination, row limits, text language, and gives a syntax example. It could be more complete with explicit guidance on how to discover table names or when to prefer sibling tools, but schema and annotations cover most remaining needs.

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 is 3. The description adds meaning by showing a realistic combination of table, filter, orderby, and expand, and by explaining that skip should use next_skip from the previous call. This is helpful but not essential given the schema.

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

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

The description states a clear action ('Query any Knesset table with OData v4 options') followed by concrete behavior and an example. It implies a general-purpose role distinct from sibling tools like get_record or get_bill, but it does not explicitly name those distinctions.

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 'any Knesset table' and the example imply this is the general-purpose query tool. However, there is no explicit when-to-use vs alternatives guidance, no exclusions, and no mention of specialized sibling tools like search_bills or get_person.

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=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds useful behavioral context: results are ordered with newest Knesset first, and each result includes its status in words. This goes beyond the annotations and helps the agent understand what to expect from the response.

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 fluff. The first sentence states the core function and filter dimensions, the second adds ordering and result content, and the final clause routes to get_bill for deeper detail. Every sentence 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?

For a search tool with no required parameters, no output schema, and annotations covering safety, the description is quite complete. It covers what the tool does, how results are ordered, what each result includes, and how to get more detail. The only minor gap is that it doesn't mention pagination (top/skip) or the default result count, but those are visible in the schema with defaults. Given the tool's simplicity, this is adequate.

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 71%, so the schema already documents most parameters. The description adds a high-level summary of filter dimensions but doesn't add detail beyond the schema for individual parameters. The 'text' parameter has an example in the schema, and 'status_id' has an example. The description's mention of 'status in words' hints at the status_id parameter's meaning but doesn't add significant new semantics. 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 specific verb ('Search') and resource ('bills'), and enumerates the filter dimensions (name, Knesset, status, type, initiator). It also distinguishes itself from get_bill by noting that search returns summaries and get_bill provides the full story. This clearly differentiates it from sibling tools like get_bill and find_person.

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 you need to find bills by various criteria, and it explicitly points to get_bill for full details of a single bill. It doesn't explicitly state when not to use it or mention alternatives like find_person for person lookup, but the context is clear enough for an agent to select it appropriately.

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