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

Given readOnlyHint=false, the highest-value disclosure is that this 'Saves the plan and changes nothing in the account', which resolves the apparent write/read ambiguity an agent would otherwise face. It also discloses a hard constraint ('Cron expressions are read in UTC: there is no time zone setting') and previews the returned content. It does not address idempotency despite idempotentHint=false, e.g. whether re-running with the same inputs creates a second plan.

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 trigger condition is correctly front-loaded and the exclusion is placed at the end as a clean sign-off. The middle sentence about return values is a long, semicolon-chained run-on ('when the job runs, if the schedule given could not be read; then how late is too late...') that takes a second read to parse, which costs a point.

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?

There is no output schema, yet the description still covers what comes back (schedule with next five runs in local time, monitor cost against remaining plan room, and open decisions), plus the UTC constraint and the no-account-change guarantee. For a six-parameter planning tool with nested `answers`, nothing an agent needs to call it correctly is missing.

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 the baseline is 3; the description earns a bump because it explains the decision loop behind the opaque `answers` object — the decisions are grace period, longest normal run and severity, and each has an id the user answers. It also clarifies `plan_id` semantics ('an earlier plan_cron_monitor plan, to change it or answer its decisions') beyond the schema's terser phrasing, though it adds little new on `schedule` formats.

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 concrete trigger — 'the user wants to know if a scheduled job, backup, queue worker or other background task stops running, runs late or fails' — naming the resource and the failure modes it detects. It also explicitly excludes the nearest wrong tool ('Not for checking a website or API endpoint: use plan_site'), so an agent can separate it from plan_site and plan_dependency without opening a schema.

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?

Both directions are stated: the positive when-to-use condition up front and the negative case with a named alternative ('use plan_site'). It further indicates the resume path, since plan_id lets it amend an earlier plan or answer its decisions, which is the kind of routing guidance that prevents duplicate plans.

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