build-action

Build Action

Purpose

Actions are what an agent can do beyond talking: call an API, extract data after the call, transfer, send an SMS, book, navigate an IVR, score the call, or email a summary. This skill builds them in the order that works:

plan → check prerequisites → create → initialize/test → attach → verify on a call

The MCP action tools have their own field names, which differ from the REST API and from the dashboard labels. Most failed action calls come from using the wrong field names, so follow the shapes below exactly, and read an existing action with get_action before changing it.

This playbook runs on the Synthflow MCP tools, whether they come from the plugin's bundled server or the official Synthflow connector.

Tools this uses

• list_actions, get_action — find existing actions; read exact field names before any update.
• list_integrations — required before booking or any provider-backed action.
• test_api_call — call the user's endpoint directly to see the real response before building on it.
• create_action — name, type, action_data.
• update_action — action_slug, update_data, confirmed.
• initialize_action — sends a test request for a custom action and activates it. Required after creating or changing one.
• attach_action_to_agent / detach_action_from_agent — model_id, action_slug, attachment_type (before, during, after), confirmed.
• get_agent_actions — what's attached to an agent now.
• list_webhook_logs, get_webhook_log_detail — request and response of real action executions, for debugging.

Some tool descriptions mention confirm_action and show_form. Those UI tools don't exist over MCP:

• Confirmation: state the change in the chat (action, agent, timing, what changes) and get the user's explicit yes before calling a tool with confirmed: true.
• Secrets: never ask the user to paste an API key or token into the chat, and never put one in action_data. Create the action without the credential and have the user add it in the action's settings in the Synthflow dashboard.