Skip to main content
Glama

Create an automation

writ_create_automation

Create event-driven automations that run workflows, send notifications, or wake AI agents on schedules, webhooks, completions, or detected changes.

Instructions

Create an automation: on an EVENT, run a workflow, send a notification, and/or wake an AI agent. Chain workflows (when workflow A completes → run workflow B), alert on completion, or have an agent act on the event (ai_prompt). Give a source workflow via on_workflow for workflow_* events, and at least one of run_workflow / notify / ai_prompt. EMAIL THE DATA, not just that it ran — notify is a template over the event: after a WORKFLOW, {{result.extracted_data.0.title}} / {{result.extracted_data..0.url}} (the run's own rows); after a CRAWL, {{rows.0.}} … {{row_count}} (the records it collected, schema fields included) plus {{seed_host}} {{pages_done}}; after a monitor change, {{extracted.price}}. A missing path renders empty, so a digest of N rows is N numbered lines. THE DIGEST PATTERN: writ_set_schedule on the workflow (or a saved crawl), then this with when=workflow_completed / crawl_completed. ON A CLOCK: when='scheduled' + schedule fires the actions at that time (a notify after run_workflow waits for that run, so {{result.extracted_data...}} is filled). run_functions + inputs call chosen functions of a multi-function workflow (what they need runs too). Anything else (conditions, scrape, extract, branches): a raw blocks tree. ON A WEBHOOK: when='webhook_received' MINTS a signed inbound URL; the answer's webhook holds the url, its signing_secret (shown only then), the two headers every call signs, curl and Python examples and an example_body. Each top-level JSON field of a call becomes the run input of the same name; inputs, notify and ai_prompt templates read any field as {{payload.}}. A call is acknowledged at once; with ?wait=true it is held until the workflow runs the automation starts finish and answers their data. webhook_trigger_id reuses an existing URL (writ_list_webhooks).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameYesName for the automation (required).
whenNoEvent: workflow_completed | workflow_started | crawl_completed | crawl_failed | ai_session_completed | ai_session_started | change_detected (give `target_id`) | webhook_received (mints a signed URL; `webhook_trigger_id` reuses one) | scheduled (a clock: give `schedule`).
titleNoNotification title (with `notify`).
blocksNoRAW flow tree instead of the action arguments (max 50): each {id, type: event|condition|action, blockType, config, parentId}. The FIRST block is the root event (its blockType is the event: one of `when`; scheduled config {mode, interval_ms | time, days, tz}); every other block names an EARLIER block as parentId. Actions: workflow {workflow_id, function_name | function_names, input_mapping}; notification {template, title, channels, recipients}; ai_session {goal, entry_url}; scrape {urls:[<=5, templates ok], format: markdown|html|both, on_error} -> {{scraped.content}} {{scraped.pages}}; extract {source:'{{scraped.content}}', fields:[{key, from: html_css|json|regex|embedded_json|body, selector, attribute, all, path, pattern, group, number, required}]} -> {{extracted.<key>}}; condition {field, operator, value}. Wait for a run: an event block workflow_completed {linked_to_block:<workflow block id>}. Every string setting takes {{placeholders}}.
inputsNoWith run_workflow: its inputs {input_name: value}, each a literal or a {{template}} over the event (e.g. {{extracted.price}}, or {{payload.order.id}} from a webhook call's body); saved values fill the rest. Never secrets.
notifyNoSend a notification with this message — a template over the event's data (see the tool description: {{result.extracted_data.0.title}} after a workflow, {{rows.0.title}} / {{row_count}} after a crawl, {{extracted.price}} on a change).
enabledNo
channelsNoNotification channels for `notify`, e.g. ["pushover","email"] (required for delivery).
priorityNo
scheduleNoWith when='scheduled': {kind:'interval', interval_minutes:N} or {kind:'daily', time:'HH:MM', tz:'<IANA zone>'} or {kind:'weekly', time, days:[1..7] (1=Mon .. 7=Sun), tz}.
ai_promptNoWake an AI agent with this task when the event fires. The agent gets the event context (page URL, diff, extracted values) and works the task in a cloud browser. Supports {{placeholders}}.
target_idNoWith when='change_detected' (required there): the monitor whose changes fire this, i.e. the monitor_id writ_create_monitor returned.
recipientsNoNotification recipients, e.g. ["email:3"]. OMIT to reach EVERY enabled recipient on the channel — the answer names who the alert actually reaches, and warns when nobody is configured.
descriptionNo
on_workflowNoSource workflow name whose event fires this (required for workflow_* events).
ai_entry_urlNoPage the woken agent starts on. Defaults to the event's page (the monitored URL on change_detected); required in practice for workflow_*/webhook events.
run_functionNoOne function name (alias of run_functions).
run_workflowNoWorkflow to RUN when the event fires (by name).
ai_session_idNoWith when='ai_session_completed' / 'ai_session_started': only this AI session.
run_functionsNoWith run_workflow: call these functions of a multi-function workflow instead of the whole workflow — one run of the selection plus what it needs (sign-in, a token, the search whose ids another reads). Omit for the whole workflow.
on_workflow_idNo
run_workflow_idNo
cooldown_minutesNoMinimum minutes between AI wakes for `ai_prompt` (default 10; 0 disables).
target_selector_idNoWith target_id: only changes of this one selector of that monitor.
webhook_trigger_idNoWith when='webhook_received': fire on this EXISTING inbound webhook (its id from writ_list_webhooks) instead of minting a new URL. Its senders keep signing with its secret; one that has no secret yet gets one, shown once in the answer.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.1.0

TDQS

A4.9/5.0
Behavior5/5

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

With annotations already declaring readOnlyHint=false, openWorldHint=true, and destructiveHint=false, the description adds rich behavioral context: webhook URLs are minted with a signing secret shown only once, calls are acknowledged immediately unless ?wait=true is used, and notification templates render empty on missing paths. These details go well beyond the safety profile provided by annotations.

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?

The description is front-loaded with a clear purpose statement and organized into thematic paragraphs (notify, clock, webhook), which helps navigation. However, it is quite lengthy and uses dense all-caps emphasis, making it less concise than ideal, though most sentences carry useful, non-redundant information.

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?

Given the tool's complexity (25 parameters, nested objects, no output schema), the description is highly complete: it covers event triggers, action types, template syntax, webhook lifecycle, scheduling, and references to sibling tools. Annotations already cover the safety profile, so the description's depth fills all remaining gaps an agent would need to invoke the tool correctly.

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?

Although schema description coverage is high (80%), the description adds substantial meaning beyond the schema, especially for notify templates (e.g., {{result.extracted_data.0.title}}, {{rows.0.<field>}}, {{extracted.price}}), webhook payload substitution ({{payload.<path>}}), and the blocks tree structure. It also clarifies parameter interactions like on_workflow being required for workflow_* events and run_functions calling selected workflow functions.

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?

The description opens with a precise verb and resource: 'Create an automation: on an EVENT, run a workflow, send a notification, and/or wake an AI agent.' It clearly distinguishes the tool from siblings by naming related tools (writ_set_schedule, writ_list_webhooks) and explaining the unique combination of event triggers, actions, and scheduling.

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?

The description explicitly covers when to use each trigger mode (workflow_completed, scheduled, webhook_received) and provides concrete patterns like 'THE DIGEST PATTERN' that route the agent to specific sibling tools for complementary tasks. It also specifies required combinations ('at least one of run_workflow / notify / ai_prompt') and references alternatives such as writ_set_schedule and writ_list_webhooks.

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