update_schedule

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It does reveal that the actions array supports both 'update' and 'delete' operations, which is significant behavioral context. However, it does not address potential side effects, permissions, or outcome details such as partial success in batch operations, leaving gaps.

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 front-loaded with a concise purpose statement, followed by mode-specific instructions and an Args list. The Args list partially repeats the earlier prose, but the overall structure is clear and scannable. It is appropriately sized and not overly verbose.

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?

Given the tool's moderate complexity, the description covers the two operation modes, parameter roles, and the action type enum. It lacks explicit return-value information, but the absence of an output schema reduces that burden. It does not mention error conditions, but the fundamental invoke patterns are sufficiently described for an agent to use the tool correctly.

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%, so the description must compensate. It does so effectively: automation_id is identified as the automation UUID, job_id as the job to update, cron as the new cron expression, and actions as an array of batch operations with structure [{type: 'update'|'delete', job_id, cron}]. All four parameters are explained, and the single-vs-batch distinction clarifies parameter relevance.

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 opens with a specific verb-resource pair ('Update one or more schedule jobs on an automation'), clearly distinguishing it from sibling tools like add_schedule or delete_schedule. It also mentions batch operations, providing a full scope of the tool's capabilities.

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 explicitly states two usage modes: single update with job_id and cron, and batch operations with an actions array. This provides clear when-to-use guidance for different scenarios. It doesn't explicitly mention alternatives, but the modes themselves suggest the appropriate use cases.

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