Server Quality Checklist

Tool Scores

• bridge_inboxA
  3.5/5.0
  Behavior3/5

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

  With no annotations, the description carries the burden of behavioral disclosure. It reveals a non-obvious behavior (acknowledged messages hidden by default), which is useful. However, it does not mention return format, pagination, or whether this is a read-only operation beyond the word 'List', so coverage is partial.

  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?

  Two concise sentences deliver the core purpose and a key behavioral detail with no filler. The structure is clear and front-loaded, making it easy for an agent to parse quickly.

  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 two-parameter read tool with full schema coverage, the description is largely complete. It covers the main purpose and the behavior of the boolean flag, though it omits details like return format because there is no output schema. Given the low complexity, this is adequate.

  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 the baseline is 3. The description adds value by explaining that acknowledged messages are hidden by default, which directly illuminates the purpose of the includeAcknowledged parameter and informs when to set it to true. This goes beyond what the schema states.

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

  Purpose4/5

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

  The description clearly states the action ('List messages') and the resource ('addressed to an agent'), making the tool's purpose obvious. It distinguishes from siblings like bridge_send or bridge_ack by focusing on reading rather than sending or acknowledging, though it does not explicitly name alternatives.

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

  Usage Guidelines2/5

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

  The description gives context about default behavior ('Acknowledged messages are hidden by default') but provides no guidance on when to use this tool versus siblings such as bridge_wait or bridge_thread. It does not mention exclusions or alternative scenarios, leaving the agent to infer usage from the name and sibling list.

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

• bridge_agentsA
  3.6/5.0
  Behavior2/5

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

  With no annotations, the description carries the full burden of behavioral disclosure. It only states the action and does not mention read-only behavior, return format, permissions, or any side effects, which is a significant gap for a tool with no 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.

  Conciseness5/5

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

  The description is a single, well-structured sentence that is front-loaded with the action and resource. It is concise and every word contributes meaning without redundancy or wasted text.

  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?

  Given the simplicity of the tool (0 params, no output schema), the description provides enough context to understand what the tool does and what it returns (list of agents with capabilities). However, it lacks any note about errors, authentication, or output formatting, which are not critical for a simple list but would round out completeness.

  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 tool has zero parameters and schema coverage is 100%, so the baseline is 4. The description adds no parameter details, but none are needed. It appropriately omits param info when there are no params.

  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 action (List) and the resource (all registered agents), plus what is included (their capabilities). It distinguishes itself from sibling tools, none of which are list operations, making it clear when to choose this tool.

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

  Usage Guidelines2/5

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

  No guidance is provided on when to use this tool versus alternatives. There is no mention of prerequisites, context, or when to prefer other sibling tools, leaving the agent to infer usage from the name alone.

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

• bridge_registerA
  3.7/5.0
  Behavior2/5

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

  No annotations are provided, so the description must carry the full behavioral disclosure burden. It states the outcome (others can discover the agent), but does not disclose whether re-registration overwrites or merges capabilities, whether authentication is required, persistence/lifetime, or what the response contains.

  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 a single, front-loaded sentence with no filler. It communicates both the action and the purpose without wasting words.

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

  Completeness3/5

  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 fully documented parameters, but there is no output schema or behavioral guidance on registration duplication, update semantics, or return values. The description is minimally adequate but leaves operational edge cases unstated.

  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?

  Schema description coverage is 100%, with clear examples for 'agent' and 'capabilities'. The tool description itself adds no extra parameter semantics beyond echoing the schema, 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 uses a specific verb ('announce') and resource ('an agent and its capabilities'), clearly conveying the registration action and its purpose. It is distinct from sibling tools like bridge_send (messaging) or bridge_agents (listing/discovery).

  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 'so others can discover it' establishes the intended context (making an agent discoverable). It does not explicitly exclude alternatives or mention when not to use it, but the context is clear enough for a simple registration tool.

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

• bridge_sendA
  3.7/5.0
  Behavior2/5

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

  No annotations are provided, so the description carries the full burden. It only mentions the broadcast feature and does not disclose delivery semantics, idempotency behavior, error conditions, or any side effects. The agent is left uninformed about what happens after the message is sent.

  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 two short sentences, front-loaded with the main action and a key usage hint. Every word earns its place, with no fluff or repetition.

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

  Completeness3/5

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

  Given the simple tool and full schema coverage, the description is adequate for basic use. However, there is no output schema or annotations, and the description does not mention prerequisites (e.g., recipient must be registered) or what the return value looks like, leaving some gaps for an agent invoking it.

  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 covers 100% of parameters with descriptions, so the baseline is 3. The description adds no new meaning; its mention of '*' for broadcast is redundant with the schema's 'to' description. It does not enrich any parameter understanding.

  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's function with a specific verb and resource: 'Deliver a message to another agent.' It also includes the broadcast usage ('*'), which distinguishes it from sibling tools like bridge_inbox (receive) and bridge_ack (acknowledge).

  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 on when to use the tool: to send a message to a specific agent or broadcast to all. It does not explicitly name alternatives or exclusions, but the purpose is self-evident among the sibling tools. The broadcast instruction adds a concrete usage guideline.

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

• bridge_threadA
  3.8/5.0
  Behavior3/5

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

  With no annotations, the description must carry the transparency burden. It conveys read-only behavior via 'Return' and discloses ordering ('oldest first'), but does not explicitly state safety profile, authorization needs, or error behavior. This is adequate but not rich.

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

  Conciseness5/5

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

  A single, information-dense sentence that is front-loaded and contains zero unnecessary words. It efficiently states the purpose and key behavioral detail (oldest first).

  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 read tool with one parameter and no output schema, the description adequately explains the scope ('full history') and ordering. It lacks explicit mention of return format or edge cases, but is complete enough for a well-named, low-complexity tool.

  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 already provides 100% coverage for the single parameter threadId with a clear description ('Thread identifier to fetch'). The description adds no additional parameter semantics, so baseline 3 is appropriate.

  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 ('Return') and clearly identifies the resource ('full history of a conversation thread') with ordering detail ('oldest first'). It distinguishes itself from sibling tools like bridge_inbox by focusing specifically on thread history.

  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 when full thread history is needed, but provides no explicit context about when to prefer this over alternatives like bridge_inbox, nor any exclusions or prerequisites.

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

• bridge_continue_codexA
  4/5.0
  Behavior3/5

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

  With no annotations, the description carries the full transparency burden. It does disclose key behaviors: resuming a saved session/worktree and continuing until a terminal state (completed/blocked/failed/round limit). However, it doesn't disclose side effects on the worktree, whether the tool is idempotent, or what happens exactly on each terminal condition – leaving important operational ambiguity.

  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 two sentences, with the main action in the first sentence and usage/termination criteria in the second. Every clause adds needed context; no filler or redundancy. It is front-loaded and easy to parse quickly.

  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?

  Given the tool's role in a multi-step orchestration and the absence of an output schema, the description adequately covers invocation timing, the continuation loop, and stopping conditions. It could be more complete by explicitly stating what the tool returns or how to interpret the terminal states, but the 'continue until' phrasing implies a status is available. Overall, sufficient for correct invocation.

  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?

  Schema description coverage is 100%, so baseline is 3. The description adds a small contextual link by stating the answer should follow 'the question returned by bridge_orchestrate_codex', but it doesn't elaborate on parameter formats or constraints beyond what the schema already provides. The schema descriptions are clear and self-sufficient.

  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's purpose: 'Resume the exact saved Codex session and worktree' – a specific verb and resource. It also differentiates from sibling tools by referencing 'the question returned by bridge_orchestrate_codex' and the 'same Claude turn', making it distinct from related orchestration and status tools.

  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 explicit when-to-use guidance: 'Call this automatically in the same Claude turn after answering the question returned by bridge_orchestrate_codex.' It also defines the continuation behavior up to 'completed, blocked, failed, or the round limit'. However, it lacks explicit when-not-to-use examples or alternatives, so it doesn't fully meet the 5-criterion.

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

• bridge_orchestration_statusA
  4/5.0
  Behavior3/5

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

  With no annotations, the description must fully disclose behavior. It states the tool retrieves state and audit events, implying a read-only action, but it does not explicitly confirm no side effects or describe the exact return structure. This is moderate transparency.

  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 a single, focused sentence with no redundancy. It front-loads the primary action and delivers the key information efficiently.

  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 no output schema, this description covers the core purpose and key usage scenarios, naming the two deliverables (state and audit events). It lacks explicit detail on response structure or potential errors, but is otherwise sufficient.

  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 already provides a 100% description for the sole parameter runId ('Orchestration run ID'). The tool description adds minimal semantic value beyond this, as the connection between runId and the retrieved state is implicitly obvious.

  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 ('Recover') and identifies a clear resource ('durable run state and its audit events'). It distinguishes this inspection tool from execution-focused siblings like bridge_orchestrate_codex and bridge_continue_codex.

  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 usage context ('after a restart or when checking progress'), indicating when to use this tool. However, it does not explicitly mention when not to use it or name alternative tools, stopping short of full exclusions.

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

• bridge_orchestrate_codexA
  4.1/5.0
  Behavior4/5

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

  With no annotations provided, the description carries the full disclosure burden. It proactively states key constraints ('never grants permission to commit, push, deploy...') and behavioral details (isolated worktree, waiting for result, separate chips). It doesn't cover every side effect but provides strong 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 three sentences, front-loaded with the core action, then conditionals, then safety. Every sentence adds value with no redundancy or filler.

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

  Completeness3/5

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

  For a complex orchestration tool with 6 parameters and no output schema, the description covers purpose, safety, and workflow. However, it omits the structure of the 'result' it waits for and any timeout/error behavior, which is a notable gap given no output schema exists.

  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?

  Schema description coverage is 100% because all six parameters have descriptions in the input schema, so the baseline is 3. The description adds minimal additional parameter semantics, though it aligns 'isolated git worktree' with the useWorktree parameter and implies maxRounds via the turn concept.

  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 'Start a saved Codex worker session in an isolated git worktree and wait for its structured result,' which is a specific verb+resource. It also distinguishes from the sibling tool bridge_continue_codex by explicitly naming it as a follow-up, and notes independent calls create separate Codex chips.

  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 clear conditional guidance: 'If status is waiting_for_fable, the active Claude/Fable coordinator should answer the returned question and immediately call bridge_continue_codex.' It also implies this tool is the entry point. However, it doesn't explicitly state when not to use it or compare with other siblings like bridge_orchestration_status.

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

• bridge_ackA
  4.2/5.0
  Behavior4/5

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

  With no annotations provided, the description carries the burden of behavioral disclosure. It clearly states the effect: messages become read and leave the unread inbox. This is sufficient for a simple state-change operation, though it doesn't mention potential edge cases or idempotency.

  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 a single, focused sentence that immediately conveys the purpose without any filler. It is front-loaded and every word earns its place.

  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 tool with only two parameters and no output schema, the description is almost complete. It explains the core action and outcome. It could optionally mention whether the operation is idempotent or reversible, but for a straightforward ack operation, this is adequate.

  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 both parameters ('Message ids to acknowledge' for ids, 'Agent acknowledging the messages' for agent) with 100% coverage. The description doesn't add any parameter semantics beyond the schema, 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.

  Purpose5/5

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

  The description clearly states the tool's function: 'Mark messages as read for an agent so they drop out of the unread inbox.' It uses a specific verb ('mark as read') and resource ('messages'), and the consequence ('drop out of unread inbox') distinguishes it from sibling tools like bridge_send or bridge_inbox.

  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: it's used to acknowledge messages for an agent, implying after reading them from the unread inbox. It doesn't explicitly list alternatives or exclusions, but the purpose is sharp enough to infer when to use it.

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

• bridge_waitA
  4.4/5.0
  Behavior4/5

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

  With no annotations, the description carries the burden of behavioral disclosure. It discloses that the tool blocks, returns as soon as the other agent sends, and cannot wake a chat whose turn has ended. It misses some details such as timeout behavior or return value shape, but the description meaningfully explains the push-style handoff behavior.

  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: the first sentence captures the core purpose, and subsequent sentences add usage, recurrence, mechanism, and a critical limitation. Every sentence contributes meaningful guidance without repetition or filler.

  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 blocking wait tool with no output schema, the description sufficiently explains when to call, how to chain calls, and the key constraint about not waking ended turns. It could elaborate on timeout behavior or what exactly is returned, but schema covers the timeout default and the 'returned message' is implied, leaving the description reasonably complete.

  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?

  All parameters have descriptive schema entries, so the baseline is 3. The description adds no parameter-specific details beyond schema, but it does imply relevance via terms like 'matching bridge message' and 'coordination thread.' Since schema coverage is 100%, the description's lack of additional param explanation is acceptable.

  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's function: 'Keep this agent turn alive until a matching bridge message arrives.' It uses a specific verb (keep/block) and resource (bridge message), and explicitly contrasts itself with reading the inbox later, distinguishing it from sibling tools like bridge_inbox.

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

  Usage Guidelines5/5

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

  Provides explicit when-to-use guidance: 'Use this instead of ending the turn and later asking the user to tell you to read the inbox.' It also instructs to call bridge_wait again automatically if the coordination thread is active, and warns to enter it before going idle. This clearly frames the tool's intended role among alternatives.

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