dialnexa

Voice AI on steroids! Docs: https://dialnexa.com/docs/mcp-tools/overview

该来源不提供完整文件导出（国内平台多为平台内托管），仅存元数据与原链

接入信息

传输形态: http
鉴权方式: 鉴权未知
端点: https://dialnexa--kamat.run.tools

鉴权方式未标注，请核对官方文档后再接入——不要直接使用以下片段

{
  "mcpServers": {
    "dialnexa": {
      "url": "https://dialnexa--kamat.run.tools"
    }
  }
}

能力清单

工具	说明
list_calls	Returns call logs for the organization, filterable by agent, status, sentiment, and date range. Use this when the user asks about call history or outcomes across multiple calls. For a single known call, use get_call instead.
get_call	Returns full details for a single call by its ID (e.g. call_abc123). Use list_calls first if you don't already have the ID.
get_call_details	Returns what actually HAPPENED on one call: its transcript, the post-call summary, notes, the recording link, and post-call-analysis field order. This is the only way to read a SINGLE call's transcript — get_call returns metadata (status, duration, cost) but never the conversation. Use it for "what did the agent say on that call?", "why did this one go wrong?", or to quote a caller's own words. Transcripts can be long; ask only for the fields you need.
get_call_retries	Returns the retry attempts made for a call, given the ORIGINAL (parent) call id. Retries are separate call records with no batch id of their own, so they do not show up in list_calls_in_batch or campaign counts — this is the only way to see them. Use it for "did it try again?", "how many attempts did this lead get?", or when a campaign's numbers do not add up. An empty list means no retries were made.
get_call_transfer	Returns whether a call was handed to a human (warm transfer) and how that went — which sessions were attempted and their status. Answers "did this reach a person?". Calls whose agent has no transfer step report had_call_transfer_node: false.
create_call	Places a real outbound phone call using one of the organization's agents. This is NOT a read-only action: it dials an actual phone number immediately and deducts from the organization's billing wallet on success. Only call this after the user has explicitly confirmed the phone number and intent — never as a guess or a way to "check" something. Requires the org to have verified KYC and sufficient wallet balance; fails with a clear error otherwise. Returns the new call's ID (e.g. call_abc123), which can be passed to get_call to check on its status afterward.
redact_call	Permanently masks a call's TRANSCRIPT and RECORDING while keeping the call record itself (status, duration, cost, outcome) intact. This is the tool for privacy and data-deletion requests — "delete the recording for that call", "remove what the caller said", a GDPR erasure ask. It CANNOT be undone and the audio is not recoverable, so never use it to tidy up or free space, and never as a side effect of another request. Requires confirm: true. If the user only wants to stop seeing it, say that this is irreversible and ask them to confirm that is what they want.
list_agents	Returns every voice agent in the organization as a compact roster — agent_id, name, type, current version number. This is the tool for resolving an agent NAME to an agent_id (names like "Nexa Agent 10" live here); it deliberately omits prompts, settings and version detail so the whole roster always fits in one result. Call get_agent with an id from here when you need full configuration.
get_agent	Returns full configuration for a single agent by ID (e.g. agent_abc123), including all versions with their functions, pronunciations, and post-call analysis config. Use list_agents first if you don't already have the ID.
create_agent	Creates a new voice agent for the organization. This is NOT a read-only action — it creates a real, persistent agent. prompt_text, language_id, and voice_id are required; everything else has sensible defaults. Use list_languages/list_voices/list_llms/list_transcribers first to get valid IDs. Only call this after the user has described what they want the agent to do — never as a guess.
update_agent	Updates a specific DRAFT version of an existing agent's configuration. This is NOT a read-only action. version_number is required — published versions cannot be updated (only re-published). Only fields you provide are changed — omit anything you don't want to touch. Use get_agent first to see current values and version numbers.
duplicate_agent	Clones an existing agent — copies its current version's prompt and every setting into a brand-new agent. Reversible: the copy is an unpublished DRAFT that makes no calls, and the original is untouched. Deliberately does NOT copy the phone-number binding, so the clone never starts answering the original's number. Use it for "make a copy of X so I can tweak it" or "same agent but for the Hindi market". Resolve the source with list_agents first.
delete_agent	Permanently deletes an agent. This is NOT reversible. Only call this after the user has explicitly confirmed they want THIS specific agent deleted — never as a guess, and never in response to an ambiguous request. Use get_agent first to confirm you have the right one. Requires confirm: true — only set this after the user has given explicit approval in this conversation, never preemptively.
list_llms	Returns the LLM providers/models available to use when configuring an agent (e.g. GPT-4, Claude). Use when the user asks what LLMs are available or wants to pick one for an agent.
get_llm	Returns details for a single LLM by ID (e.g. llm_abc123). Use list_llms first if you don't already have the ID.
list_fallback_llms	Returns the LLMs eligible to be configured as an agent’s fallback model (used if the primary LLM fails). Use when the user asks what fallback LLM options exist.
list_languages	Returns the languages available for agent voices and transcription. Use when the user asks what languages are supported or wants to configure agent language.
get_language	Returns details for a single language by ID (e.g. lang_abc123). Use list_languages first if you don't already have the ID.
list_voices	Returns available TTS voices for configuring an agent. Supports three modes via the mode param: standard catalog (filterable by provider/accent/gender/name), just the distinct accent values, or speech-to-speech-capable voices only.
get_voice	Returns details for a single voice by ID (e.g. voice_abc123). Use list_voices first if you don't already have the ID.
get_voice_languages	Returns the languages a specific voice supports, given its voice ID.
list_transcribers	Returns the speech-to-text transcriber options available for configuring an agent.
get_transcriber	Returns details for a single transcriber by ID (e.g. trs_abc123). Use list_transcribers first if you don't already have the ID.
list_fallback_transcribers	Returns transcribers with is_fallback=true — use this list to populate the Fallback STT selector when configuring per-agent STT fallback settings.
list_batch_calls	Returns the organization's batch call campaigns (bulk outbound call jobs), each with an id and title. Use this to find a batch_id before listing the calls inside it or its leads.
list_calls_in_batch	Returns the individual call logs that belong to a specific batch call campaign, given its batch_id. This is NOT a single-batch-details lookup — it's the calls made within that batch. Use list_batch_calls first to find the batch_id.
list_batch_call_leads	Returns the leads (contacts) uploaded into a specific batch call campaign, given its batch_id — phone number, notes, and dynamic variables per lead.
clean_batch_call_names	Suggests a cleaned-up natural first name for each raw name you pass in — same AI suggestion logic the dashboard's batch call upload wizard uses (extracts a first name, e.g. "Rai Rao" -> "Rai", strips titles, fixes casing). Read-only — it only returns suggestions, it does not change anything. Call this on the name column before create_batch_call, show the user original vs. suggested for each, let them accept/reject/edit, then build the final CSV using the confirmed names.
preview_batch_call_leads	Parses a small CSV/Excel leads file WITHOUT creating anything — same preview/validation the dashboard's batch call upload wizard runs before letting a batch start. Returns how many rows are valid vs. invalid, and for each invalid row, which phone number failed and why (bad country code, invalid length, destination not allowed by this org's calling rules, etc.). Use this on the file before create_batch_call: if invalid_row_count > 0, show the user the specific bad rows, get them fixed or dropped, then call create_batch_call with the corrected file. Same file_base64 size limit as create_batch_call (a few dozen rows).
create_batch_call	Creates a batch call campaign from a small lead list and starts dialing real phone numbers immediately. This is NOT a read-only action, spends real money, and cannot be undone once calls go out (the campaign itself can be cancelled afterward with update_batch_call_status, but any calls already placed are not). Requires confirm: true — only set this after the user has explicitly approved starting this specific batch, never preemptively. Only suitable for short lists (a few dozen leads at most) — for larger campaigns, tell the user to use the dashboard upload instead. Recommended order: clean_batch_call_names on the name column, then preview_batch_call_leads on the file, resolve any issues with the user, THEN call this. file_base64 must be the base64-encoded content of a CSV or Excel file with a phone_number column (and optionally name/other columns as dynamic variables). agent_version_number is required in practice — omitting it fails with "no outbound phone number found," since the org's phone number is bound to a specific agent+version pair, not just the agent. Use get_agent or list_agent_versions first to find the right version_number.
update_batch_call_status	Changes the execution status of a batch call. This is NOT a read-only action. pause halts new outbound calls (in-progress ones continue, can be resumed); resume continues a paused batch; cancel permanently stops it, removes queued calls, and marks call logs cancelled — it cannot be resumed or undone, and requires confirm: true (only set this after the user has explicitly approved cancelling this specific batch, never preemptively). pause/resume do not require confirm.
list_workflows	Returns the organization's automation workflows (multi-step call/WhatsApp sequences), each with an id and name. Use this to find a workflow_id before inspecting its leads.
get_workflow	Returns details for a single workflow by ID (e.g. workflow_abc123). Use list_workflows first if you don't already have the ID.
list_workflow_leads	Returns the leads enrolled in a workflow along with their current execution status (which step they're on, when they entered, when they completed). Optionally filter to specific lead IDs.
get_workflow_lead_variable_keys	Returns the distinct dynamic variable names (from the uploaded lead CSV columns) available for a workflow's leads — e.g. to know what personalization fields exist.
get_workflow_lead_history	Returns the full execution history for one lead within a workflow — every step it passed through, timestamps, and current status. Use list_workflow_leads first to find the lead_id.
update_workflow_status	Changes the execution status of a workflow. This is NOT a read-only action. Valid actions: activate (start, must be in draft status; blocking validation errors fail the call — common causes: multiple or zero entry nodes, unreachable nodes, missing CONVERTED/DROPPED nodes, call get_workflow_structure first to catch these before activating) and resume (continue a paused workflow) both return non-blocking warnings in the response when present — e.g. the agent bound to a call node changed since this workflow was last configured — relay these to the user rather than ignoring them. pause/deactivate (halt new leads entering, in-progress ones continue) has no such warnings.
remove_workflow_lead	Removes a single lead from a workflow. This is NOT reversible. Use list_workflow_leads first to find the lead_id. Requires confirm: true — only set this after the user has explicitly approved removing this specific lead, never preemptively.
list_knowledge_base_documents	Returns the organization's knowledge base entries used to ground agent responses. Use this to find a kb_id before fetching a specific document.
get_knowledge_base_document	Returns a single knowledge base document by ID (e.g. kb_abc123). Use list_knowledge_base_documents first if you don't already have the ID.
get_knowledge_base_affected_agents	Returns the agents that currently use this knowledge base. Call it BEFORE proposing delete_knowledge_base or any change to a KB, so the user is told which agents lose that knowledge by name rather than in the abstract. An empty list means nothing is attached and deleting is safe.
create_knowledge_base	Creates a new, empty named knowledge base container for the organization. This is NOT a read-only action. Note: this only creates the container — adding documents/content to it requires a file upload that is not available through this tool; that has to be done from the dashboard.
update_knowledge_base	Renames a knowledge base container. This is NOT a read-only action.
delete_knowledge_base	Permanently deletes a knowledge base and its documents. This is NOT reversible, and fails if the knowledge base is still attached to any agent. Requires confirm: true — only set this after the user has explicitly approved deleting this specific knowledge base, never preemptively.
list_organization_phone_numbers	Returns phone numbers owned by the organization, including which agent (if any) is assigned inbound/outbound on each.
get_organization_phone_number	Returns details for one of the organization's phone numbers by ID (e.g. phn_abc123).
search_plivo_numbers	Searches Plivo for phone numbers available to purchase in a given country. Use type to filter local/tollfree/mobile and region for city/state. This searches a provider catalog, not the org's owned numbers — use list_organization_phone_numbers for those.
get_phone_number_active_workflows	Returns the ACTIVE workflows that dial through this phone number. Call it BEFORE proposing delete_phone_number or reassigning a number, so the user knows what stops working — releasing a number that a live workflow calls through breaks that workflow mid-run. An empty list means nothing active depends on it. Paused workflows are deliberately excluded: they are not blocking.
purchase_phone_number	Purchases a phone number from Plivo and registers it to the organization. This is NOT a read-only action — it spends real money from the organization's wallet immediately. Use search_plivo_numbers first to find an available number and its telephony_provider_id. Requires confirm: true — only set this after the user has explicitly approved buying this specific number, never preemptively.
create_sip_trunk	Links an organization-owned SIP trunk phone number for outbound/inbound calling. This is NOT a read-only action. Only call this after the user has provided real SIP termination details — never as a guess or with placeholder values.
delete_phone_number	Releases/deletes one of the organization's phone numbers. This is NOT reversible. Use get_organization_phone_number first to confirm you have the right one. Requires confirm: true — only set this after the user has explicitly approved removing this specific number, never preemptively.
list_user_webhooks	Returns the organization's configured outbound webhooks (URLs notified on events like call completion). Secrets are masked.
get_user_webhook	Returns details for a single webhook by ID (e.g. webhook_abc123). Secret is masked.
get_external_webhook	Returns the organization's external webhook configuration — the endpoint DialNexa posts call results to, and its settings. Answers "where do my call results go?" and "is a webhook set up?". Returns null when none is configured. Separate from list_user_webhooks, which covers per-agent webhooks.
list_templates	Returns the platform's catalog of pre-built agent templates, optionally filtered by agent type. Use this when the user wants to start from a template rather than build an agent from scratch.
get_template	Returns details for a single agent template by ID. Use list_templates first if you don't already have the ID.
get_spend_limits	Returns the organization's monthly spend cap, its early-warning alert threshold, how much has been spent so far this month, and when the month resets — all in INR. Pair this with get_wallet_balance for any "how much can I still spend" question: a large wallet behind a small monthly cap is not the runway the balance alone suggests. A null limit means no cap is set.
get_billing_alert_emails	Returns the email addresses that receive this organization's balance and spend alerts. An empty list means alerts fall back to the organization owner.
get_wallet_balance	Returns the organization's current billing wallet balance in INR — the money left to spend on calls. This is the SAME balance the dashboard sidebar shows, and it is the tool to use for any "how many credits / how much balance do I have left" question. The other billing tools return the plan and rate CATALOG, not what is left. Orgs still on the legacy credit system have no INR wallet; this reports that explicitly rather than returning zero.
list_billing_plans	Returns the platform's catalog of available billing plans (pricing tiers).
get_billing_plan	Returns details for a single billing plan by ID. Use list_billing_plans first if you don't already have the ID.
get_billing_plan_sip_rate	Returns the organization's current SIP call rate (INR), based on its assigned billing plan.
get_agent_builder_inventory	Returns the catalog of building blocks available to the agent builder — LLMs, transcribers, languages, and other resolver options usable when configuring an agent.
get_prompt_suggestions_for_agent	Returns pending AI-generated prompt improvement suggestions for a specific agent, based on recent call analysis.
list_campaigns	Returns the organization's batch call campaigns with pagination, optionally filtered by status. Use this to find a batch_id before looking up its details or status.
get_campaign	Returns details for a single campaign by ID (e.g. batch_abc123). Use list_campaigns first if you don't already have the ID.
get_campaign_status	Returns the current control status (running/paused/completed/etc.) and available actions for a campaign, given its batch_id.
delete_campaign	Deletes a campaign from the organization's list — the same delete the dashboard offers on a draft campaign. Removes the campaign only; calls it already placed keep their own records. Allowed for campaigns that are not live: draft, completed, or cancelled. A campaign that is still going (running, paused, scheduled, waiting) CANNOT be deleted — cancel it first with update_batch_call_status, then delete. Requires confirm: true, and this cannot be undone.
list_organization_folders	Returns the folders used to organize the organization's agents, optionally filtered by name. Use this to find a folder id before filtering agents by folder.
create_organization_folder	Creates a folder for grouping agents. Reversible — folders hold no data of their own, and deleting one does not delete the agents inside it. Use move_agent_to_folder afterwards to file agents into it.
update_organization_folder	Renames a folder. Reversible, and the agents inside it are untouched. Use list_organization_folders first to get the id.
delete_organization_folder	Deletes a folder. The agents inside it are NOT deleted — they become unfiled. Requires confirm: true. Say plainly that the agents survive, so the user is not scared off a harmless cleanup, and do not describe this as deleting agents.
move_agent_to_folder	Files an agent into a folder, or removes it from one. Purely organisational and reversible: it changes nothing about how the agent behaves, dials or is billed. Resolve the agent with list_agents and the folder with list_organization_folders first.
list_phone_number_pricing	Returns phone number rental pricing by telephony provider and country. Use when the user asks how much a phone number costs in a given country.
list_countries	Returns the global list of countries phone numbers/calls can be configured for, with their country codes. This is reference data, not org-specific — use list_org_phone_country_rules for what the organization has actually enabled.
list_org_phone_country_rules	Returns the organization's configured rules per country (e.g. allowed prefixes, dialing mode) for outbound calling.
list_enabled_network_groups	Returns the telephony network groups currently enabled for the organization's outbound calling.
list_agent_versions	Returns all versions of a given agent, given its agent_id. Use list_agents first if you don't already have the agent_id.
get_agent_version	Returns full configuration for a single version of an agent, given its agent_id and version_number, including functions, voice, LLM, and transcriber config.
list_agent_functions	Returns the tool/function definitions (e.g. transfer call, book appointment, custom API calls) configured on a specific agent version. Credential-shaped config values (API keys, tokens, auth headers) are redacted. Use get_agent_version first if you don't already have the version_number.
get_dashboard_stats	Returns the organization's call/agent/onboarding summary stats — the same numbers shown on the dashboard home page.
get_dashboard_weekly_stats	Returns the organization's call volume for each of the last 7 days.
list_active_agents	Returns the organization's currently active agents (status active, with an inbound or outbound number assigned) — a lighter-weight view than list_agents, used on the dashboard home page.
get_my_organization	Returns basic details (name, plan, settings) about the caller's own organization. Takes no arguments — always returns the organization the API key belongs to, never another org.
create_workflow	Creates a new, empty workflow shell (status: draft) for the organization. This is NOT a read-only action. This only creates the workflow itself — it has no nodes or connections yet. Follow up with add_workflow_node to build out the flow, then add_workflow_edge to connect nodes, then update_workflow_status with action "activate" once the graph is complete. Exactly 6 node types exist, each with its own required config shape: - VOICE_CALL: config = { phone_number_id: "phn_abc123", outputs: { COMPLETED?: node_id, DNP?: node_id, FAILED?: node_id } }. Places a call using the agent bound to that phone number. outputs can be created empty ({}) — this is the ONE node type you can create before its targets exist, then wire up later with add_workflow_edge. - CONDITIONAL: config = { conditions: [{ field: "dynamic_variables.status", operator: "equals"\|"not_equals"\|"exists"\|"contains"\|"greater_than"\|"less_than", value: "..." }], logical_operator: "AND"\|"OR", outputs: { true: node_id, false: node_id } }. Both outputs.true and outputs.false are REQUIRED AT CREATION TIME — unlike VOICE_CALL, you cannot create this node first and wire it later. Create its true/false target nodes FIRST, then create this node with both real target ids already in outputs. - TIME: config = { duration: { value: 24, unit: "minutes"\|"hours"\|"days" }, output: node_id } to wait a fixed duration, OR { time_source: "postcall_analysis", pca_field: "Time of Callback", output: node_id } to wait until a post-call-analysis field's value. output is REQUIRED AT CREATION TIME, same constraint as CONDITIONAL — create the target node first. - APPLICATION: config = { application_integration: "whatsapp", wati_template_name: "template_name", wati_template_params: ["param1","param2"], output: node_id }. WhatsApp (via Wati templates) is the ONLY application integration this tool supports — if the user asks for a different integration (email, Slack, etc.), tell them it isn't available here rather than guessing a config shape for it. output is REQUIRED AT CREATION TIME, same constraint as CONDITIONAL/TIME. - CONVERTED / DROPPED: terminal nodes, config = {} (or omit), no outputs concept at all. Every workflow needs at least one of each before it can be activated. They can never be the SOURCE of an edge — execution stops there. Build order matters and differs by node type: VOICE_CALL nodes can be created empty and connected later. CONDITIONAL/TIME/APPLICATION nodes CANNOT — their target node(s) must already exist before you create them, with the real target id(s) already in outputs/output (the underlying validation rejects creating them otherwise). A practical order: create terminal nodes (CONVERTED/DROPPED) and any VOICE_CALL nodes first, then build CONDITIONAL/TIME/APPLICATION nodes working backwards from those targets, filling in real ids as you go. Regardless of node type, ALWAYS follow up by calling add_workflow_edge for every connection, even ones already set inline in a node's outputs/output at creation time — add_workflow_edge is what creates the structural connection (workflow_edges) that activation's reachability check reads; setting outputs/output directly only sets the runtime routing, not the structural connection, so skipping add_workflow_edge means activation will report the target as unreachable even though it would work fine at call time. Calling add_workflow_edge for a pair whose config is already correct is safe — it just confirms the structural edge, no error. Graph shape rules — these are ONLY checked when you activate (update_workflow_status, action "activate"), never while you're adding nodes/edges, so a graph can look finished and still fail to activate if you didn't keep these in mind while building: 1. Exactly ONE node may have zero incoming edges — that's the entry point every lead starts at. Every other node needs at least one incoming edge from add_workflow_edge. Two disconnected starting points, or a node nobody points to, both fail activation. 2. Every node must be reachable from that entry point by following edges forward — a node created but never wired to anything fails activation as unreachable. 3. No cycles, ever — this one IS checked immediately on add_workflow_edge (rejected and rolled back on the spot), not deferred. 4. At least one CONVERTED and one DROPPED node must exist and be reachable. Before calling update_workflow_status with action "activate", call get_workflow_structure and check points 1, 2, and 4 yourself — catching a broken connection there is far clearer for the user than an activation error.
get_workflow_structure	Returns all nodes and edges currently in a workflow's graph — use this to see the current build state before deciding what to add next, to find node ids to connect with add_workflow_edge, and as a final self-check before activating (confirm exactly one node has no incoming edge, every other node has at least one, and a CONVERTED and DROPPED node both exist and are connected).
add_workflow_node	Adds a single node to an existing workflow. This is NOT a read-only action. Exactly 6 node types exist, each with its own required config shape: - VOICE_CALL: config = { phone_number_id: "phn_abc123", outputs: { COMPLETED?: node_id, DNP?: node_id, FAILED?: node_id } }. Places a call using the agent bound to that phone number. outputs can be created empty ({}) — this is the ONE node type you can create before its targets exist, then wire up later with add_workflow_edge. - CONDITIONAL: config = { conditions: [{ field: "dynamic_variables.status", operator: "equals"\|"not_equals"\|"exists"\|"contains"\|"greater_than"\|"less_than", value: "..." }], logical_operator: "AND"\|"OR", outputs: { true: node_id, false: node_id } }. Both outputs.true and outputs.false are REQUIRED AT CREATION TIME — unlike VOICE_CALL, you cannot create this node first and wire it later. Create its true/false target nodes FIRST, then create this node with both real target ids already in outputs. - TIME: config = { duration: { value: 24, unit: "minutes"\|"hours"\|"days" }, output: node_id } to wait a fixed duration, OR { time_source: "postcall_analysis", pca_field: "Time of Callback", output: node_id } to wait until a post-call-analysis field's value. output is REQUIRED AT CREATION TIME, same constraint as CONDITIONAL — create the target node first. - APPLICATION: config = { application_integration: "whatsapp", wati_template_name: "template_name", wati_template_params: ["param1","param2"], output: node_id }. WhatsApp (via Wati templates) is the ONLY application integration this tool supports — if the user asks for a different integration (email, Slack, etc.), tell them it isn't available here rather than guessing a config shape for it. output is REQUIRED AT CREATION TIME, same constraint as CONDITIONAL/TIME. - CONVERTED / DROPPED: terminal nodes, config = {} (or omit), no outputs concept at all. Every workflow needs at least one of each before it can be activated. They can never be the SOURCE of an edge — execution stops there. Build order matters and differs by node type: VOICE_CALL nodes can be created empty and connected later. CONDITIONAL/TIME/APPLICATION nodes CANNOT — their target node(s) must already exist before you create them, with the real target id(s) already in outputs/output (the underlying validation rejects creating them otherwise). A practical order: create terminal nodes (CONVERTED/DROPPED) and any VOICE_CALL nodes first, then build CONDITIONAL/TIME/APPLICATION nodes working backwards from those targets, filling in real ids as you go. Regardless of node type, ALWAYS follow up by calling add_workflow_edge for every connection, even ones already set inline in a node's outputs/output at creation time — add_workflow_edge is what creates the structural connection (workflow_edges) that activation's reachability check reads; setting outputs/output directly only sets the runtime routing, not the structural connection, so skipping add_workflow_edge means activation will report the target as unreachable even though it would work fine at call time. Calling add_workflow_edge for a pair whose config is already correct is safe — it just confirms the structural edge, no error. Graph shape rules — these are ONLY checked when you activate (update_workflow_status, action "activate"), never while you're adding nodes/edges, so a graph can look finished and still fail to activate if you didn't keep these in mind while building: 1. Exactly ONE node may have zero incoming edges — that's the entry point every lead starts at. Every other node needs at least one incoming edge from add_workflow_edge. Two disconnected starting points, or a node nobody points to, both fail activation. 2. Every node must be reachable from that entry point by following edges forward — a node created but never wired to anything fails activation as unreachable. 3. No cycles, ever — this one IS checked immediately on add_workflow_edge (rejected and rolled back on the spot), not deferred. 4. At least one CONVERTED and one DROPPED node must exist and be reachable. Before calling update_workflow_status with action "activate", call get_workflow_structure and check points 1, 2, and 4 yourself — catching a broken connection there is far clearer for the user than an activation error. Adding a node does not connect it to anything by itself — use add_workflow_edge afterward, or reference other node ids directly inside this node's outputs/output config.
update_workflow_node	Updates an existing node's label and/or config (e.g. to fill in outputs once the target nodes exist, or fix a mistake). This is NOT a read-only action. Only fields you provide are changed. Exactly 6 node types exist, each with its own required config shape: - VOICE_CALL: config = { phone_number_id: "phn_abc123", outputs: { COMPLETED?: node_id, DNP?: node_id, FAILED?: node_id } }. Places a call using the agent bound to that phone number. outputs can be created empty ({}) — this is the ONE node type you can create before its targets exist, then wire up later with add_workflow_edge. - CONDITIONAL: config = { conditions: [{ field: "dynamic_variables.status", operator: "equals"\|"not_equals"\|"exists"\|"contains"\|"greater_than"\|"less_than", value: "..." }], logical_operator: "AND"\|"OR", outputs: { true: node_id, false: node_id } }. Both outputs.true and outputs.false are REQUIRED AT CREATION TIME — unlike VOICE_CALL, you cannot create this node first and wire it later. Create its true/false target nodes FIRST, then create this node with both real target ids already in outputs. - TIME: config = { duration: { value: 24, unit: "minutes"\|"hours"\|"days" }, output: node_id } to wait a fixed duration, OR { time_source: "postcall_analysis", pca_field: "Time of Callback", output: node_id } to wait until a post-call-analysis field's value. output is REQUIRED AT CREATION TIME, same constraint as CONDITIONAL — create the target node first. - APPLICATION: config = { application_integration: "whatsapp", wati_template_name: "template_name", wati_template_params: ["param1","param2"], output: node_id }. WhatsApp (via Wati templates) is the ONLY application integration this tool supports — if the user asks for a different integration (email, Slack, etc.), tell them it isn't available here rather than guessing a config shape for it. output is REQUIRED AT CREATION TIME, same constraint as CONDITIONAL/TIME. - CONVERTED / DROPPED: terminal nodes, config = {} (or omit), no outputs concept at all. Every workflow needs at least one of each before it can be activated. They can never be the SOURCE of an edge — execution stops there. Build order matters and differs by node type: VOICE_CALL nodes can be created empty and connected later. CONDITIONAL/TIME/APPLICATION nodes CANNOT — their target node(s) must already exist before you create them, with the real target id(s) already in outputs/output (the underlying validation rejects creating them otherwise). A practical order: create terminal nodes (CONVERTED/DROPPED) and any VOICE_CALL nodes first, then build CONDITIONAL/TIME/APPLICATION nodes working backwards from those targets, filling in real ids as you go. Regardless of node type, ALWAYS follow up by calling add_workflow_edge for every connection, even ones already set inline in a node's outputs/output at creation time — add_workflow_edge is what creates the structural connection (workflow_edges) that activation's reachability check reads; setting outputs/output directly only sets the runtime routing, not the structural connection, so skipping add_workflow_edge means activation will report the target as unreachable even though it would work fine at call time. Calling add_workflow_edge for a pair whose config is already correct is safe — it just confirms the structural edge, no error. Graph shape rules — these are ONLY checked when you activate (update_workflow_status, action "activate"), never while you're adding nodes/edges, so a graph can look finished and still fail to activate if you didn't keep these in mind while building: 1. Exactly ONE node may have zero incoming edges — that's the entry point every lead starts at. Every other node needs at least one incoming edge from add_workflow_edge. Two disconnected starting points, or a node nobody points to, both fail activation. 2. Every node must be reachable from that entry point by following edges forward — a node created but never wired to anything fails activation as unreachable. 3. No cycles, ever — this one IS checked immediately on add_workflow_edge (rejected and rolled back on the spot), not deferred. 4. At least one CONVERTED and one DROPPED node must exist and be reachable. Before calling update_workflow_status with action "activate", call get_workflow_structure and check points 1, 2, and 4 yourself — catching a broken connection there is far clearer for the user than an activation error.
delete_workflow_node	Permanently deletes a node from a workflow AND any edges connecting to or from it (cascades automatically), also clearing the matching routing entry on any node that pointed to it. This is NOT reversible. Requires confirm: true — only set this after the user has explicitly approved deleting this specific node, never preemptively.
add_workflow_edge	Connects two existing nodes in a workflow with a directed edge — this is the recommended way to connect nodes, since it automatically keeps the source node's routing config (config.outputs/config.output, what the execution engine actually reads at call time) in sync with the edge. This is NOT a read-only action. Rejected (and automatically rolled back) if it would create a cycle in the graph. Adding the same edge twice is safe — it just returns the existing one rather than erroring. label is REQUIRED and must be exactly "COMPLETED", "DNP", or "FAILED" when the source is a VOICE_CALL node, or exactly "true"/"false" when the source is CONDITIONAL — these are the literal keys the execution engine looks up, not just display text. label is optional for TIME/APPLICATION sources (they have only one next-node slot) and unused for CONVERTED/DROPPED sources (terminal, no next node).
delete_workflow_edge	Removes a single connection between two nodes, and clears the matching entry from the source node's routing config (config.outputs/config.output) so it can't keep silently routing to a node with no structural edge behind it. This is NOT reversible, though re-adding it with add_workflow_edge is straightforward if needed. Edges FROM a CONDITIONAL/TIME/APPLICATION node cannot be deleted outright — those node types always require every route to be set (validateNodeConfig rejects clearing it), so removing one would leave the node in a state it can never be saved in again. Use add_workflow_edge with a different to_node_id to REPLACE where such a route points instead.
list_integrations	Returns every integration available to the organization — provider/adapter keys, what each does, and current connection status (connected/disconnected/error, with a masked credential hint if connected). Use this first to find valid provider_key/adapter_key values before calling any other integration tool.
create_integration_connect_token	Starts a hosted OAuth connection flow for an integration and returns a URL — send the user that URL to click and finish connecting there (e.g. logging into Slack). This is NOT a read-only action, though it never handles the user's actual credentials directly (that happens on the provider's own hosted login page). Not every adapter supports this — some require pasting an API key directly into the dashboard instead, which isn't available through this tool. Use list_integrations first to find valid provider_key/adapter_key values.
validate_integration_connection	Re-checks an existing integration connection against the provider and updates its stored status (connected/error). Use this if a connection looks stale or the user reports it's not working. Fails if there's no connection at all yet for this provider/adapter — use create_integration_connect_token first in that case.
disconnect_integration	Disconnects an integration. This takes effect immediately — anything currently relying on this connection (agent functions, workflow application nodes) will stop working until it's reconnected. Reversible by reconnecting, but not instantaneous (the user has to go through the connect flow again), so requires confirm: true — only set this after the user has explicitly approved disconnecting this specific integration, never preemptively.
request_integration_access	Requests access to an integration that's currently disabled by admin — posts a notification for the team to review, it does not enable the integration itself. Use list_integrations first to check whether the tool is actually disabled (this fails if it's already enabled).

纠错与举报（发现条目失效、署名有误或涉及侵权？）

提交举报 / 纠错

侵权举报经核验成立后，我们会即时下线该条目并删除已存的内容副本。