Lection

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, covering the safety profile. The description adds only that results are shown 'as a table', a modest output-shape hint, and says nothing about pagination limits beyond what the schema's maxRows already implies.

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, no filler, with the core action front-loaded and the id-discovery guidance following immediately. 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?

No output schema exists, but the description states the return is rows rendered as a table, which is adequate for a read-only, annotated tool with a fully documented 3-parameter schema. A note on row-limit or truncation behavior would make it fully complete.

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 id, kind, and maxRows are already fully documented in the schema; the description's mention of fetching by id adds nothing new. 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?

States a specific verb (fetch) plus resource (the rows of a saved scrape or scheduled run) and the output shape (a table), keyed by id and kind. It is clearly distinguishable from the sibling list_my_saved_scrapes and list_my_runs tools, which it explicitly points to for id discovery.

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 an explicit prerequisite: 'Use list_my_saved_scrapes or list_my_runs first to find the id,' which routes the agent correctly. It does not state when-not to use it or contrast further with alternatives, so it falls short of a full 5.

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

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

Annotations already declare this as a read-only, idempotent, non-destructive, closed-world call, so the safety profile is covered. The description adds genuinely new behavioral context beyond that: the login requirement, the fact that execution happens in the user's Chrome extension rather than in ChatGPT, and the nature of the return (install link plus the right tool page). It does not mention any rate limits or failure modes, so 4 rather than 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 tight sentences with the purpose front-loaded, followed by the rationale and the call trigger, then the return value. No filler, no repetition of the title or annotations.

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 states what is returned (install link and the relevant tool page), and the annotations cover the safety profile, so nothing essential is missing for invocation. The only gap is that the "other" platform value has no described behavior, which is a minor incompleteness.

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 platform enum is documented, so the baseline is 3. The description adds value by enumerating what data each platform value covers (Instagram comments/followers/following/posts, LinkedIn connections), helping the agent reason about the enum. The "other" enum value is left unexplained, preventing a 5.

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 purpose: explaining how to export Instagram data (comments, followers, following, posts) or LinkedIn connections via Lection. It clearly positions this as an informational/how-to tool rather than a scraper, which separates it from sibling extraction tools like youtube_comments. It does not name a specific sibling to contrast with, so it falls just short of the top mark.

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 whenever the user asks for Instagram or LinkedIn data" is an explicit, unambiguous trigger condition. It also explains why the flow differs (login required, runs in the user's own browser via the extension rather than inside ChatGPT). No when-not-to-use or explicit alternative-tool routing is given, so it is a strong 4 rather than 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=false and destructiveHint=false, so the safety profile is covered. The description usefully discloses the shape of what comes back (status, row counts, errors), but says nothing about pagination, result ordering, or how 'recent' is bounded.

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 compact sentence with the resource and returned fields front-loaded and no wasted words. It is arguably too terse for the informational gaps it leaves, but nothing in it 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?

A zero-required-parameter, read-only list tool with honest annotations and no output schema; the sentence names the returned fields, which is exactly the compensation needed. Nothing essential to calling it correctly is missing.

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

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

Schema description coverage is only 33% — only scheduleId carries a description ('Only runs of this schedule.'). The description does not compensate: it never mentions the limit cap (max 20) or the status enum values, so an agent has no prose guidance on narrowing results.

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 'List' plus a precise resource ('recent runs of the user's schedules'), with the returned payload sketched in (status, row counts, errors). It is distinguishable from list_my_schedules and get_run_results, though it never names those siblings 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?

No when-to-use guidance, no prerequisites, and no routing to alternatives such as get_run_results for detailed run output or list_my_schedules for schedule configuration. The agent must infer usage entirely from the name.

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=false, so the safety profile is fully covered structurally. The description only adds the shape of the returned rows, with no mention of ordering guarantees, empty-state behavior, or pagination beyond the schema's limit bound.

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, and the primary purpose is front-loaded before the workflow context. Every clause earns its place by either defining the resource or routing the agent to downstream tools.

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

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

With no output schema, the description compensates by naming the returned fields and the 'most recent' ordering, and it places the tool in the workflow chain. Only minor gaps remain, such as what happens when the user has no saved scrapes.

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

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

Schema description coverage is 100% with a single well-documented 'limit' parameter (default 10, range 1-20), so the schema carries full semantic load. The description adds nothing about the limit parameter; baseline 3 applies.

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

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

States a specific verb and resource (list the user's most recent saved scrapes) and even enumerates the returned fields (title, page, row count, id). It separates the resource from sibling list tools like list_my_runs and list_my_schedules by naming 'saved scrapes' explicitly, though it never directly contrasts itself with those siblings.

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?

'A saved scrape is the starting point for schedule_extraction and get_run_results' tells the agent exactly why and when it would call this tool: to obtain a scrape id needed to feed extraction or run-result lookups. No explicit exclusions or when-not-to-use guidance is given, 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?

No annotations are provided, so the description carries the full behavioral burden. It discloses the fields returned (name, cadence, destination, next run, last status), but says nothing about read-only safety, permissions, pagination, sorting, or rate limits.

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 a single, front-loaded sentence that lists the returned fields with zero wasted words. It is appropriately sized for a simple list 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?

With no output schema and no annotations, the description does list the return fields, which is useful. However, it omits any parameter semantics, filtering behavior, or usage context, leaving clear gaps for an agent invoking it beyond the no-argument default.

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 input schema has 2 parameters with 50% description coverage and one enum, but the description does not mention parameters at all. Since coverage is not high, the description should compensate for the gaps, and it does not.

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 ('List') and specific resource ('the user's scheduled extractions'), which distinguishes it from siblings like list_my_runs and list_my_saved_scrapes. It does not explicitly name any sibling or clarify boundaries, so it falls 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?

There is no guidance about when to use this tool versus alternatives such as pause_schedule or schedule_extraction. Usage is only implied by the tool's name and resource, with no exclusions or prerequisites 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, openWorldHint=false and destructiveHint=false, so the safety profile is fully covered. The description adds only the information scope (plan limits, destinations, credits); it says nothing about freshness, auth scopes, or whether limits are per-workspace or per-user.

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, no filler. The content list comes first and the usage cue is placed at the end where it reads as a routing 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?

With no output schema, the description carrying the enumeration of returned fields is doing the necessary work. It covers plan, schedule allowance, destinations and credits, but leaves the exact units/format of "cloud credits" and the schedule limit unspecified.

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?

Zero parameters, so the baseline is 4; the schema is empty and there is nothing for the description to clarify or compensate for.

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 ("Show") plus a concrete resource ("linked user's Lection plan") and an enumeration of what it surfaces: schedule allowance, delivery destinations, cloud credits. It is distinguishable from siblings like list_my_schedules or list_my_runs, though it never names them 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?

Gives explicit when-to-use triggers: "Use before scheduling or when a plan limit is hit." No when-not conditions and no named alternatives, but the pre-flight context is clear enough for an agent to pick this over a listing tool.

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=false and destructiveHint=true, so the mutation profile is known; the description adds the non-obvious recovery path ('The user can resume it from the Lection dashboard') and the confirmation requirement, which are real behavioral context the annotations do not carry. It does not say what happens when the schedule is already paused or the id is invalid.

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, the core action front-loaded, followed by the recovery path and the safety instruction; every sentence carries distinct information with no padding.

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 single-parameter, no-output-schema tool with rich annotations, the description covers purpose, reversibility, and the confirmation requirement. Only edge-case behavior (already-paused schedule, schedule ownership validation, error mode) is left implicit.

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

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

Schema description coverage is 100% and the schema field already explains the UUID and points to list_my_schedules as the source, so the description adds no parameter meaning. Baseline 3 is appropriate for a single fully-documented parameter.

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 (pause) and resource (a schedule belonging to the user) plus the resulting effect ('so it stops running'), which lets an agent distinguish it from list_my_schedules and schedule_extraction without opening the schema.

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

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

Gives a clear operating condition (pause to stop a running schedule) and an explicit procedural prerequisite ('Confirm with the user first'), but names no alternative tool or exclusion cases because none exist among the siblings.

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

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

Annotations declare non-readOnly, non-idempotent, non-destructive, closed-world, but add nothing about cost or side effects. The description adds substantive context beyond them: the job is recurring and lands in the user's Lection account, it may consume cloud credits, and plan limits can block creation with a clear message. It stops short of stating reversibility/cleanup (pause vs delete) or failure behavior.

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

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

Three sentences, front-loaded with the action and its cadence/destination scope, followed by the confirmation requirement and the limits caveat. Every sentence carries information; only the destination enumeration slightly duplicates the enum in the schema.

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 mutation with full schema coverage and no output schema, the description supplies the missing behavioral layer (cost, confirmation, plan limits). It does not cover what the schedule id/result looks like or how to later modify it, but that is largely outside this tool's scope.

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 all nine parameters including defaults, enums and formats. The description only restates the cadence and destination option sets, adding no syntax or format detail 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+resource ('Create a recurring schedule ... that re-runs one of the user's saved scrapes') and enumerates the cadence and delivery options. This clearly separates it from siblings like list_my_schedules and pause_schedule, which read or modify existing schedules rather than create them.

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 pre-call instruction ('confirm the saved scrape, cadence and destination with the user') which is real usage guidance for a mutation. It does not name alternative tools (e.g. pause_schedule for stopping, list_my_saved_scrapes for obtaining the id — though that is referenced in the schema), so it falls short of explicit when/when-not routing.

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

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

Annotations already carry the safety profile (readOnly, destructive=false, openWorld, idempotent), so the description's main additions are the input-format flexibility and the 20-item cap. It does not disclose rate limits, auth requirements, or pagination behavior, which matters for an open-world external API call. With annotations covering safety, this is adequate but not rich.

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

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

Four tight sentences: purpose, input formats, return shape, then purpose/alternative routing. Front-loaded and free of filler; every clause carries information.

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

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

An output schema exists, so return-field explanation is a bonus rather than a requirement, and annotations cover the safety profile. For a filtered read-only list tool, the description covers everything an agent needs to invoke 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 100%, so both parameters are already documented, including the maxRows 1-20 cap. The description's handle/URL examples mirror the schema text rather than adding new meaning. 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?

States a specific verb and resource ('List the latest videos on one YouTube channel') and scopes it to a single channel with accepted identifier formats. It explicitly distinguishes itself from youtube_search, so an agent can route correctly 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?

Gives an explicit use case ('audit a creator or competitor channel') and names the alternative with its selection condition ('To search all of YouTube by keyword use youtube_search'). Nothing is left 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 cover read-only/idempotent/open-world safety, and an output schema covers return fields. The description still adds a meaningful constraint beyond structured data: only 'top-level' comments (not replies) and only for 'public' videos. Return-field enumeration is somewhat redundant given the output schema, keeping this off 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?

Four tight sentences, front-loaded with the core action, then return shape, use cases, and the key precondition. No filler; each 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?

With annotations covering the safety profile and a full output schema covering returns, plus the top-level/public constraints and sibling routing in the description, nothing an agent needs to call this correctly is missing.

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

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

Schema description coverage is 100%, so both url and maxRows are fully documented in the schema (including youtu.be and /shorts/ support and the 1-20 range). 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?

States a specific verb+resource ('Fetch top-level comments from one public YouTube video') with clear scope, and distinguishes itself from youtube_search by requiring a URL rather than a query. An agent can tell exactly what this returns 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 names the alternative ('to find videos first use youtube_search') and states the precondition (needs a specific video URL), plus names concrete use cases (sentiment, feedback mining, finding engaged commenters). Routing is fully specified.

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 supply the full safety profile (readOnlyHint, openWorldHint, idempotentHint, destructiveHint=false), so the bar is lower. The description's behavioral additions (20-result cap, returned fields) largely duplicate the schema's maxRows description and the existing output schema, so it adds only modest value beyond structured data.

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 verb and resource, then return shape, then usage and the sibling routing. No filler or redundant phrasing.

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 an output schema present the description needn't enumerate return fields, and annotations handle the safety profile; the description still covers scope, result limits, use intent, and the sibling alternative. Nothing needed to invoke it correctly is missing.

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

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

Schema coverage is 100%, so the baseline is 3, but the description supplies concrete query examples ("n8n automation tutorial", "best budget laptops 2026") that clarify the intended free-text style beyond the schema's "exactly as you would type them into YouTube" wording, and restates the 20-row ceiling in the context of results.

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 ("Search YouTube for videos by keyword") with concrete example queries, and explicitly distinguishes itself from the sibling youtube_channel_videos. An agent can tell it apart from the channel-scoped alternative 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?

Names explicit use cases (content research, finding competitors, spotting popular topics) and routes the agent to the alternative when the intent is channel-scoped: "To list videos from one specific channel use youtube_channel_videos instead." When-to-use and when-to-use-something-else are both covered.

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