set_page_requests

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

The annotations only declare idempotentHint and destructiveHint, so the description carries the real behavioral burden, and it does: 'on' means the agent must run a monitor command so requests arrive immediately, 'off' means the monitor is stopped and requests then queue on the Moontide server until the next Moontide tool call. That downstream consequence for other tools is exactly the kind of context annotations cannot express.

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?

It is front-loaded with the effect of each state before the when-to-call guidance, and every sentence contributes something (state semantics, trigger conditions, prompt alternative). Sentences are dense and long, so the text is heavier than strictly necessary, but there is no filler.

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 one required enum parameter, no output schema, and only idempotency/non-destructiveness annotations, the description covers everything an agent needs: what each state does, how the monitor is started and stopped, where queued requests surface, and when to invoke it. Nothing material is missing for correct invocation.

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 100% and the enum values are already documented in the schema, so the baseline is 3. The description adds workflow-level meaning beyond the schema — what actually happens to the agent and the server in each state — which makes the choice between 'on' and 'off' operationally meaningful rather than just a label.

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 uses a specific verb and resource: it switches how requests typed on the Moontide page reach the agent, and it spells out both 'on' and 'off' modes concretely (run the Monitor tool now vs. requests wait and arrive in the next tool reply). That is far more specific than a restatement of the name, though the opening 'Switches how requests ... reach you' is slightly abstract until the following sentences clarify it.

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?

It gives an explicit trigger ('Call it when the user asks, in any words, to turn page requests on or off, to take requests from the Moontide page right away, or to stop'), which covers phrasing variation an agent will actually encounter. It also names the alternative path — the page-requests-on and page-requests-off MCP prompts — so the agent knows a sibling mechanism exists when the client offers prompts.

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