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

Annotations only declare readOnlyHint=false, destructiveHint=false, openWorldHint=true, so the description usefully adds input normalization (whitespace collapsed, max 100 chars) and clearing semantics (null/empty resets to board-id display). It does not mention that locked boards require an access key or what the response contains, which are meaningful gaps for a mutation.

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 with zero filler, front-loaded with the effect of the call and followed by constraints and read-back guidance. Every clause carries actionable 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?

With no output schema, the description compensates well by telling the agent exactly where the name can be read back, and it fully specifies the mutation semantics. The remaining hole is the undocumented author parameter and the lock/access-key prerequisite, which only appear in schema text.

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 50%: name and access_key are documented in the schema, while board_id and author are not. The description adds real meaning for name (100-char cap, whitespace collapsing, null clears) beyond the schema's terse 'null or empty clears it', but says nothing about the undocumented author parameter, so it only partially compensates.

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 and resource ('Set the shared board name') and immediately enumerates where the value surfaces (rail label, tab title, export filenames). No sibling tool performs board renaming, so the agent can distinguish it from set_board_mode or update_task 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?

Explains applicability ('Works in draw and todo mode') and routes the agent to the correct read path ('Read it as name from get_board / list_tasks'), which is an explicit alternative pointer. It stops short of stating when not to use it, and it doesn't mention the locked-board prerequisite, though the schema covers that.

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