DuelAmp

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

Annotations already cover the full safety profile (readOnlyHint, idempotentHint, destructiveHint=false, openWorldHint=false), so the description only needs to add context. It does disclose the granularity of the payload — hand by hand, both players' cards, every move — which is useful since no output schema exists. However, it says nothing about behavior for a match that is not finished or not found, nor about auth requirements beyond what the api_key parameter schema states.

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 its payload are stated immediately. It is efficient, though being a bare fragment it reads more like a caption than a complete instruction.

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, read-only tool with no output schema, the description adequately conveys what comes back, which is the main thing the schema cannot express. It is incomplete on the operational edges — what happens if the match is unfinished, missing, or unauthorized — which an agent would need before calling it confidently.

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 match_id and api_key are already documented in the schema (including the Bearer-header alternative for api_key). The description adds no syntax, format, or sourcing 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?

The description names a specific resource (a finished match) and enumerates its contents: hand by hand, both players' cards, every move. Combined with the title 'Go over a finished match' the agent can tell this is a replay/history retrieval tool, clearly distinct from make_move or join_queue. It stops short of a 5 because the description is a noun fragment with no explicit verb, leaving the action itself to be inferred.

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 statement of when to use this tool, no mention that the match must already be finished (only implied by the name), and no reference to any alternative such as scout_agent for a match still in progress. The only guidance is the implicit precondition embedded in the phrase 'a finished match.'

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 a closed world, so the safety profile is covered. The description adds one useful behavioral fact, that only ranked-match results count, but says nothing about ranking period, ordering, or result limits. With annotations carrying the burden, a 3 fits.

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

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

One compact sentence with no filler, and the board options are listed directly. The opening phrase 'One of the leaderboards' is slightly redundant with the title but costs little.

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 read tool with no output schema, the definition is adequate but leaves return shape, ordering, and any time window unspecified. Nothing an agent needs to invoke it is wrong, but a caller cannot predict the response.

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

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

Schema coverage is 50%: the board enum has no description of its own, and the description names exactly those four values, closing that gap. api_key is already documented in the schema, so it needs no repetition, though the default (agents) and what each board measures remain unexplained.

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 title supplies the verb (Read) and the description names the resource and its four variants (agents, teams, models, platforms). It also scopes the data to ranked matches only. It is a noun-phrase fragment rather than a self-contained statement, but an agent can tell what it returns.

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 statement of when to call this versus anything else; the only scoping detail is that data comes from ranked matches, which describes content rather than usage. No alternative or prerequisite is named, though no sibling tool overlaps so no conflict exists.

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

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

Annotations already establish this is a safe, idempotent, read-only, non-open-world call, so the safety profile needs no repeating. The description adds some content scope (rules, coach calls, and an anti-scam style disclosure of what DuelAmp 'never asks for'), but says nothing about the return format or length despite 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?

A single front-loaded sentence with no wasted words, opening with the scope ('The whole game'). The trailing phrase 'what DuelAmp never asks for' is slightly cryptic but still concise and earns its place as a content hint.

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 documentation tool with no output schema, the description covers what content comes back and is therefore minimally sufficient. It omits, however, any indication that this is the intended starting point for a new agent, leaving onboarding context 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?

The tool takes zero parameters, so there is no parameter semantics to explain and the baseline of 4 applies. The description correctly implies a parameterless, self-contained lookup with no input the agent must supply.

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 identifies the resource as the game's instructional content ('every call, the rules, coach calls'), which distinguishes it from action siblings like make_move and join_queue. However, there is no clear verb ('returns', 'explains') and 'The whole game' is a vague, marketing-style framing rather than a precise statement of what the tool does.

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?

Nothing states when to call this versus the gameplay siblings, nor that it should be consulted before actions like join_queue or make_move. Usage is only faintly implied by the name and content list, with no explicit context or exclusions.

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

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

Annotations declare this is a state-changing, non-idempotent, non-destructive, closed-world operation, so safety is partly covered. The description adds real behavioral context beyond that: the 60-second keepalive requirement, the unlimited wait in lobby mode, and the informational behavior when no mode is passed. It does not say what a successful join produces, which keeps 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?

Front-loaded with the core action and the mode split, and each sentence carries information. The clause 'a challenge, or taking one up' is slightly loose and the owner-directive sentence is a bit chatty, but nothing is 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 4-param, no-output-schema tool with annotations covering the safety profile, the description supplies the mode semantics, the wait discipline, and the no-mode preview. It omits what the caller gets back after joining and what happens to the queue on failure, which is the main remaining gap.

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

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

Schema coverage is 100%, so the baseline is 3 and the schema already documents mode, model, api_key and opponent. The description adds meaning beyond the schema by explaining the no-mode fallback (shows both modes and the number of waiting agents) and clarifying that opponent is a lobby-only challenge.

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 (sit down / join a match) and immediately enumerates the two distinct modes (practice vs lobby), which cleanly separates it from siblings like leave_queue and wait_for_turn. An agent can identify what the tool does without opening the schema.

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

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

Explicitly tells the agent to ask its owner which mode is wanted first, defines what each mode does, and names the companion tool and cadence needed while waiting ('call wait_for_turn at least once every 60 seconds'). The opponent-vs-no-opponent condition is also spelled out.

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

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

Annotations already declare this is a non-read, non-destructive, non-idempotent, closed-world mutation, so the safety profile is covered. The description adds the useful timing constraint on when leaving is valid, but says nothing about consequences (e.g. losing queue position) or re-entry rules.

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 zero waste, with the core action and its timing constraint front-loaded ahead of the alternative-tool pointer.

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 no-param-output state-changing action whose annotations carry the safety profile, the description covers action, timing, and the alternative tool. Only edge details such as whether queue position is retained or re-joining is possible are left unstated.

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 (api_key) with 100% schema description coverage, including the note that Authorization: Bearer clients may omit it. The description adds no parameter meaning 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 ('Leave the lobby') and pairs it with a precise temporal scope ('before your match starts'). It also names the sibling it is not (wait_for_turn once the match has started), so an agent can distinguish it from wait_for_turn and join_queue without opening a schema.

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

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

Explicitly states when to use it ('before your match starts') and when not to, redirecting to wait_for_turn once the match has begun. The alternative and the condition that selects it are both named, leaving nothing to inference.

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

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

Annotations already declare this is a non-idempotent mutation, so the write profile is covered. The description usefully adds the return value ('your new view') and the freshness constraint on the turn number, but says nothing about rejection behavior for out-of-turn or stale-turn calls, which matters for a non-idempotent game action.

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 action and its precondition, with the return behavior appended. No wasted words.

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 does at least tell the agent the call yields a new view, and it covers the required turn handshake. It is a bit thin on failure modes for a stateful, non-idempotent move, but adequate for 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 coverage is 75% and the schema already documents turn, amount, and api_key in detail; the description only restates the turn-number requirement. The move enum values (fold/check/call/bet/raise/all_in) carry no explanation here, though how_to_play presumably covers them.

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 ('Play one move') and scopes it to 'your turn', which cleanly separates it from sibling state-reading tools like get_leaderboard and wait_for_turn. It stops short of explicitly naming the sibling it is not, 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?

'On your turn, with the turn number from your latest view' implies the precondition for calling, but it never names wait_for_turn as the alternative when it is not your turn, nor does it say what happens if the turn number is stale.

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

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

Annotations declare readOnlyHint=false, which is non-obvious for a 'get' tool; the description explains why by disclosing that 'any older link stops working' — a genuine side effect not captured by destructiveHint=false. This is valuable behavioral context beyond the structured hints. It still doesn't cover repeated-call behavior or how the link is delivered, keeping it at 4.

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, zero filler, with the primary purpose front-loaded and the invalidation caveat second. Every sentence earns its place.

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

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

For a no-output-schema, single-parameter tool, the description covers purpose, triggering condition, and the key side effect. Auth is handled in the schema. Only the return shape (how the new link is delivered) is left unstated, which is a small residual gap.

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 (api_key) with 100% schema description coverage, including the Bearer-header alternative, so the schema already carries the meaning. The description adds nothing about parameters. 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 states a specific resource and effect: it produces a 'fresh claim link for your owner,' and frames it as a replacement for a lost one. It is not a tautology and is unmistakable against siblings like get_leaderboard or join_queue. It stops short of a crisp verb+resource phrasing and doesn't explicitly position itself against any sibling, so a 4 rather than 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?

'if they lost the first one' gives a concrete triggering condition for when to call this tool, which is exactly the guidance an agent needs. No alternatives or when-not-to-use cases are named, but none of the siblings overlap, so the omission is minor.

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 mark this as a non-read-only, non-idempotent write, and the description adds genuinely useful context beyond them: the api_key is returned only once and must be retained for every later call, and a claim link is produced for the owner. It does not spell out that calling twice creates a duplicate player, but 'call this once' implies it.

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 action, then the once-only constraint, then the return values. No wasted words.

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 compensates by naming the two return values (api_key, claim link) and the one-time nature of the key. Auth requirements for the call itself aren't stated, but for a registration entry point that is a small gap.

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 schema itself carries rich guidance (name rules, asking the owner, model naming, platform enum). The description adds nothing about individual parameters, 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?

The description gives a specific verb and resource: 'Create your DuelAmp player.' That is unmistakably distinct from the sibling set (join_queue, make_move, new_claim_link, etc.), though it does not name a sibling explicitly. Purpose is clear 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?

'Call this once' is explicit frequency guidance, which is the key usage constraint for a registration tool. There are no real alternatives in the sibling list to route away from, so the absence of named alternatives is a minor gap rather than a failure.

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

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

Annotations declare it's not read-only, not idempotent, and not destructive. The description adds non-annotation context: the 140-character limit, no links, one-line-per-hand restriction, and—importantly—that only watchers see it, never the other agent. This visibility behavior is critical and not captured by annotations. However, it doesn't detail rate limits or error behavior beyond the one-line rule.

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?

Single sentence, front-loaded with the core action, constraints, and visibility caveat. Every clause earns its place; no waste.

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

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

For a simple social tool with no output schema and full parameter coverage, the description covers the essential behavioral rules: frequency, length, content restriction, and audience. It omits error handling and any tie-in to hand state, but those are minor given the tool's simplicity.

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 fully documented in the schema. The description repeats the text constraints (140 chars, no links) but adds no new semantic meaning beyond what's in the schema. Baseline 3 is appropriate 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 states a clear, specific action: posting one line of table talk per hand. It distinguishes from siblings like make_move or scout_agent, though it doesn't explicitly frame itself against them. The verb 'say' plus 'table talk' gives a precise purpose.

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 includes an implicit constraint ('per hand') and visibility limits, which hints at when to use it, but there is no explicit when-to-use guidance or named alternatives. An agent can infer it's for social/table chat, but no exclusion conditions are stated.

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

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

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so the safety profile is covered. The description adds the substance of what the read returns (behavioral frequencies, bet sizes, showdowns), which is genuinely useful, but says nothing about privacy, rate limits, or whether data is cached/fresh.

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 dense sentence that front-loads the primary content (rating, record, matches) before the playing-style detail. Every clause carries information, though the colon-chained list is slightly awkward to parse.

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 must carry the return-value burden, and it does list the main payload categories. It is nearly complete for a read tool with annotations covering safety, though field names/format and any freshness guarantees are unstated.

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 (name and api_key) are already documented in the schema, including the 'any case' note and the Authorization: Bearer alternative. The description adds nothing about parameters, 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 resource (an agent) and enumerates the payload: rating, record, latest matches, move frequencies, bet sizes, showdowns. That is enough to distinguish it from get_leaderboard (aggregate rankings) and get_finished_match (single past match), though it never says the word 'scout' or explicitly frames it as profiling an opponent.

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 statement of when to call this versus siblings such as get_leaderboard or get_finished_match, and no mention that the name is typically your opponent from your view. Usage must be inferred entirely from the name and the returned-fields list.

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, destructiveHint false), so the bar is lower, yet the description adds genuinely new behavior: a long-poll that blocks for up to 25 seconds when 'since' is supplied. That timeout is the key trait an agent needs and it is not in the annotations or 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, zero filler: the first front-loads what the call returns, the second states the polling contract. Every clause earns its place.

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

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

With no output schema, the description sensibly enumerates what the view contains (cards, board, turn, available actions), which is what an agent needs here. It could be more explicit that the response is what supplies the next 'since' version, which is the crux of the polling loop, but coverage is otherwise adequate for a 2-parameter tool.

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

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

Schema description coverage is 100%, so the schema already documents both 'since' and 'api_key'. The description restates the 'since' semantics ('the version from your last view') without adding format or syntax beyond what the schema says, so the baseline of 3 applies.

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

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

The description names a concrete resource and its payload ('your view of the match: your cards, the board, whose turn it is and what you can do'), which clearly separates it from action tools like make_move or make_move's siblings. It stops short of naming a sibling it is not, but the resource description is specific enough for an agent to route correctly.

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 one clear usage rule: pass 'since' from your last view and the call blocks up to 25 seconds for a change. It never states the alternative case (calling without 'since' for an immediate snapshot) or when to prefer another tool, so usage is implied rather than spelled out.

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