Fabrica (Sepolia testnet)

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, and openWorldHint, so the safety profile is covered. The description adds genuinely non-obvious domain behavior: how the score is encoded and what each digit position means. It does not address auth, rate limits, or whether tokenId performs a lookup with side effects, but with annotations carrying the safety burden this is strong added context.

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 before the digit mapping. The digit-position breakdown is information-dense but each clause is necessary and there is no filler.

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

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

No output schema exists, so the description must convey the return semantics; it partially does by explaining the digit breakdown. However, with two optional and zero required parameters, it never clarifies when to supply 'score' versus 'tokenId' or what happens if both/neither are provided, leaving a real gap for an agent deciding how to call 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 coverage is 100%, so the baseline would be 3. The description goes beyond the schema by explaining the meaning of the score integer (5-digit positional encoding, category per digit, max 75342), which materially helps interpret the 'score' parameter. It adds nothing about how tokenId resolution works or how the two optional params interact.

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

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

States a specific verb and resource: it explains a property's confidence score breakdown. This is clearly distinct from the get_* siblings, which retrieve entities rather than interpret a score. It stops short of naming any alternative or contrasting scope, so it is clear but not maximally differentiated.

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

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

There is no explicit when-to-use or when-not-to-use guidance, and no routing to alternatives. The reader must infer that this tool is for interpreting a score integer or a token's score. Nothing states prerequisites or the relationship between the two optional inputs.

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, and openWorldHint, so safety and side-effect behavior are covered. The description adds useful scope (event types covered, property vs wallet) but omits pagination/ordering behavior and the default result cap, which matter for a feed tool.

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 core purpose, no filler. The 'and more' and duplicate mention of 'transaction history and event timelines' add slight redundancy but do not bloat it.

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 read-only feed tool with full schema coverage and rich annotations, the description is adequate but thin on behavior an agent often needs: default limit, pagination, ordering, and whether type filtering is server-side. No output schema exists, so return-shape expectations go unaddressed.

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

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

Schema description coverage is 100%, so all five parameters are already documented in the schema. The description only restates that activity can be scoped to a property or wallet, adding no syntax, format, or filtering nuance 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 (Get) and resource (activity feed) with enumerated event types and scope. It is reasonably distinguishable from siblings like get_portfolio or get_property, though it doesn't explicitly call out how it differs from those overlap-prone 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?

The description indicates the tool covers property or wallet activity, which implies when to use it, but gives no explicit when-to-use vs alternatives guidance, no exclusions, and no mention of sibling tools. An agent must infer the use case.

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 non-destructive, so the safety profile is covered. The description adds real behavioral nuance beyond that: the returned amount is an estimate and the actual rate is fixed by a live quote at borrow time, which prevents the agent from treating the value as binding.

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 compact sentences, front-loaded with the core action and its outputs before the estimate caveat. The example question earns its place as usage guidance, though the opening could be marginally tighter.

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 read-only tool with no output schema, the description does the necessary work of naming the returned fields and flagging the estimate-vs-live-quote limitation. What is missing is minor: no note on whether slug and tokenId are alternatives, and no indication of failure behavior when a property has no lending pool.

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 two params (slug, tokenId) are documented in the schema. The description adds no additional meaning about how slug and tokenId relate (e.g. whether both are needed or which serves as fallback), 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?

Specific verb ('Get') plus resource ('borrow quote') scoped to 'a specific tokenized property', and it enumerates what comes back (pool liquidity, max loan amount, durations, existing loan status). The property-scoped framing implicitly separates it from the market-wide sibling get_lending_market.

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 concrete triggering question ('How much can I borrow against this property?'), which tells the agent the context in which to call it. It stops short of naming alternatives or exclusions (e.g. when to use get_lending_market instead), so it falls just under the top tier.

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, and openWorldHint, so the safety profile is fully covered by structured data. The description adds useful domain semantics (pool-based lending, and that loan records include retired peer-to-peer loans), but says nothing about pagination, filter interaction, or result shape.

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, front-loaded with the core action and its returned fields. The trailing sentences provide interpretation context for loan provenance rather than padding, though the historical P2P aside is tangential to 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 read-only tool with no output schema, the description usefully enumerates what the response contains (counts, loans, liquidity, utilization, APR, events). Combined with annotations covering safety and a fully documented schema, an agent has what it needs 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% with all five parameters, including the status enum and limit bounds, fully documented in the schema itself. The description adds no filter syntax or format detail beyond what the schema already provides, 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 ('Get an overview of the Fabrica lending market') and enumerates the returned content (loan counts, loans, pool liquidity/utilization, APR, recent events), which clearly separates it from point-in-time siblings like get_borrow_quote. It stops short of explicitly naming which sibling to prefer, so it lands at clear-but-undifferentiated.

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

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

The description never says when to call this versus alternatives such as get_borrow_quote or get_protocol_stats, nor does it state prerequisites or when it is not appropriate. The only usage signal is the implicit 'you want market data' framing of the returned fields.

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, openWorldHint and destructiveHint=false, so the safety profile is covered. The description usefully adds scope ('complete portfolio') and the breadth of what is aggregated, but says nothing about cost, latency, or behavior on unknown/empty addresses.

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

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

A single front-loaded sentence with no filler; the resource and the enumeration of returned data are the only content and both earn their 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?

With no output schema, the description compensates well by enumerating the returned categories (properties, loans, orders, credit history, total value). What is missing is any note on aggregation behavior or prerequisites, but for a simple single-address read it is largely sufficient.

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 with 100% schema description coverage ('Ethereum wallet address (0x...)'), so the schema carries the semantics. The description adds no format, chain, or validation detail beyond the schema, making this a baseline 3.

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

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

States a specific verb and resource ('Get a wallet's complete Fabrica portfolio') and enumerates exactly what the result contains: properties, loans, orders, credit history, value. It does not name or contrast with any sibling, but the siblings (get_activity, get_property, get_protocol_stats) are distinct enough that disambiguation is not really needed.

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

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

The description never says when to call this versus alternatives such as get_activity or get_property, nor does it state preconditions (e.g. would scan a wallet that may have no history). Usage is only implied by the enumerated contents.

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

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

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so the safety profile is covered. The description still adds real value by disclosing the return medium ('Returns an inline image'), which is absent from annotations and from any output schema.

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 core action and followed by output format and options; nothing is padded. The theme/dimension sentence mildly duplicates the schema but is not 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?

With no output schema, the description correctly covers the return format (inline image) and the option surface, and annotations handle safety. It omits edge cases such as wallets with no properties or invalid addresses, but is otherwise sufficient 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 coverage is 100%, so address, theme, width and height are already documented with ranges and defaults. The description restates theme and dimension support without adding syntax, units, or constraints beyond 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 with scope: a static map image of all properties owned by a wallet. The 'all properties owned by a wallet' framing implicitly separates it from get_property_image and get_property_map, but it never names those siblings explicitly, so an agent must 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?

Usage is only implied by the scope phrase; there is no explicit when-to-use, when-not-to-use, or pointer to alternatives such as get_portfolio (data) versus this (visual). An agent can guess the intent, but nothing is 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 open-world, so the safety profile is covered. The description adds real value by disclosing the breadth of returned data (legal description, valuation, ownership, loans, listings, activity, imagery) and by carving out geometry to a sibling tool.

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 opens with the core verb and resource, then enumerates return facets and ends with the sibling hand-off. No filler sentences, and the most important information comes 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 no output schema, the description carries the burden of describing returns and does so comprehensively, including the geometry exclusion. The only gap is that it omits the one-of relationship between the two optional identifiers.

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 slug and tokenId are already documented with examples, establishing the baseline of 3. The description adds nothing about the two lookup modes, and notably neither parameter is required, so it never clarifies whether one of slug or tokenId must be supplied.

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

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

States a specific verb (Get) and resource (tokenized property details on Fabrica/Sepolia) and enumerates the returned facets, so the agent knows exactly what it fetches. It also explicitly distinguishes itself from get_property_map, which covers boundary geometry.

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 final sentence routes the agent to get_property_map for boundary geometry, an explicit alternative for a related need. However, it gives no guidance on when to use get_property vs search_properties, nor on choosing between the slug and tokenId lookup paths.

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 open-world, so the safety profile is covered. The description adds genuinely useful behavior the annotations cannot convey: the response is an inline image, and a pin marker is substituted when no parcel boundary exists.

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

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

Three tight sentences, front-loaded with the core purpose before the fallback and option details. The final sentence overlaps with what the schema already says about theme and dimensions, but it is brief and not 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?

No output schema exists, and the description usefully explains the return is an inline image, so that gap is covered. However, all five parameters are optional and the description never clarifies whether slug or tokenId is the identifying input, leaving an agent unsure how to form a valid call.

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

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

Schema description coverage is 100%, so the schema documents every parameter including enums, defaults and min/max ranges. The description only restates themes and custom dimensions generically, adding no syntax or default information 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: a static map image of a tokenized property, with the parcel-boundary behavior spelled out. It distinguishes itself from the sibling get_portfolio_image by scope (property vs portfolio), but does nothing to separate itself from get_property_map, which an agent could easily confuse with this one.

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 statement of when to choose this over get_property_map or get_property. The existence of closely named siblings (get_property_map, get_portfolio_image) makes an explicit routing rule valuable, and none is given.

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, openWorldHint and destructiveHint=false, so the safety profile is covered. The description adds the return format (GeoJSON boundary for property and county), which is useful context, but says nothing about payload size, coordinate precision, or remote fetch behavior despite openWorldHint.

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 well-formed sentence with the resource front-loaded and no wasted clauses. Slightly dense in listing three use cases, but still tight.

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 annotations carrying the safety semantics and no output schema to explain, the description's identification of GeoJSON boundary output plus the schema's parameter docs cover what an agent needs to invoke it. Minor gaps only around payload characteristics.

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 all three parameters are documented in the schema, including the includeCountyBounds default. The description adds no 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?

Names a specific verb (get) and resource (GeoJSON boundary data) and scopes it to a tokenized property plus its county. It clearly separates this from get_property/get_property_image by emphasizing boundary geometry, though it never names a 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 stated use cases (mapping, spatial analysis, visualization) imply when this tool is appropriate, but there is no explicit when-not guidance or pointer to alternatives such as get_property for non-geometric data.

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, destructiveHint=false, and openWorldHint=true, so the safety profile is fully covered structurally. The description adds the data scope but says nothing about freshness, caching, or how aggregation is performed, so it contributes only modestly 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?

A single sentence with the resource and scope stated up front, followed by a dense but non-redundant list of the metrics covered. No filler or repetition.

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

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

For a zero-parameter read-only tool with rich annotations, the description is close to sufficient, and it helpfully enumerates expected output fields in the absence of an output schema. It could go further by noting value units/currency or freshness of the statistics, but nothing essential is missing.

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

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

The tool takes zero parameters, so there is no parameter semantics for the description to carry. Baseline 4 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 (Get) and resource (protocol-wide statistics) and then enumerates the concrete metrics returned: totals, lending volume, pool TVL/utilization, geographic distribution, contract addresses. This makes it clearly distinguishable from per-entity siblings like get_property, get_portfolio, and get_lending_market.

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 says what the tool returns but never says when to call it or when to prefer a sibling instead. There is real overlap risk with get_lending_market and get_portfolio (lending volume, TVL), and no guidance resolves 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?

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, openWorld), so the bar is lower. The description usefully adds that these are Sepolia test properties with no real-world effect, which materially changes how an agent should treat the results. It omits pagination/capping behavior, keeping it from 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?

Three short sentences, front-loaded with purpose. Slight redundancy: the second sentence restates the search action, and the third repeats "Sepolia" already named in sentence one.

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 9-parameter, all-optional list tool with rich annotations and full schema coverage, the description covers purpose, environment, and return shape. It omits any note on result fields or pagination semantics, but with no output schema and thorough parameter docs this is largely sufficient.

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 every parameter (limit, offset, region, ownedBy, hasLoans, minAcres, maxAcres, minScore, hasListings) is already documented in the schema. The description adds no extra parameter meaning, 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 ("Search tokenized real properties on the Fabrica protocol") and clarifies it returns a list rather than a single record, which implicitly separates it from the get_property sibling. It does not name any sibling explicitly, so it stops short of a 5.

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

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

The filter-based framing ("matching the given filters") implies this is the discovery/browse tool, but there is no explicit when-to-use, when-not-to-use, or named alternative such as get_property for known IDs. Usage must be inferred.

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