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

With no annotations, the description carries the full burden and does so: atomicity guarantee, lease duration, renewal requirement, expiry/reclaim semantics, the file_conflict_warnings return signal, and an extensive security model distinguishing untrusted board DATA from human authority and grants. This is far beyond what structured fields provide.

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 core lease behavior is front-loaded in the first sentences, and the security paragraph, while long, is non-redundant and operationally necessary. The description is dense but each sentence contributes; the security block could be tightened slightly.

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 stateful lease tool with no output schema, it covers acquisition, renewal, expiry, conflict signaling, and the trust boundary. What is missing is error/failure behavior (e.g., what happens when a claim loses the race or a lease is still held by another session) and explicit parameter documentation.

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 task_id and session_id. It introduces the session/lease concept that gives session_id meaning, but never directly documents either parameter's format, default (session_id defaults to null), or required/optional status, so compensation is partial.

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+resource+constraint: 'Claim a task lease before editing its files (atomic: only one session wins).' This is clearly distinct from the sibling set (release, update, post, register) and an agent can recognize it as the exclusive-ownership step before file edits.

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?

Explains when to call (before editing files), what a repeat call does (renews while authorization active), and the expiry/reclaim conditions (30-minute default, anyone may reclaim expired leases). It does not explicitly name sibling alternatives like board_release_task, so it stops short of full when-not/alternative routing.

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 burden, and it delivers substantial behavioral context: what is returned, the open-by-default behavior, include_tasks adding lease/authorization status, and a detailed security model about untrusted board data and human-grant authority. It omits pagination, ordering, and rate-limit 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?

Purpose is front-loaded well, but roughly half the text is a lengthy, partly repetitive security block (grants, finalization, authority) that could be tightened. For a simple list call the overall length is heavier than needed.

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 or annotations, the description adequately covers what the tool returns and the trust/authority model an agent needs. It is not fully complete for list semantics (no ordering/pagination), but nothing critical to correct invocation 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 0%, so the description must compensate and largely does: it explains the project filter, the include_tasks=true effect (adds tasks with lease/authorization status), and the open default for status. It does not spell out the closed/all enum values, but the meaning of each parameter is derivable.

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+resource ('List threads') and elaborates the return payload (pinned summaries, task counts, cap proximity) plus the default scope (open threads in all projects). The purpose is distinct from the task/post-oriented siblings, though it never explicitly names or contrasts them.

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?

Implied usage only: it explains the default status, the project filter, and the include_tasks switch, which hints at when to reach for it. But there is no explicit when-to-use/when-not guidance and no routing to alternatives like board_read_updates or board_claim_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?

With no annotations, the description carries the full burden and does so richly: sealed=true blind-review semantics and unseal conditions, propose_task creating a task in 'proposed', immutable category, decisions requiring human finalization, and grant scoping. The security paragraph also states the trust model for board content, which is exactly the behavioral context an agent needs.

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 front-loaded with the core purpose and type vocabulary, then proceeds to semantics and security. The density is justified by eleven params and a genuine security model, though a few clauses (grant restatements) are repetitive and could be tightened.

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 complex eleven-parameter tool with no annotations and no output schema, the description covers virtually everything an agent needs to call it correctly, including sealed/proposal side effects and the authority model. It omits any mention of the return value (e.g., post id) and never explains session_id.

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, and it defines most parameters meaningfully: type enum values, thread_id vs new_thread_title, body <=4KB with commit-and-ref guidance for refs {kind,path,rev}, to, needs_response, sealed, task_id, propose_task fields, and category. It leaves session_id entirely unexplained and does not formalize the refs/object shapes, hence not a 5.

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 opening 'Post to a thread' gives a specific verb and resource, and the type list plus thread_id/new_thread_title guidance pins down what the tool does. It doesn't explicitly contrast with siblings like board_read_updates or board_claim_task, so an agent must infer the boundary.

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 explains when each post type applies (e.g., request/handoff are informational, needs_response asks for a reply, propose_task only on a 'proposal', decisions are proposals until finalized) and covers thread routing. It never names an alternative sibling tool to use instead, so it stops short of explicit when-not 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?

With no annotations, the description carries the full burden and does so richly: idempotent cursor semantics, sealed-post withholding, decision-proposal vs final semantics, and an explicit security model declaring board content untrusted data that cannot grant authority. These are exactly the traits an agent needs and none are in structured fields.

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?

Dense but front-loaded: the core read semantics come first, or the security warning last. Every clause adds operational meaning, though the security paragraph is long and the whole block is close to over-budget.

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 6-parameter, no-output-schema tool with no annotations, the description covers cursor lifecycle, filtering, thread history, seal behavior, decision state, and security/trust boundaries. An agent can call it correctly without consulting other sources.

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, and it does for the important parameters: ack_through (the ack value from the previous call), only (enum values), history+thread_id interaction. It leaves limit and session_id unexplained, so not quite complete.

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 opening sentence names a specific verb and resource ('Read unread board posts') and scopes it precisely ('threads in your session's project plus posts addressed to you anywhere'). This clearly distinguishes it from siblings like board_list_threads and board_post, which read/post different views of the board.

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 gives explicit operational conditions: the cursor advances only on ack_through, only='addressed'/'needs_response' narrows results, and history=true with thread_id reads a thread without touching the cursor. What it lacks is routing guidance against alternatives (e.g., when to use board_list_threads instead), so it stops short of the top band.

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 zero annotations, the description carries the full burden and does well: it discloses that identity is token-derived and the agent name is not choosable, that the call is a once-per-session operation, and how resume works. It does not describe error behavior, what happens if called twice, or session lifetime, which keeps it from 5.

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 purpose is correctly front-loaded, but roughly half the text is a generic board-wide security policy rather than behavior specific to registering a session, which bloats a three-optional-parameter call. The parameter notes are terse and useful; the security block would be better placed as shared context.

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 3-optional-param registration call with no output schema, the description covers the essential mechanics — timing, identity source, path semantics, and resume — and states that a session_id is returned. It leaves out idempotency/re-registration behavior, which an agent might reasonably want to know.

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% and the schema gives only titles, but the description compensates for all three parameters: 'project = absolute path of the main repo you work in', 'worktree = your git worktree path if different', and the resume semantics of resume_session_id. It could be sharper on the fact that resume_session_id is an integer session_id returned by a prior registration.

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 opening sentence states a specific verb and resource — 'Register this agent session on the board and get a session_id' — with no ambiguity about the outcome. None of the siblings (board_post, board_claim_task, board_release_task, etc.) perform session registration, so it is cleanly distinguishable.

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?

'Call once at session start' gives explicit timing, and 'Pass resume_session_id to continue a session you registered earlier' gives a clear condition for the resume path. It does not name a when-not case or an alternative (there is no sibling that registers sessions), so it stops short of 5.

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 burden. It usefully discloses the state transition back to 'accepted' and lays out the trust/authority model (board text is data, only human grants authorize). However, it omits who may release, what happens if you do not hold the lease, error behavior, and any auth/permission requirements.

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 first sentence is excellent and front-loaded, but the multi-sentence SECURITY block is generic boilerplate that dominates the definition and is not specific to releasing a task. The signal-to-length ratio is poor for such a simple operation.

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 single required parameter and no output schema, the description covers purpose, state change, and the board trust model. It still leaves gaps a caller needs: the role of note/session_id and what happens on a failed or invalid release.

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 three parameters, so the description must compensate and largely does not. It never explains task_id, the optional note, or session_id even though the 'your lease' framing hints at a session/lease concept.

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 opening sentence names a specific verb and resource and states the exact resulting state ('Release your lease on a task... status returns to accepted'), which also implicitly contrasts it with the sibling board_claim_task. An agent can tell what this does and how it differs from claiming/updating without opening any 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?

The phrase 'so others can claim it' implies the scenario (handing off a task you no longer need), but there is no explicit when-to-use statement, no mention of when NOT to release, and no named alternative such as board_update_task. Usage is inferable but not spelled out.

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 burden and does add real context: a 4 KB cap, the summary-vs-instruction distinction, and an authority/grant model for board content. However, it never states overwrite semantics (does setting replace an existing summary?), who is permitted to pin one, or rate/approval behavior for this specific call.

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 core purpose is a single efficient front-loaded sentence, but it is followed by a long block of security boilerplate that reads as generic board-wide policy rather than tool-specific behavior. The content is arguably relevant given prompt-injection risk, yet its bulk dilutes the tool's own semantics.

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?

There is no output schema and no annotations, so the description must cover behavior alone; it addresses trust/authority well but omits the mutation semantics (replacement, persistence, error cases) and two of three parameters. Adequate but with clear gaps for a write tool.

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, and it only partially does: the '<= 4 KB' cap on summary is useful, but thread_id and especially session_id are left completely unexplained in both the schema and 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 names a specific verb and resource ('Set a thread's pinned summary') and even states its role ('the current state of the thread for newcomers'). It is clearly distinguishable from write-heavy siblings like board_post, though it never explicitly names an alternative 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?

It implies the purpose (orienting newcomers to a thread) but gives no explicit when-to-use vs when-not guidance and never points to a sibling such as board_post for ordinary messages. An agent must infer the trigger conditions itself.

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 provided, so the description carries the full burden and does so well: it discloses authorization requirements (lease holder, human acceptance, standing grants), side effects (attaching a note, posting a 'status' when blocked), failure conditions (revoked/expired grants), and a prompt-injection security model treating board text as untrusted 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?

Front-loaded with the lifecycle transition, then constraints, then security. Every section is relevant, but the final security block is dense and run-on, and some authority nuances are repeated across sentences rather than stated once crisply.

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 annotations and no output schema, the description supplies the safety and authorization context an agent needs, plus side-effect disclosure. It leaves gaps on return values and on session_id semantics, but nothing essential for correct invocation 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 0%, so the description must compensate. It explains the meaning of 'status' values and the 'note' parameter, and 'task_id' is implied by 'move a task', but 'session_id' is never mentioned or explained, leaving one of four parameters 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?

States a specific verb (move) plus the exact resource and its full state machine: proposed -> accepted -> working -> blocked -> done | declined. This level of scope detail lets an agent distinguish it from siblings like board_claim_task or board_release_task without opening any 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?

Gives explicit conditions for operation: only the lease holder can mark done, working/blocked renew the lease, proposed tasks need human acceptance or a matching standing grant, and revoked/expired grants block work. It does not name alternative sibling tools (e.g., board_claim_task) for the cases it excludes, so it stops short of full when-not/alternative routing.

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