LocalSchema

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

Annotations already declare readOnlyHint, idempotentHint, and closed-world, so safety profile is covered. The description usefully discloses the return payload (JSON-LD, script tag, issues to fix) and that no API key is needed. It omits a significant behavioral fact baked into the schema: several parameters (rating, reviews, specialHours) are silently omitted from free output, which materially affects caller expectations.

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: the core action first, then the returned artifacts and the no-key reassurance. Zero waste and well front-loaded.

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

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

No output schema exists, and the description does cover the return shape, which is important. But for a 32-parameter tool with heavy nesting and paywalled-field behavior, it should note the free-tier omissions and give at least minimal guidance on the required name field and businessType selection.

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

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

With 32 parameters and only 34% schema description coverage, the description carries substantial compensating burden but adds no parameter meaning at all — it never mentions name being the sole required field, businessType defaults, or the geo/address/openingHours conventions. It leaves the agent to reverse-engineer usage entirely from a partially documented 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 LocalBusiness JSON-LD') plus a secondary action ('validate it against Google's rich result rules'), and the mention of validation distinguishes it from the sibling validate_schema which only validates an existing page/schema. An agent can tell this is a generation-plus-validation tool 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?

Usage is implied by 'from business details' and the validation mention, and the schema references '/business-types' (pointing at list_business_types). But there is no explicit when-to-use vs validate_page/validate_schema/run_health_check, and no stated prerequisite about needing a location/client first.

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 annotations already declare the operation read-only, closed-world, and idempotent. The description adds useful behavioral context beyond those annotations: it returns both the install snippet and live status, and it explains that after pasting, published updates propagate automatically, which helps the agent understand the tool’s effect.

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 compact and front-loaded, starting with the core action and resource. Every clause adds useful information about key scope or post-install update behavior without repetition.

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

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

For a simple one-parameter read-only tool with full schema coverage and annotations, the description provides everything needed: what is returned, how to interpret the key prefix, and what happens after installation. No output schema is present, but the description names the returned content sufficiently.

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%, and the single parameter is already described as the hosted embed key. The description adds meaning beyond the schema by explaining the loc_ prefix for one location and the org_ prefix for a client with several locations, clarifying how to choose the right key.

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: getting the install snippet and live status for a hosted embed key. It also distinguishes the two key forms (loc_… for one location, org_… for a client with several), so an agent can identify exactly what this tool retrieves.

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

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

It clearly positions the tool around hosted embed keys and explains the workflow of pasting the script tag once, with published updates reaching the site automatically. It does not explicitly name alternatives among the siblings, but no sibling is closely overlapping, so the usage context is clear.

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 and closed-world, so the safety profile is covered. The description adds a genuinely useful non-annotated fact: a LocalSchema Pro API key must be supplied in the request headers, an auth prerequisite no structured field conveys. It stops short of noting rate limits or whether unpublished data can be absent.

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

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

A single front-loaded sentence naming the resource and its payload, followed by the auth requirement. The return-value enumeration is a dense comma list but every element maps to real retrieved data, so little is wasted.

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 describing returns and does so by enumerating the four payload components. The auth prerequisite is also supplied. Only minor ambiguity remains about what 'embed details' and 'validation issues' actually contain.

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 exists and schema coverage is 100%, with the schema itself explaining that the id comes from list_locations. The description adds nothing about the parameter beyond noting the returned business fields share the same shape save_location accepts, 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 ('Get one saved location') and pins the scope to a single record, which implicitly distinguishes it from list_locations. The description also enumerates exactly what is retrieved (business fields, current/published JSON-LD, validation issues, embeds), so an agent knows precisely what it gets.

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 singular 'one saved location' plus the schema note that location_id comes from list_locations implies the list-then-fetch flow, but the description never explicitly states when to prefer this over list_locations or the validate_* / get_embed_snippet siblings. Usage is inferable rather than guided.

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 openWorldHint=false, so the safety profile is covered. The description adds domain scope ('LocalSchema supports') and selection advice, but does not disclose return ordering, completeness guarantees, or exact output shape beyond examples.

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

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

Two sentences, front-loaded with the resource and examples, followed by the actionable selection rule. Every sentence earns its place and there is no redundant text.

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

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

For a zero-parameter, read-only list tool with annotations covering safety and no output schema, the description supplies what is needed: what is listed, illustrative examples, and how to choose a returned value. The examples make the return contents clear enough without an explicit 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 has zero parameters, so the baseline is 4. The description mentions businessType, but that is a parameter of another tool rather than this one; no parameter semantics need to be explained here.

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

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

States a specific verb 'List' and a specific resource 'schema.org LocalBusiness subtypes LocalSchema supports', with concrete examples (Dentist, Plumber, Restaurant). The resource is clearly distinct from sibling list tools such as list_clients and list_locations, so an agent can identify it without ambiguity.

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

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

The description gives clear downstream context: 'Use the most specific one as businessType.' It does not name alternatives or when-not conditions, but no sibling tool appears to offer the same business-type enumeration, so the guidance is sufficient for selection.

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

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

Annotations already declare readOnly, idempotent, and closed-world behavior, so the bar is lower. The description adds genuinely useful non-annotated context: that a LocalSchema Pro API key must be supplied in request headers, plus an overview of what the payload contains.

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 compact sentences: the resource and returned data are front-loaded, with the authentication caveat second. No filler or redundancy.

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

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

There is no output schema, so the description carries return-value disclosure and does a reasonable job by enumerating the main fields returned. Auth is covered; pagination or result-size behavior is not mentioned, but little else is missing for a zero-argument list tool.

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

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

The tool takes zero parameters, so the baseline is 4. The description correctly implies a single unfiltered call with no arguments, consistent with the empty 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 (List) and resource (clients/brands) and names the enriched fields returned (location counts, embed script, white-label report link). This is clearly distinct from siblings like list_locations or list_business_types, though it does not explicitly say so.

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 explicit when-to-use or when-not-to-use guidance versus alternatives such as list_locations or get_location. Usage is only implied by the resource name; the only stated prerequisite is the API key in request headers.

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

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

Annotations already declare readOnlyHint, idempotentHint and openWorldHint=false, so the safety profile is covered. The description adds genuinely new context: the Pro API key requirement in request headers and the shape of the payload returned. It stops short of pagination or rate-limit behavior, which is a real gap for a list endpoint.

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

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

Two sentences, zero filler, with the resource and returned fields front-loaded and the auth prerequisite trailing. 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?

No output schema exists, but the description compensates by listing the returned fields, and the auth requirement is stated. The remaining gap is pagination/result-size behavior for an unfiltered list call, which an agent would want to know.

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 client_id parameter, so the schema already explains that it narrows results to one client. The description adds nothing about the filter, which is the baseline 3 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 and resource ('List the business locations saved in the LocalSchema account') and enumerates the fields returned (publish state, embed script, website, health check score). It is clearly distinct from get_location by being a plural list, though it never names the sibling explicitly.

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

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

The only guidance is a prerequisite ('Needs a LocalSchema Pro API key in the request headers'). There is no statement of when to prefer this over get_location for a single record, nor any exclusion about the optional client_id filter being the way to narrow scope.

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 flag readOnlyHint=false, openWorldHint=true, and destructiveHint=false; the description adds real value beyond them by disclosing the write side effects (records the result in the dashboard and client reports), the external network scan of the customer website, and the API-key auth requirement. It leaves out duration, rate limits, and failure/partial-result 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?

Two sentences, front-loaded with the purpose and followed by the prerequisite. The enumerated capabilities are dense but each clause adds distinct information; the auth requirement is appended where it is easy to miss before invocation.

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

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

For a one-parameter tool with no output schema but full annotation coverage, the description supplies what an agent needs: what is checked, that it persists results to dashboard/reports, that it reaches the open web, and that an API key header is required. Only the expected result/report shape is 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?

There is a single parameter with 100% schema description coverage ('Location id from list_locations'), so the schema already carries parameter meaning. The description only says the check is 'for a saved location' and adds no format or sourcing detail beyond that, so 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 states a specific verb (run a health check) on a specific resource (a saved location's schema) and enumerates the concrete sub-actions: markup validation, website embed scan, hard-coded schema conflict detection, and unpublished-change detection. It is far more specific than validate_schema or validate_page, though it never explicitly names those siblings as alternatives.

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?

Clear context is given: this operates on a saved location (implying list_locations/get_location as the setup step) and requires a LocalSchema Pro API key in the request headers. It does not state when to prefer this over validate_schema or validate_page, which is the only missing 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 write, non-destructive, non-idempotent, and closed-world behavior. The description adds an important auth requirement (LocalSchema Pro API key in request headers) and clarifies the report toggle, without contradicting annotations. It does not detail failure modes, but the safety profile is largely covered.

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, front-loaded with the create/update purpose and optional report toggle, followed by the auth note. Every clause earns its place with no redundancy.

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

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

For a six-parameter write tool with full schema coverage and annotations, the description covers purpose, create/update condition, and API-key requirement. It omits return or error behavior, but the schema and annotations carry most remaining burden.

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

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

Schema description coverage is 100%, so all six parameters are fully documented in the schema. The description only echoes client_id as the update selector and the report toggle, adding no syntax or format details beyond the schema.

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

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

States a specific verb and resource: create a client (brand) or update one by client_id, plus optional report toggle. This clearly distinguishes the tool from siblings like list_clients (listing) and save_location (locations).

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?

Explains the create-vs-update condition via client_id, giving clear context for invocation. However, it does not name alternatives such as list_clients for finding a client_id or save_location for location updates, so there are no explicit exclusions or sibling routing.

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 mutation profile, so the description carries real weight: it discloses the auth requirement (Pro API key in headers), patch semantics ('only the business fields you send change'), and the externally visible side effect of publishing to a live embed. It leaves unanswered what a failed/unpublished save leaves behind.

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 efficient: the core write action leads, with the publish side effect and the auth requirement following. The em-dash parentheticals stay readable and no clause is filler, though the single mega-sentence is close to overloaded.

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 should say what comes back (created location id, embed URL, publish status) and it doesn't. Auth, patch semantics and publish behavior are covered, but the return contract for a create-or-update tool is 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 coverage is 100%, so the schema already documents publish, location_id, client_id, website_url and the business merge rules. The description reinforces the create-vs-update role of location_id and patch behavior but adds no format or constraint detail beyond what the schema states, so 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?

Names a specific verb and resource plus the upsert distinction: 'create one, or update one by location_id'. That single clause separates it from get_location/list_locations and tells an agent the tool covers both write paths 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?

Gives clear context for when to reach for it (saving a location, optionally publishing so the client's site updates) and states the Pro API key prerequisite. It doesn't name an explicit alternative or exclusion — e.g. 'to read a location use get_location' — so it stops short of full routing 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, and openWorld, so the safety profile is covered. The description adds real context beyond them: it hits the network, requires a publicly reachable page, needs no API key, and returns errors, warnings, embeds, and concrete recommendations.

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 tightly packed sentence that front-loads the action and then lists the audit outputs. The 'No API key needed' note is a useful trailing detail rather than filler, though the enumerated list is dense enough to be slightly hard to scan.

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 and only one parameter, the description carries the return-value burden and does so reasonably: it names the categories of findings (errors, warnings, embeds, recommendations). It stops short of describing response shape or how many findings are returned, but 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?

There is one parameter at 100% schema coverage, and the schema already documents it as a public http(s) URL with an example. The description's 'public web page' phrasing mildly reinforces the accessibility constraint but adds no format or length guidance beyond the schema. Baseline 3 is appropriate.

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

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

The description uses a specific verb+resource ('Fetch a public web page and audit its structured data') and enumerates what is inspected: JSON-LD blocks and types, LocalBusiness errors/warnings, LocalSchema embeds, recommendations. It implicitly distinguishes itself from validate_schema by emphasizing a live page, but never names that sibling explicitly.

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?

'Fetch a public web page' implies this is for live URLs rather than pasted schema text, which hints at validate_schema being the alternative for raw markup. However, no explicit when-to-use/when-not-to-use statement or prerequisite is given, leaving the routing to the agent's 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 cover safety (readOnlyHint, idempotentHint, openWorldHint=false), and the description usefully adds what the tool emits — errors, missing recommended fields, best-practice warnings — plus the no-auth constraint. It doesn't mention size limits or latency, but otherwise adds real 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?

Two tight sentences, front-loaded with the verb and scope; the input formats and output contents each get exactly one clause. 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 appropriately summarizes the return payload (errors, missing recommended fields, warnings). The only meaningful omission is input size limits for the 600,000-character cap, which affects failure modes for whole-page HTML.

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 'code' parameter is already documented as accepting JSON-LD, a script tag, or full page HTML. The description restates those same accepted formats almost verbatim, adding no syntax, encoding, or size guidance (the 600k max length is undisclosed).

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 (Validate) and resource (LocalBusiness structured data), and enumerates the accepted input forms (JSON-LD, script tag, full HTML page). It is clearly a validation tool, but it does not distinguish itself from the sibling validate_page, which an agent could easily confuse it with.

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

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

The description implies the use case (checking existing markup before publishing) and notes 'No API key needed', but never states when to pick this over validate_page or generate_schema. The agent must infer routing from the sibling names alone.

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