Postclick by PPC.io: Landing Page CRO

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false. The description adds value beyond them: it discloses cost ('Free', 'costs nothing'), states repeated calls are safe and normal, names the precondition of a completed audit, and describes the return shape ('what comes back is written to be read out'). What it does not cover is failure behavior when the audit is absent or still running, which keeps it short of a 5.

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

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

Front-loaded with the routing rule before the detail, and every sentence carries information. It is long, and the per-topic enumeration plus the relay instructions make it dense, but the length is justified by the eight mutually ambiguous topic values rather than padding.

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

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

With a two-parameter schema, no output schema, and no nested objects, the description supplies exactly what is missing: the meaning of each topic, the prerequisite, the cost profile, and guidance on how to relay the returned content. Nothing an agent needs to call it correctly is 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 coverage is 50% and audit_id carries no description at all. The description compensates heavily on the one enum parameter, expanding each of the eight topic values into the specific questions it answers, which is meaning an agent cannot derive from the bare enum 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?

States a specific verb+resource+scope: it answers one question from a completed audit by returning that part in full. It explicitly contrasts itself with 'the entire report' and with the agent's own summary, so an agent can place it against get_audit and get_audit_report without opening sibling schemas.

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?

Explicit trigger ('THIS IS THE TOOL FOR ANY FOLLOW-UP QUESTION about a page you have already audited'), an explicit prohibition ('Never answer a question about an audited page from your own summary of it'), a stated prerequisite ('Needs a completed audit'), and a per-topic routing table that tells the agent which topic answers which kind of question.

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 declare readOnlyHint=false, openWorldHint=true, and idempotentHint=false; the description adds genuinely new behavioral context beyond them — that the call kicks off an asynchronous job returning an audit_id that must be polled with get_audit and wait:25. It does not restate the safety profile, so it complements rather than repeats 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?

Four compact sentences, front-loaded with the required precondition and then the downstream workflow. No filler, though the mix of prerequisite, exclusion, and follow-up steps in one sentence makes it slightly dense to parse at a glance.

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 still names the return value (audit_id) and the exact follow-up calls needed to retrieve the result, and it states the boundary against build/design tools. Nothing an agent needs in order to invoke and continue the workflow 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 both url and context are already fully documented in the schema, including the 500-character limit and the 'pass what they already told you' guidance. The description's line 'Pass campaign context already supplied' reinforces, but does not extend, the schema. Baseline 3 is correct when the schema does the heavy lifting.

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 (start a landing-page audit) and explicitly scopes out adjacent work with 'Does not design or build a page,' which distinguishes it from build_page and publish_page. An agent can tell what this tool does and does not do without opening the schema.

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

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

Explicitly sequences prerequisites and alternatives: authorise price via check_balance first, search for existing work when the request concerns a prior audit, then get_audit with wait:25, then run_cro_skill for the deliverable. This is a full when-to-use and what-to-use-instead map.

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 this is a non-read-only, non-idempotent, open-world mutation, so the safety profile is partly covered. The description adds real behavioral context beyond them: a gating precondition (quote approval), the async return value (build_run_id), and the completion signal (artifact_ready) needed to know when the build is done.

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 tight sentences, front-loaded with the core action, followed by the polling contract and the constraint. Every sentence carries an actionable instruction with 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?

No output schema exists, and the description compensates by naming the returned build_run_id and the artifact_ready completion condition, plus the quote-review prerequisite. Minor gaps remain (error/failure behavior if approval is missing), but an agent has enough to call and poll 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 coverage is 67%; concept_id and direction are documented inline ('From get_concepts', 'Optional plain-English steer'), while audit_id is undocumented in both places. The description only alludes to the concept via 'the design the user selected' and adds no syntax or format detail, so baseline 3 is appropriate.

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

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

States a specific verb and resource ('Build the design ... into a complete HTML page') and clarifies scope by noting it must follow quote approval. It is clearly distinguishable from siblings publish_page and share_page, which it explicitly tells the agent not to invoke unprompted.

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 a clear precondition (live quote must be approved) and an exclusion ('Do not publish or share the page without the user asking'), which routes the agent away from publish_page/share_page. It also prescribes the follow-up polling step (get_build with wait:25). It stops short of naming the alternative tools outright.

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

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

Annotations already declare readOnly/idempotent/non-destructive/openWorld=false, so the safety profile is covered. The description adds beyond them by disclosing that prices are live and that an absent price must be treated as unknown rather than inferred — a real trust constraint.

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 the verb and returned data, followed by usage timing and the price-quoting rule. 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 names what is returned (balance, billing mode, live prices) and warns about missing prices, covering the agent's needs for a no-arg read 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?

Zero parameters, so there is nothing for the description to disambiguate; baseline of 4 applies. The description instead characterizes the returned fields, which is appropriate for a no-arg tool.

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 ('Read') plus concrete resources ('account balance, billing mode and live audit/build/pack prices'). No sibling tool overlaps this read-only billing surface, so the agent can route unambiguously.

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 states when to call: 'before a new paid step or when the user asks about cost.' It also gives a data-handling rule (quote only returned prices; missing price is unknown). No alternative tools are named, but none are needed here.

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, non-destructive and closed-world, so the safety profile is fully covered by structured data. The description adds no behavioral context beyond that – no indication of cost, auth, result shape, or whether results are complete vs. truncated – so it is adequate but adds little.

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 front-loaded sentences: the first says what it does and when, the second preempts the most likely mis-invocation by routing to run_cro_skill. No filler, no repetition of the title or annotations.

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

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

For a parameterless read-only listing tool with no output schema, the description covers purpose and the main routing decision. It stops short of describing what the listing returns (e.g., pages, assets, skill names), which is the one gap remaining given the absent output schema.

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

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

The tool takes zero parameters and the schema is empty, so there is nothing for the description to disambiguate. Baseline 4 applies; no parameter behavior is misrepresented.

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 gives a concrete verb+resource ('List what is in the account') and the title narrows it to a Postclick account overview, which separates it from action-oriented siblings like run_cro_skill or publish_page. It is slightly abstract about what 'what is in the account' actually enumerates, so it is clear but not maximally specific.

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 states an explicit trigger ('when the user asks to see their work') and an explicit exclusion plus alternative ('For a page fix, copy rewrite or designer brief, call run_cro_skill directly'). It does not cover the many other siblings (get_notes, get_asset, list_cro_skills), so routing against those is left to inference.

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

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

Annotations already declare readOnly/idempotent/non-destructive, so the safety bar is low. The description adds real behavioral context beyond them: the output is a zip with assets/, README and metadata.json, it also returns implementation_prompt, and crucially that every variant stops at a draft and never publishes without user confirmation. Missing only things like download-link expiry or rate limits.

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?

Front-loaded with 'Free' and the packaging behavior, and most sentences carry information. Slightly chatty in places ('This is the one for a user who wants the files'), but no sentence is purely 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?

No output schema exists, so the description carries the return-value burden and does so — download link, files, implementation_prompt. Combined with the publishing-safety note, an agent has enough to call and use it, though build_run_id semantics remain unexplained.

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%: platform has a schema description and enum, but build_run_id is undocumented anywhere. The description compensates well for platform — explaining that WordPress and Webflow steps genuinely differ and to ask when unknown — but adds nothing about build_run_id, which an agent must pass on every call.

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 — packages a finished page as a downloadable zip — and explicitly distinguishes itself from the sibling share_page ('share_page is the one for a user who wants something to look at'). An agent can route correctly 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?

Explicit when-to-use versus share_page, explicit guidance on when to pass platform and what to do when it is unknown ('Ask if you do not know'), and a note on who executes the resulting steps. Exclusions and alternatives are both covered.

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 readOnly/idempotent/non-destructive safety, and the description adds genuinely new behavioral context: the call is free, `expand=*` pulls everything attached, long write-ups are deliberately withheld with addresses to fetch them because the full payload exceeds a hundred thousand characters, and answers list available_links. That is real operational detail beyond the annotations.

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

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

Mostly well front-loaded — the free/safe framing and address format land first, then expand, then routing. However, the get_audit_report recommendation is stated twice in near-identical sentences ("as finished prose" / "written up as prose instead"), which is dead weight in an otherwise tight description.

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

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

No output schema exists, so the description must convey return shape, and it does: everything arrives with its headline detail, long write-ups are explicitly withheld with fetch addresses, and available_links lets the agent go deeper. Nothing needed to call 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 coverage is 100%, so the baseline is 3, but the description adds meaning: `expand` with `*` returns everything and its per-audit contents are enumerated, `uri` accepts a bare id, and the description explains the conditional default for `fields` and where available_links come from. It enriches the schema rather than repeating it.

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

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

States a specific verb and resource — reads any single thing by its address — and names the address form (postclick://audit/<id>). It explicitly distinguishes itself from `search`, `describe`, `get_audit_report`, and `get_asset`, so an agent can pick it over siblings without opening schemas.

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 explicit routing: expand first to see the shape, then fetch the two or three that matter; for finished prose use `get_audit_report`; for a picture pass the asset_id to `get_asset`. Both the when-to-use and the alternatives are named, not implied.

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

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

Annotations only declare the generic profile (non-readonly, open-world, non-idempotent, non-destructive). The description adds real workflow behavior beyond them: it returns a run to be resumed via get_concepts, it is quote-gated and cost-bearing, and it must not trigger a build without explicit user choice.

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 dense but purposeful sentences, front-loaded with purpose and gating before mechanics. Information-dense rather than wasteful, though the tight run-on phrasing slightly reduces scannability.

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 explains the return value (a run) and the resume path, plus the user-consent gate. Nearly complete for a gated generation tool; only the undocumented audit_id keeps it from being fully self-contained.

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 67% and the schema already carries rich prose for count (cost, reuse of existing directions) and direction. The description adds no parameter-level detail and leaves audit_id undocumented, so it does not meaningfully improve on 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?

States a specific verb+resource ('Generate visual design directions') scoped to an existing audit, and explicitly separates itself from build_page with 'Never start a build without their choice.' An agent can distinguish it from siblings like build_page and audit_page without opening any 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?

Preconditions are explicit (after the user requests designs and authorises the pack quote), it routes to check_balance for costs and get_concepts to resume, and it names an exclusion ('Never start a build'). Full when/when-not/alternative coverage.

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 readOnly/idempotent/non-destructive, and the description adds value beyond them: it says the call is free, that the url form is a public link requiring no login at full size, that bytes are downscaled to ~1024 across, and warns that full-size designs cost hundreds of thousands of tokens and that choosing wrong 'is expensive'. That cost and safety context is not in 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?

Front-loaded with 'Free.' and the essential routing rule, and every sentence carries a decision-relevant fact. Some phrasing is discursive ('and getting it wrong is expensive', 'not by habit'), which costs a little density but does not obscure the call.

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 no-output-schema read tool, it covers everything an agent needs: required asset_id usage pointer, both output modes with defaults, embedding syntax, resolution behavior, and cost implications. No material gap remains.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds real meaning: it explains the default value and behavioral consequences of `as`, and the embedding format for bytes (data:<mime>;base64,<bytes>) and the cost tradeoff for max_width ('smaller is cheaper') that the schema only implies.

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 (fetch an image asset by its asset_id) and immediately distinguishes the two output forms, which is the real decision the caller faces. An agent can tell this apart from siblings like get_concepts or audit_page without opening the schema.

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

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

Explicit routing: `as: "url"` is named as the default and usually right, with concrete conditions ('anything you publish with publish_page', 'showing somebody a design'), while `as: "bytes"` is scoped to 'ONLY for a document you are writing in a place that refuses to load pictures from other websites, which includes artifacts'. This is when-to-use and when-not, not inference.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true and destructiveHint=false, so safety is covered structurally. The description adds genuinely non-structured context: that a timeout preserves the run, that stalled/cancelled runs must not be read as completion, and a scope caveat ('Reading does not authorise a redesign'). No contradictions 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?

Four tight sentences, front-loaded with what is returned, then polling behavior, then completion semantics, then the next-tool handoff. No filler and no repetition of the schema.

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

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

With no output schema, the description usefully enumerates the returned fields (status, progress, elapsed time, ranked findings with typed edits) and explains how to interpret non-terminal states. It could still clarify the relationship to get_audit_report and where audit_id comes from, but it is close to complete for a 2-parameter polling 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 coverage is only 50%: wait is documented in the schema, audit_id is bare. The description compensates by giving the recommended wait value (25) and by implying resumption ('resume by ID'), which gives audit_id meaning. It stops short of describing audit_id format or acquisition.

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

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

The description names a specific verb and resource ('Read audit status, changed progress, server elapsed time and ranked findings with typed edits'), so the agent knows exactly what comes back. It implicitly separates itself from the finished-report tool by noting a failed/cancelled/stalled run is not a finished report, though it never names get_audit_report directly.

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 explicit operating guidance ('Use wait:25 while running') and routes the agent onward ('Once complete, use run_cro_skill or ask_audit for the relevant buyer, copy or offer evidence'). It does not state when to prefer this over get_audit_report, so the alternative selection is only partially covered.

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, but the description adds genuinely useful caveats: the result can be long, missing/withheld sections stay unknown, and buyer journeys are modelled rather than real research. Those fidelity warnings go beyond anything in the structured fields.

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

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

Four short sentences, front-loaded with the core action, then alternatives, then caveats. Tight and purposeful, though the caveat sentence could be trimmed slightly.

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 correctly states the return format (markdown) and length expectation, and covers the routing alternatives and data caveats. It is close to complete for a simple two-parameter read 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 coverage is 50%: topic is documented in the schema with its key list, while audit_id is bare. The description only reinforces the topic alternative ('use topic ... for one question') without adding format or semantics beyond the schema, so 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?

States a specific verb (read), resource (stored audit), scope (complete) and output format (markdown), which is enough to distinguish it from get_audit, ask_audit and run_cro_skill at a glance.

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 routes the agent: use the topic parameter or ask_audit for a single question, and run_cro_skill for a specific deliverable. This is a clear when-to-use-this vs when-to-use-something-else statement, not an implied one.

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?

The description adds substantial behavior beyond the annotations: it says the tool is free, builds take 15 to 25 minutes, wait calls hold open, running is non-terminal and contains no page, HTML is summarised by default to avoid flooding, and elapsed_seconds is server-measured from the build start. These details help the agent set correct expectations and avoid misusing the return payload.

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

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

The description is front-loaded with purpose and then proceeds through usage, return behavior, and parameter guidance in a logical order. It is longer than strictly necessary, but each sentence carries practical information for polling and interpreting the result.

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 supplies the missing return-value context: status stages, non-terminal running state, default summarised HTML, full HTML via include_html, and elapsed_seconds. Combined with annotations covering safety, it is complete enough for an agent to call and interpret the tool 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?

It adds meaningful semantics for wait (holding open, returning on stage change) and include_html (when the user actually wants the file), beyond the schema descriptions. build_run_id is not described in the text, though its purpose is clear from the name and required status.

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: it returns the status of a build and the completed page. This cleanly distinguishes the check/poll tool from its sibling build_page, which starts a build, without requiring the agent to open 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?

It gives clear polling guidance: wait set to 300, hold open until the stage moves or the page is ready, and call again on an unchanged stage. It also explains when to set include_html. However, it does not name explicit alternatives or when-not-to-use conditions.

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 cover the safety profile (readOnly, idempotent, non-destructive, closed-world), and the description goes well beyond them: zero credit cost and repeat-safety, data provenance distinguishing measured DataForSEO figures from model-written judgement, the edge case that an empty result is a real answer not a failure, and the stale-audit limitation.

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?

Front-loaded with the most decision-relevant fact ("Costs nothing") and organized around what is returned, provenance, and caveats. It is on the dense/long side with some run-on listing of returned fields, but nearly every sentence adds routing or trust 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?

No output schema exists, so the description takes on the burden of describing return content — which it does thoroughly (ads, keywords, volumes, CPC, landing pages, head-to-head summary, captures) and annotates with provenance and confidence caveats. Nothing an agent needs to call 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?

One parameter with 0% schema description coverage, so the description must carry the burden. It does imply the requirement ("Needs a completed audit", "Older audits carry no ad data"), which tells the agent audit_id must reference a finished audit, but it never states where audit_id comes from or its format. Adequate but with a clear 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 resource (the competitor layer of a finished audit) with an explicit enumeration of contents: rivals bidding on the same clicks, live ads, keywords, search volume, CPC, landing pages, top advertiser, and paid keyword count. It also names the sibling it is not (ask_audit), so an agent can route correctly 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?

Gives an explicit prerequisite ("Needs a completed audit"), an explicit alternative with a selection rule ("ask_audit with topic:competitors is the one for the written comparison; this is the one for the numbers"), and an exclusion (older audits carry no ad data). All the when/when-not decisions 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?

Annotations already cover the safety profile (readOnly, idempotent, non-destructive), and the description adds substantial operational context beyond them: it is free, packs take 3-8 minutes, long-polling holds the connection and returns on a material change, and a partial set is non-terminal. It also discloses that figures/ratings/testimonials are placeholders, not real data. It stops short of describing pagination or exact response shape, but the added context is rich.

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

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

Dense but almost every sentence carries actionable content (polling etiquette, placeholder caveat, sibling routing). The purpose is slightly deferred behind the leading 'Free.' and the length could be trimmed, but there is little true waste.

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 fully carries the return-value burden: it explains the image/picture rendering, the link, the runs.active progress signal, and the recommended flag. Combined with the polling and share_page guidance, an agent has everything needed to call this 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?

Adds meaning beyond the 67%-covered schema: the strategic recommendation to set wait=300 while rendering is active and why, and the behavioral difference of concept_id (opening screen per design vs. full stack of bands in page order). audit_id is undocumented but self-evident from the required-parameter 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 and resource ('Returns every concept rendered for an audit') and enumerates what each concept carries (image URLs, full-size link, runs.active count). It also implicitly distinguishes itself from generate_concepts (generation) and share_page (sending), so an agent can route correctly without opening other schemas.

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?

Explicit conditional routing: use wait=300 while runs.active > 0, omit concept_id to compare opening screens, pass concept_id to build a single design, and use share_page instead when the user wants to SEND a design. It also names when to stay silent on empty polls, which is real when-to-use 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 declare readOnly, idempotent, non-destructive, closed-world, so the safety profile is covered. The description adds value beyond them by disclosing the cost profile ('Free') and clarifying the two behavioral modes (single record vs. entire workspace). Return shape and any pagination behavior are still unspecified.

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, zero filler, and the core return semantics are front-loaded before the usage advice. 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 no-arg-required read tool with no output schema, the description covers what comes back and the two scoping modes. It stops short of describing the note structure or ordering, a minor gap rather than a blocking one.

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

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

Schema description coverage is 100% and the single parameter is fully documented in the schema. The description only restates the same semantic ('no address given' = all notes), so it adds no syntax or format detail beyond the schema. Baseline 3 applies.

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

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

States a specific verb and resource ('Returns the notes') and precisely scopes it to one record or the whole workspace. The read-vs-write split against the sibling save_note is clear from the phrasing, though save_note is never named explicitly, which keeps 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?

Gives concrete usage context ('worth calling at the start of a repeat job, so a monthly report picks up whatever the last one left behind'). No explicit when-not-to-use or named alternative, but the situational guidance is specific rather than generic.

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

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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds genuinely new context not in the annotations: the return shape ('starter requests and portable skill downloads') and the auth constraint ('No account or credits needed').

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

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

Two tight sentences, front-loaded with the resource and followed by the return/auth facts. The mid-sentence enumeration of skill categories is a little listy but each item earns its place by narrowing the discovery scope.

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 parameters and no output schema, the description carries most of the load, and it does state the return payload and the no-auth requirement. The one substantive omission is any pointer to run_cro_skill as the follow-up action, which leaves the browse-then-execute flow 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?

The tool takes zero parameters, so per the rubric the baseline is 4. Nothing in the description needs to compensate for an input schema, and it correctly does not invent parameter details.

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

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

The verb 'Find' plus the resource ('Postclick methods' / landing page skills) and an enumeration of the skill categories make the purpose clear. However, it never distinguishes itself from the obvious sibling run_cro_skill, so an agent can't tell discovery from execution purely from this text.

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. The tool is clearly a listing/discovery endpoint, yet the description never says 'use this to browse, then call run_cro_skill to execute' — the single most important routing decision among its siblings is left to inference.

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

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

Annotations declare destructiveHint=true and idempotentHint=true; the description substantiates both by explaining that re-publishing the same name replaces the page while the link keeps working. It also discloses the 2 MB page ceiling and the no-templating/no-styling guarantee, which annotations cannot convey. Auth model is covered only as 'public, no login' on the viewer side, so not quite exhaustive.

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?

Front-loads the core value (free, hosted, public, ready for a client) before the image-handling caveats. It is on the long side and closes with a slightly redundant restatement ('Use the client's name in the name so they can read it out') that repeats the slug-reuse point already made.

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 no-output-schema publishing tool, the description covers the essentials: where the page lives, that it is public, the size ceiling, overwrite/idempotency behavior, and the image-embedding policy. Nothing an agent needs in order to call 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 coverage is 100%, so the baseline is 3 and the schema already documents all four parameters. The description nonetheless adds real meaning: image URLs must come from get_asset with as: "url", the slug should be reused to update a previously sent report, and using the client's name in the slug makes it human-readable.

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 (hosts/publishes), the resource (the HTML you wrote), and the concrete outcome (a public page at postclick.ppc.io/r/<name>, no login). An agent can distinguish this from sibling page tools like build_page, export_page, or share_page without opening any 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?

Gives a clear context for use (a finished report ready to send to a client) and an explicit when-not for the image-inlining technique, with the condition that selects it (a destination that blocks external images). It does not route the agent between sibling tools such as share_page or export_page, so it stops short of full alternative 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/non-destructive, and the description adds genuinely new behavior: the tool returns source material rather than a new AI analysis, and missing evidence or ambiguous page matches surface explicitly. The content constraints (no unverified free/guarantee/rating claims, no placeholders like $X) further constrain behavior in ways annotations cannot express.

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 core purpose sentence is placed after usage and several output-style policy sentences, so the description is not front-loaded around what the tool is. Much of the content (never add free/guarantees, don't use $X placeholders) reads as prompt/behavior rules that inflate a tool description rather than earning each sentence as tool-selection 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?

With no output schema, the description appropriately describes the return ('source material for you to turn into the requested deliverable, not a new AI analysis') and the error behavior for missing evidence and ambiguous matches. Combined with a fully documented 6-param schema, an agent has enough to call it 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 100%, including enum semantics for skill and section, so the schema does the heavy lifting and the baseline is 3. The description only adds the page-vs-audit_id resolution hint already present in the schema, so it adds little parameter meaning beyond structured fields.

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

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

The description contains a specific verb+resource statement: 'Finds an existing audit by page URL or client name and retrieves the selected skill plus its relevant evidence in one call.' This clearly separates it from generative siblings, but it is buried after usage and content-policy prose, and it never names a sibling (e.g. get_audit) as the alternative.

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?

Opens with an explicit when-to-use trigger ('Use when the user wants page fixes, message match, buyer objections, copy rewrites or a client test brief') and adds selection conditions for first-fix vs. full rewrite vs. experiment brief. It also states exclusions ('never starts an audit, spends credits or publishes') and the one-change rule for first-fix requests.

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?

Adds behavior beyond the annotations: overwrite semantics ('Saving the same name again replaces it'), and the important non-effect that 'we never look inside it and the audit engine never reads it,' so it cannot alter Postclick's behavior. This complements idempotentHint/destructiveHint with the concrete consequence an agent needs.

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?

Front-loads the key point ('Free') and is well-organized, but the conversational tone makes it slightly longer than needed for a 3-parameter tool. Every sentence still carries information, so no serious bloat.

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 (and none is needed), and the description explains persistence, retrieval paths (get_notes and via the record itself), and that it has no engine side effects. An agent has everything required to call it 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 coverage is 100%, so the baseline is 3; the description adds real meaning by stressing the key is user-chosen and that 'any name, any value' is accepted, plus re-save replaces. That contextualizes value/key beyond their terse schema descriptions.

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

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

States a specific verb (attach/save) and resource (arbitrary name/value notes on a record), and clearly frames the scope as free-form metadata that attaches to 'any record.' It distinguishes itself from read-side siblings by naming get_notes as the retrieval counterpart.

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 clear context for use ('so the work you do around these audits survives between conversations') and names the alternative for reading back (get_notes). It stops short of explicit when-not-to-use guidance, but the intended use case is unambiguous.

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 it as a safe, read-only, idempotent operation, but the description adds valuable behavioral context beyond them: it is 'Free', it returns 'an address for each hit that you pass straight to `fetch`', and an empty query lists the most recent work. These details help the agent understand cost, output shape, and a non-obvious default behavior.

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

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

The description is front-loaded with the key information ('Free. Finds anything...') and progresses logically through what it matches, what it returns, when to use it, and the empty-query behavior. The example phrases are illustrative without being wasteful.

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

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

Given the tool's complexity, the full schema description, and the absence of an output schema, the description is complete enough: it explains the search mechanism, the return format, the empty-query fallback, and the kind parameter's narrowing role. No critical information is missing for correct invocation.

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

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

Schema description coverage is 100%, so the schema already documents all four parameters thoroughly. The description adds only minor color (e.g., 'page URL' as a query example) and largely repeats the schema's semantics, so 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 clearly states a specific verb ('Finds') and resource ('anything in this workspace by words'), and enumerates the types of things it matches (domain, page URL, client name, caption, project). It distinguishes itself from siblings by explaining that each hit returns an address to pass to `fetch`, which separates it from content-fetching tools.

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 provides explicit when-to-use guidance with a concrete trigger ('Use this the moment somebody refers to work they have already done') and several realistic examples. It also gives an alternative path for a specific case ('Use kind=audit to find audits directly') and defines the empty-query behavior, leaving little ambiguity about when to invoke it.

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

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

Although the description discloses many behavioral traits, it states that minting a new build link 'revokes the previous one' while annotations declare destructiveHint=false. That is a destructive side effect contradicting the annotation, which the scoring rubric treats as an annotation contradiction.

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

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

The description is front-loaded and mostly earns its length for a tool with several distinct sharing modes. It is slightly longer than necessary, with minor redundancy such as 'no-login' and 'including someone with no account' restating the same access condition.

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 still explains the return behavior well: a public link, one stacked design page for concept_id, a built page for build_run_id, and an audit link for audit_id. It gives enough context to call the tool correctly despite the branching parameter combinations.

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 already 100%, but the description adds meaningful semantics beyond the schema: concept_id returns a stacked design page, build_run_id shares a built page and revokes the prior link, audit_id shares the audit, and section opens the Competitors view. It also clarifies mutual exclusivity and reuse behavior.

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 gives a precise verb and resource: it 'mints a public no-login link' and explicitly distinguishes sharing a design, built page, or audit. It is immediately clear what the tool produces and how it differs from siblings like export_page.

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 states exactly when to use the tool ('send me the designs', 'forward this to my client'), when not to use it (never a dashboard or app link), and names the alternative for source files (export_page). The rules for mutually exclusive IDs and link reuse are also explicit.

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