Manage Focus Time

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

Beyond the annotations, the description adds valuable behavioral context: Focus Time events auto-decline meeting invitations and, by default, set chat status to Do Not Disturb. These side effects are not obvious from the tool name alone and help the agent understand the real-world impact of creating such an event. The destructiveHint annotation is not contradicted by the description.

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?

Two focused sentences front-load the core purpose and the key behavioral consequences. No filler or repetition of schema details.

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?

The schema and output schema cover the parameter and return details, and the description covers the behavioral context. It is complete enough for an agent to understand this is a multi-action management tool for a special calendar event type, though it could have explicitly routed to regular-calendar or out-of-office siblings for contrast.

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 100%, so the parameters are already thoroughly documented with formats, defaults, and action-specific requirements. The description adds a conceptual layer by explaining the auto-decline and chat-status behavior that maps to auto_decline_mode and chat_status, but it does not need to restate the schema details. Baseline 3 is appropriate.

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 the specific resource (Focus Time events on Google Calendar) and explains their distinguishing behavior: auto-declining invitations and defaulting chat status to Do Not Disturb. It is clear what the tool operates on, though 'Manages' does not enumerate the create/list/update/delete actions covered by the action parameter.

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 description establishes that this is for protecting uninterrupted work time and that these events behave differently from normal events, which implies when to use it. It does not explicitly name alternatives like manage_event or manage_out_of_office, nor does it state when not to use this tool.

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