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

With no annotations, the description carries the full behavioral burden. It usefully discloses that the note is broadcast to other sessions and is consumed via `board`, but says nothing about note lifetime/expiry, author attribution, or whether posting overwrites anything. Adequate disclosure of audience, incomplete on persistence semantics.

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, zero waste: purpose and audience first, then trigger conditions. Every clause earns its place and the call-to-action 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?

For a one-parameter, no-annotation, no-output-schema tool, the description covers purpose, audience, read path, and when to invoke. Minor gap on note lifetime/attribution, which would matter for a shared coordination board but is not strictly needed to call the tool correctly.

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

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

Schema coverage is 100% for the single `text` parameter, so the schema already documents format and language expectations. The description adds content guidance (what to include in the note) that complements the parameter, but no syntax or length detail beyond the schema. Baseline 3 applies when the schema does the work.

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 concrete verb+resource ('Post a short note for the other DSH sessions') and enumerates the content types (work in progress, files/repo, decisions). It also names the sibling that reads the notes ('board'), so an agent can distinguish announce from board without opening either 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?

Explicit trigger conditions are given: start something long, take ownership of files another session might edit, or finish a task. It also specifies the read counterpart ('Other sessions read it with `board`'), giving both when-to-use and the alternative 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 provided, the description carries the full burden, and it does disclose two behavioral facts: results are ordered newest first and are scoped to notes from *other* DSH sessions (implying the caller's own notes are excluded). It does not say anything about the note structure, whether posting requires announce first, or pagination 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?

A single tight sentence with no filler, and the most important scoping fact (which notes) plus ordering are front-loaded. Nothing could be removed without losing information.

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 read-only listing tool with a fully documented two-parameter schema and no output schema, the description covers scope, source, and ordering adequately. The only gap is that the shape/content of a returned note is left entirely implicit.

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

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

Schema description coverage is 100%, with both `limit` (default 20) and `since_minutes` fully documented in the schema itself. The description adds no syntax, format, or interaction details for either parameter, so the baseline of 3 applies.

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 (Read) and resource (notes other DSH sessions posted) and names the sibling tool `announce` that produces the content, which cleanly separates it from the write side. The 'newest first' ordering also pins down what the result looks like. An agent can tell this is the announcement-reading tool without opening 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?

The description explains what the tool reads but gives no guidance on when to reach for it versus `peers`, `overlaps`, `session_detail`, or `whoami`. There is no explicit when-to-use or when-not-to-use statement; an agent must infer that this is the bulletin-board counterpart to `announce`.

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. It discloses what is compared, which usefully implies a read-only analytical operation, but it says nothing about cost, latency, scope of scanning, or whether the report is exhaustive or sampled.

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: the first defines the output dimensions, the second the usage conditions. Nothing is wasted and the substance 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?

With no output schema, the description partly compensates by listing the three report categories. There are no annotations to cover safety or mutability either, but the tool is clearly a read/report operation and only the response format and limits remain underspecified.

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

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

Schema description coverage is 100%, so limit and active_within_minutes are already fully documented in the schema. The description adds no additional meaning such as windowing semantics or how truncation via limit affects the collision analysis, so the baseline 3 applies.

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?

It states a specific verb (report) and resource (collision risk between DSH sessions) and enumerates the three concrete dimensions detected: overlapping file touches, shared workspaces, and duplicate git commands in one repo. That level of detail clearly separates it from siblings like peers or session_detail.

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 triggering conditions: before editing a repo another session is working in, or when the user asks whether two sessions will clash. It does not name alternative tools (e.g. peers) or say when not to use it, so it stops just short of a 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?

No annotations are provided, so the description must carry the behavioral load. It effectively communicates read-only observation via 'See' and 'check', and discloses the specific current-state fields returned and recency ('right now'), though it does not explicitly state absence of side effects or any auth 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?

Two sentences: the first defines the tool and enumerates return fields; the second gives usage scenarios. Front-loaded, no waste, every sentence earns its place.

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

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

No output schema exists, so the description must explain return values. It enumerates the key fields returned, which is helpful, but does not specify the structure (e.g., list) or ordering. Combined with complete schema coverage for parameters, it is largely complete.

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

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

Schema description coverage is 100%, so the schema already documents all four parameters including defaults and filters. The description adds no parameter-level detail, so the baseline 3 applies.

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?

Specific verb+resource: 'See what the other DSH agent sessions on this machine are doing right now' with an enumerated list of returned details. It does not explicitly name or distinguish itself from siblings like session_detail or overlaps, so it falls short of 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?

Gives three clear when-to-use scenarios: before touching shared files/repos, when the user mentions another window/session, and to check if a task is already handled. No when-not guidance or named alternatives, so not a 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?

No annotations are provided, so the description carries the burden; 'Read' signals a non-mutating operation, and it discloses that the timeline is returned in order and spans three entry types, which is real behavioral content. It does not mention permissions, rate limits, or how truncation behaves when limit/frames are exhausted, so it falls short of full disclosure.

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 tight sentences: the first front-loads what is returned, the second front-loads when to reach for it. No filler, no repetition of schema fields.

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 no annotations, the description must stand alone; it usefully describes the returned timeline composition (messages, replies, tool calls) and ordering, covering most of what an agent needs. It stops short of describing response shape or truncation semantics, which is the main remaining gap.

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

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

Schema description coverage is 100% and all three parameters (limit, frames, session_id) are documented in the schema, including the prefix-matching behavior of session_id. The description adds no parameter-level detail beyond what the schema already supplies, so the baseline 3 applies.

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 (Read) plus a precisely scoped resource (the recent activity timeline of ONE DSH session) and enumerates what the timeline contains: human messages, agent replies, tool calls. This distinguishes it from siblings like peers (list) and overlaps without needing to open 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?

Explicitly sequences usage: 'Use it after `peers` when another session's work matters to yours,' naming the sibling that precedes it and the triggering condition. It lacks an explicit when-not clause (e.g., what to use for a broad multi-session view), but the routing intent is clear.

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 for a zero-parameter introspection call it does reasonably well by disclosing exactly what identity information is surfaced, including the live 'whether a tool is currently running' status. It never explicitly says the call is side-effect free or whether it requires an active session, which is the remaining gap.

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 tight sentences, with the identity payload front-loaded and the use case trailing. Every clause does work, though the phrasing is slightly loose and could have been trimmed further.

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, so the description must describe the return values itself — and it does, listing session id, workspace, title, and running status. It stops short of specifying formats (e.g., id form, title source) or the relationship to session_detail, leaving a small but real gap.

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 takes zero parameters, so there is nothing for the description to disambiguate; the baseline of 4 applies. The description instead usefully characterizes the return payload, which is the relevant semantics for a no-arg call.

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 (Identify) and resource (DSH session) and enumerates the returned fields: session id, workspace, title, and running-tool status. It is clear on its own, but it never contrasts itself with the sibling 'session_detail', which an agent would plausibly confuse it with.

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 offers one concrete scenario ('when you need to tell a human or another session where a note came from'), which is implied usage guidance rather than an explicit rule. It does not state when not to use it or name alternatives such as session_detail, so the agent must still infer the boundary.

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