The rule MCP tool: two calls, one principle

A couple of weeks back we argued that rules and agents are complements, not substitutes — rules are the deterministic rails the agent runs on, agents handle the ambiguous middle the rules can’t enumerate.

That’s the philosophy. This is what it looks like in the API.

The rule MCP tool ships with two calls and only two:

get_rule_list       — read-only. Lists every automation rule in the tenant.
add_endpoint_action — attach a webhook-style POST action to an existing rule.

That’s the whole surface. There is no create_rule. No update_rule. No delete_rule. Connect an agent to an Ekso install and it can see exactly what’s running — every trigger, every action, every condition — but it cannot rewrite the rails it’s running on.

What get_rule_list is for

The most useful thing an agent can do on its first day in a new install is ask: what’s already automatic here, and what isn’t?

Prompt: "Before you start triaging the queue, list the automation
rules on this tenant and tell me which ones will fire on items I touch.
Don't take any action a rule would already take."

The agent calls get_rule_list, gets back the full set of ConfigRule objects, and now knows the floor. It won’t re-escalate a ticket the SLA rule is about to escalate. It won’t tag a finance item the routing rule is already tagging. It treats the rules as authored intent — which is what they are — and steers around them.

This is the bit most “AI agent for X” tools skip. They drop the agent into a system and let it act as if it’s the only thing acting. Then the rule fires three seconds later and the team gets duplicated work, conflicting notifications, or both.

What add_endpoint_action is for

The one place we lean the other way is deliberately narrow. An agent can attach a webhook to an existing rule — pass a ruleId, a URL, and headers — and when the rule fires, Ekso POSTs the fire-envelope to the URL. Fire-and-forget. URL targets are validated (no loopback, no link-local, no cloud metadata endpoints).

The trigger stays human-authored. The reach is what gets extended. An agent can wire a rule into a Slack channel, a custom dashboard, a downstream LLM. It cannot redefine what the rule fires on.

The principle in one line

Rules persist. Tickets don’t. The cost of an agent writing a bad ticket is one bad ticket; the cost of an agent writing a bad rule is every ticket that comes after. The tool’s shape reflects that asymmetry.

Two calls. One reads the rails. One extends what happens when the rails trip. That’s the contract.

---

Full reference: ekso.dev/mcp-tools/rule. The MCP surface index is at ekso.dev/mcp-tools/introduction. And if you missed the underlying argument, that’s over here.