Skip to main content
Glama

HellouOne

by ai.hellou
OverviewDiscussionsAdmin

Create automation rule

create_automation_rule
Destructive

Create an automation rule: when EVENT happens and CONDITIONS match, run ACTIONS. The conditions and actions schemas list the exact attribute keys, operators and values each event accepts — use those, not values you have seen elsewhere. Read list_labels / list_agents / list_teams / list_inboxes for the ids and titles an action or condition needs. The assistant cannot create rules that call an external address or send attachments.

Input Schema

NameRequiredDescriptionDefault
nameYes
activeNo
actionsYesWhat happens when the rule matches, in order. action_params per action: change_priority → exactly one of low, medium, high, urgent, nil; change_status → exactly one of open, resolved, pending, snoozed; assign_agent → one agent id (list_agents), or the string "nil" to unassign; assign_team → one team id (list_teams), or the string "nil" to unassign; add_label → label titles (list_labels), one or more; remove_label → label titles, one or more; send_message → the message text (one string); send_email_transcript → one string of comma-separated email addresses; mute_conversation → none; snooze_conversation → none; resolve_conversation → none; send_whatsapp_flow → one object: {flow_id (list_whatsapp_flows, published only), flow_cta (the button label, at most 30 characters), body, and optionally header, footer, initial_screen}; send_email_to_team → one object {"team_ids": [ids], "message": "text"}.
conditionsYesWhen the rule applies. Every condition after the first needs a query_operator (and / or); the first has none. attribute_key must be one the event supports: message_created: message_type, content, email, inbox_id, conversation_language, phone_number | conversation_created: status, browser_language, mail_subject, country_code, phone_number, referer, email, inbox_id, conversation_language, priority | conversation_updated: status, browser_language, mail_subject, country_code, referer, phone_number, assignee_id, team_id, email, inbox_id, conversation_language, priority | conversation_opened: browser_language, email, mail_subject, country_code, referer, assignee_id, phone_number, team_id, inbox_id, conversation_language, priority. Operators per attribute: message_type (equal_to/not_equal_to), content (equal_to/not_equal_to/contains/does_not_contain), email (equal_to/not_equal_to/contains/does_not_contain), inbox_id (equal_to/not_equal_to/is_present/is_not_present), conversation_language (equal_to/not_equal_to), phone_number (equal_to/not_equal_to/contains/does_not_contain/starts_with), status (equal_to/not_equal_to), browser_language (equal_to/not_equal_to), mail_subject (equal_to/not_equal_to/contains/does_not_contain), country_code (equal_to/not_equal_to), referer (equal_to/not_equal_to/contains/does_not_contain), priority (equal_to/not_equal_to), assignee_id (equal_to/not_equal_to/is_present/is_not_present), team_id (equal_to/not_equal_to/is_present/is_not_present). Values: status → open, resolved, pending, snoozed; priority → urgent, high, medium, low, nil (no priority); message_type → incoming, outgoing; inbox_id → inbox ids (list_inboxes); assignee_id → agent ids (list_agents); team_id → team ids (list_teams); country_code → ISO 3166-1 alpha-2, e.g. CO, US; browser_language → ISO 639-1, e.g. es, en; conversation_language → ISO 639-1, e.g. es, en; content → text fragments; contains matches any of them; phone_number → E.164, e.g. +573001234567; email → contact email; mail_subject → email subject text; referer → page URL the widget was opened from. A custom attribute (list_custom_attributes) is an attribute_key of its own with custom_attribute_type set; is_present / is_not_present take no values; attribute_changed (conversation_updated only) takes {"from": [...], "to": [...]} objects.
event_nameYes
descriptionNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.4/5.0
Behavior4/5

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

Annotations already declare destructiveHint=true, readOnlyHint=false, and idempotentHint=false, so the safety profile is covered. The description adds real behavioral context beyond that: the assistant cannot create rules that call an external address or send attachments, which is a non-obvious capability limit.

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?

Three tight sentences, front-loaded with the rule model, then the schema-pointer warning, then the hard constraint. No filler and nothing repeated from structured fields.

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 destructive create tool with no output schema, annotations plus this description give enough to invoke correctly: the rule structure, where to source ids, and what cannot be created. The only omission is whether name uniqueness or duplicate rules are enforced.

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-level coverage is only 33%, but the nested descriptions on conditions and actions are exhaustive, and the description actively directs the agent to them ('the conditions and actions schemas list the exact attribute keys... use those, not values you have seen elsewhere'). It also points at sibling list tools that supply the required ids, compensating for the coverage gap.

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 and immediately defines the tool's mental model (event + conditions → actions), which distinguishes it from sibling update_automation_rule, toggle_automation_rule, and delete_automation_rule. An agent knows exactly what this creates without opening the schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives clear operational guidance: read list_labels / list_agents / list_teams / list_inboxes for the ids and titles needed, and warns against reusing values seen elsewhere. It does not explicitly state when to prefer this over update_automation_rule, but for a create tool the context is otherwise clear.

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

All HellouOne toolsInspect
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