Managing automations from an AI assistant (MCP)

The same automations, through an AI assistant

Everything you can do in the builder — pick a trigger, chain steps, fill in templates, test, enable, watch runs — is also exposed through the Model Context Protocol (MCP). Point an MCP-capable AI assistant (Claude Desktop, Claude Code, Cursor, and others) at your AppGram organization and you can describe an automation in plain language, then let the assistant build, validate, and run it for you.

This is the same backend the builder talks to. There's no second copy of your data, no separate permissions model — the assistant acts within whatever your API key allows.

What an assistant can do

Build

• List existing automations across your organization or scoped to a project.
• Read any automation's full definition — trigger, condition, every step.
• Create a new automation from a description, or clone an existing one.
• Install a template from the catalog — built-in or one you've saved — into a fresh, disabled automation ready to fill in.
• Edit any field of an existing automation: rename it, swap a step, change a condition, replace a placeholder.
• Save a working automation back to the catalog as a custom template for the rest of your organization.
• Delete an automation when you no longer need it.

Validate & preview before saving

• Validate — check a proposed definition against the v1 schema without saving. The assistant sees the structured errors and can fix every problem before it touches your account.
• Preview — a pure dry-run of the path the engine would take against a sample event, with no database writes and no outbound calls. Secrets in the rendered config are redacted. Safe to call as often as needed.

Test for real

• Simulate — fire a synthetic event through the same matcher that production uses. The worker executes every step end-to-end (real HTTP requests, real messages), then the assistant can pull the run and step logs and tell you exactly what happened.
• List recent runs for any automation, drill into a single run, and read each step's input, output, error, attempt count, and duration.
• Delete a failed test run from history if you don't want it counted.

Discover templates

• Browse the merged template catalog — AppGram's built-in templates plus any custom ones in your organization — filtered by category.
• Open one to see its full definition and the notes that explain every step and placeholder before installing.

A typical loop

When you ask an assistant to set up an automation, the flow usually looks like this:

1. You describe what you want: "When a high-priority feature request is created, post it to our #product Slack channel and tag the requester."
2. The assistant drafts a definition and runs validate on it. If the schema rejects anything, it sees the joined errors and fixes them — without ever saving a broken draft.
3. It runs preview against a sample event so you can see which path the engine would take and what each step's templated config resolves to.
4. It creates the automation, usually disabled.
5. It simulates a real event and reads the run + step logs back to confirm the steps actually fire and succeed.
6. It updates the automation to enabled: true so real events start triggering it.
7. Later, if something looks off, it lists recent runs and pulls the failed one to find the broken step.

Each of these is a distinct, auditable action — the assistant can't take a shortcut around validation or testing.

Things to say

Once an MCP client is connected, plain-language asks work:

• "Show me every automation in this project and which ones failed in the last 24 hours."
• "Install the support-ai-triage template, fill in the OpenAI key, and turn it on."
• "My status-incident automation hasn't fired today — pull its recent runs and tell me what's going on."
• "Add a step that emails the requester when their wish moves to 'shipped'."
• "Simulate a wish_created event with priority=high and walk me through what happens."
• "Save this automation as a custom template called 'High-priority wish broadcast'."

Connecting your assistant

AppGram's MCP server runs at the AppGram MCP endpoint and authenticates with a standard API key from your organization. Drop the endpoint and key into your MCP client's server config (the exact JSON is documented in Organization → Developer tools → API keys), restart the client, and the automation tools appear alongside the rest of AppGram's MCP surface — wishboards, support, status pages, surveys, releases, and the Help Center.

API-key scope decides what the assistant can do. A project-scoped key only sees that project's automations; an organization key sees them all. Revoke a key any time to cut access instantly.

Safety and limits

• Secrets stay encrypted. Sensitive fields the assistant writes — API keys, signing secrets, bot tokens — are stored encrypted at rest, the same as values entered in the builder. They are never echoed back to the assistant in plain text after saving.
• Schema enforcement. The same v1 schema that powers the builder validates every definition the assistant submits, so it can't save a structurally broken automation.
• Same limits as the builder. Up to 50 steps per automation and a 2000-character cap on condition expressions — the assistant gets a clear error if it tries to exceed either.
• Deletes are real. delete_automation hard-deletes the automation and cascades its runs and step logs. Tell the assistant to disable instead when in doubt.

When to reach for which

Use the builder when you want to see the canvas, drag nodes around, and click through the catalog. Use an assistant over MCP when you'd rather describe what you want in a sentence, when you're spinning up many similar automations, or when you're triaging "why didn't this run?" against a fleet of automations at once.

Both paths share the same data, so you can mix and match — draft with an assistant, refine in the builder, then ask the assistant to install the same flow into a second project.