Get details of a specific automation workflow, optionally filtered by node type.
| Name | Required | Description | Default |
|---|---|---|---|
| api_key | No | MailerCloud API key | |
| node_type | No | Filter by node type | |
| automation_id | Yes | Automation ID,required |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the read-only safety profile is established. The description adds the node_type filter behavior, which slightly goes beyond the annotations, but it doesn't explain what 'details' includes or any authentication requirements. It aligns with annotations and adds modest value.
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 a single, tightly worded sentence with no filler. It front-loads the core action ('Get details of a specific automation workflow') before the optional qualifier ('optionally filtered by node type'). Every word contributes to understanding.
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 simple read-only get tool with all parameters documented in the schema and a full annotation set, the description is sufficient for correct invocation. The only missing piece is a description of the return payload format, but since no output schema exists and the tool is a straightforward get operation, this is not critical.
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 description coverage is 100%, with each parameter already documented in the input schema (automation_id is required, api_key is the MailerCloud key, node_type filters by node type). The description's mention of 'node type' simply echoes the schema, so it adds no meaningful new meaning.
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 states a specific verb and resource: 'Get details of a specific automation workflow'. It clearly distinguishes this from sibling tools like get_campaign, get_contact, and get_template, since none of the siblings target automations. The optional node_type filter further clarifies the tool's focused scope.
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 phrase 'a specific automation workflow' provides clear context that this tool is for retrieving a single automation by ID, not for listing or broad queries. It does not explicitly name alternatives or exclusions, but the resource 'automation workflow' is unique among siblings, making the intended use clear enough.
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.
Tool purposes are largely distinct, with clear separation between CRUD operations, analytics, and deliverability tools. Some overlap exists between get_campaign, analyze_campaign, and campaign_health_dashboard, but descriptions clarify scope sufficiently.
Most tools follow a consistent verb_noun pattern (list_, get_, create_, update_, delete_, send_). Minor exceptions like campaign_health_dashboard and engagement_funnel are descriptive but break the pattern.
With 47 tools, this is a very large surface area. While the variety reflects the breadth of email marketing operations, the count exceeds what is typically manageable and suggests potential redundancy or over-scoping.
The tool set covers most core workflows: contact/list management, campaign lifecycle, templates, webhooks, analytics, and transactional email. Minor gaps like no delete for templates or tags are acceptable but not fatal.
