Retrieve all automations in a Conduyt account with their name, trigger event, status, and execution counts. Paginate results to review workflows and monitor performance.
List all automations (workflows) in the account. Returns name, trigger event, status, and execution counts.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Page number (default 1) | |
| per_page | No | Results per page (default 25, max 100) |
Changes observed during successful MCP inspections.
v4.71.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the behavioral burden; it does disclose the returned fields (name, trigger event, status, execution counts), which is genuinely useful given there is no output schema. However, it says nothing about pagination behavior beyond the schema, result ordering, or permission requirements for reading automations, so disclosure is partial.
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?
Two tight sentences with the purpose front-loaded and the return payload immediately after; every word earns its place and there is no filler.
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 list tool with zero required parameters, the combination of the description's return-field summary and the fully documented pagination schema covers nearly everything needed to invoke it. The only gap is that large result sets and their ordering are not hinted at, and no output schema exists to compensate.
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?
Both parameters (page, per_page) have 100% schema description coverage including defaults and the max-100 cap, so the schema already does the work. The description adds no pagination or ordering guidance, which fits the baseline-3 case where the schema handles parameter 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?
States a specific verb and resource ('List all automations') and pre-empts the terminology ambiguity by glossing it as '(workflows)'. It is clear what the tool returns, though it does not explicitly distinguish itself from adjacent listing siblings such as conduyt_list_drip_campaigns or conduyt_list_sequences.
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?
There is no statement of when to use this versus alternatives — no mention of conduyt_get_automation for single-record detail, nor of any filter conditions. The 'in the account' scope is the only contextual hint, leaving the agent to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.