Skip to main content
Glama
ptaramona

Conduyt MCP Server

by ptaramona
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Local

conduyt_create_automation

Create a new automation by specifying its name and trigger event, then build the action graph after converting human-readable names to UUIDs.

Instructions

Create a new automation. Requires a name and trigger event. Use conduyt_resolve_names to convert human-readable names to UUIDs before building actions.

Input Schema

NameRequiredDescriptionDefault
kindNoAutomation type — 'native' for the built-in graph engine (use `actions`), 'n8n' for an external n8n webhook (requires n8nWorkflowId + n8nWebhookUrl). For agent-built automations use 'native'.
nameYesAutomation name
actionsNoActions graph — v1: [{type, config}], v2: {nodes:[], startNodeId}
scheduleNo5-field cron expression (required if triggerEvent='scheduled')
descriptionNoDescription of what this automation does
graphVersionNoGraph version — 1 (legacy array) or 2 (node graph). Default 1
triggerEventYesTrigger event (e.g. 'contact.created', 'deal.stage_changed', 'tag.added', 'scheduled', or 'message.understood' — fires when the copilot has read an inbound text/email and understood its intent; list them all with conduyt_list_automation_events)
n8nWebhookUrlNon8n webhook URL (required when kind='n8n')
n8nWorkflowIdNon8n workflow ID (required when kind='n8n')
scheduleTimezoneNoIANA timezone for scheduled triggers (e.g. 'America/Los_Angeles')
triggerConditionsNoConditions that must match for the trigger to fire. Scalar filters like tagId/pipelineId/bookingPageIds, plus per-event config: for 'message.understood' filter on the reading with { filters: [{ field: 'trigger.intent', operator: 'equals', value: 'document_sent' }] } (intents: interested, question, callback_requested, appointment_confirm, appointment_cancel, document_sent, objection, not_interested, opt_out, wrong_number, unclear; also trigger.channel sms|email and trigger.sentiment positive|neutral|negative; {{trigger.summary}} / {{trigger.ask}} are merge fields downstream); for 'contact.untouched' pass { untouchedDays: N } (integer 1-365) to fire once per quiet episode when a contact has had no outreach for N+ days — without it the trigger is the minutes-scale speed-to-lead alert. Unknown keys on native events are rejected at create/publish (422).

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv4.71.0

TDQS

A3.5/5.0
Behavior2/5

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

With no annotations at all, the description carries the full burden, yet it discloses almost no behavior beyond required fields. It doesn't say whether the created automation is a draft requiring publish_automation, what permissions are needed, what happens to invalid trigger conditions, or what the response contains. Only the resolve_names hint adds workflow context.

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 short, front-loaded sentences with no filler: creation statement, prerequisites, and the resolve_names workflow hint. Every sentence carries actionable information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The rich parameter schema compensates for the thin description on inputs, but the tool has no annotations and no output schema. For a create tool in a family that includes publish_automation, the agent is left unsure whether the result is a live automation or a draft and what creation returns, which is a material gap.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema itself documents all 11 parameters, including enums and conditional requirements. The description only restates the two required fields and adds a helper pointer for actions, so the baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource ("Create a new automation"), clearly identifying the create operation among siblings like update_automation, publish_automation, and list_automations. It doesn't explicitly differentiate itself from those siblings, so it falls just short of a 5.

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?

It names the required fields (name and trigger event) and explicitly directs the agent to use conduyt_resolve_names before building actions, which is concrete usage guidance. It does not state when to prefer this over update_automation or publish_automation, keeping it at a 4 rather than 5.

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

Deploy Server

Other Tools