Create an automation workflow from a trigger and an ordered list of steps. Created paused by default — call toggle_automation to activate once the steps are reviewed.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Automation name | |
| steps | No | Ordered workflow steps | |
| active | No | Start active immediately (default false) | |
| trigger | Yes | Event that starts the workflow | |
| trigger_config | No | Trigger parameters, e.g. { "tag": "trial" } for tag_added |
Changes observed during successful MCP inspections. Dates show when Glama detected each change.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate a write operation (readOnlyHint=false) but provide no other behavioral clues. The description adds critical behavior: 'Created paused by default'. This is a key trait that influences when and how the tool should be used. It doesn't disclose return value or error cases, but the paused behavior is significant and well-stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no wasted words. The first sentence states the purpose, the second adds the critical behavioral note. Front-loaded and efficient – every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 5 parameters, 2 required, nested objects, and no output schema, the description covers the primary purpose and the important paused-by-default behavior. However, it lacks mention of the return value (likely the created automation ID) and doesn't clarify that steps are optional despite being referenced as a core component. Still, the schema fills many gaps, making this description adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description does not add meaning beyond the schema; it simply restates 'trigger and an ordered list of steps' which is already present in the schema descriptions. It provides no examples, clarifies optional fields (steps is not required but is implied), or explains trigger_config. No extra semantic value is added.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Create an automation workflow') and specifies the key components ('from a trigger and an ordered list of steps'). It distinguishes the tool from siblings like toggle_automation by noting that the automation is created paused by default, requiring a separate activation step.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells the agent when to use this tool (to create an automation workflow) and what to do afterwards ('call toggle_automation to activate once the steps are reviewed'). It also implies a workflow: create, review, then activate. This provides clear context for usage compared to alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Most tools are cleanly separated by resource and action, and the descriptions do a good job of cross-referencing related tools. However, there are several close clusters—get_analytics vs generate_report, get_deliverability_score vs run_deliverability_audit, check_dmarc vs verify_domain, and list_emails vs list_inbox_conversations vs get_email—that could cause an agent to pick the wrong one. The detailed descriptions reduce but do not eliminate this ambiguity.
Tool names follow a consistent snake_case verb_noun pattern throughout: create_, get_, list_, send_, toggle_, and so on. Even multi-word actions like select_ab_test_winner and categorize_inbox_emails stay uniform. The only slight deviation is the bare verb upgrade, but it is readable and does not break the overall pattern.
54 tools is far beyond the typical well-scoped MCP surface and lands heavily in the 'too many' range. While the domain is broad, many tools could be consolidated—multiple analytics/reporting tools, several deliverability checks, and separate email/inbox listing tools create redundancy. The sheer number increases selection overhead and makes the toolset harder for an agent to navigate reliably.
The core email marketing lifecycle is represented: domains, contacts, campaigns, templates, automations, sends, and analytics all have main operations. However, there are notable gaps—no update/delete for campaigns, templates, forms, or automations; no create/update/delete for forms; no sandbox enable/disable; and no way to install marketplace items. These are workable gaps but would cause failures for agents trying to perform full lifecycle management.