Read board

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so safety is covered. The description adds genuinely new behavioral context beyond them: the returned revision is a concurrency token to feed back as baseRevision, and the layout is scoped to a single chapter. It stops short of noting result size, pagination, or behavior when 'all' chapters are requested.

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, and the highest-value content (what is returned, and the read-before-write rule) is front-loaded. The reference-resolution example is compact and actionable.

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 carries the return-value burden and does so by enumerating the returned sections and layout fields. All parameters are schema-documented, leaving only minor gaps such as response size or the shape of scene/sources when the include flags are set.

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 all three parameters are already documented, including the 'all'/'free'/default-camera behavior for chapter. The description adds only the implied scoping of chapter to the returned layout and the baseRevision linkage; includeScene and includeSources get no additional meaning from the prose. 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 ('Read') plus a named resource ('the shared blackboard') and an explicit enumeration of what comes back: revision, chapters, camera, steps, and per-chapter layout fields. It also implicitly separates itself from board_update by framing this as the read half of the read/write pair, so an agent can distinguish it from that sibling without opening a 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 concrete trigger conditions: read before board_update and pass the revision as baseRevision, and read to resolve references like 'step 4, eq2'. That is a clear ordering constraint plus a real use case, but no when-not guidance and no comparison against siblings such as board_snapshot or board_library, which an agent must still infer.

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