Export status

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the description's added value is the available=false condition (server too old to run exports) and the side-effect note that a successful export makes the new library visible to other tools. These are genuinely non-obvious behaviors an agent would otherwise misinterpret. Polling cadence and failure semantics are still unstated.

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 use_case block is front-loaded and dense with concrete facts, and the important_notes carry the two operational caveats. Minor waste remains: the <example> line shows a zero-argument call that conveys nothing, and the return-field enumeration partially duplicates the existing output schema.

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 parameters, an output schema, and read-only annotations, the description only needs to supply the non-obvious semantics, which it does via the available=false case and the post-export visibility note. What is missing is operational framing around polling (one-shot vs. repeated calls, whether a terminal state is guaranteed), which matters for a status 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?

The tool takes zero parameters, so there is no parameter meaning to add and the baseline of 4 applies. The description does not waste words on inputs, which is correct here.

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 resource and enumerates exactly what is reported: running/finished/failed state, phase (deck, details, proton, hltb), progress, elapsed time, log tail, and whether the library changed. It never explicitly contrasts itself with the sibling backlog_start_export, so an agent must infer that this is the read-side counterpart of the export pair rather than being told.

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?

"How the library refresh is going" plus the note that other tools see the new library after a successful export clearly frames this as the post-start monitoring call. It stops short of explicit guidance such as when to poll, how often, or that it should be called after backlog_start_export, and no alternative tool is named.

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