calendar_feed_enable

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

With no annotations, the description carries the full burden and does so thoroughly: it discloses idempotency, that regenerate=true irreversibly invalidates every older link, the alarm schedule (09:00, remindDaysBefore + day-before for expiries, 3 and 1 day for fiscal), that filed/renewed items drop at next refresh, and critically that the link itself is a credential a third party could read. That last point is exactly the kind of security context an agent needs.

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?

Action and idempotency are front-loaded, and the dense middle paragraph is justified because there is no output schema to carry return-shape detail. It is long but nearly every clause supplies non-obvious behavior; only the full return-object enumeration feels slightly encyclopedic.

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 no-annotation, no-output-schema tool, this is complete: it covers both the enabled and disabled return shapes, the credential/security caveat, refresh semantics, and the regenerate side effect. An agent has everything needed to call it safely and describe the result.

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 exceeds that by explaining the concrete consequences of regenerate ('every older link stops working') and the event-level meaning behind includeExpiries/includeFiscal, letting an agent reason about what toggling them actually yields rather than just what they nominally name.

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 clause gives a specific verb and resource: 'Turn on the calendar subscription.' An agent immediately knows this enables a feed, distinct from calendar_feed_disable/get/update by name. However, it never explicitly contrasts itself with those siblings, so it stops short of the rubric's 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 idempotency note ('an existing one keeps its link') and the regenerate clause give implicit guidance on when to re-call versus force a new link. But there is no explicit when-to-use-vs-alternative statement, e.g. how this differs from calendar_feed_update or calendar_feed_get. Usage must be inferred.

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