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

With no annotations, the description carries the full behavioral burden, yet it discloses little: "latest" and "72h Corrections" hint at a temporal window but the term "Corrections" is never defined, and nothing is said about return shape, item count, or auth needs. It does not contradict anything, but it leaves most behavioral traits unstated.

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?

A single front-loaded sentence with no filler or repetition. It is efficiently sized, though its brevity borders on under-specification rather than ideal terseness.

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 two-parameter, zero-annotation, no-output-schema tool, the description is too thin. Undefined jargon ("72h Corrections") and unexplained enum options leave the agent guessing about what it will actually retrieve.

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

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

Schema coverage is 0%, so the description must compensate for both undocumented parameters and it largely fails. "ORG/TEAM" loosely maps to the team param, but the kind enum values (DAILY_BRIEF, ACCOMPLISHMENT_DIGEST, TEAM_ROLLUP) are never explained, and what "72h Corrections" means relative to kind is unclear.

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 ("Fetch") and resource ("Morning Briefs and 72h Corrections") with ORG/TEAM scope, so an agent can grasp the intent. It does not, however, distinguish itself from any of the many sibling bridge_* tools, leaving differentiation to name inference alone.

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?

There is no explicit when-to-use guidance and no named alternative. The word "latest" weakly implies a recency-based read, but the description never says when to pick this over bridge_context or the other siblings.

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

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

With no annotations, the description carries the full behavioral burden, and it discloses almost nothing: it mentions update but not which inputs cause a write, whether writes overwrite existing state, whether they are reversible, or what permissions are needed. The read/update split is the one useful hint, but it is not operationalized.

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?

It is a single front-loaded sentence with no filler, which is structurally fine. But the brevity comes at the cost of specification — the sentence is too compressed for a multi-mode tool with three undocumented 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?

A dual read/write tool with no annotations, no output schema, and 0% parameter documentation needs far more than one sentence. Nothing explains the mode-selection logic, the return shape, or how this differs from bridge_context_pull, so an agent cannot confidently 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?

Schema description coverage is 0% and none of the three parameters (topic, write_body, write_topic) are explained in the description. Only the write_ prefix and the word "update" weakly imply a read-mode topic versus write-mode body/topic, leaving the caller to infer the contract entirely from parameter names.

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 verb pair ("read or update") and enumerates four resource areas (status, branch binding, claims, scratchpad), so the domain is identifiable. However, it does not distinguish this tool from the sibling bridge_context_pull, and the "read or update" duality leaves the actual operation ambiguous rather than specific.

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?

There is no guidance on when to choose this tool over bridge_context_pull or the other bridge_* siblings, and no indication of prerequisites or preconditions. An agent has to guess whether this is the general entry point or a write-specific variant.

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?

No annotations are supplied, so the description carries the full burden. 'Pull' implies a read operation, but nothing states permissions, whether results are truncated or paginated, ordering, or how the 72h-corrections subset relates to the 7-day window; for a tool with three scoping parameters this leaves significant behavioral gaps.

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?

A single front-loaded sentence with zero filler; the colon-list efficiently enumerates payload contents. It is dense with domain jargon ('seams', 'leases') but that is a clarity tradeoff rather than verbosity.

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 three undocumented parameters, no annotations, and no output schema, the description should explain scoping and return shape but does not. An agent can guess it retrieves recent context but cannot confidently construct a call or predict the result.

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 schema gives only names and types. The description's '7-day' hints at the days parameter's default, but it says nothing about what repo and team scope (single value? filter on repo vs org?), nor whether days overrides the 7-day window.

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?

Names a specific verb ('Pull') and resource ('7-day org context') and enumerates the content types returned (tasks, quotes, citations, decisions, leases, seams, briefs, corrections). However, it never distinguishes itself from the sibling bridge_context, which by name sounds like the same retrieval, so an agent cannot tell which to pick from the description alone.

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?

There is no when-to-use guidance, no when-not-to-use, and no mention of the obvious alternatives (bridge_context, bridge_brief_latest, bridge_seam, bridge_fact). Usage is only implied by the word 'Pull'.

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?

No annotations are supplied, so the description carries the full behavioral burden for a 14-parameter, five-action tool, and it discloses almost nothing. It does not say whether 'propose' or 'resolve' mutate state, who may resolve, whether a blocking decision halts work, or what a listed decision looks like. Only the blocking/advisory distinction conveys any behavior at all.

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 definition is a single compact sentence with no filler or repetition, and the verb list is front-loaded. Its brevity is efficient rather than padded, though it tips into under-specification for a tool of this breadth.

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 14 optional parameters, five distinct actions, no annotations, no output schema, and zero schema descriptions, this description is far too thin for the tool's complexity. An agent has no way to know which parameters pair with which action, which actions are writes, or what any action returns.

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% across 14 parameters, so the description must compensate and it largely does not. It clarifies only that `to` holds recipients and that `mode` is blocking/advisory; the remaining twelve parameters (option, options, criteria, criterion, score, urgency, decision_id, task_id, context, rationale, action) get no mapping to which action consumes them.

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 the resource (1-Click Decisions) and enumerates five verbs (list, propose, score, resolve, check), so an agent knows the general domain. However, '1-Click Decisions' is unexplained jargon and the five actions are lumped into one clause with no indication of what each does, so the tool's actual purpose per invocation stays fuzzy.

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?

There is no when-to-use guidance, no preconditions, and no reference to any of the seven sibling tools (bridge_context, bridge_job, bridge_fact, etc.) that might be alternatives. The parenthetical '(blocking/advisory)' hints that decisions gate progress but stops short of telling the agent when to pick this tool.

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

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

With no annotations, the description carries the full behavioral burden. It discloses the <=280 character limit and that this is an ingest/write-like operation, but says nothing about persistence, validation, duplicate handling, permissions, error behavior, or what the tool returns.

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?

A single front-loaded sentence with no filler. It is appropriately concise, though the terseness leaves important semantics unexplained rather than being maximally useful.

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 four-parameter mutation-like tool with zero schema description coverage and no annotations or output schema, the description is too thin. An agent cannot confidently determine how to populate kind, task_id, or confidence, nor what happens after ingestion.

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 all four parameters. It only clarifies the bounded length of 'statement'; it adds nothing about 'kind' values, 'task_id' semantics, or the meaning and effect of 'confidence'.

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 gives a specific verb and resource: 'Ingest' a 'verification fact' for 'task reconciliation', plus a length bound. It is clear enough to distinguish from context/seam/decide siblings, though it does not explicitly name which sibling to use instead.

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 phrase 'for task reconciliation' implies the use case, but there is no explicit when-to-use or when-not-to-use guidance and no reference to alternative sibling tools. The agent must infer selection from context.

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?

No annotations are supplied, so the description carries the full behavioral burden, yet it discloses nothing about side effects. Three of the five verbs (dispatch, claim, complete) are clearly mutations, but the description never says what state changes, whether claims are exclusive/locking, what happens on conflict, or whether any action is idempotent. It only hints at mutability through verb choice.

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?

It is a single front-loaded sentence with no filler, which is structurally clean. But the brevity comes at the cost of under-specification rather than efficiency — the compact form does not earn its place given how much is left unsaid.

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 five actions, seven undocumented parameters, no annotations, and no output schema, one sentence is wholly inadequate. Nothing tells an agent the valid action/parameter combinations, the workflow ordering, or what a successful call returns.

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% across 7 parameters, and the description adds no parameter meaning whatsoever. It does not map job_id, task_id, pr_url, commit_sha, globs, or notes to any of the five actions, leaving the agent to infer which fields are required for dispatch versus claim versus complete — a critical gap for a multi-action 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 names five distinct verbs (list, dispatch, claim, complete, compile) applied to a resource (capsules/agent jobs), so the domain is discernible. However, 'capsules' is unexplained jargon and the sentence lumps five very different operations into one clause, leaving the actual purpose of the tool ambiguous. It does not overlap with any sibling (bridge_context, bridge_decide, etc.), but that differentiation appears incidental rather than stated.

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?

There is no guidance on when to use this tool versus any sibling, nor any indication of which of the five actions an agent should pick for a given intent. The order of operations implied by 'dispatch, claim, complete' (a workflow) is never explained, so an agent must guess the job lifecycle.

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

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

With no annotations supplied, the description carries the full behavioral burden, and it discloses almost nothing. It does not say that claim is a mutating, conflict-prone operation, whether a held lease blocks the claim, what happens on expiry, whether release requires the original owner, or whether any of this needs authorization. Only the bare existence of leases is conveyed.

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?

One sentence, front-loaded with the verbs, with no filler or repetition. However, the brevity is achieved through under-specification rather than economy — the same sentence could have carried the claim-before-edit rule without becoming bloated.

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?

This is a stateful, mutating coordination tool with six undocumented parameters, no annotations, and no output schema. The description gives no sense of the lifecycle (claim to release), failure modes, or what a list result contains, so an agent would have to guess at every non-trivial call.

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% across six parameters, so the description must compensate and does not. It never explains `globs` (what path patterns are covered by a lease), `ttl` (format or expiry behavior), `lease_id` (required for release?), `reason`, or `all` (scoping list to all worktrees?). Only the `action` enum values are echoed in prose.

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 three concrete verbs (claim, release, list) applied to a specific resource (cross-worktree file scope leases), and the verb set maps exactly onto the `action` enum, so an agent can match intent to tool. It loses a point because 'file scope lease' is domain jargon with no gloss, and it draws no boundary against the sibling bridge_* tools, leaving the agent to infer that this is the only concurrency-control tool in the family.

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?

There is no when-to-use guidance at all: nothing says an agent should claim before editing shared files, release when done, or list to discover existing holders. The three modes are enumerated but the conditions that select among them are left entirely to inference, and there is no mention of what to do when a claim is refused.

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

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

With no annotations and no output schema, the description carries the full behavioral burden. It signals that retract and edit are mutating actions but does not disclose permissions, reversibility, side effects, required fields by action, defaults, or response behavior.

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 definition is a single front-loaded sentence with no filler, and the action list is easy to scan. Its brevity is appropriate structurally, though that concision contributes to gaps assessed in other dimensions.

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?

This is a five-parameter CRUD-style tool with no annotations, no parameter descriptions, and no output schema. The one-sentence description does not explain per-action semantics, required fields, or return behavior, leaving too much for an agent to infer before 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?

Schema description coverage is 0%, so the description would need to compensate. It repeats the enum values already present in the schema for tag and action, but explains nothing about seam_id, summary, task_id, conditional parameter requirements, or default behavior.

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 specific verbs (log, edit, retract, list) and names the resource as seams with four enumerated seam types. The purpose is clear, but it does not differentiate this tool from siblings such as bridge_decide or bridge_fact, and the term 'seams' is not independently defined.

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 enumerates possible actions but gives no guidance on when to choose this tool over related siblings, nor when to use log versus edit or retract. There are no prerequisites, exclusions, or contextual triggers for action selection.

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