phone_update_auto_receptionist_call_handling_setting

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It flags the operation as a WRITE that 'modifies live call routing configuration', which signals it has real-world impact. However, it doesn't disclose whether this is reversible, requires specific permissions, affects active calls, or what the response format looks like. For a live-routing mutation, this is a meaningful disclosure 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?

Two short sentences, no wasted words. The WRITE OPERATION warning is front-and-center and immediately signals the mutation risk. It's appropriately concise for a 3-parameter tool.

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 mutation tool with no annotations, no output schema, and a nested 'settings' object with unspecified internal structure, the description is under-specified. The 'settings' parameter is the most complex and least explained — the agent gets no guidance on the shape of the payload, enums within it, or validation rules. The purpose is clear but the operational details needed to invoke confidently are 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 67% (hourType has a description and enum, settings has a description, but autoReceptionistId has no description). The description itself adds no parameter-level semantics — it doesn't explain how hourType maps to the three enum values, what structure the settings payload should follow beyond 'matching the Zoom Phone API schema', or what the autoReceptionistId should reference. The 'settings' description is notably vague, deferring to an external schema the agent may not see.

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 clearly states the verb ('update'), the resource ('auto receptionist'), and the specific field ('call handling setting for a specific hour type'). It distinguishes itself from the sibling 'phone_update_user_call_handling_setting' by targeting the auto receptionist rather than a user, though it doesn't explicitly name that sibling. The explicit WRITE OPERATION warning adds helpful emphasis.

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?

No when-to-use or when-not-to-use guidance is provided. While the WRITE OPERATION warning implies this is a mutating action, the description doesn't explain when a user would choose this over the sibling auto-receptionist GET endpoint (phone_get_auto_receptionist_call_handling_settings) or how it differs from the user-level update tool. The distinct auto-receptionist vs user context is clear but not explicit.

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