update_automationModify an existing Instagram comment-to-DM automation: update only supplied fields, or set active to false to pause and true to resume.
Update fields on an existing automation. Only provided fields change. Set active:false to pause, active:true to resume.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ||
| name | No | ||
| active | No | ||
| dailyCap | No | ||
| actionType | No | ||
| triggerType | No | ||
| templateText | No | ||
| excludeKeywords | No | ||
| includeKeywords | No |
Changes observed during successful MCP inspections.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only declare readOnlyHint=false, so the description must carry the behavioral load. It usefully discloses the partial-update contract ('only provided fields change') and the pause/resume semantics of `active`, but says nothing about permissions, whether an update can fail or be reversed, or what happens to related fields (e.g. templateText when actionType changes).
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?
Three short sentences, no filler, and the core update contract is front-loaded before the pause/resume tip. Every sentence contributes information an agent needs.
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 highest-risk behavior for a mutation tool — partial update semantics — is covered, along with the active toggle. However, with 9 undocumented parameters, no output schema, and only a readOnlyHint=false annotation, the definition leaves large gaps around required identifiers, field interactions, and failure behavior.
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% across 9 parameters, so the description is the only source of meaning and it covers just one field (`active`). The required `id` parameter is never explained, and no guidance is given on dailyCap, actionType/triggerType enums, templateText, or the include/exclude keyword arrays.
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 gives a specific verb+resource ('Update fields on an existing automation'), which clearly separates it from create_automation and delete_automation in the sibling list. It stops short of explicitly naming or contrasting those siblings, but the purpose is unambiguous.
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?
It states when the tool is applicable at the field level ('only provided fields change' implies PATCH-style usage) and gives explicit how-to for the pause/resume case via `active`. It never says when to prefer this over create_automation or delete_automation, nor are prerequisites or conflict cases addressed, so guidance is implied rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.