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

Annotations already indicate this is not read-only and not destructive, but the description adds non-obvious behavioral limits: only pending clarifications can be answered, and permissions/sandbox changes are out of scope. This is valuable context beyond the annotations, though it does not describe side effects or outcome details.

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 with no filler: the first states the purpose, the second states a key limitation. Both sentences earn their place, and the most important information is front-loaded.

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 core operation and an important limitation, but given the nested `answers` schema, absent output schema, and no parameter descriptions, it leaves key workflow details unclear: how to construct the answers payload, where the IDs come from, and what a successful response looks like. Adequate but with clear gaps.

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

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

Schema description coverage is 0%, so the description must compensate. It names receipt and question IDs as identifiers, which adds some meaning, but it does not explain the nested `answers` object structure, its key semantics, or its relationship to the top-level `questionId`. This is a significant gap for a three-parameter tool with nested objects.

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

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

The description states a specific action ('Answer') applied to a specific resource ('a pending Codex clarification') and names the identifying inputs ('receipt and question IDs'). This clearly distinguishes bridge_answer from siblings like bridge_submit and bridge_receipt, and it is not a tautology.

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 clearly identifies the intended context: answering pending clarifications identified by receipt and question IDs. It also gives explicit exclusions ('Cannot approve permissions or widen sandbox'), but it does not name an alternative tool for those excluded actions, so it falls short of full routing 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?

Beyond the annotations (readOnlyHint=false, destructiveHint=false), the description adds meaningful behavioral context: writes are versioned and non-overwriting, and creation has no side effects on skills or routines. This clarifies the tool's safety profile and side-effect scope. It does not mention potential error conditions or what happens on duplicate writes, but it goes beyond the minimal annotation coverage.

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 fluff. The core purpose is front-loaded in the first sentence, and the second adds a critical side-effect clarification. Every word contributes to the agent's understanding.

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

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

For a 4-parameter tool with no output schema and sparse annotations, the description is incomplete. It omits definitions for 'name', 'project', and 'text', does not describe return values or error behavior (e.g., what happens if the artifact exists), and gives no context on how these parameters relate to other bridge tools. An agent would need additional information to call it correctly in all cases.

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

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

The schema has 0% description coverage, so the description must compensate. However, it only clarifies the 'action' parameter (write/read) through the enum and the phrase 'without overwriting'. It does not explain the purpose of 'name', 'project', or 'text', leaving the agent to guess these are artifact identifiers and content. The description adds little value for parameter meaning.

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 verb('Create' or 'read') and a resource ('versioned UTF-8 artifact'), and adds a distinctive property ('without overwriting') that differentiates it from ordinary writes. It also explicitly says what it does not do ('does not install skills or schedule routines'), which helps set it apart from sibling tools like bridge_submit or bridge_steer without needing their schemas.

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

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

The description provides a negative usage hint: artifact creation does not install skills or schedule routines, implying those actions belong to other tools. However, it does not explicitly name alternatives or state concrete conditions for when to use this tool versus a sibling. The guidance is present but implicit, leaving the agent to infer the full decision.

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 mark the tool as non-read-only and non-destructive, so the bar is lower. The description adds useful behavioral details beyond that: cancellation is a request requiring receipt polling, and it does not revert file changes. This gives the agent a realistic model of the tool's behavior 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?

Three short sentences, each carrying distinct information: the action, the verification workflow, and the non-undo limitation. The most important procedural detail is front-loaded, and there is no redundant filler.

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

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

For a tool with one required parameter and no output schema, the description captures the essential workflow and limitation. It could explain how the receiptId is obtained or what the cancellation receipt looks like, but the combination of annotations and concise description makes it sufficiently complete for a simple cancel 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 schema has 0% description coverage, and the description does not explain the receiptId parameter or where it comes from. 'Poll receipt to verify' hints at the role of a receipt, but it never explicitly ties receiptId to the cancellation request or to a prior bridge_submit call, so the agent must infer the parameter's meaning.

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

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

The description states a specific action ('Request cancellation'), a specific target ('bridge-owned running job'), and adds a key distinction with 'Does not undo file changes.' It does not explicitly name sibling tools, but the resource and action are clear enough to separate it from bridge_submit or bridge_steer.

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

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

The description gives clear operational context: cancellation is requested, not performed instantly, and the agent should poll a receipt to verify. It also warns that file changes are not undone, which helps the agent avoid using this tool as a rollback. It stops short of explicitly naming alternatives or when-not-to-use conditions, but the guidance is still actionable.

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 readOnlyHint=true and destructiveHint=false, and the description adds valuable specificity: it does not authenticate and does not change settings, and it is scoped to local information. This goes beyond the annotation flags by clarifying authentication behavior and local scope, which helps an agent know what side effects to expect (none). 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.

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

The description is two sentences with no filler. The primary purpose is front-loaded in the first sentence, and the negative scope in the second adds value without redundancy. Every word contributes to understanding.

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

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

For a simple, parameterless, read-only diagnostic tool, the description covers what it reads (local capabilities and versions) and what it excludes (auth and settings). There is no output schema, but the description adequately tells an agent what information to expect. Given the annotations and zero parameters, 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?

The tool has zero parameters, so the schema has no properties to describe. The description correctly focuses on behavior rather than parameters. This matches the baseline for a zero-parameter tool, where no parameter-level meaning 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 uses a specific verb and resource: it 'Read[s] local bridge capabilities and Codex/Claude Code versions,' which clearly defines the action and object. It also explicitly states what it does not do (authenticate or change settings), further distinguishing it from sibling tools that likely perform mutations or other reads. Verdict: clearly identifiable and differentiated.

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

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

The description implies a diagnostic/preflight use case: checking local capabilities and versions, likely before using other bridge tools. It explicitly notes it is not for authentication or settings changes, giving a when-not, but it does not name alternative tools or provide explicit conditions for selecting it over siblings. This is clear context with an exclusion, but not fully explicit alternatives.

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 one useful behavioral detail about Codex Desktop registration versus Claude Code local folder context. However, it omits the 'register' and 'inspect' actions, doesn't disclose side effects or prerequisites, and the annotations only say the operation isn't read-only without adding depth.

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, and the primary actions are front-loaded. It is concise, though the brevity contributes to missing information rather than being a model of efficiency.

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 five parameters, no output schema, and only weak annotations, this description is not complete enough for an agent to call the tool correctly. It covers only a subset of the action enum and gives no information about return values, path semantics, or when 'create' vs 'register' is appropriate.

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

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

Schema description coverage is 0%, so the description must compensate for parameter meaning. It explains provider behavior somewhat ('Codex can register with Desktop; Claude Code uses the folder as local CLI project context'), which maps loosely to the 'provider' and 'project' parameters, but 'name', 'action', and 'parent' are left undocumented.

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 mentions specific actions ('List aliases', 'create an allowed directory') but the resource and intended scope are vague ('aliases', 'allowed directory'). It doesn't distinguish the tool from sibling bridge tools or account for the 'register'/'inspect' actions present in the schema.

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

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

No guidance is given on when to use bridge_projects instead of related tools. The only contextual note differentiates Codex and Claude Code behavior, but it doesn't state when this tool should or shouldn't be selected.

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, which the description aligns with by saying 'Read'. It adds meaningful behavioral nuance by explaining that 'completed' only means the agent turn finished, not independent verification, and notes 'bounded output' hinting at size limits. This goes beyond the annotations and adds value.

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 concise and well-structured: one sentence for the core action and one for state interpretation. It front-loads the primary purpose and delivers critical context efficiently without redundancy.

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

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

For a simple read tool with two parameters and no output schema, the description covers the core behavior and state semantics. However, it omits details about the return format and the effect of 'includeOutput', which is a gap given the lack of an output schema. The 'bounded output' mention is vague, leaving the agent with some uncertainty about what to expect.

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

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

Schema description coverage is 0%, so the description must compensate, but it doesn't explain the 'receiptId' parameter or the 'includeOutput' flag. While 'receiptId' is inferable from the name, 'includeOutput' is not mentioned at all, leaving the agent to guess its effect. The description fails to add meaning beyond the schema's bare type 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 the tool reads a durable delivery receipt, including hashes, state, and bounded output. It uses a specific verb and resource, and the meaning is unambiguous. However, it doesn't explicitly differentiate from sibling tools like bridge_sessions or bridge_answer, relying on the name for distinction.

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 guidance by interpreting the 'uncertain' and 'completed' states, instructing the agent to inspect the session before retrying when uncertain and clarifying that 'completed' does not imply verification. This helps decide next steps, though it doesn't explicitly say when to use this tool versus alternatives.

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 mark the tool as read-write and non-destructive; the description adds that it confirms stored metadata and that desktop rendering is separate, which is useful for setting expectations. It does not disclose permissions, failure modes, or what 'allowed' means, so coverage remains partial.

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

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

Three sentences, front-loaded with the primary actions; the behavioral note about desktop rendering is relevant but could be clearer. No major redundancy.

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 does not explain parameter combinations, defaults, or edge cases such as whether position applies when unpinning, whether title and pin can be set together, or what 'registered project' means. Without an output schema, more detail is needed for reliable invocation.

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

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

With 0% schema description coverage, the description must carry parameter meaning. It maps 'Rename' to title, 'move into/out of Pinned' to pin, and 'First position' to position, but never explicitly names parameters and leaves 'assignProject' ambiguous (boolean flag vs action). The mappings are inferable but not stated.

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 explicitly names three concrete operations — rename, assignProject, and pin/unpin — on a Codex session, making the tool's purpose clear. However, it does not explicitly differentiate from siblings like bridge_sessions or bridge_steer, relying on the agent to infer that this is the management tool.

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

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

The description implies when to use the tool (whenever a session needs renaming, project assignment, or pinning), but provides no explicit guidance about when to prefer a sibling tool or when not to use this one. No alternatives or exclusions are mentioned.

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

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

Annotations already declare this tool read-only and non-destructive; the description adds meaningful behavioral context beyond that: sessions are limited to 'allowed' ones, Claude Desktop sessions may not be resumable, and returned text is untrusted. It does not contradict the annotations, but it omits some behaviors around cursor pagination and the includeQueue/includeOutput flags.

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 short sentences front-load the core purpose and then add only high-value caveats. There is no filler or restatement of the schema.

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

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

With no output schema and zero parameter descriptions in the schema, the description must carry more load for an 8-parameter tool. It explains the core read/find behavior and trust caveats but leaves pagination, queue/output flags, project/thread semantics, and return shape unexplained.

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

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

Schema description coverage is 0%, so the description must compensate, but it only clarifies provider selection and the find/read action. The remaining six parameters (query, cursor, project, threadId, includeQueue, includeOutput) receive no semantic explanation in either the schema or the description.

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 operation as finding/reading Codex or local Claude Code sessions, specifying the resource and provider scope. It does not explicitly contrast with bridge_session_manage or other siblings, so it misses the explicit differentiation required for a 5.

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

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

The description gives useful context for provider selection and warns that Claude Desktop sessions are not CLI-resumable, but it never states when to prefer bridge_sessions over sibling tools such as bridge_session_manage. Usage guidance remains 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.

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

Annotations already mark the tool as readOnlyHint=false and destructiveHint=true, so the description does not need to restate those. It adds value by disclosing the requirement for 'explicit acceptance of the Desktop policy' and the caveat that it 'Never claims completion from queue acceptance', which are behavioral nuances beyond the annotations. 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?

Two concise sentences with no wasted words. The primary action is front-loaded, and the policy requirement and completion caveat are placed secondarily. Each clause contributes essential information, making it efficient and easy to scan.

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 no output schema and a moderately complex tool, the description covers the core behavior, prerequisites, and a key caveat. It does not explain return values or error conditions, but for a recover/adopt operation these may be less critical. The description is sufficiently complete for an agent to understand when and how to invoke it.

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

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

With schema description coverage at 0%, the description must compensate. It mentions queuedSubmissionId and requestId as identifiers and acceptDesktopPolicy as the policy flag, giving some meaning. However, it omits threadId and receiptId entirely, leaving those ambiguous. The partial coverage is helpful but not complete for a five-parameter tool.

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

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

The description states a clear purpose: 'Recover an exact desktop queue receipt or adopt an existing CLI queue item' with specific verbs and resources. It distinguishes from sibling tools like bridge_submit by explicitly noting 'without enqueueing again', and from bridge_receipt by covering recovery and adoption. The scope is precise and actionable.

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

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

The description provides clear context on when to use this tool (recovering a receipt or adopting a CLI queue item) and a prerequisite (acceptance of Desktop policy). However, it does not explicitly name alternative tools or state when not to use it, leaving some room for inference rather than direct 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 signal readOnlyHint=false, openWorldHint=true, and destructiveHint=true, so the safety profile is available. The description adds useful behavioral context beyond those annotations: asynchronous execution, whole UTF-8 prompt and text-artifact handling, a stable requestId, and a durable receipt. It does not elaborate on destructive side effects, but the annotation covers that signal 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?

The description is short and front-loaded, with the primary action stated first. Every phrase adds some information, but the telegraphic fragments ('Choose provider. Whole UTF-8 prompt...') make it read less smoothly than a well-structured sentence while still remaining efficient.

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

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

Given 10 parameters, a destructiveHint annotation, and no output schema, the description is under-specified. It explains the async submission pattern but omits critical call context such as how project relates to bridge_projects, the meaning of onBusy and delivery, the distinction between prompt and promptFile, and the behavior of acceptDesktopPolicy. An agent has enough to invoke it at a basic level but not enough to use it correctly across realistic scenarios.

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

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

Schema description coverage is 0%, so the description must compensate for explaining parameters. It only vaguely maps 'Choose provider' to provider, 'whole UTF-8 prompt and text artifacts' to prompt/artifacts, and 'stable requestId' to requestId. Six other parameters (project, onBusy, delivery, threadId, promptFile, acceptDesktopPolicy) receive no semantic explanation in either the description or schema, leaving a significant gap.

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 operation: starting or continuing a Codex or Claude Code CLI session asynchronously. It also distinguishes its role from the sibling receipt tool by instructing 'Poll bridge_receipt.' It is specific enough that an agent can understand the tool's core function without inspecting the schema, though it does not explicitly contrast with steering or cancellation siblings.

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

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

The only usage guidance is 'Poll bridge_receipt,' which implies the expected follow-up pattern after submission. However, there is no explicit statement about when to use bridge_submit versus alternatives like bridge_steer or bridge_session_manage, nor any mention of conditions such as onBusy or delivery. Usage context is implied rather than fully specified.

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