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

With annotations already marking the call as mutating but non-destructive and idempotent, the description adds useful behavioral context: the operation is asynchronous (returns a job), deterministic, and is a shortcut over the same engine as run_tab_book. This adds value beyond annotations without contradicting them.

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, action first, with each clause earning its place: what the tool builds, the eligibility condition, the underlying engine and behavior, and the next step for polling. No filler or redundant restatement of the tool name.

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?

The description covers the return channel (job to poll with get_job) and the deterministic shortcut behavior, which matters given no output schema. But it leaves parameter semantics for 3 of 5 parameters and the run_tab_book alternative unaddressed, so an agent still has to infer some selection and invocation details.

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 only 40% (requestId and workspaceToken get descriptions; waveId, tableIds, projectId do not). The description does not compensate: the only parameter hint is 'existing hosted project' loosely mapping to projectId, and it gives no guidance about waveId or tableIds. This is a significant invocation gap.

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 action and object ('Build a reusable tab book') and an eligibility condition ('existing hosted project'). It gestures at its relationship to run_tab_book by calling itself a task shortcut, but it never explicitly says how it differs from that sibling, so it stops short of full differentiation.

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 'existing hosted project' supplies clear context, and 'returns a job to poll with get_job' tells the caller what to do next. However, it does not provide explicit when-to-use versus run_tab_book or other tabulation/report siblings, nor any 'use X instead when...' exclusion. The choice is left mostly to inference.

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