Capable

Define automation rule

define_automation

Destructive

Create an automation rule: when trigger_event fires (record.written) and condition_spec matches, run action_tool with action_args (a {{placeholder}} template over the trigger facts). The action re-enters the governance chokepoint, so it still respects approvals + write-scope. Requires the workspace automation flag to actually fire. Returns the rule. An existing rule is edited with update_record / delete_record on object_type "automation" (its id and key come from describe_schema).

When to use: When an admin wants an action to fire automatically on a record write — e.g. flag big deals, create a follow-up task.

Example: When an opportunity over $100k is created, make a task for me to review it.

Input Schema

Name	Required	Description
`label`	Yes	Display name for the rule. Its slug becomes the rule key, which must be unique in the workspace.
`action_args`	No	Arguments for action_tool. Text a person reads embeds {{record_name}} or {{account_name}}; ids and keys come from {{record_id}}, {{account_id}}, {{object_key}} or {{tool_name}}. A whole-string placeholder keeps the fact's raw type.
`action_tool`	Yes	The registered tool to run, by name (e.g. create_record, add_note). Account-creating actions (create_account, migrate_crm, create_record of account) are refused.
`trigger_event`	No	The event that fires the rule. Only "record.written" (any governed record write) exists today; it is the default.
`condition_spec`	No	all (AND) / any (OR) lists of {field, op, value?} on object_key, tool_name, record_id, account_id; op eq/neq/gt/gte/lt/lte/contains/in/is_null/is_not_null. {} = every write.

Output Schema

Name	Required	Description	Default
`automation`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 22, 2026

changedInput schema / properties / action_args / description

Previous value: -"Arguments for action_tool. String values may embed {{object_key}}, {{tool_name}}, {{record_id}} or {{account_id}}; a whole-string placeholder keeps the fact's raw type."New value: +"Arguments for action_tool. Text a person reads embeds {{record_name}} or {{account_name}}; ids and keys come from {{record_id}}, {{account_id}}, {{object_key}} or {{tool_name}}. A whole-string placeholder keeps the fact's raw type."

Changed1 schema field changedOct 20, 2026
- removedInput schema / $schema
```
Removed value: -"https://json-schema.org/draft/2020-12/schema"
```
Changed4 schema fields changedOct 19, 2026
- removedOutput schema / $schema
```
Removed value: -"https://json-schema.org/draft/2020-12/schema"
```
- removedOutput schema / additionalProperties
```
Removed value: -{}
```
- removedOutput schema / properties / automation / additionalProperties
```
Removed value: -{}
```
- removedOutput schema / properties / automation / propertyNames
```
Removed value: -{
-  "type": "string"
-}
```
First observedOct 6, 2026

TDQS

A4.6/5.0

Behavior4/5

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

Beyond the annotations (destructiveHint=true, openWorldHint=true, idempotentHint=false), the description discloses that the action re-enters the governance chokepoint and still respects approvals and write scope, and that the workspace automation flag is required for the rule to actually fire. It does not say what happens on duplicate label/rule key or subsequent invocations, which matters given the non-idempotent hint.

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

Conciseness5/5

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

Mechanics are front-loaded, followed by when-to-use, then an example — a clean triage order with no filler. Every sentence carries operational information (fire conditions, governance, flag prerequisite, edit path).

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

Completeness4/5

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

For a 5-param, nested-object, mutation tool with an output schema and full annotations, the description covers prerequisites, governance behavior, and the edit alternative. The gap is failure modes (duplicate key, refused account-creating action at runtime) which are only partly covered by the schema's action_tool note.

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

Parameters4/5

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

Schema coverage is 100%, so the baseline is 3, but the description adds the cross-parameter semantics: condition_spec gates on trigger facts, action_args is a {{placeholder}} template over those same facts, and the whole pipeline runs through governance. That linkage between action_tool and action_args isn't fully conveyed by the per-field schema text alone.

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 first sentence states a concrete verb+resource (create an automation rule) and immediately explains the trigger/condition/action composition, which no sibling tool offers. It also explicitly distinguishes itself from update_record/delete_record for editing an existing rule, so an agent can separate it from the CRUD siblings.

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?

A dedicated 'When to use' line names the scenario (admin wants an action to fire automatically on a record write) and gives a concrete example. It also routes the editing case to the alternatives (update_record / delete_record on object_type 'automation') and points at describe_schema for the id/key.

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

All Capable tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?