FanDuel API

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

No annotations are provided, so the description carries the full behavioral burden, yet it discloses almost nothing. It does not explain what a Watch does (notification? alert threshold?), whether creation has side effects or limits, or how the user_request field is used downstream; only the verb "Create" signals a write operation.

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 sentence is short and front-loaded with the verb, with no filler or repetition. But its brevity comes from under-specification rather than efficiency, so it does not earn a high conciseness score.

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 five-parameter mutation tool with no annotations and no output schema, the description should explain what a Watch is, what happens when one is created, and how it relates to update_watches or delete_watches. None of that is present, leaving a substantial gap relative to the tool's complexity.

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 including the enum for stat and the required user_request is documented in the schema itself. The description adds no meaning beyond that, which is the expected baseline 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?

The description names a verb ("Create") and a resource ("Watches"), so the basic action is identifiable. However, "Watch" is an undefined domain concept and the phrase "one of your Watches" is close to restating the tool name; nothing distinguishes it from siblings like update_watches or list_watches.

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 when-to-use guidance, no prerequisites, and no mention of alternatives such as update_watches or delete_watches. An agent must infer entirely from the name that this is the tool for establishing a new watch.

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

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

With no annotations, the description carries the full burden and does disclose the two most important traits: the action is irreversible ('Cannot be undone') and requires user confirmation. It says nothing about whether associated data or history is removed, what permissions are needed, or what a successful call returns.

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

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

Two short sentences with the destructive warning front-loaded after the purpose statement; nothing is wasted. It is arguably too terse for a destructive tool, but not 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?

Covers purpose, irreversibility and the confirmation requirement, which is adequate for a two-parameter delete. Missing are the identifier semantics for 'id', any ownership lookup guidance, and what the call returns (no output schema exists to cover that).

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

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

Schema coverage is 50%, and the undocumented parameter is the critical one, 'id'. The description only implies it must identify one of the caller's own Watch records ('one of your Watches') without stating the identifier format or how to obtain it. The other parameter, user_request, is already fully explained in 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 ('Delete one of your Watches'), which clearly separates it from create_watches, get_watches, list_watches and update_watches in the sibling set. It doesn't explicitly name a sibling, but the delete semantics are unambiguous.

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

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

Provides one real precondition ('confirm with your user first'), which is useful guidance for a destructive operation. It gives no guidance on when to delete versus when to deactivate via update_watches, or on any ownership/permission constraints.

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

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

With no annotations provided, the description carries the full burden and only conveys that this is a read operation. It says nothing about permissions or ownership scoping ("your" is undefined), what happens when the id is unknown, or whether it returns configuration, history, or notification state for the Watch.

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

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

A single short sentence with zero filler, and the key selector is placed at the end without burying anything. Its efficiency is close to under-specification rather than padding, but nothing 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?

For a two-parameter tool with no annotations and no output schema, the definition is too thin: it never explains what a Watch is, what the response contains, or why user_request is required for a read. An agent could call it, but only by guessing from the schema alone.

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

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

Schema coverage is 50%: the id parameter has no schema description and the description adds nothing beyond "by id" (no format, no source for obtaining the id). The user_request parameter, which has a notable privacy caveat in the schema, is not mentioned at all in the description.

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?

"Read one of your Watches by id" gives a specific verb (Read) and resource (Watches) with single-item scope, which implicitly separates it from list_watches. It stops short of explicitly naming the list/update/delete siblings, so an agent must infer the boundary rather than being told.

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 when-to-use or when-not-to-use guidance and no mention of alternatives such as list_watches (to find an id) or update_watches/delete_watches. The only hint is "by id", which merely restates the required schema field.

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

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

With no annotations, the description carries the behavioral burden and does well by disclosing the returned fields, their units, and the meaning of direction and probability-shift metrics. It does not explicitly state read-only behavior or data freshness, but the retrieval-like behavior is evident and there is no contradiction.

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

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

The description is front-loaded with purpose, then usage scenarios, input modes, and return fields. Every sentence contributes useful information, and the long return-field sentence earns its length by explaining the key output metrics.

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-style analysis tool with no output schema and no annotations, the description provides sufficient completeness: it explains what is returned, the units, the input selection modes, and the questions it supports. The remaining gaps, such as explicit safety labeling, are minor given the tool's evident read-only nature.

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 schema already documents all five parameters at 100% coverage, establishing a baseline of 3. The description adds meaningful selection semantics by explaining that prop_id targets one prop while player with optional stat or event_id targets all of that player's props, going beyond the schema text.

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

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

The description clearly states the resource and operation: line movement from open to current for a prop, including the exact questions it answers. It is specific enough to identify the tool, but it does not explicitly distinguish itself from siblings like prop_history or recent_changes.

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

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

It gives clear usage context by naming the questions the tool answers and explaining the two input modes: a single prop_id or a player with optional stat/event_id filters. It does not state when to avoid this tool or point to sibling alternatives, so it falls short of full when-to-use guidance.

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

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

No annotations exist, so the description carries the full behavioral burden. It does disclose the salient output fields and the filtering dimension, which is real value, but says nothing about the pagination contract (limit default 50, has_more/offset flow) or data freshness for 'live' games, so an agent cannot infer result completeness.

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 with the resource and return shape front-loaded, the sibling hand-off second, and the filter hint last. No redundant restatement of the tool name or filler.

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

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

For a read-only list tool with no output schema, the description compensates well by naming the fields returned and the downstream call to make. The remaining gap is pagination and result-cap behavior, which the schema only hints at indirectly through the offset description.

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 limit, offset, sport, league and user_request are already documented inline. The description's 'filter by sport or league' merely echoes the schema and adds no format detail, and it says nothing about the required user_request parameter, leaving it at 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?

The first sentence names a specific verb (lists) and resource (upcoming and live games) and enumerates the returned fields: event_id, start time, in-play flag, prop count. It also implicitly contrasts with list_props by positioning this tool as the discovery step, so an agent can tell the two apart without opening either schema.

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

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

Explicit sequencing guidance is given: use this to find a game before calling list_props with event_id, plus a note that sport or league can filter the result. There is no statement of when NOT to use it (e.g. historical or settled games), which keeps it short of a 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?

With no annotations, the description carries the full burden. It usefully discloses the return shape (line, over/under prices in American and decimal, status, move summary from open) and the 'current' freshness framing, but says nothing about read-only safety, whether live calls have latency limits, or pagination behavior beyond the schema's offset field.

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, zero filler, front-loaded with the resource identity before the use cases and the filter list. The example question phrasing is the most efficient way to convey intent.

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 10-parameter read tool with full schema coverage and no output schema, the description replaces the missing return documentation by enumerating the fields each prop contains. The one gap is sibling positioning — it never clarifies when to reach for prop_history or line_move instead.

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 every parameter already carries a description, including defaults, enums and examples. The description's sentence listing filterable dimensions maps one-to-one onto the schema and adds ordering guidance but no new 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 ('Current FanDuel player prop lines and prices'), then anchors it with two literal example questions an agent would be asked, and enumerates the returned fields. It is immediately distinguishable from siblings like prop_history or line_move by its present-tense 'current' framing.

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

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

Gives concrete use cases — answering 'what is the line for <player> <stat>?' and scanning a game or league board — and names the filter dimensions that support each. It stops short of explicit when-not guidance or naming alternative sibling tools such as prop_history or recent_changes for historical 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?

With no annotations, the description carries the full behavioral burden. It implies a read operation by using "List," but does not disclose pagination behavior, whether results are filtered or sorted, permission requirements, or what the response 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?

The description is short and front-loaded, with the operation named first and the concept of a watch defined immediately afterward. The wording is efficient, though the definition sentence could be slightly more operational for a listing tool.

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 tool with no annotations, no output schema, and low schema description coverage, the description is incomplete. It defines the watch entity but omits list-specific behavior such as pagination, filtering, sorting, and return shape.

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

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

Schema coverage is only 33%, with limit and offset undocumented in the schema, and the description does not explain either parameter. It also does not clarify the required user_request parameter's role beyond what the schema already states.

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 clear verb and resource: "List Watches," and explains that a watch is a tracked player prop with a line or price move alert. It is specific enough to understand the core operation, but it does not distinguish list_watches from the sibling get_watches tool.

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 offers no explicit when-to-use guidance, exclusions, or comparison to alternatives such as get_watches or list_props. An agent must infer that this tool is for listing all watches rather than retrieving a specific watch or listing related prop 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?

No annotations are provided, so the description carries the full behavioral burden; it does disclose ordering ('oldest first') and the shape of each returned record, which is useful. It says nothing about volume, pagination, or limits on how many historical states are returned, which is the main risk for a history endpoint with no 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?

Two sentences, front-loaded with the returned content and followed immediately by the routing rule. No filler, no restatement of the tool name, and the ordering guarantee is placed where it is read 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 and no annotations, the description usefully compensates by enumerating what each recorded state contains and in what order, which an agent needs to interpret the result. The remaining gap is pagination or depth of history, which matters for a potentially long event stream.

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 parameters are already documented; the description only reinforces that this is a single prop's history and that prop_id originates from list_props, which the schema already states. There is no added semantics for user_request in the description, 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?

States a specific resource and return set: 'Every recorded state of one prop, oldest first', enumerating line moves, price moves and suspensions plus the move summary. It is clearly distinguishable from list_props and line_move, which the description names as the sources of the open/current view rather than the history.

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

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

Explicitly sequences usage: 'Use it after list_props or line_move' establishes the prerequisite call that supplies prop_id and a summary view. It also frames when-not by contrast — 'when you need the full path, not just open and current' — routing the agent to the lighter siblings for the current state.

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

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

With no annotations, the description carries the full disclosure burden, and it does cover the meaningful traits: ordering (oldest first), incremental cursor semantics, and what event types appear. It never states the operation is read-only, whether calls are rate-limited, or whether the feed can be truncated, so key behavioral context is missing for a tool with zero annotation coverage.

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 front-loaded sentences with the payload and ordering stated first, then the polling recipe, then the optional filter. The trailing fragment 'Optional league filter' is slightly tacked on but earns its place by flagging the only optional scope control.

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 four-parameter read feed with full schema description coverage and no output schema, the description supplies enough: payload categories, ordering, and the meta.next_cursor return hint. It stops short of describing the response envelope or event payload fields, which matters slightly more given no output schema exists.

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 limit, since, league and user_request. The description reinforces the cursor protocol for since and notes that league is optional, but adds no detail on limit bounds or on the required user_request parameter. Baseline 3 applies 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?

The description names the resource ('the change feed') and enumerates its contents precisely: new props, line moves, price moves and status changes. It states ordering ('oldest first') and cursor scope, which separates it in spirit from list_props or prop_history, though no sibling is named 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?

It gives a clear usage context ('keep up with the market without rereading the board') and the exact polling protocol: start with since 0, then pass back meta.next_cursor. It does not name an alternative for one-off historical lookups or state when not to use the feed, so it falls short of full alternative 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?

With no annotations, the description carries the full behavioral burden. It usefully discloses that a human team reads every submission and that it consumes no quota, which is genuine value. However, it omits what happens after submission, whether the submitter is identified, whether follow-up is possible, and whether the call is fire-and-forget.

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 and roughly seventeen words, with the purpose front-loaded and the reassurances after. Nothing is padded and every sentence carries a distinct fact.

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 three-parameter submission tool with no output schema, purpose, audience and cost are covered, so the core is there. The undefined `contact` parameter and the absence of any post-submission behavior leave meaningful gaps for an agent deciding what to put in the payload.

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

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

Schema description coverage is 0%, so the description must compensate for all three parameters and does not. The enum in `kind` is self-describing, but `message` has no guidance on scope, length, or expected content, and `contact` is entirely unexplained — the agent cannot tell whether it is an email, a handle, or whether supplying it enables a reply.

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?

"Tell the team what is missing or wrong" states a concrete action and the kind of input it accepts (defects and gaps), which separates it cleanly from every sibling tool (watches, props, events, history). It never uses a send/report verb explicitly, leaning on the tool name for the action, but the intent is unambiguous.

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

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

The phrase "what is missing or wrong" implicitly defines the trigger for calling it, but there is no explicit when-to-use framing, no mention of when not to use it, and no reference to any alternative channel. Adequate but leaves the agent to infer.

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

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

With no annotations, the description carries the full behavioral burden and delivers none of it. It does not state whether this is a partial update (are omitted fields preserved?), whether the Watch must belong to the caller, whether changes are reversible, or why a required user_request accompanies every mutation.

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

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

A single front-loaded sentence with zero waste, but the terseness is close to under-specification rather than disciplined concision — there is nothing to front-load because nothing extra is said.

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

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

A six-parameter mutation tool with no annotations and no output schema needs the description to explain update semantics and the purpose of the mandatory user_request. Neither is covered, leaving the agent to guess at behavior that matters for calling it correctly.

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

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

Schema description coverage is 83%, so the properties (line, note, stat enum, player, user_request) are already documented in the schema. The description adds no meaning beyond that — notably it never explains the unusual required user_request field or confirms that only supplied fields change. 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?

"Change fields on one of your Watches" gives a specific verb (change/update) plus a specific resource (Watches), and the plural sibling set (create_watches, delete_watches, get_watches) makes the CRUD role obvious. It stops short of saying which fields are updatable or what a Watch represents, so it is clear but not maximally distinguishing.

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 when-to-use guidance, no exclusion of alternatives, and no stated prerequisites. The agent must infer that an existing Watch id is required and that creating or removing Watches belongs to create_watches/delete_watches, rather than being told.

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