Skip to main content
Glama

update_automation

DestructiveIdempotent

Change or pause one of the user's Clarifo automations, only when the user asks. Give only what changes; everything else stays. pause=true switches it off (it can be switched on again with activate_automation after the user approves its settings; this tool never switches one on). Confirm the change with the user first, then say what changed (before and the new settings) and give review_url.

Args: automation_id: From automations. idempotency_key: Optional; leave it out. Clarifo recognises a repeated identical request by its content. Give one only to retry this same request. pause: True to switch the automation off. name: New name. instructions: For an instructions (prompt) automation: the new instructions it answers across the watchlist. cadence: For a prompt automation: daily, weekly, monthly, quarterly. language: For a prompt automation: en, fi, sv. scope_value: The watchlist (portfolio id) a prompt automation reads, or the market / sector of a report automation. scope_kind: For a report automation: all, market, watchlist, sector, industry. folder: Folder its documents go to. max_new_per_run: For a report automation: documents per run. run_times: For a report automation: run times, e.g. ["07:00"]. run_days: For a report automation: weekdays 1-7 (Monday = 1). timezone_name: IANA zone for the run times, e.g. "Europe/Helsinki". workspace_id: Optional; the automation's workspace. template: The name (or id) of one of the user's report templates of the automation's kind, or "standard" for Clarifo's standard format.

Returns: {"status": "automation_updated" | "automation_paused", "changed", "before", "automation_id", "name", "enabled", "what", "schedule", "cadence", "review_url"} or {"error", "failure_kind"}.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "automation_id": "<automation_id>"
    },
    "name": "update_automation"
  }
}

Input Schema

NameRequiredDescriptionDefault
nameNo
pauseNo
folderNo
cadenceNo
languageNo
run_daysNo
templateNo
run_timesNo
scope_kindNo
scope_valueNo
instructionsNo
workspace_idNo
automation_idYes
timezone_nameNo
idempotency_keyNo
max_new_per_runNo

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.7/5.0
Behavior4/5

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

Adds real context beyond the annotations: a confirm-first requirement, the obligation to report before/new settings plus review_url, pause semantics and reversibility, and a clear explanation of the content-based idempotency behavior. It does not spell out failure modes despite listing an error/failure_kind return, which keeps it just short of the top mark given destructiveHint=true on a partial-update tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the core constraint and the confirm-first rule, then a clean per-argument list where each line carries distinct information. Slightly verbose from repeated "For a prompt automation" / "For a report automation" prefixes, but no sentence is genuinely wasted.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 16-parameter partial-update mutation with full annotation coverage and a stated return shape, the description covers scope, safety workflow, idempotency, per-kind field applicability, and response fields. Nothing an agent needs in order to call it correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0% across 16 parameters, so the description must carry the load and it largely does: it maps each field to the automation kind it applies to (prompt vs report), gives value formats for run_days (1-7, Monday = 1), run_times ("07:00"), timezone_name (IANA), and enumerates scope_kind values. Only max_new_per_run and workspace_id are described thinly.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ("Change or pause one of the user's Clarifo automations") plus the boundary that it never enables an automation, naming activate_automation as the tool that does. An agent can distinguish it from activate_automation without opening either schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives explicit when-to-use ("only when the user asks"), how much to send ("Give only what changes; everything else stays"), the excluded case (never switches one on), and a required workflow step ("Confirm the change with the user first"). The alternative for enabling is named directly.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.