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

Beyond the annotations, the description discloses the asynchronous 15-minute cadence, that the job may update, trash or remove Drive files the bundle no longer contains, that nothing is pushed during this call, and the billing/lapse behavior for already-mirrored files. This is exactly the kind of consequence-level context annotations alone cannot convey.

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?

Sentences are front-loaded and each carries distinct payload: what is queued, what the background job does destructively, that nothing happens now, provider default, plan gating, and provider support. No filler or repetition.

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?

For a two-parameter mutation tool with no output schema, the description covers timing, destructive side effects, provider support, and billing prerequisites. An agent has everything needed to decide whether to call it and what to warn the user about beforehand.

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%, so both rootKey and provider are already fully documented, including the 'github' refusal and the omit-for-all behavior. The description restates that provider omission queues all connected providers but adds no syntax or format detail beyond the schema, so baseline 3 applies.

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 opens with a precise verb+resource: "Queue one bundle for the next mirror push," and clarifies that the actual file write is deferred to a scheduled job. That distinguishes it from an immediate-push or reconcile operation, though no sibling tool (e.g. muninn_mirror_reconcile, muninn_mirror_status) is named explicitly to sharpen the contrast.

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?

Clear conditions are given: use this to mark a bundle dirty for the next scheduled push, omit provider to queue all connected providers, and expect nothing to happen synchronously. Limitations (paid plan required, lapsed accounts pause, 'github' is refused) further constrain use, but no alternative tool is named for callers who want an immediate push.

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