monitor

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

The description is unusually rich: it discloses deterministic state, no push behavior, dedicated headless session, rate limits (floor/caps/429), and pause-on-failure. These details go well beyond the minimal readOnlyHint annotation and set accurate expectations.

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 description is compact and front-loaded with the core purpose, but some phrasing is cryptic (e.g., 'reports stale with the failure, never unchanged') and information is packed into run-on semicolon clauses. It could be clearer without adding length.

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?

It provides helpful operational context (session isolation, rate limits, failure behavior) but no return format or output schema, and no guidance on how fields like since/value/label are used. Given the 9-parameter schema and no output schema, this is not fully complete.

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?

It maps several schema fields indirectly: condition types, selector_count, action values, interval floor, and URL. However, parameters like since, value, and label are not explained, leaving important semantics ambiguous.

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 opening sentence clearly states the tool watches one URL for a deterministic change while the server runs, and the four condition types are enumerated. It does not explicitly describe the full lifecycle of creating/managing monitors, which slightly reduces clarity.

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 some action guidance: 'report is how you ask what happened, and check_now forces a check,' and states nothing is pushed. It does not compare this tool to sibling alternatives like wait_for or get_page_view, so when to choose it over those is mostly implicit.

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