CCAPI

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

The annotations already declare readOnlyHint=true, so the description's job is lighter. It adds the non-streaming behavior and the fact that it works with any text model, providing context beyond the annotations without contradiction.

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

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

Two sentences total: the first states the core action and scope, the second lists use cases and a behavioral note. No filler, front-loaded with the verb, and every sentence serves a purpose.

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 readOnlyHint annotation, full parameter schema, and an output schema, the description provides sufficient context. The non-streaming note and model family list add useful detail beyond what structured data provides.

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 100% coverage with detailed descriptions for all 6 parameters. The tool description does not add parameter-specific guidance beyond referring to 'conversation' and 'model', so the baseline of 3 is appropriate.

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

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

The description clearly states the action ('Send a conversation... and get the reply') and the resource ('any text model available through CCAPI'), with a specific list of model families. It distinguishes itself from siblings like list_models and get_balance by focusing on the core chat completion functionality.

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 lists three concrete use cases (second opinion, bulk work, reaching unconfigured models) and notes that responses are non-streaming. However, it does not explicitly state when not to use the tool or how it differs from alternatives, though the use cases largely imply this.

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 the read-only, idempotent, and destructive hints, so the bar for extra behavioral disclosure is lower. The description adds the source-image requirement and endpoint identity, but provides little deep behavioral context such as side effects, billing, or failure modes. It does not contradict 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 with no filler. The core purpose is front-loaded and the sibling routing is packaged efficiently in a single, actionable sentence.

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 schema and output schema carry most of the parameter and return documentation, so the description mainly needs to convey purpose and routing, which it does. However, the conflict between the required source-image statement and the optional images parameter leaves an important invocation detail unresolved, so completeness suffers.

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%, which normally earns a baseline of 3, but the description says 'Provide at least one source image' while the images parameter is marked 'Optional' in the schema. This creates real ambiguity about whether a source image must be passed and through which parameter. A semantic requirement stated in the description should be consistent with 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 tool edits existing images according to an instruction and uses a dedicated image edit endpoint. It also differentiates from generate_image by explicitly routing pure text-to-image use cases away. This leaves no doubt about the tool's core function.

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 explicitly says when to use this tool versus generate_image: use generate_image for pure text-to-image or when models take references through the generation endpoint. It also implies edit_image requires at least one source image. This is strong routing guidance for the main sibling alternative.

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 mutability and non-idempotency, so the description's added value lies in disclosing the asynchronous nature and the required prerequisite workflow. It explicitly states the clip_id source and that polling with get_task is needed, which goes beyond the structured annotation 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?

The description is three tight sentences with no filler. It front-loads the core purpose, then gives the required dependency, and closes with the asynchronous polling instruction. Every sentence earns its place.

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

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

For a mutation tool with an output schema and full parameter descriptions, the description covers the essential workflow: source of the clip_id, continuation behavior, and polling mechanism. It does not describe edge cases or failure modes, but the provided annotations and schema make this reasonably 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 coverage is 100%, so baseline is 3. The description adds meaningful semantics by tying clip_id to the raw payload of a completed generate_music task and by framing continue_at as a timestamp within the original song. This gives the agent practical understanding beyond the schema's bare definitions.

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 a specific action ('Continue an existing song from a given timestamp'), the resource (a previously generated song), and the outcome ('producing a longer version'). It naturally distinguishes itself from generate_music by emphasizing that it operates on an existing clip rather than creating from scratch.

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 concrete usage context: it requires a clip_id from a completed generate_music task and tells the agent to poll with get_task. It does not explicitly name alternatives or exclusion conditions, but the dependency and follow-up workflow are clear enough to guide tool selection.

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 annotations already establish read/write and idempotency hints, and the description adds valuable behavioral details beyond them: sync latency in '10-60 seconds,' the async fallback with a task_id, and the financial consequence of the call. The warning against speculative retries is especially important given idempotentHint=false. This gives an agent realistic expectations about cost, delay, and failure handling.

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 sentences deliver purpose, output format, latency guidance, and a financial warning with no filler. The most important information is front-loaded, and each sentence earns its place. This is an appropriately sized description for a tool with this many parameters.

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

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

For a tool with 11 parameters and an output schema, the description covers the essential operational context: what it does, how outputs are returned, how to handle slow models, and cost implications. The main omission is explicit routing among image-related siblings like edit_image or upscale_image, but the schema and output schema make up most of the remaining invocation details.

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 parameters are already well documented. The description goes a step further by adding meaning around key parameters: reference images are tied to image-to-image mode, async is explicitly connected to timeout handling, and 'Returns image URLs directly' clarifies the default response_format behavior. This enriches the schema without repeating its content.

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 core action: 'Generate an image from a text prompt, optionally guided by reference images (image-to-image).' It also notes the return format ('Returns image URLs directly'), which helps define what the tool produces. However, it does not explicitly distinguish itself from sibling tools such as edit_image or upscale_image, leaving some potential for confusion about when to choose this tool over those.

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 actionable usage context: if the client times out, 'set async=true to get a task_id you can poll instead,' plus a clear cost warning: 'This call costs money — do not retry speculatively.' It does not explicitly state when to use generate_image versus edit_image or upscale_image, so it lacks the strongest possible sibling-routing guidance, but the practical wait/retry advice is useful.

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 cover the mutation/safety profile (readOnlyHint=false, destructiveHint=false). The description adds valuable behavioral context beyond annotations: it is asynchronous and requires polling with get_task, and it produces lyrics only, not audio. No contradictions 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.

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

Three sentences with no redundancy: core function first, then the primary use case and user-benefit context, then the async behavior. Every sentence earns its place and the structure is immediately scannable.

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?

Complete for an async lyric-generation tool. With an output schema present, return values do not need explanation. The description covers purpose, distinction from audio generation, integration with generate_music, and polling behavior, so an agent has what it needs to invoke 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?

Input schema coverage is 100%, so all parameters and their meanings are already documented. The description does not add parameter-level detail beyond the schema, so the baseline 3 applies. No compensation needed.

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 ('Write') and resource ('song lyrics from a description'), and explicitly differentiates from audio generation with 'without generating audio'. It also names the related sibling generate_music, making the tool's scope immediately clear.

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

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

Provides explicit when-to-use guidance: as a first step before generate_music with custom=true, so users can approve lyrics before paying for audio. It also implicitly tells when not to use it (when audio is needed) and points to the async flow with get_task.

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 clearly discloses that the operation is asynchronous, returns a task_id to poll, typically takes 30–120 seconds, and normally produces two variations. These are valuable behavioral details beyond the generic annotations, with no contradiction.

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

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

Three dense sentences deliver the core operation, mode distinction, and asynchronous behavior without filler. The most decision-relevant information is front-loaded, making the description easy to parse.

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

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

The description covers the essential workflow, modes, polling mechanism, and timing expectations, which is enough for an agent to invoke the tool correctly. It does not mention failure semantics or explicitly rule out sibling tools, but the detailed input schema and presence of an output schema cover most remaining context.

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 all parameters are already well documented. The description adds a useful high-level synthesis of the custom vs simple modes, but it does not provide substantial new parameter-level meaning beyond what the schema already states.

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

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

The description names a specific verb and resource ('Generate a song'), and immediately distinguishes two modes (simple vs custom) plus an instrumental option. It is clearly differentiated from sibling tools like extend_music and generate_lyrics by describing the generation workflow and output behavior.

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 explicit guidance on when to use each mode: simple for model-written lyrics and custom for user-supplied lyrics. It also instructs the agent to poll with get_task after receiving the task_id, but it does not explicitly contrast this tool with alternatives such as extend_music or generate_lyrics.

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 substantial behavioral context beyond the annotations: async execution, task_id polling, expected latency, cost severity, and retry caution. Annotations only declare it is not read-only and not idempotent; the description clarifies what that means in practice and does not contradict any annotation.

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 with no filler: the core capability, the async contract, and the cost warning are all included and front-loaded. Every sentence earns its place and no structured information is redundantly repeated.

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 an 11-parameter async generation tool, the description covers the full lifecycle: how to start, how to poll, how to make the server wait, and when to be cautious. The output schema handles return-value details, so nothing essential 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%, and the input schema already provides detailed, example-rich parameter descriptions including model names, aspect ratio fallbacks, and image_roles semantics. The tool description adds workflow-level context but no new per-parameter meaning, so the baseline of 3 is appropriate.

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

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

The description opens with a precise verb and resource: 'Generate a video from a text prompt.' It immediately distinguishes this tool from sibling image/music generation tools by mentioning reference images and image-to-video/first-last-frame use cases. The async task_id behavior is also front-loaded, so the agent knows what this tool produces.

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 poll with get_task(platform='video'), explains the 30-180 second latency, and offers wait_seconds as an alternative. It also warns that video generation is the most expensive capability and instructs confirming the prompt before spending on retries — clear operational 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?

Annotations already declare readOnlyHint=true, covering safety. The description adds the specific behavioral output—'remaining and used balance'—which goes beyond the annotation. It doesn't add extraneous details like pagination or rate limits, but for such a simple read operation, this is sufficient.

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

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

Two short sentences, front-loaded with the primary purpose. The first sentence states what it does; the second adds usage guidance. No wasted words.

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

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

Given a zero-parameter read-only tool with an output schema, the description fully covers the purpose and usage. Annotations handle safety, and the output schema defines return structure. No gaps remain.

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

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

There are zero parameters, so the baseline is 4. The schema has no parameters, and the description clarifies that the balance pertains to 'this CCAPI key,' implying authentication context rather than a parameter. No further parameter explanation is needed.

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's function: 'Report the remaining and used balance for this CCAPI key.' The verb 'Report' is specific, and the resource is unambiguous. This distinguishes it from sibling tools like chat_completion, get_task, and list_models.

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 explicit usage context: 'Useful before starting an expensive batch of generations, or to explain a quota failure to the user.' This tells the agent exactly when to invoke this tool, satisfying the 'explicit when' criterion.

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 the description adds valuable context such as the possible statuses (queued, in_progress, completed, failed), the requirement to pass identifiers exactly as returned, and the behavior of wait_seconds. This goes beyond the schema without contradicting 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 only three sentences, with the purpose front-loaded and no redundant information. Each sentence earns its place: purpose, identifier handling, and polling/waiting behavior.

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 output schema already documents return values, so the description needn't repeat them. It covers the source tools, the async=true prerequisite, status outcomes, and polling/waiting options, making it complete for a tool of this complexity.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds operational meaning by instructing the user to pass platform and task_id exactly as returned and explaining that wait_seconds causes the server to wait up to that duration, thereby enriching the parameter definitions.

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 identifies the tool as checking the status of an asynchronous generation task, explicitly naming the submitting tools (generate_video, generate_music, etc.). It uses a specific verb ('check') and resource ('status of an asynchronous generation task'), and is easily distinguishable from unrelated sibling tools.

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 explicitly states when to use this tool: for tasks submitted by the listed generation tools with async=true. It also gives clear polling guidance ('poll every few seconds until it settles') and explains the alternative of using wait_seconds for server-side waiting, which helps an agent decide on the best invocation strategy.

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?

Beyond the readOnlyHint annotation, the description discloses that availability depends on the key's group and changes over time, and that results include the capability category and MCP tool. This adds meaningful behavioral context not present in 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 only two sentences, front-loaded with the tool's action, and every sentence serves a purpose—no filler or unnecessary content.

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 does not need to detail return values, but it still explains the dynamic nature of availability, the key-based scoping, and the purpose of the returned fields. It also provides clear guidance on when to invoke the tool, making it complete for a listing operation.

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 covers 100% of parameters with detailed descriptions (search and category), so the baseline is 3. The tool description does not add any additional parameter semantics beyond what the schema already provides.

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 a clear resource ('the AI models this CCAPI key can actually call'), and it distinguishes itself from sibling tools by focusing on model discovery rather than generation or account tasks.

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 instructs when to use: 'Call this before generating anything if you are unsure a model name is valid' and includes a strong directive to avoid guessing model names. This provides clear usage context, even though it doesn't 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 indicate this is not read-only and not idempotent; the description adds useful behavioral context beyond them, including the fixed 2x upscale factor, hard input constraints, and the recommended fallback. It does not disclose cost, rate limits, or model-quality behavior, but the output schema covers the response shape.

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 core action and model, followed by essential constraints and a routing fallback. Every sentence earns its place with no filler or redundant explanation.

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 full parameter schema, output schema, and annotations covering mutation/idempotence, the description supplies the remaining decision-critical facts: the exact upscale multiplier, valid input dimensions, file size cap, and what to do when inputs exceed limits. Nothing essential 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 the schema already documents image, model_quality, and response_format in detail. The description restates input limits at the tool level but adds no new parameter-level meaning beyond 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?

Description states a specific verb and resource: increase resolution of an existing image 2x using ccapi-upscale-v1. It clearly distinguishes this from sibling tools like generate_image (creates new) and edit_image (edits) by focusing on resolution-only upscaling of an existing image.

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 names when the tool is appropriate (existing image, within 256x256 to 1024x1024, under 5 MB) and provides a concrete alternative for larger inputs: regenerate with a high-resolution model instead. This gives an agent actionable selection guidance.

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