CRM Connector

Propose an automation

propose_automation

Destructive

AI Agents (inside one system): Use when the customer wants something to keep happening by itself inside one system on AI Agent (not for a one-off change: use propose_changes), such as "when a deal is won and the amount is above 5,000, add a kick-off task for the owner and a note". It turns that into one fixed rule on one record type: when (trigger), only if (conditions), then (actions). Before calling it, describe the rule in plain words (when, only if, then, and whether it also acts on records that already match) and get a yes. Nothing runs yet: the answer gives the rule as one sentence, how many records it would have acted on in the last 30 days with examples, and an approval link. Share that link: the rule only starts once the customer approves it there, and from then on the platform runs it again and again without asking. Use describe_record_type for the field keys; each action is one of the actions of propose_changes (set_fields, add_note, add_task and so on), with the values that action takes there. Pass replaces with an automation id to change an existing rule. A rule only acts inside that one system: to sync records between two systems, use an integration (plan_integration). It never deletes and never records a payment.

Input Schema

Name	Required	Description
`name`	Yes	A short name for the rule, as the customer would call it.
`type`	Yes	The record type, as list_ai_systems lists it: contact, opportunity, invoice, estimate, job, appointment.
`system`	Yes	Which AI agent: the system's id from list_ai_systems, or the name of the system or its connection. Ask the person which AI agent they mean unless they named it in this conversation; never pick one yourself.
`actions`	Yes	Then: 1 to 3 actions, run in this order on the record that met the rule.
`trigger`	Yes	When the rule acts: created (a record of the type is made), becomes (a field gets a value, such as a deal becoming won), or changes (a field changes in any way).
`replaces`	No	Optional: the id of an earlier automation of the same system that this rule replaces once it is approved.
`conditions`	No	Only if: at most 5 conditions on the same record, all of which must hold. Leave it out when the rule always acts.
`apply_to_existing`	No	Also act once on the records that already match when the rule is switched on. Off by default: the rule then only acts on what happens from now on.

Output Schema

Name	Required	Description	Default
`id`	Yes
`name`	Yes
`rule`	Yes
`type`	Yes
`notice`	No
`status`	Yes
`examples`	Yes
`sentence`	Yes
`systemId`	Yes
`warnings`	Yes
`lastRunAt`	Yes
`approveUrl`	Yes
`systemName`	Yes
`pauseReason`	Yes
`firings30Days`	Yes
`matchedLast30Days`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedOct 29, 2026

changedInput schema / properties / actions / items / properties / arguments / description

Previous value: -"For the other kinds: one item of its propose tool, for the record that met the rule. Use {record.id} as its id and leave type out for the rule's own record type. A date may be {today} or {today+3} (three days after the rule acts)."New value: +"For the other kinds: one item of propose_changes with that action, for the record that met the rule. Use {record.id} as its id and leave type out for the rule's own record type. A date may be {today} or {today+3} (three days after the rule acts)."

changedInput schema / properties / actions / items / properties / kind / description

Previous value: -"set_fields to set or empty fields of the record, or the action of a propose tool, which the rule applies by itself: update_fields (propose_field_update), move_stage (propose_stage_move), add_note (propose_note), add_task (propose_task), link_records (propose_link) or unlink_records (propose_unlink)."New value: +"The action the rule applies by itself, one of the actions of propose_changes: set_fields to set or empty fields of the record, or update_fields, move_stage, add_note, add_task, link_records or unlink_records."

First observedOct 29, 2026

TDQS

A4/5.0

Behavior1/5

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

The description adds rich process detail, but it directly conflicts with the destructiveHint=true annotation by stating “Nothing runs yet” and that the rule only starts after customer approval. It also says the rule “never deletes,” reinforcing that the tool call itself is not destructive. This is an annotation contradiction.

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 long, but the complexity of an 8-parameter nested proposal tool justifies most of the length. It is front-loaded with usage guidance and the core rule shape, though there is some repetition around the one-system scope and approval flow.

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 complexity, output schema, and nested input, the description covers purpose, alternatives, prerequisites, return behavior, approval lifecycle, and key limitations. An agent has enough context to know what this tool does and how to prepare the call, aside from the annotation conflict.

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 a useful conceptual mapping of trigger/conditions/actions and apply_to_existing into “when / only if / then / also existing records.” It also ties nested action values back to propose_changes and field keys to describe_record_type, helping the agent connect the parameters.

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 (“propose an automation”) and narrows the scope to one fixed rule on one record type. It explicitly distinguishes the tool from propose_changes for one-off changes and plan_integration for cross-system syncing.

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 clear when-to-use guidance (“keep happening by itself inside one system”) and explicit alternatives for one-off changes and integrations. It also describes the pre-call confirmation step and how to use replaces for an existing rule.

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

All CRM Connector 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?