Leads Discovery Agent by Nova (CIVAI)

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

With no annotations, the description carries the full behavioral burden. It usefully discloses two side effects (marks scans interrupted, releases the schedule lock), which is real value, but omits permissions required, irreversibility, and whether it works on non-stuck scans.

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 the key action and its effects parenthetically attached; zero filler. It is efficient, though it is arguably too terse to be fully useful rather than padded.

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 state-changing tool with no annotations, no output schema, and three fully undocumented parameters, the description is thin. It omits required permissions, return behavior, and error conditions an agent needs before invoking it.

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% for all three parameters (reason, agent_id, scan_ids), and the description clarifies none of them. It does not say what a reason is for, whether agent_id scopes the abort, or whether scan_ids can be a partial list.

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 (stop scans) and narrows scope to 'stuck running scans,' which distinguishes it from delete_scans and continue_scan. However, it does not explicitly name any sibling to route the agent, leaving full differentiation to inference.

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?

'Stop stuck running scans' implies a use case (recovering scans that are hung), but there is no explicit when/when-not guidance and no mention of alternatives such as delete_scans or continue_scan. 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?

No annotations are provided, so the description carries the full burden. It discloses what gets cleared (seen handles / WA progress), which is useful, but says nothing about reversibility, permission requirements, or side effects on in-progress scans (e.g., continue_scan). For a destructive operation with zero annotation coverage this is a significant 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?

One compact sentence with the imperative verb front-loaded and no wasted words. Its brevity, however, edges toward under-specification rather than true conciseness.

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?

A destructive, zero-annotation, no-output-schema tool with an undocumented parameter requires more context than this provides. The description omits the safety profile, parameter semantics, and any relationship to the scan workflow it affects.

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% and the single required parameter (agent_id) is undocumented in the schema. The description only alludes to 'an agent' without specifying format, source, or whether it accepts names versus IDs, so it fails to compensate for the coverage gap.

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 and resource ('Clear Leads Discovery scan cache') and clarifies what is being cleared ('seen handles / WA progress'), which helps distinguish it from siblings like delete_scans. However, it does not explicitly differentiate itself from the closely related delete_scans or explain the scope of 'cache' versus scan records.

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

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

No guidance on when to clear the cache versus using delete_scans, delete_scan_schedule, or any other sibling. No prerequisites or conditions are stated, leaving the agent to infer when this destructive operation is appropriate.

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 says a paused scan is continued but does not state whether this resumes, restarts, or mutates the scan, whether it needs specific permissions, whether the pause state is consumed, or what happens on failure. For a mutation tool with zero annotation coverage, this is a significant 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?

A single, front-loaded sentence with no filler. It is efficient, though its brevity contributes to the surrounding documentation gaps rather than being a purely positive trait.

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 4-parameter mutation tool with no annotations, no output schema, and 0% schema coverage, the description is far too thin. It omits required-parameter meaning, the effect of continuing, and success/failure 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?

Schema description coverage is 0% with 4 parameters. The description only vaguely gestures at 'selected_resources' (groups/targets) and says nothing about agent_id, scan_id, or the optional max_contacts_per_group, so it fails to compensate for the completely undocumented 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 (continue) and resource (a scan paused for selection), plus names the kinds of resources involved. However, it doesn't distinguish this tool from siblings like run_scan or trigger_scan_schedule, and 'paused for selection' is domain jargon an agent may not fully parse.

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 'paused for selection' implies the tool is only used after a scan has reached a selection state, which gives some conditional guidance. But there is no explicit when-to-use/when-not-to-use statement and no mention of alternatives such as run_scan.

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 explains the age-window semantics of two discovery params, but says nothing about permissions, duplicate-schedule behavior, whether the schedule executes immediately on creation, or side effects of auto_import/auto_outreach. For a 14-parameter mutation tool with zero annotation coverage, this is a significant 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?

It is compact and front-loads the purpose before the parameter detail, which is the right ordering. However, the second half is an extremely dense run-on clause packed with ranges and defaults, while whole parameter groups that matter more for a successful call go unmentioned; the allocation of words is skewed rather than economical.

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?

A 14-parameter creation tool with a nested object, no annotations, and no output schema needs far more than one sentence. The description gives solid detail on the discovery age-window logic but leaves the caller guessing about required fields' formats, scheduling semantics, and the return value, so an agent could easily construct an invalid or unintended schedule.

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% across 14 parameters, and the description only explains two of them (max_post_age_days with its 1-365 range and omit=no-limit default, post_age_relax_steps with its 0-4 range and default 3). Twelve parameters — including the required agent_id and channel, plus frequency, run_hour_utc, auto_import, auto_outreach, source_scan_id, and the nested params object's remaining keys — get no semantic help at all.

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

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

The description opens with a specific verb+resource ('Create an auto-scan schedule') and names the two operating modes (Import Only vs Message now outreach), which is genuine intent-level information. It does not explicitly differentiate itself from update_scan_schedule, trigger_scan_schedule, or list_scan_schedules, but the create verb makes the distinction largely self-evident.

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 two modes imply the situations the tool covers, but there is no explicit when-to-use guidance, no mention of prerequisites (does the agent need to exist first?), and no routing to update_scan_schedule for modifying an existing schedule or trigger_scan_schedule for running one now. Usage is inferable rather than 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?

With no annotations, the description carries the full burden. It usefully discloses scope ('completed scan runs', not schedules), but says nothing about irreversibility, required permissions, or what happens to associated results. Partial behavioral context only.

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 the scope boundary in parentheses. No wasted words, and the key constraint is immediately visible.

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 destructive mutation tool with no annotations, no output schema, and 0% parameter documentation, the description does far too little. It should at minimum cover irreversibility and parameter semantics, which are entirely 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 0% and both required parameters (agent_id, scan_ids) are completely undocumented in both schema and description. The description adds no meaning about what a scan_id is, the batch semantics of the array, or the agent_id's role.

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 (delete) and resource (completed scan runs), and explicitly contrasts with the sibling delete_scan_schedule by noting it does not delete schedules. An agent can distinguish this from the schedule-deletion tool without opening either schema.

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

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

The parenthetical gives a clear exclusion (does not delete schedules), which routes the agent toward the schedule-deletion sibling, and the word 'completed' implies it only targets finished runs. However, it does not name the alternative tool explicitly or state prerequisites.

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 behavioral burden for a destructive operation, yet it says nothing about permanence, required permissions, or any side effects on associated scans. 'Delete' restates the tool name rather than disclosing 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?

A single front-loaded sentence with zero wasted words. It is efficient, though its brevity reflects under-specification as much as conciseness.

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 destructive, two-parameter tool with no annotations, no output schema, and no parameter documentation, the description is far too thin. An agent lacks the information needed to call it safely or 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?

Schema description coverage is 0% and the description mentions neither agent_id nor schedule_id, so it adds no meaning beyond the schema's bare property names. Only the self-descriptive parameter names keep this from being a 1.

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 (Delete) and resource (auto-scan schedule), which distinguishes it from siblings like delete_scans, update_scan_schedule, and trigger_scan_schedule. It is clear but does no explicit sibling differentiation beyond the resource name itself.

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 versus alternatives, no prerequisites (e.g., whether the schedule must be disabled first), and no warning that the operation is irreversible. The agent must infer all 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 disclosure burden. It adds useful behavior: the output is actionable steps per channel, the daily budget is already split, and Nova never touches the ad account; however, it does not explicitly state read-only behavior, auth needs, rate limits, or whether any side effects occur.

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

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

Three short sentences, front-loaded with what is returned, then when to use it, then the account-access caveat. 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?

With no annotations or output schema and only 33% schema coverage, the description does explain the guide's content and a usage condition. However, it omits the meaning of agent_id and leads_target, so an agent lacks full parameter context.

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 33%, with only the channel parameter described in the schema. The description says 'per channel' but adds no meaning for agent_id or leads_target, leaving the required agent_id and optional leads_target semantics to guesswork.

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 first sentence specifies the returned artifact: an ad plan rendered as per-channel tap steps in the owner's words with the budget already divided. That is clear, but it never names the sibling get_ad_plan or explicitly states how this differs from it, so sibling differentiation is left implicit.

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 gives an explicit selection condition: use this when the owner wants to run the ads themselves. It also contrasts with Nova handling the ad account, but it does not explicitly mention get_ad_plan as the alternative or state 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?

With no annotations, the description carries the full safety burden and does so: 'Reads only; nothing is launched and no money moves' explicitly rules out side effects and spend, and it discloses the empty-state contract status=no_evidence. It stops short of describing what happens with missing evidence beyond that status or any account/permission implications.

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?

Compact at roughly three sentences with the core output and the read-only guarantee front-loaded. Slightly run-on phrasing ('three things to film, each citing a count...') costs a little readability.

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 must characterize returns — it names the plan components, the spend/reach figures, and the no_evidence status, which is enough to call and interpret the tool. Only the guide-style sibling relationship and account_mode consequences remain unaddressed.

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 75%, so most parameter meaning is already structured. The description adds that spend is derived from a lead target, but says nothing about country or account_mode behavior beyond what the enum and schema descriptions already provide.

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 output: an ad plan built from the agent's scans, containing three filmable concepts with cited lead counts plus spend/reach for a lead target. This is clearly distinguishable from the scan-management siblings, though the framing is narrative rather than a crisp verb+resource statement.

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

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

Usage is only implied — an agent infers it should call this when it wants ad recommendations for a business. No explicit when-to-use/when-not, and the closely named sibling get_ad_guide is never referenced or differentiated.

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 behavioral burden and largely fails it. It implies a read operation but never states it is read-only, whether it requires specific permissions, whether results are cached or paginated, or what triggers recomputation. The only behavioral hint is the '(window e.g. 7d, 30d)' parenthetical.

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 compact sentence with the resource front-loaded and the window format as a parenthetical aside. Nothing is wasted and the parenthetical earns its place by documenting the undocumented param.

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% param coverage, the definition is thin for an analytics endpoint: it never describes what analytics are returned (counts, trends, groupings), how they are aggregated over the window, or the empty-result case. An agent can call it but cannot anticipate the response.

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 for both params. It adds genuine meaning for 'window' by showing accepted values ('7d', '30d'), but gives no meaning for the required 'agent_id' beyond the name, and doesn't state the default window or granularity.

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 ('Get') and resource ('sourced-leads analytics') scoped to an agent, which is more concrete than the tool name alone. However, 'analytics' is left undefined, so the agent still doesn't know what metrics or shape of data comes back. No sibling is close enough to require explicit differentiation, so no penalty there.

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 an example input format for the window but never says when to reach for this tool versus the scan-oriented siblings (list_scan_results, get_scan). There is no when-to-use, no prerequisites, and no mention of alternatives.

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 exist, so the description carries the full burden. It does disclose that leads come back paginated and what the payload contains (status, progress, leads), which is genuinely useful behavior beyond the schema. However it omits permission requirements, error behavior for a bad scan_id/agent_id, and any indication of whether the call is side-effect free.

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 no filler; the parenthetical efficiently packs in the return contents. It is appropriately sized, though the brevity comes at the cost of the missing detail noted elsewhere.

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, no annotations, and 0% parameter coverage mean the description should do more heavy lifting. It covers the return payload shape but leaves all four parameters undocumented and does not describe pagination defaults or how to page through leads.

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% for all four parameters, and the description only hints at pagination, without explaining limit, offset, scan_id, or agent_id. The relationship between agent_id and scan_id (both required) and the pagination syntax are left entirely to inference.

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 ('Get one scan') and enumerates the payload it returns (status, progress, leads), which implicitly distinguishes it from the singular/plural siblings. It does not explicitly name list_scans or list_scan_results, so differentiation relies on the reader inferring 'one' vs 'list'.

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?

No when-to-use guidance is given. With siblings list_scans and list_scan_results available, the agent gets no explicit rule for choosing this single-scan fetch over the list endpoints, and no prerequisites (auth, ownership) are 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?

With no annotations, the description carries full behavioral burden, and it does disclose a meaningful side effect via the outreach modes (none|immediate|bulk_followup), warning the agent that import can trigger outreach. However it says nothing about permissions, duplicate handling, or reversibility of the CRM write.

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 compact sentence with the action front-loaded and the optional mode values parenthetically scoped. It is efficient, though arguably too terse to be self-sufficient.

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 5-parameter mutation tool with no annotations, no output schema, and no schema descriptions, this one-liner is insufficient. It should at least clarify what lead_ids/scan_id refer to and what happens to the CRM record after import.

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% across 5 parameters. The description only documents the outreach field and its allowed values (which the schema lacks), leaving agent_id, scan_id, lead_ids, and label entirely unexplained in both places.

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?

Specific verb+resource: 'Import discovered leads into the agent CRM', which reads clearly as a CRM write operation rather than a scan operation. It does not name any sibling tool or explicitly distinguish itself from list_scan_results or suggest_targets, so it stops short of 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?

No when-to-use guidance, prerequisites, or alternatives are given. The agent must infer that this follows a scan and consumes lead_ids from discovery results; nothing in the text routes it against the many scan/discovery siblings.

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 does real work: it discloses that the spend cap is debited before any creation and that nothing is created above the cap, plus the connected-account precondition and the no-creative-writing guarantee. Still missing are the failure/refund behavior when a cap is hit mid-flight, idempotency, and what the caller gets back.

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?

Four short sentences, front-loaded with the operation and the spend-cap constraint. The idiom 'named out loud' is evocative but slightly informal; nothing is wasted, though a touch more precision would help.

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 an 11-parameter mutation with no annotations and no output schema, the description covers the safety-critical spend-cap behavior well but leaves gaps: channel/currency scope, daily_budget interplay with the cap, and return value (e.g., a plan id usable with get_ad_plan/stop_ad_plan) are unaddressed.

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 82%, so the schema already documents cap_minor, currency, channel, and the creative fields. The description reinforces the cap semantics ('the number the owner approved') but adds nothing about the other 11 parameters such as daily_budget_minor, country, or call_to_action. 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 first sentence names a specific verb and resource ('Run one ad on one channel') and the sibling set (get_ad_plan, list_ad_plans, stop_ad_plan) makes the create-vs-read-vs-stop distinction clear. The line 'this never writes an ad' is a useful clarification about creative generation, but in isolation it reads as if the tool does not create an ad at all, which slightly muddies the purpose.

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?

'Needs a connected ad account' gives a prerequisite, and 'Run one ad on one channel' implies a single-ad scope. But there is no explicit when-to-use/when-not guidance versus get_ad_plan or stop_ad_plan, and no mention of what to do instead if the account is not connected.

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 disclosure burden and does deliver ordering ('newest first'), returned fields (cap, channel, running/stopped status) and the read-only nature of the call. It omits pagination/result limits, what happens for an agent with no plans, and any permission scoping, which are meaningful for a list endpoint.

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 compact sentence that front-loads scope and ordering and then enumerates the payload fields; there is no filler and nothing an agent must read past to get the essentials.

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 stands in for the return shape by naming the fields and their status semantics. For a one-parameter read tool this is close to sufficient; only pagination and agent_id semantics are 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 0% for the single agent_id parameter, but the phrase 'this agent' implicitly conveys that the list is scoped to that identifier. It adds no format or constraint detail for agent_id, so it only partially compensates for the undocumented 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?

Names a specific verb (list) and resource (ad plans) and scopes it to 'this agent', so an agent can distinguish it from the singular get_ad_plan or the mutating launch_ad_plan/stop_ad_plan siblings. It does not explicitly name the sibling it is not, keeping it just short of 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?

Usage is implied by 'Every ad this agent has already launched' and 'Reads only', which signals a safe enumeration call, but there is no explicit when-to-use guidance or routing to get_ad_plan for single-plan detail.

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. The verb 'List' does signal a non-mutating read of status data, which is the key behavioral fact here, but the description says nothing about permissions, response shape, or whether the list can be empty/filtered.

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 tight sentence with no filler, and the enumerated connector types come early. It is efficiently sized for a simple list tool, if a touch sparse.

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 tool with no output schema, the description covers what is listed and for whom, which is the essential information. It falls short on the one parameter it takes and on what the returned status values look like.

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% and the single parameter agent_id is undocumented. The phrase 'for a support agent' hints that agent_id identifies the support agent, but the description never confirms this or explains the expected identifier format.

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 (List) and resource (connector status) and enumerates the connector types covered (WhatsApp, Instagram, Email, X), scoped to a support agent. It is clearly distinguishable from the scan-related siblings, though it does not explicitly contrast with them.

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 call this tool, what preconditions apply, or what alternatives exist. The agent must infer from the name alone that this retrieves connector status rather than modifying anything.

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 behavioral burden. It implies a read operation but discloses nothing about pagination, authentication, whether leads are truncated, or what is returned for an active vs completed scan.

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 short sentence, front-loaded with the alias relationship and the resource. It wastes no words, though the extreme brevity is under-specification rather than elegance.

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 4-parameter tool with no annotations, no output schema, and no schema descriptions, this eight-word description is far too thin. It omits return shape, pagination behavior, and any distinction from get_scan, leaving the agent to infer nearly everything.

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% across four parameters, including two required ones (agent_id, scan_id) plus limit/offset. The description mentions no parameter at all, so an agent gets zero guidance on identifier formats or pagination semantics.

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 and resource ("read leads from an active or completed scan") and explicitly names the sibling it duplicates (get_scan), so an agent can immediately tell what it mirrors. It does not explain what distinguishes it from get_scan beyond being an alias, but the core purpose 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 never says when to prefer this tool over get_scan, which is the only decision that matters for an alias. The phrase "active or completed scan" hints at scope but offers no explicit when-to-use, prerequisites, or selection criteria.

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 conveys only that results include past and active scans; nothing about permissions, pagination, ordering, or result volume is disclosed.

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 tight sentence with the scope qualifier front-loaded and no filler. It is appropriately brief for a simple list operation, though the brevity comes at the cost of substance.

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 an undocumented required parameter, the definition leaves too much unspecified for an agent to call it confidently. A tool whose only input is a bare agent_id needs at least a note on its meaning and the result shape.

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 required parameter agent_id has 0% schema description coverage, and the description never explains what the agent identifier is or where it comes from. The parameter is effectively undocumented in both places.

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 ('List') and resource ('leads discovery scans') scoped to an agent, and the phrase 'past and active' distinguishes it from a singular get_scan. It does not explicitly contrast with siblings like list_scan_results, so it stops short of 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?

No when-to-use guidance and no alternatives named, despite many closely related siblings (get_scan, list_scan_results, list_scan_schedules). The agent must infer the choice from the name alone.

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 exist, so the description carries the full behavioral burden, yet it says nothing about whether inactive/disabled schedules are included, ordering, pagination, or what happens for an unknown agent_id. For a read tool with zero annotation coverage this leaves the agent guessing about the result set.

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 short, front-loaded sentence with no filler. It is efficient, but its brevity reflects under-specification rather than deliberate compression of rich 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?

With no annotations, no output schema, and an undocumented parameter, the description would need to explain return contents and scoping to be complete. As written, an agent knows only the general topic of the call.

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% and the single agent_id parameter has no documented meaning beyond the vague phrase 'for an agent'. The description does not clarify format, source, or whether it accepts an ID versus a 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 a specific verb (List) and resource (auto-scan schedules) scoped to an agent. It is distinguishable from create_scan_schedule, delete_scan_schedule, update_scan_schedule and trigger_scan_schedule by the 'list' verb, though it never explicitly contrasts itself with those siblings.

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 no when-to-use or when-not-to-use guidance and names no alternative. An agent must infer that this is the read-only enumeration counterpart to trigger_scan_schedule/update_scan_schedule on its own.

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 of behavioral disclosure. It explains the age-window relaxation nuance ("window widens within a run only") but omits permissions, whether the scan is asynchronous, side effects, and what the call returns.

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 front-loads the purpose and then packs relevant parameter detail into a compact follow-up sentence. The second sentence is dense but contains useful semantics rather than 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 mutation tool with no annotations, no output schema, a nested params object, and 0% schema description coverage, the description is incomplete. It covers purpose and some nested discovery parameters but omits the required agent_id, the overall params shape, and start/return 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?

Schema coverage is 0%, and the description compensates partially by listing allowed channel values and giving ranges/defaults for max_post_age_days and post_age_relax_steps. However, it leaves the required agent_id entirely undocumented and does not describe the structure of the params object beyond x/instagram discovery 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?

States a specific action, "Start a leads discovery scan," and enumerates supported channels. It is clear what the tool does, though it does not explicitly distinguish itself from sibling scan tools such as continue_scan or trigger_scan_schedule.

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 continue_scan, trigger_scan_schedule, or create_scan_schedule. With many related scan tools, the agent is left to infer that "Start" means a new immediate scan.

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. It adds real value by disclosing that the campaign is paused first and spend stops on the first call, which is non-obvious sequencing behavior. It does not disclose whether the stop is reversible, whether the plan can be relaunched with launch_ad_plan, what state the plan ends in, or what the response returns.

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 sentences with no filler, and the key operational fact (spend stops immediately) is front-loaded after the action statement. Slightly terse given the remaining gaps, but structurally sound.

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 mutation tool with no annotations, no output schema, and an undocumented agent_id, the description covers the spend-stopping behavior but leaves reversibility, resulting state, and the meaning of agent_id to inference. Adequate minimum but clearly incomplete.

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 only 50%: plan_id is documented as coming from list_ad_plans, but agent_id has no description anywhere. The description text adds no parameter meaning at all, so it fails to compensate for the undocumented required parameter.

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: switching one launched ad off, which maps to stop_ad_plan and is clearly distinct from launch_ad_plan in the sibling list. The wording 'launched ad' rather than 'ad plan' is slightly loose but an agent can identify the operation.

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 'one launched ad' implies a precondition (the plan must already be launched), which usefully distinguishes this from launch_ad_plan. However, there is no explicit when-to-use/when-not guidance and no mention of what to do if the plan is not launched.

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, yet it discloses nothing about cost, latency, rate limits, or whether proposed targets are persisted or ephemeral. The word 'AI-propose' hints the output is generated rather than ground truth, but that is not made explicit.

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 no wasted clauses; the constrained parenthetical keeps it tight. It is efficient, though the parenthetical is terse to the point of underspecification.

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 6-parameter, 0%-coverage tool with no annotations and no output schema, one sentence is inadequate. An agent cannot tell what it will receive back, how to size depth/breadth, or what min_followers and disable_hard_filter do.

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% across 6 parameters, so the description must compensate, but it only maps the channel concept (Instagram/X) and vaguely flags depth/breadth as optional. min_followers, disable_hard_filter, and the required agent_id are left entirely unexplained.

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 (AI-propose) and resource (@targets) scoped to Instagram or X for a discovery scan, which is more informative than the bare name. It does not, however, distinguish itself from siblings like run_scan or trigger_scan_schedule, so an agent must infer where suggestion ends and scanning begins.

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 only usage signal is the parenthetical noting depth/breadth are optional, which is vague and says nothing about prerequisites or sequencing relative to run_scan/continue_scan. No when-to-use, when-not-to-use, or alternative is named.

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 exist, so the description carries the full behavioral burden. It reveals that this is an execution/trigger action rather than a query, but says nothing about side effects, whether the scan runs asynchronously, resource consumption, permissions, or whether the schedule's own state is modified.

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 short, front-loaded sentence with no filler; the action and the immediacy clause are stated first. It is efficient, though arguably too terse given the undocumented parameters.

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% parameter coverage, the description leaves too much unspecified for a mutating trigger tool — an agent cannot tell what the scan produces, what state changes occur, or how the two IDs relate.

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% and there are two required parameters (agent_id, schedule_id). The description does not mention either parameter or explain their relationship, relying entirely on the self-evident naming, which is insufficient compensation for a total coverage gap.

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 and resource (run/trigger a scan schedule) and adds the 'Run now' cue to indicate immediate rather than scheduled execution. It distinguishes reasonably well from create_scan_schedule and update_scan_schedule, though it doesn't clearly separate itself from sibling run_scan or continue_scan.

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 parenthetical '(Run now)' implies use when you want the schedule to fire immediately instead of at its scheduled time, but no explicit when-to-use guidance, prerequisites, or alternatives (e.g., run_scan vs this) are 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 provided, so the description carries the entire burden. It discloses one useful behavioral trait (the age window widens within a run only), but says nothing about whether omitted fields are preserved on update, whether pausing requires enabled=false, what side effects or permissions apply, or what happens to in-flight runs.

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-sentence, front-loaded structure that leads with the operation and then the caveat about discovery params. Dense but no wasted sentences; the second sentence could have been split for readability but every clause carries 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 13-parameter mutation tool with a nested 'params' object, no annotations, and no output schema, the description covers only a sliver of the surface. An agent could not determine patch semantics, field interactions, or the meaning of most parameters from this text.

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% across 13 parameters, and the description only explains two of them (max_post_age_days and post_age_relax_steps, including ranges, defaults, and the omit semantics). Eleven parameters – label, channel, enabled, frequency, run_hour_utc, max_runs, auto_outreach, max_leads_per_run, relax_target_filter_after_runs, params, auto_import – are undocumented in both schema and description, a large gap the text does not compensate for.

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 and resource ('Update ... an auto-scan schedule') and adds the pause/resume capability, which distinguishes it from create/delete/trigger siblings in the same family. It never names an alternative explicitly, but the resource 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?

No guidance on when to use this tool versus create_scan_schedule, trigger_scan_schedule, or delete_scan_schedule. The pause/resume mention implies that toggling 'enabled' is the mechanism for pausing, but that is left for the agent to infer with no stated conditions or exclusions.

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