Server Quality Checklist

Tool Scores

• get_free_skillA
  4.2/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint=true and idempotentHint=true, and the description echoes these while adding valuable context about error handling: invalid inputs return an error object rather than raising protocol errors. This goes beyond annotations by describing the exact failure mode and retry safety.

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

  Conciseness5/5

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

  The description is concise, with key information front-loaded: purpose, example, error behavior, and idempotency. Every sentence earns its place, with no redundant fluff or excessive detail.

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

  Completeness4/5

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

  For a simple one-parameter tool with an output schema present, the description covers essential aspects: what it does, example I/O, error handling, and safety. It is complete enough for an agent to use correctly, though it could explicitly differentiate from get_full_skill for added clarity.

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

  Parameters4/5

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

  Schema description coverage is 100% with clear slug description referencing search_catalog, and the description reinforces it with a concrete example ('inbox-zero-assistant') and typical output. This adds practical meaning beyond the schema by showing usage in context.

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

  Purpose5/5

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

  The description clearly states the tool loads a product's free gateway skill with complete instructions, using a specific verb and resource. It distinguishes from siblings like get_full_skill by highlighting 'free' and 'gateway' nature, and provides a typical input/output example.

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

  Usage Guidelines3/5

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

  The description implies usage context by showing typical input with a slug from search_catalog and mentioning safety to retry, but it does not explicitly state when to use this tool over alternatives like get_full_skill or exclude scenarios. No exclusions or alternative tool mentions are given, so guidelines are implied rather than explicit.

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

• get_full_skillA
  4.3/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint=true and idempotentHint=true, and the description reinforces these traits with 'Every call is read-only and idempotent'. It adds valuable extra behavior by detailing the error handling pattern: 'on invalid, missing, or malformed input... returns {"error": ...}' rather than raising a protocol error, which is not covered 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.

  Conciseness5/5

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

  The description is compact and well-structured: it opens with the primary purpose, then gives a concrete example, error behavior, and a safety note. Every sentence adds valuable information with no redundancy or fluff.

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

  Completeness5/5

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

  The description is fully complete for this tool: it explains the purpose, provides a typical input/output example, documents error handling, and covers read-only/idempotent behavior. The output schema exists and annotations cover safety, so the description needn't elaborate on return values or security, making it comprehensive.

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

  Parameters3/5

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

  The input schema has 100% description coverage, with each parameter (slug and skill_name) clearly defined. The description only provides an example input without adding meaning beyond what the schema already states, so the baseline score of 3 applies.

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

  Purpose5/5

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

  The description clearly states 'Load one paid skill's complete instructions from a product', which specifies the verb (load), resource (one paid skill's instructions), and source (a product). It distinguishes itself from siblings like get_free_skill by explicitly noting 'PREMIUM (paid plan)' and 'paid skill', making the purpose unambiguous.

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

  Usage Guidelines4/5

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

  The description provides clear context by indicating this is for paid skills and shows a typical input/output, implying usage for retrieving full skill instructions. However, it does not explicitly mention alternatives like get_free_skill or when not to use this tool, so it lacks explicit exclusion guidance.

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

• preview_productA
  4.4/5.0
  Behavior5/5

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

  Annotations already declare read-only, idempotent, and non-destructive behavior. The description adds valuable behavioral context: it never raises protocol errors and instead returns a structured error object, shows an example response format, and explains the free nature of the tool. This goes well beyond the structured annotations.

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

  Conciseness4/5

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

  The description is front-loaded with the main purpose, followed by a detailed example and error-handling notes. Each sentence contributes value: the example is informative, the error behavior is crucial, and the safety note is practical. Though slightly dense, it remains well-structured and not wasteful.

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

  Completeness5/5

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

  For a single-parameter tool with an output schema, the description covers the purpose, input source, output example, error behavior, and idempotency/retry guidance. This is sufficient for an agent to select and invoke the tool correctly without ambiguity.

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

  Parameters3/5

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

  The schema provides 100% coverage with a descriptive explanation of the 'slug' parameter, including an example. The tool description also includes an example input ('inbox-zero-assistant'), but this is redundant with the schema and adds no new semantic meaning. The schema already carries the full weight.

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

  Purpose5/5

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

  The description states 'Preview one product: metadata, persona teaser, and paid-skill teasers' with a specific verb and scope. It distinguishes from siblings by emphasizing the teaser/preview nature and includes an example output that clarifies the tool's purpose.

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

  Usage Guidelines4/5

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

  The description provides clear context by mentioning that typical input comes from search_catalog or recommend_products, and notes that calls are read-only and idempotent. However, it does not explicitly name alternatives like get_full_product or state when not to use this tool, so guidance is clear but not fully explicit.

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

• get_full_personaA
  4.5/5.0
  Behavior5/5

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

  Beyond the annotations (readOnly, idempotent, non-destructive), the description explains error behavior in detail: it never raises a protocol error, instead returning a structured error object with fix suggestions. The example return format and the note about correcting input add valuable context not present in annotations. No contradiction with annotations.

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

  Conciseness5/5

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

  The description is compact and front-loaded: a clear purpose sentence, followed by premium/availability, a concrete input/output example, error-handling behavior, and a retry safety note. Every sentence contributes unique information, with no redundancy or fluff.

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

  Completeness5/5

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

  For a simple read-only tool with one parameter, the description is complete: it covers purpose, premium restriction, example usage, return shape, error handling, and retry safety. The annotations cover safety, and the provided example compensates for the lack of an explicit output schema. The description fully equips an agent to invoke and recover from errors.

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

  Parameters3/5

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

  The input schema already fully describes the only parameter 'slug' with 'exactly as returned by search_catalog' (100% schema coverage). The description adds a concrete example value, but this illustrates rather than expands semantics. Baseline of 3 is appropriate since the schema carries the semantic weight.

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

  Purpose5/5

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

  The description opens with a clear, specific statement: 'Load a product's complete persona definition.' This uses a distinct verb ('load') and resource ('complete persona definition'), which clearly separates it from sibling tools like get_full_product or get_full_skill. The example and error behavior further reinforce 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.

  Usage Guidelines4/5

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

  The description includes usage conditions: 'PREMIUM (paid plan)' indicates when access is restricted, and 'after correcting the input it is always safe to retry' provides a clear retry guideline. However, it does not explicitly contrast with alternative tools (e.g., when to use this over get_full_product), 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.

• list_kitsA
  4.5/5.0
  Behavior4/5

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

  Annotations already declare read-only, idempotent, and non-destructive behavior, but the description adds valuable context beyond them: it is FREE, it never raises a protocol error but returns an error object, and retrying after correction is always safe. It also documents the exact return object structure.

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

  Conciseness5/5

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

  The description is extremely concise and front-loaded: the first sentence states the purpose, followed by terse, high-value additions (FREE, return format, alternative tool, error behavior). Every sentence earns its place with no filler.

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

  Completeness5/5

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

  For a zero-parameter list tool, the description covers all necessary context: the exact return shape, error handling, idempotency/retry safety, and how it relates to the premium sibling tool. The presence of an output schema further reduces the need to describe return values, and the description is sufficient even without it.

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

  Parameters4/5

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

  With zero parameters, the baseline is 4 per the rubric. The description confirms 'Takes no arguments,' which is redundant with the empty schema but adds clarity by explicitly stating that there are no inputs to provide.

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

  Purpose5/5

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

  The description clearly states the tool lists 'the 12 themed kits with pricing and member products' — a specific action on a specific resource. It distinguishes from siblings like get_full_kit by noting that a kit's slug is used with get_full_kit for deeper detail.

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

  Usage Guidelines4/5

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

  The description implies usage: call this tool to get an overview of all kits, then use get_full_kit for premium detail on a specific kit. It names the alternative explicitly ('Use a kit's slug with get_full_kit (premium)'), though it doesn't state explicit when-not-to-use scenarios.

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

• recommend_productsA
  4.5/5.0
  Behavior4/5

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

  Annotations already declare read-only, idempotent, and non-destructive behavior. The description adds valuable context beyond annotations: it explains that invalid/malformed input never raises a protocol error but returns a structured error object, and that retrying after correction is always safe. This adds behavioral clarity not present in 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.

  Conciseness5/5

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

  The description is well-organized: opening purpose sentence, 'FREE' note, example input/output, error behavior, and safety retry. Every sentence provides distinct value with no redundancy. It is concise yet information-dense.

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

  Completeness5/5

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

  Given the tool has only 2 parameters and an output schema, the description covers all essential aspects: purpose, usage context, expected output shape, error handling, and idempotency. It fully prepares 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.

  Parameters4/5

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

  Schema coverage is 100% with descriptions for both 'need' and 'limit'. The description adds meaning by showing a realistic example of the 'need' parameter and illustrating how 'limit' affects output (via the example and clamping note). It also clarifies the 'try_free' field in the response, which is beyond the schema's parameter list.

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

  Purpose5/5

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

  The description uses a specific verb ('recommend') and resource ('catalog products') for a need described in plain language, clearly distinguishing it from sibling tools like search_catalog or list_kits. It also includes a concrete input/output example that reinforces the tool's purpose.

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

  Usage Guidelines4/5

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

  The description implies usage for plain-language needs and provides a typical input, but it does not explicitly state when to prefer this tool over alternatives or list exclusions (e.g., 'don't use for exact matches, use search_catalog'). Still, the context is clear and supported by the example.

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

• get_full_productA
  4.6/5.0
  Behavior5/5

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

  Beyond annotations (readOnly, idempotent), the description adds that it never raises a protocol error and returns a structured error object with fix instructions. It also gives an example of the return shape, which is useful behavioral context.

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

  Conciseness4/5

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

  The description is moderately sized but every sentence adds value: purpose, premium requirement, example, error behavior, and retry safety. It is well-structured and not unnecessarily verbose.

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

  Completeness5/5

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

  With only one parameter and an output schema, the description is very complete. It covers expected output, error handling, premium requirement, and idempotency, leaving little ambiguity for an agent.

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

  Parameters4/5

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

  Schema coverage is 100%, so baseline is 3. The description adds value by showing a typical input example and the parameter description clarifies that the slug must be 'exactly as returned by search_catalog,' which helps correct usage.

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

  Purpose5/5

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

  The description clearly states 'Load one product in full: persona plus every skill's instructions,' using a specific verb and resource scope. It distinguishes from siblings like get_full_persona and get_full_skill by emphasizing the complete product bundle.

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

  Usage Guidelines4/5

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

  Mentions that this is PREMIUM (paid plan), which is a clear prerequisite/usage condition. Provides typical input and error-return behavior, and explicitly says retry is safe after correcting input. However, it does not explicitly name alternative tools for when not to use this one.

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

• get_full_kitA
  4.7/5.0
  Behavior5/5

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

  The description discloses that the tool never raises a protocol error on invalid input, instead returning an error object with fix instructions. It also reiterates the read-only and idempotent nature, reinforcing the annotations with actionable safety context.

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

  Conciseness5/5

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

  The description is well-structured and front-loaded with the main purpose, followed by an example, error behavior, and safety note. Every sentence adds valuable information without filler.

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

  Completeness5/5

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

  For a simple one-parameter tool, the description covers purpose, usage coordination with list_kits, error handling, access restrictions, and retry safety. It is complete given the rich annotations and full schema coverage.

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

  Parameters4/5

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

  The input schema already fully documents the slug parameter with an example and origin (list_kits). The description adds a concrete 'typical input' example and previews the output structure, which helps the agent understand the parameter's role beyond the schema baseline.

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

  Purpose5/5

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

  The description uses a specific verb ('Load') and resource ('a themed kit and every member product'), clearly distinguishing this from sibling get_full_* tools that focus on individual entities. It also specifies the premium requirement, adding purpose-related context.

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

  Usage Guidelines4/5

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

  The description implies when to use the tool (to retrieve a full kit and its products) and references list_kits as the source for a valid slug, providing a coordination hint. It does not explicitly exclude alternatives, but the scope is unambiguous.

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

• search_catalogA
  4.7/5.0
  Behavior5/5

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

  Beyond the annotations (readOnlyHint, idempotentHint, destructiveHint), the description discloses error behavior (returns an error object instead of protocol error) and emphasizes safe retry after correction. It also notes the output format and that the service is FREE, adding meaningful behavioral context.

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

  Conciseness5/5

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

  The description is three sentences, front-loaded with the purpose, and includes a compact example. It has no unnecessary content except a one-word 'FREE' notice, which is acceptable.

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

  Completeness5/5

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

  For a search tool with an output schema, the description covers ranking, error handling, browse mode, and retry safety. This is sufficient for an agent to invoke the tool correctly without additional context.

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

  Parameters4/5

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

  The schema covers all 3 parameters with full descriptions, and the description adds a concrete typical input example and explains that an empty query with an area set browses that area. This enriches the bare schema with intended usage semantics.

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

  Purpose5/5

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

  The description clearly states it searches all 138 catalog products by keyword and/or focus area, providing a specific verb, resource, and scope. This distinguishes it from sibling tools like get_full_product (details) and recommend_products (recommendations).

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

  Usage Guidelines4/5

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

  The description gives explicit usage patterns, such as keyword search, focus-area browsing, and a typical input example. It does not mention alternative tools by name or provide exclusion criteria, but the context is clear enough for selecting the right tool.

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

• upgrade_infoA
  4.8/5.0
  Behavior5/5

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

  The description adds context beyond the annotations by explaining error behavior: 'on invalid, missing, or malformed input this tool never raises a protocol error — it returns {"error": ...}'. It also reinforces the annotations by stating 'Every call is read-only and idempotent', and adds the practical implication of safe retrying. This gives the agent a complete behavioral model.

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

  Conciseness5/5

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

  The description is compact and front-loaded: the main purpose is stated immediately, followed by required parameter info, return shape, error handling, and safety guarantees. Every sentence adds value, with no redundant or filler content.

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

  Completeness5/5

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

  For a tool with no parameters and an output schema, the description covers all essential aspects: what it explains, what the response contains ('message', 'how', 'free_tier'), how errors are handled, and its read-only/idempotent nature. Combined with the annotations and schema, the agent has everything needed to use it correctly.

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

  Parameters5/5

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

  With zero parameters, the description explicitly notes 'Takes no arguments.' This directly matches the empty properties schema and removes any ambiguity. Since the baseline for 0 params is 4, the explicit confirmation and clarity push it to 5.

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

  Purpose5/5

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

  The description opens with a specific verb and scope: 'Explain how to unlock full personas, paid skills, and kits.' It clearly states what the tool does and covers a distinct informational niche compared to sibling tools like get_full_skill or list_kits, making it easy for an agent to select when a user asks about upgrade paths.

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

  Usage Guidelines4/5

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

  The phrase 'FREE.' and the explanation of what the tool returns ('describing the upgrade path and what stays free') give clear context for when to invoke it—when users ask about unlocking paid features or free-tier benefits. It does not explicitly name alternatives or exclusions, but the purpose is obvious enough that an agent can infer appropriate usage.

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