Enable or disable a scheduled job discovery cron job by its ID. Changes take effect on the next reconcile cycle within 60 seconds.
Enable or disable a scheduled job discovery cron job by its ID. The agent will pick up changes on its next reconcile cycle (within 60 seconds).
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Schedule ID to toggle | |
| enabled | Yes | true to enable, false to disable |
Changes observed during successful MCP inspections.
v3.2.5Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It adds valuable behavioral context: changes are picked up on the next reconcile cycle within 60 seconds. This informs the agent about eventual consistency. However, it doesn't mention permissions, whether toggling is reversible (though implied), or what happens on invalid IDs.
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, front-loaded with the core action and followed by a useful timing detail. No wasted words; every sentence earns its place.
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 simplicity (2 required parameters, no output schema, no annotations), the description covers the essential action and includes a relevant timing detail. It's almost complete, but could mention whether the change is immediate or requires the agent to poll, and whether permissions are needed.
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 both parameters are fully documented in the schema with clear descriptions ('Schedule ID to toggle' and 'true to enable, false to disable'). The description adds no additional parameter detail, so 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 states a specific verb (enable/disable) and resource (scheduled job discovery cron job) with an identifier. It's clear about what it does, though it doesn't explicitly differentiate itself from sibling schedule tools like delete_schedule, list_schedules, or schedule_jobs beyond the enable/disable action.
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 implies usage context (toggling a schedule's enabled state) but doesn't provide explicit when-to-use guidance, alternatives, or prerequisites. It's clear enough to infer the tool's role, but lacks guidance such as when to disable versus delete a schedule.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.