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

Annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=false and destructiveHint=false, so the safety profile is covered by structured data. The description adds genuinely new context: this is app-only, and the payload includes next-run timings plus the plan's alert limit. It stops short of describing shape, ordering, or whether a null market widens scope, which is the remaining behavioral gap.

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?

One sentence, no filler, with the 'App only' scoping constraint front-loaded before the payload contents. Slightly awkward phrasing ('with when each next runs') but nothing 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?

With no output schema, the description does the right thing by enumerating the returned concepts (schedules, next runs, plan alert limit), and annotations carry the safety profile. It is still thin for an agent needing to know how market scoping and the limit interact, and there is no output structure hint beyond prose.

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% and the single 'market' parameter is typed as nullable with a null default, so the description carries the burden. Saying schedules are 'for a market' implies the parameter filters by market, but it never says what a null market does (all markets? default market?) or what form a market identifier takes.

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 names a specific resource and its contents: alert schedules for a market, each schedule's next run, and the plan's alert limit. That is enough to tell it apart from the write siblings (create/update/delete) and from a plain list. It does not explicitly name which sibling it competes with (e.g. qanvo_app_alerts), and the name 'alert_options' is ambiguous without the sentence, so it falls short of a 5.

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 usage signal is the 'App only' prefix, which is a scope marker rather than guidance on when to pick this over list_alerts or qanvo_app_alerts. There is no statement of when not to use it and no alternative is named.

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