context

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

The description adds some behavior beyond the sparse readOnlyHint=false annotation: it discloses that 'reminder delivery metadata' is recorded (consistent with a non-read-only tool), that graph output is compact/authorized, and that bodies are not returned. However, it says nothing about pagination despite a cursor parameter, budget behavior, or authorization requirements beyond the word 'authorized'.

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 compact sentences with no filler, and the core restore behavior is front-loaded before the view=graph guidance. The dense noun list in the first sentence is slightly opaque, but nothing is wasted.

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?

This is a complex 9-parameter tool with conditional schema constraints, 0% parameter description coverage, and multiple view modes. The description addresses only a fraction of that complexity, leaving key parameters, view selection, and pagination behavior unexplained, even though the output schema means return-value details need not be covered.

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 0% across 9 parameters, so the description carries the full burden, but it only explains view=graph and vaguely references selecting 'initiatives.' It leaves query, since, cursor, include, initiative vs. initiatives, recorded_at, budget_chars, and the other view modes completely undocumented.

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 verb 'Restore' plus a list of resources (project rules, current records, open work, saved reasoning) gives a rough sense of the tool, but the scope is diffuse and overlaps heavily with siblings such as read, search, trail, and history. Only the graph-view sentence provides any differentiation, and even that is framed around output shape rather than the tool's core purpose.

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 only routing guidance is 'Use view=graph for compact authorized structure... bodies remain in read,' which covers one view mode and implicitly points to the read sibling for bodies. There is no guidance on when to choose context over search, read, trail, history, or reference, nor any prerequisites for the other view modes.

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