placements

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

Annotations already declare readOnly/idempotent/non-destructive, so 'Free and read-only' is largely redundant, but the description goes further: it discloses that a paid Essentras recovery service and its current price are surfaced, that help-page read dates are included, and that no recovery or timeline can be promised because Meta decides. That is real behavioral context 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?

Front-loaded with cost and safety profile, then who it is for, then the input rule, then the return contents. It is dense and the enumeration of returns runs long, but almost every clause carries information an agent needs.

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

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

With no output schema, the description correctly carries the return burden by listing the route, first step, help pages with read dates, timing guidance, scam warnings and service price. Privacy constraints, safety profile and limitations are all covered; only minor detail about response shape 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 100% with a fully documented enum, so the baseline is 3. The description adds a rule the schema does not encode — pass only 'what happened' and never identifiers — which meaningfully constrains how the single parameter may be populated.

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 (returns the official Instagram recovery route) and scopes it to five enumerated owner situations. It is unmistakable against siblings like check_review_removability or find_removal_route, which target entirely different platforms and questions.

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?

Names the qualifying conditions (legitimate owner, hacked/disabled/locked/twofa/no-email-phone) and an explicit do-not ('never the handle, email, phone, password or a code'), plus the boundary 'no hacking and no account access'. No competing sibling is named as an alternative, but none plausibly competes.

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/destructive/openWorld/idempotent, so the description's additive value is the caveats: 'The score is an Essentras rule of thumb, not a Google metric. Google decides whether to show a panel, and paid placements are paid editorial, not independent coverage.' It also describes the return payload in detail. It does not discuss rate limits or auth, but for a free read-only scorer that is minor.

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/read-only and the core purpose, then the answer topics and the return payload. It is dense and long, but each sentence carries distinct information (inputs, outputs, caveats) with little 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 must explain return values, and it does thoroughly: score out of 100, band, each gap with points and next action, the recommended next step, and Google sources with read dates, plus partial-result behavior ('With answers missing it returns the questions still to ask'). It also clarifies score provenance limits.

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

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

Schema description coverage is 100% with all 11 enums fully documented, so the schema already carries the parameter meaning. The description enumerates the same topic list ('subject, the panel state, and coverage, quality, wikipedia...') and adds one useful constraint ('never their name or links'), but largely restates what the schema provides.

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

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

States a specific verb+resource: 'Scores how ready a person or business is for a Google Knowledge Panel.' It further anchors the tool to a named feature ('the same score as the free Entity Readiness Check on essentras.com') and is clearly distinct from siblings like check_wikipedia_notability or check_review_removability.

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 strong context: 'Free and read-only,' and instructs the agent to 'Ask the person 11 multiple-choice questions about their sources and what Google shows today (never their name or links).' However, it never explicitly contrasts when to choose this tool over the sibling readiness checks (e.g. wikipedia notability), so 5 is not warranted.

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 safety (readOnly, idempotent, non-destructive, closed-world), so the bar is lower. The description still adds real behavioral context: it is free, it will not remove anything ('Google decides every removal'), and it explicitly discloses the negative-result rule ('A genuine negative review gets No policy match'). It does not discuss any rate limits or auth, but none appear to apply.

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 front-loaded with the most decision-relevant facts ('Free and read-only', what it tells the owner) and no sentence is pure filler. The second sentence is a long colon-list that essentially restates the schema fields, making the passage denser than it needs to be, but overall the size is justified by what it communicates.

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?

There is no output schema, so the description carries the full burden of describing returns, and it does: verdict, Google's rule with policy link and read date, where to report, evidence to attach, timing, appeal path, templates, and the paid service only when offered. For a 6-parameter, nested-enum tool this is complete enough for an agent to run 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 a 3 is the baseline, but the description adds meaning by turning the fields into a conversational sequence: whose review, whether the reviewer was a real customer, what it contains, whether they can show it, and where they are in Google's process. That ordering and the emphasis on collecting facts rather than the review text is guidance the schema alone does not convey.

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: it tells a business owner whether a Google review matches one of Google's named review rules, and it even identifies the scope of the verdict (strong match, arguable, no policy match). That is far more precise than a restated name. It never names a sibling such as find_removal_route, so an agent comparing candidates still has to infer the boundary between 'judge removability' and 'find a removal route.'

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 strong operational guidance for the interaction ('Ask the person for facts only, never the review text, a name or a link'), which implies the usage context. However, it never states when to choose this tool over siblings like find_removal_route, nor any exclusions or prerequisites beyond that one instruction.

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

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

Annotations already cover the safety profile (readOnlyHint, openWorldHint=false, idempotentHint, destructiveHint=false), yet the description adds substantial context: the per-source verdict vocabulary, the returned rule citation with link and read date, conditional disclosure duties, and a price surfaced only when the band is 'Reviewer judgment applies'. It also states a substantive rule (press releases, sponsored and paid placements never count) and a limitation disclaimer that the bands are an Essentras rule of thumb while volunteer reviewers decide.

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 opening 'Free and read-only' front-loads the key constraint, and the middle sentences about the input-gathering protocol and return shape earn their place. It is dense and slightly run-on in the return-value and press-release clauses, and the 'never send the outlet, headline or link' instruction duplicates schema text, costing a point.

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 carries the full burden of explaining returns and does so thoroughly: per-source verdicts, overall band, rule citation with link and date, disclosure duties, and the conditional service/price mention. Inputs, output shape, and scope limits are all covered, so an agent needs nothing further to invoke and interpret 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 100%, and the enum descriptions for source type, the five questions, subject, criteria and connection are unusually detailed, so the schema does the heavy lifting. The description repeats the data-minimization rule ('never the outlet, headline, link or the person's name') that the schema's sources description already states, adding no new parameter meaning. Baseline 3 applies.

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

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

The description names a specific action (tests a subject's sources against Wikipedia notability guidelines) and enumerates the exact rules applied (WP:GNG, WP:NCORP, WP:BASIC, WP:CREATIVE). It is clearly distinguishable from sibling checks like check_knowledge_panel_readiness or check_review_removability, which address different platforms entirely.

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 concrete procedural guidance: ask about the article subject, the person's connection, and each source's type plus five yes/no/unsure answers, with an explicit exclusion list of data never to submit. What it lacks is any statement of when NOT to use this tool or which sibling to prefer for adjacent questions, so it stops short of a full 5.

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

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

Annotations already declare readOnly, idempotent, non-destructive, closed-world behavior, so the safety profile is covered. The description adds real behavioral context beyond that: 'Official channels only,' the decider is 'Google, the publisher or the platform,' the fit label is 'from Google's own criteria (not a success rate),' and 'a refund is never a promise of removal.' This expectation-setting is genuinely additive.

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 opening 'Free and read-only' is well front-loaded, and spelling out the return payload is justified since no output schema exists. But the sentence is a bloated run-on, and enumerating every content type ('contact details, an ID number, intimate images...copied work') duplicates the schema enum verbatim, which is wasted space.

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 carries the burden of return values and does so thoroughly (route/source, steps, official links with read dates, evidence, timeline, fit label, letters, limits, web link, service price). Combined with annotations covering the safety profile, an agent has enough to call and interpret this tool, though the prevarication about pricing/refunds could be tighter.

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 both parameters carry exhaustive enum descriptions, so the schema already carries the semantic load. The description restates region ('where the person lives (US, EU, EEA or UK, or elsewhere)') and the situation list without adding format or syntax beyond what the schema provides. Baseline 3 applies.

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

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

The description gives a specific verb+resource: it finds the removal route for 'something about a person that shows in Google' across a long, concrete list of content types. The Google-focused scope implicitly separates it from platform siblings like check_instagram_recovery_path and check_wikipedia_notability, though no sibling is named outright. Purpose is unmistakable but sibling routing is left 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?

It states the tool is 'Free and read-only' and instructs the agent to 'ask only what it is and, where it matters, where the person lives,' which is useful invocation guidance. However, it never says when to use this versus the check_* or quote_* siblings, and gives no explicit exclusions. Usage context is implied 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?

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so safety is covered. The description adds useful non-annotation context by enumerating the returned detail (price, turnaround, authority, audience), which matters because there is no output schema. It still says nothing about error behavior for an unknown id, so it is not a full behavioral account.

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 sentence with the scope and returned fields front-loaded; every clause earns its place and nothing is 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 simple read-only single-record fetch with full annotation coverage and a fully documented parameter, the description is nearly sufficient. Since no output schema exists, listing the returned fields carries real weight, though the list is illustrative rather than a complete account of 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?

Only one parameter, and the schema documents it at 100% coverage ("Outlet id returned by search_outlets"). The description's "by its id (from a search result)" adds provenance meaning but no format or syntax beyond what the schema already states, so the 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?

"Full detail for a single outlet by its id" gives a specific verb+resource+scope, and the parenthetical "(from a search result)" plus the listed fields (price, turnaround, authority, audience) separate it from the sibling search_outlets, which returns search results rather than one record.

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 phrasing "by its id (from a search result)" establishes the intended workflow of retrieving a record produced by search_outlets, so the agent knows when to reach for this tool. It stops short of naming search_outlets explicitly or stating exclusions (e.g., when a search result already contains enough 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?

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, so the safety profile is covered. The description adds real value beyond them by disclosing the response content (price or 'priced per case', refund terms, who decides) and the existence of a free checker to run first, though it says nothing about rate limits or freshness of pricing.

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

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

One dense sentence that front-loads the scope ('beyond single placements') before the parenthetical service list and the optional filter. The long inline enumeration of eight service types is slightly heavy, but each clause carries information the agent needs.

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

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

With no output schema, the description must frame returns, and it does by naming price, refund terms, decision-maker, and the prerequisite checker. For a single-parameter read-only catalogue tool this is close to sufficient, with only the placement-vs-service boundary left implicit.

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% with a single enum-constrained optional parameter already documented as 'Only services in this category.' The description's 'Optional category filter' merely restates the schema, so the 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 (list services with prices) and scopes it precisely as 'every Essentras service beyond single placements', which implicitly separates it from quote_placements and quote_service. The enumerated service types and the promised fields (USD price or 'priced per case', refund terms, who decides) make the output contract visible without opening anything.

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 'free checker to run first' line routes the agent toward the check_* siblings as a prerequisite step, and 'beyond single placements' implies single placements belong to the quote tools. There is no explicit when-not or a direct naming of quote_service/quote_placements as alternatives, so it stops short of a full 5.

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

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

Annotations already cover readOnlyHint, idempotentHint and destructiveHint=false, so the no-charge/no-order statement largely corroborates them. The description goes further, though, by disclosing that the total matches what the buyer is actually charged (tiers included) and by explaining the refund condition if the placement is not published or the turnaround is missed — real context an agent cannot get from 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 sentences, front-loaded with the pricing outcome and then the side-effect guarantees and checkout flow. Every sentence carries information, though the checkout_url explanation is slightly long for what it conveys.

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 compensates by naming the returned fields (line items, volume discount, final total, checkout_url) and explaining the payment/refund lifecycle. Nothing an agent needs to call this 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% for the single items parameter, including the 'list each outlet once' and 'max 30' constraints, so the schema already carries the semantics. The description adds no parameter-level detail beyond that, making the baseline 3 correct.

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 — prices a set of outlets — and enumerates what comes back (line items, discount, total, checkout_url). It is clear on its own, but never distinguishes itself from the similarly named sibling quote_service, so an agent must infer the split from the noun alone.

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 rather than stated: the buyer-facing checkout flow and the 'charges nothing and creates no order' note imply this is the pre-purchase pricing step. There is no explicit when-to-use or when-not rule, and no sibling is named as an alternative.

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, closed-world), and the description adds genuinely new context: "It charges nothing" (no billing side effect), the refund-negotiation shape of the result, the per-case-service fallback, and the warning that the platform, not the agent, makes the final decision. That is meaningful behavioral disclosure beyond 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?

Three sentences, no filler, with the payoff (pricing plus start_url) front-loaded before the edge case and the cautionary note. The first sentence is a dense comma-list of returned fields, 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?

With no output schema, the description carries the burden of explaining returns and does so (price, tier, refund terms, decision maker, start_url), plus the cost profile and the per-case-service exception. Only missing is any hint about the response envelope or whether pricing can be stale/subject to change, which would round out a pricing tool with no 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?

Schema description coverage is 100% – both `id` (with examples) and the optional `tier` are fully documented in the schema, including the pointer to list_services as the id source. The description adds no parameter syntax or format detail beyond that, so the 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+resource ("price of 1 service") and enumerates exactly what is returned: price, tier price, refund terms, decision maker, and start_url. It implies a distinction from quote_placements by scoping to a single service rather than placements, but never names the sibling outright, so an agent must still infer the boundary.

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 conveys implied context (call it when you need a service price) and one conditional routing rule (per-case services return the free assessment page instead), plus agent-facing guidance ("Never promise the outcome"). It stops short of any explicit when-to-use-this-vs-alternative instruction, so the agent must infer the choice against quote_placements and the check_* 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?

Annotations already declare readOnly/idempotent/non-destructive, so the safety profile is covered. The description adds real behavioural context beyond that: offers carry a fixed USD price, a turnaround, link disclosure, and a stable id that quote_placements accepts — which tells the agent the handles are reusable across calls.

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 purpose and filters, then return shape, then the budget filter hint. No filler and nothing buried at the end that should be first.

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 17 params and no output schema, the description does the important work of sketching what a result contains (price, turnaround, link disclosure, stable id) and connects it to quote_placements. It stops short of noting pagination/limit behaviour or result ordering, which matters for a large catalogue, but overall it is sufficient to call 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 94%, so parameters are already thoroughly documented, including the non-obvious max_turnaround_days week conversion. The description only reinforces max_price as the budget filter, which the schema already states ('Use the buyer budget'), adding nothing beyond the baseline.

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 (Searches) and a well-scoped resource (buyable media placements) with the filterable dimensions spelled out. It also distinguishes itself from get_outlet (single lookup) implicitly by emphasising catalogue search, and names the downstream consumer quote_placements.

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

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

The description implies this is the discovery step before quote_placements, which is useful workflow context. But it never says when NOT to use it (e.g. when the buyer already has an outlet id and should use get_outlet instead), and no explicit alternatives or prerequisites are given.

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