mentiondrop

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

Annotations already indicate this is a non-read-only, non-idempotent, non-destructive operation. The description adds useful behavioral context by mentioning plan limit enforcement and rejection of generic keywords, which are not conveyed by annotations.

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

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

Two sentences deliver the core purpose, parameter purpose, and key constraints without redundant wording. Information is front-loaded and every clause adds value.

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?

The tool is a simple creation operation with 3 parameters and no output schema; the description covers functionality, parameter motivation, and constraints. It doesn't describe the response format or error details, but this is reasonably complete 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 descriptions are absent (0% coverage), so the description compensates by explaining the purpose of 'role' and 'context', and enumerating role values. It doesn't detail keyword constraints, but the schema covers those.

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 function with a specific verb and resource: 'Start monitoring a new keyword for this account.' This distinguishes it from sibling tools like update_keyword and list_keywords by emphasizing 'new'.

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

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

The description implies its use for adding a new keyword but does not explicitly contrast it with alternatives such as update_keyword or search_mentions. It does state constraints like the plan limit and rejection of generic keywords, but lacks when-not-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?

The description adds valuable behavioral context beyond the annotations by disclosing that it never posts, sends, or publishes anything, and that the output is for human review. This is particularly useful given readOnlyHint=false, as it clarifies the true side-effect profile, though it does not cover storage or retrieval of drafts.

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 states the core action and then adds a critical safety qualifier. Every part is informative, and there is no filler or repetition.

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

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

Given the absence of an output schema, the description explains the return value ('draft text for human review'), notes the prerequisite ('processed mention'), and clarifies side effects. It is mostly complete for a simple two-parameter tool, though it could mention error cases or whether a draft is persisted.

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

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

With 0% schema description coverage, the description must compensate for parameter meaning. It does so by referencing 'one processed mention' (mapping to mention_id) and 'reply or outreach email' (mapping to draft_intent enum), thereby adding semantic context even though it does not literally name the parameters.

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

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

The description uses a specific verb ('Generate') with a clear resource ('a draft reply or outreach email') and scopes it to 'one processed mention.' It also explicitly distinguishes itself from siblings by stating it never posts, sends, or publishes anything, making its purpose 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 description provides clear context for when to use the tool: for generating a draft for a processed mention. It implicitly differentiates from sibling tools (get/search/list mentions, create/update keywords) by focusing on draft generation, but it does not explicitly state when not to use it or name alternative tools.

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 and destructiveHint=false, so the safety profile is covered. The description adds that it matches by competitor-role keywords and can be narrowed by competitor name, but doesn't disclose behaviors like pagination, default time range, or what 'recent' means. It doesn't contradict annotations.

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

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

Two sentences, front-loaded with the main action, no fluff. The structure is efficient and all words contribute to understanding.

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?

The tool is simple with 4 optional parameters and no output schema. Annotations cover safety, and the description states purpose and use case. However, missing parameter details (especially limit and date range) and no mention of return format leave some gaps. It's adequate but not 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 0%, so the description must compensate. It explains 'competitor' via 'optionally narrowed to a single competitor name' and implies time from 'recent', but does not explain 'to', 'from', or 'limit' parameters. The limit parameter is not mentioned, and the date-range semantics are left vague.

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 tool returns 'recent mentions matched by competitor-role keywords' with an optional competitor-name filter. This specific verb+resource+scope distinguishes it from siblings like get_recent_mentions and search_mentions, which are more generic.

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 provides a clear use case: 'Use this to see what people are publicly saying about rival products.' However, it doesn't explicitly name alternatives or state when not to use this tool, so it stops 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?

Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds meaningful behavioral context by specifying that the output is grouped into owned brand mentions, competitor signals, demand signals, and conversations, which is more than the annotations provide. It does not mention pagination or rate limits, but for a read-only summary tool this is acceptable.

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 exactly two sentences with no filler. The first sentence front-loads the primary purpose and deliverable; the second adds a direct usage guideline. Every word 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?

While the purpose and usage are clearly described, the complete absence of parameter semantics is a critical gap, especially given 0% schema coverage. The description also doesn't explain how 'limit' affects the grouped result or the exact structure of each category. For a simple read-only tool, this is still incomplete.

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%, and the description provides no explanation for 'to', 'from', or 'limit'. The phrase 'recent mentions' is too vague to map to these parameters. The description completely fails to compensate for the schema's lack of parameter documentation.

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?

Description uses the specific verb 'Return' and defines a concrete deliverable: 'one grouped catch-up brief of recent mentions' split into four named categories. This clearly distinguishes it from sibling tools like get_recent_mentions or search_mentions, which would require separate queries for each category.

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

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

The final sentence provides a clear usage condition: 'Use this when a single summary is wanted instead of separate queries.' This tells the agent when to choose this tool over querying individually, though it does not explicitly name alternative tools or state 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 already state readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds the ownership restriction and lists the record fields, which is useful behavioral context beyond the annotations.

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

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

The description is two sentences, front-loaded with the core action, and every word earns its place. The field list is a bit long but directly useful for a get-by-id operation.

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 single-fetch tool with no output schema, the description lists expected return fields and ownership scoping, which is fairly complete. It omits behavior for nonexistent ids or unauthorized access, but these are not critical for such a simple 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 coverage is 0%, so the description must explain the only parameter 'id'. It does say 'by id', clarifying that id is the mention identifier, but does not provide format or additional detail. This is minimal augmentation over 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?

The description clearly states the verb 'Fetch' and the resource 'one mention by id', and enumerates the returned fields. This distinguishes it from sibling tools like get_recent_mentions or search_mentions, which operate on collections or search queries.

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 use case is implied: when you have a specific mention id and need the full record. The ownership constraint ('Only returns mentions owned by this account') provides context, but no explicit alternatives or exclusions are named relative to 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 already declare readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds important behavioral criteria: mentions must 'read as demand or pain signals' and either carry a suggested action or score at least 80. It also scopes to 'recent' mentions. This goes beyond annotations without contradicting them, though it omits details like pagination or parameter effects.

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 two sentences long, front-loads the core action, and avoids any filler. The first sentence defines the output and filter criteria; the second sentence gives the use case. Every clause adds value, and the overall structure is highly efficient.

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?

The description provides a strong purpose and usage scenario, and annotations cover the safety profile. However, correct invocation is hampered by missing parameter semantics (especially 'to' and 'from') and no mention of return format or pagination. Given the 4-parameter schema and no output schema, the description is not fully complete, though it is more than minimal.

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 has four parameters with zero descriptions (0% schema_description_coverage). The tool description does not explain the meaning of 'to' or 'from' (likely date range but could be user handles) or precisely how 'limit' and 'keyword' function. The description fails to compensate for the lack of schema detail, leaving the agent to guess parameter semantics.

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

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

The description uses a specific verb 'Return' and clearly identifies the resource as 'recent industry-role mentions' while defining what constitutes a pain signal ('carry a suggested action or score at least 80 for relevance'). This distinguishes it from siblings like get_recent_mentions and search_mentions, which are general-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 offers clear usage context: 'Use this to find people publicly describing a problem the product solves.' This tells the agent when to select this tool, though it does not explicitly mention alternatives or when not to use it. The guidance is clear but lacks explicit exclusions or alternative tool names.

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 and destructiveHint=false, so the agent knows it's safe. The description adds behavioral detail beyond the annotations: output ordering (newest first), return fields, and account-specific matching, which is useful context.

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

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

The description is two sentences, front-loaded with the main purpose and return details, followed by filters and use case. No unnecessary words or repetition.

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

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

The description covers purpose, output fields, ordering, filters, and usage context. With readOnly annotations and no output schema, this is fairly complete, though date range format and limit behavior are left 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?

Schema has 7 params with no descriptions (0% coverage). The description mentions filtering by role, keyword, source, sentiment, and date range, covering most parameters, but omits limit and doesn't explain the format for to/from. It partially compensates for the lack of schema descriptions.

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 'Return the most recent mentions matched for this account, newest first' and lists specific return fields (AI summary, sentiment, relevance score, suggested action). It also enumerates filter dimensions (keyword role, keyword, source, sentiment, date range), distinguishing it from siblings like search_mentions and get_mention.

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 explicitly says 'Use this to answer "what came in lately"' which gives a clear use case. It does not mention when not to use it or name alternative tools, but the context is sufficient for guiding selection among 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?

The description adds concrete behavioral detail beyond the readOnlyHint and destructiveHint annotations by specifying exactly what the tool returns (id, role, active state). It doesn't mention potential pagination or volume limits, but for a simple list endpoint this is a minor omission.

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 two sentences: the first states the action and output fields, the second gives usage guidance. Every word is purposeful and there is no redundancy or fluff.

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

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

For a zero-parameter, read-only list tool, the description fully covers what the return contains and why to call it first. It is self-sufficient even without an output schema, and the annotations confirm its safe 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 tool has zero parameters, so the description naturally doesn't add parameter details. With 100% schema coverage (empty schema), the baseline is 4, and the description appropriately focuses on output scope instead.

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

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

The description uses a specific verb ('List') and resource ('every keyword this MentionDrop account monitors') and explicitly names the output fields (id, role, active state). It clearly differentiates itself from sibling tools by positioning it as the discovery endpoint for keyword ids and role names.

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 provides explicit usage guidance: 'Call this first' to discover the ids and role names needed by other tools. While it doesn't name alternatives or state when not to use it, the instruction is clear and actionable for a discovery 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 indicate that this is a write operation (readOnlyHint=false) and idempotent (idempotentHint=true). The description adds meaningful context beyond these: the feedback 'tunes how future mentions are scored for the account' and explicitly reassures that re-sending the same verdict is safe, reinforcing idempotency. No contradictions.

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 crisp sentences, front-loaded with the core action and followed by the consequence and idempotency note. No filler or redundant content; 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?

The tool is simple with only two parameters and no output schema. The description covers the purpose, feedback effect, and idempotency. It does not explain return values or error handling, but given the low complexity and supportive annotations, the description is sufficiently complete for an agent to invoke the tool 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 0%, so the description must compensate. It mentions the two parameters implicitly: 'one mention' corresponds to 'id', and 'relevant or not_relevant' corresponds to 'verdict'. However, it does not provide details on the format of 'id' or how to obtain it, and only minimally explains 'verdict' by giving the enum values. It adds some value but is not fully compensatory.

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 action ('Record a review verdict'), the target ('on one mention'), and the specific verdict values ('relevant or not_relevant'). It is easily distinguished from sibling tools like search_mentions or get_mention, which focus on retrieval, whereas this focuses on writing feedback.

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

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

The description gives clear context: this is for providing feedback on a single mention to tune future scoring. It does not explicitly state when not to use it or list alternatives, but the purpose is distinct enough that context implies when it is appropriate. No exclusions are mentioned, but the intended use case is clear.

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

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

Annotations already declare read-only and non-destructive, so the bar is lower. The description adds meaningful behavioral detail: it searches over specific fields and uses AND semantics ('contain every word'). This goes beyond annotations, although it omits details like ordering, pagination, or how filters interact.

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 two sentences, front-loaded with the core action and then a usage note. Every sentence adds value and there is no redundancy. It is appropriately concise for the tool's complexity.

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 8 parameters, no output schema, and no parameter descriptions, the tool needs a richer description to cover defaults, filter behavior, and return format. The description only handles the main search behavior, leaving significant gaps for an agent to invoke the tool correctly, especially around the optional filters.

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 0%, so the description must compensate for all 8 parameters, but it only explains the query parameter semantics. It does not mention the purpose or meaning of to, from, role, limit, source, keyword, or sentiment, which are otherwise undocumented. The description adds value for the required parameter but leaves the rest completely ambiguous.

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 tool finds mentions matching a query across specific fields (title, summary, URL, etc.) with an explicit 'every word' semantic. It also distinguishes itself from time-based retrieval by saying 'rather than a plain time window', making its purpose specific and differentiated from siblings like get_recent_mentions.

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 provides a clear use case: 'look for a specific topic, product, or phrase' and contrasts it with 'a plain time window', which implies the alternative. However, it does not explicitly name sibling tools like get_recent_mentions or mention when not to use it beyond the time-window contrast, 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?

With idempotentHint and destructiveHint annotations, the description adds the behavioral detail that pausing sets is_active to false rather than deleting, which is not visible in annotations. It also confirms the update-by-id working model.

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

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

Three compact sentences with no redundant information; the purpose, usage hint, and behavioral nuance are all communicated efficiently.

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 7-parameter update tool with no output schema, the description gives a complete picture of what can be updated and the key non-deletion behavior. It does not describe return values or error cases, but these are not expected given the simplicity and annotations.

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 0%, so the description compensates by enumerating all updatable parameters: role, context, active state, min_relevance, excluded content types, and exclusion terms, mapping directly to the schema properties. The id parameter is also referenced. It doesn't add constraints or enum details, but schema handles those.

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

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

The description uses a specific verb ('Update'), identifies the resource ('monitored keyword'), and requires an id, while listing the editable fields. It clearly distinguishes from create_keyword and list_keywords.

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 explicitly tells the agent to use list_keywords to find the id, providing a clear prerequisite, and clarifies the pausing behavior. It does not explicitly contrast with create_keyword, but the context is clear enough.

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