Each canonical purpose below is copied verbatim from the server manifest. Names, scopes, required top-level inputs, operation modes, and contract safeguards are generated from the same snapshot.
Your connected client’s
tools/list response is authoritative for the server it reaches. It includes the complete JSON Schema. If its count differs from this pinned snapshot, review the server revision before automating writes.The catalog still lists
create_client_tool, update_client_tool, assign_tool_to_workflow, configure_customer_api_tool, create_workflow_tool, and update_workflow_tool because those tools exist in tools/list. Creating, editing, or assigning a custom HTTP destination is temporarily not a supported public operation while Nexor hardens destination validation. Do not use these tools to configure a destination until this notice is removed.How to read the catalog
Read means the manifest declares no write scope. Write means the call may change state. A safeguard names only what the tool contract exposes. No contract flag is not permission to skip operator approval for a consequential action.
Task voice (2)
Task voice (2)
| Tool | Scope | Mode | Required top-level input | Safeguard or availability | Canonical purpose |
|---|---|---|---|---|---|
prepare_agent_task_voice | workflows:write | Write | master_workflow_id | No contract flag | Prepare the selected paused agent’s composed tasks for voice, including template and authored tasks. Queues destination-first flow generation and verifies same-call swaps. Idempotent retries preserve completed work. Does not activate tasks, assign channels/numbers, call leads or book meetings. Preparing is not ready: use get_agent_task_voice_preparation to inspect the result. Calendar/channel setup remains separate. |
get_agent_task_voice_preparation | workflows:read | Read | master_workflow_id | No contract flag | Inspect preparation of a paused agent’s composed voice tasks. Top-level status is not_started (nothing queued: call prepare_agent_task_voice), preparing (running: wait), pending (not ready after the last run: call prepare again), failed, republish_required (the prepared voice of the open draft still includes a tool now handled by an automation; preparing again does not fix it, republish the agent) or ready; per-task statuses are informational, from saved flow state and background-job evidence, plus pending workflow and error code. Ready means voice artifacts are prepared, not activated, calendar/channel ready or audio-tested. Inspect after creation or retry; never invent success from a queued job. |
Agent integration flows (13)
Agent integration flows (13)
| Tool | Scope | Mode | Required top-level input | Safeguard or availability | Canonical purpose |
|---|---|---|---|---|---|
list_agent_hubspot_inbound_options | workflows:read | Read | workflow_id | No contract flag | Read contact properties, including calculated/read-only values, for shared HubSpot intake data. These values go into the shared contact, not private agent fields. Use get_agent_integration_flows to inspect current settings, draft, affected agents and revision. Reading does not import or activate anything. |
change_agent_hubspot_inbound | workflows:write | Write | workflow_id, connection_id, expected_revision, action | confirm: true | Prepare/apply HubSpot intake mappings and optional metadata-to-Variable bindings for one task (scope=task). Legacy shared mode must be explicitly reviewed. Read flows and inbound options first. configure saves the complete patch as a draft without changing current imports: phone_priority (ordered property names) and extra_properties (hubspot_property, metadata_key). apply requires confirm=true after explaining the exact draft, the actual affected tasks from the read-back, including changed phone selection; it affects future imports/updates only and does not start intake, replay history or delete stored data. discard removes only the draft. Requires permission over every affected agent; revision, account or legacy-edit conflicts require fresh review. Read committed state before reporting success. |
list_agent_kommo_pipelines | workflows:read | Read | workflow_id | No contract flag | Read verified Kommo pipelines and stages for the selected agent before changing an existing route. Returns account identity and available destination stages. Reading never imports or moves cards. |
change_agent_kommo_route | workflows:write | Write | workflow_id, connection_id, action | confirm: true | Create, configure, pause, activate or remove ONE Kommo route for ONE agent. Read get_agent_integration_flows and list_agent_kommo_pipelines first. create saves a new pipeline/source/destination route paused. configure changes pipeline_id, source_status_id, destination_status_id and optionally ingest_unsorted (primary route only, with expected_ingest_unsorted), pausing changes; it moves the same imported card, not arbitrary CRM records. activate can import existing and new cards from the source stage and start lead contact; explain this before confirm=true. pause stops future intake but does not undo imports or disconnect the account. remove deletes this route and disables unsorted acceptance if it was the primary route; it preserves imported contacts. Activation, pause and removal need operator agreement. Preserve other agents; reread after conflicts; report success from committed read-back. crm_agent_inactive (next_action=activate_task): with agreement, set_workflow_active on its workflow_id, then retry. |
list_agent_hubspot_lists | workflows:read | Read | workflow_id | No contract flag | Read the current HubSpot contact-list catalog for an agent mode. Returns verified list IDs, names, connection identity and whether a list is already configured. Choose an unassigned list for change_agent_hubspot_list(action=create); do not invent IDs or duplicate an existing legacy route. Reading this catalog does not import contacts. |
list_agent_hubspot_field_options | workflows:read | Read | workflow_id | No contract flag | Read exact source identities for this agent’s fields, canonical lead data and derived activity (status, summary, collected data, last sent message, worked marker), plus writable contact properties and enum options from its HubSpot account. Also reports verified, unknown or denied contact-write permission. Derived activity is limited to the triggering run. Use source IDs as returned; never match an agent field by name alone. Reading does not change contacts. |
change_agent_hubspot_fields | workflows:write | Write | workflow_id, connection_id, expected_revision, action | confirm: true | Configure, activate or pause ONE agent’s HubSpot contact-field output. Read get_agent_integration_flows and list_agent_hubspot_field_options first. configure replaces only this agent’s output mapping, overriding the shared mapping for its leads, and keeps its state: a sending output keeps sending only if activation checks pass, else nothing is saved; a paused one stays paused. Get agreement before changing a sending output. Each mapping: verified source ID (lead and agent fields differ), hubspot_property, optional enum value_mapping, write_once. Activation requires verified write permission and rejects another agent writing the same property; never disable another agent to bypass it. activate/pause require agreement and confirm=true. Activation affects only future changes on linked contacts; no replay or contact creation. Report success only from committed read-back; reread revision conflicts. crm_agent_inactive (next_action=activate_task): with agreement, set_workflow_active on its workflow_id, then retry. |
list_agent_hubspot_status_options | workflows:read | Read | workflow_id | No contract flag | Read this agent mode’s status keys and the account’s actual writable hs_lead_status enum options before configuring its status output. No CRM writes or imports. |
change_agent_hubspot_status | workflows:write | Write | workflow_id, connection_id, expected_revision, action | confirm: true | Configure, activate or pause the hs_lead_status output of ONE agent mode. Read get_agent_integration_flows and list_agent_hubspot_status_options first. configure writes patch.mapping (agent status key to actual HubSpot enum value) and leaves this output paused. Inherited mapping becomes agent-specific. activate/pause require confirm=true after agreement; activation handles future status changes on linked contacts, never creates contacts or enables account activities/field sync. Other agents and shared settings are preserved. Expected revision prevents stale edits. Use the committed read-back to report success. crm_agent_inactive (next_action=activate_task): with agreement, set_workflow_active on its workflow_id, then retry. |
get_agent_hubspot_import_status | workflows:read | Read | workflow_id, connection_id, route_key | No contract flag | Read the latest manual import queue job for the exact list and assigned agent. Returns state and aggregate counts only. Completed jobs can still contain record errors; not_found is not proof of success. Automatic membership reconciliation is not presented as a manual import. |
import_agent_hubspot_list | workflows:write | Write | workflow_id, connection_id, route_key, expected_revision | confirm: true | Explicitly import existing members of ONE saved, enabled HubSpot list into its assigned agent. Explain that the agent may contact these leads, then require confirm=true. Use exact connection_id, route_key, workflow_id and revision from get_agent_integration_flows. Does not activate recurring intake. Returns queued/job_id, not proof of completion. The existing importer preserves identity and deduplication; an in-progress response must not be retried blindly. A paused entry must first be enabled (it can have recurring=false for manual-only imports). crm_agent_inactive (next_action=activate_task): with agreement, set_workflow_active on its workflow_id, then retry. |
get_agent_integration_flows | workflows:read | Read | None | No contract flag | Inspect saved intake routes, data mappings and outputs for one agent mode or agent group. Requires workflow_id or agent_group_id; both constrain the scope. Returns exact flow identities, configuration revisions, shared/inherited scope, available operations and affected agents. Configuration is not evidence of a successful execution. Read before changing a flow; never treat an observed lead source or a tool name as proof of a native CRM connection. workflows[] reports each task’s active and paused: a route or output activates only while its task is active and not paused, so run set_workflow_active first. GHL opportunity_outcome flows carry outcome_mode: mapped (status map saved), no_action (this task’s own empty map: it never touches GHL) or category_default (inherited empty map: terminal statuses write Won/Lost by status category). Read outcome_mode before calling an outcome with state=not_configured broken. |
change_agent_hubspot_list | workflows:write | Write | workflow_id, connection_id, route_key, action, expected_revision | confirm: true | Change ONE HubSpot list intake for ONE agent mode, preserving all other routes. Use the connection_id, route_key and revision from get_agent_integration_flows. create requires a v3: list identity and expected_revision=null; it saves paused. configure accepts only name, recurring, pause_on_exit and sync_interval_minutes; behavior changes save paused, name-only changes preserve state. activate observes existing members without importing them, then receives future entries after the first complete scan. Existing-member import is separate and may contact leads. pause/remove affect only this route, never OAuth or existing leads. activate/pause/remove require confirm=true after explaining the exact effect and receiving operator agreement. Returns committed read-back; conflicts require rereading, not retrying blindly. crm_agent_inactive (next_action=activate_task): with agreement, set_workflow_active on its workflow_id, then retry. |
Agent CRM configuration (21)
Agent CRM configuration (21)
| Tool | Scope | Mode | Required top-level input | Safeguard or availability | Canonical purpose |
|---|---|---|---|---|---|
get_agent_variable_bindings | workflows:read | Read | None | No contract flag | Read task/group Variables, exact field IDs, metadata source paths and intake value conversions. Use before changing bindings; no imports or CRM writes. |
set_agent_variable_bindings | workflows:write | Write | bindings | No contract flag | Bind existing Variables to incoming lead metadata for one task or group. Read get_agent_variable_bindings first. Each binding includes its task, field ID and expected current source. metadata_key=null unlinks without deleting stored lead data. Optional intake_value_map replaces value conversions (null clears) and requires expected_intake_value_map. All rows commit atomically; other tasks remain unchanged. Affects future intake, not historical backfill. Read back before reporting success. |
list_agent_ghl_pipelines | workflows:read | Read | workflow_id, connection_id | No contract flag | Read verified GHL pipelines and stages for this task and exact connection/location. Use before mapping outcomes or automatic import filters. |
list_agent_ghl_intake_options | workflows:read | Read | workflow_id, connection_id | No contract flag | Read unassigned GHL pipeline/workflow/default intake sources and the creation revision for this task and connection. Never invent a source ID or take another task’s default. |
change_agent_ghl_flow | workflows:write | Write | workflow_id, connection_id, route_key, expected_revision, action | confirm: true | Configure one GHL task flow. Read get_agent_integration_flows and catalogs first. create claims an available source paused; pause/activate/remove use its exact route_key. remove (confirm=true) deletes one pipeline:/ghl_workflow:/legacy route this task owns, even shadowed or disconnected, never default; imported leads stay. On crm_recurring_import_active, first configure the returned recurring:<pipeline ID> with enabled=false and current stage_ids/cutover_at. configure on outcome:<task UUID> replaces only that task’s terminal-stage bucket (own empty = no_action). configure on recurring:<pipeline ID> sets automatic-import enabled, stage_ids and cutover_at (ISO or null). Enabling auto-sync requires confirm=true and an active intake. Preserve sibling pipelines. Saves configuration, not an import or proof of execution. Reread after conflicts. crm_agent_inactive (next_action=activate_task): with agreement, set_workflow_active on its workflow_id, then retry. |
get_agent_zoho_intake | workflows:read | Read | workflow_id, connection_id | No contract flag | Read task-scoped Zoho organization intake configuration, exact Accounts/Deals/Contacts fields, revision and latest import activity. Output alone does not import leads. Read contact_sources capabilities. Choose the unique Deal contact, the organization, or explicit contact-to-organization fallback when supported. Reads do not import or write CRM records. |
change_agent_zoho_intake | workflows:write | Write | workflow_id, connection_id, expected_revision, action | confirm: true | Configure, pause or activate automatic organization intake for one task. Read get_agent_zoho_intake first. Uses that task’s Accounts output matching, Variables and allowed Deals.Stage values. Configure saves paused. Activate requires confirm=true and may import existing/future organizations and start outreach. Runs every five minutes, admits each organization once, skips existing contacts rather than transferring them, requires one related Deal. Choose contact_source explicitly. deal_contact_then_organization requires capability support and fallback_fields mapped from Accounts; primary fields use Contacts. Fall back only for absent/unlinked contact or missing/invalid phone; foreign contact or API errors block. Never switch after unanswered outreach. Read back saved configuration and activity; no execution evidence is not success. Does not write Zoho. crm_agent_inactive (next_action=activate_task): with agreement, set_workflow_active on its workflow_id, then retry. |
list_agent_zoho_fields | workflows:read | Read | workflow_id | No contract flag | Read Zoho fields, exact options and task Variables with types. Supports Leads (default), Accounts, Deals and Contacts. Leads capabilities.reserved_mapping_destinations must be excluded from mappings; automatic_identity_destinations come from native lead identity. Mobile is separate. Accounts returns account_stage_modules, account_deal_selection, account_field_types, account_multiselect_mode, capabilities.account_stage_field_types and max_text_stage_length. For stage.module=Deals read the Deals catalog and use Stage of the unique related deal; account fields still map to Accounts. Text stage fields have no options; use operator-supplied values only when text is advertised. Never invent field names or values. |
change_agent_zoho_flow | workflows:write | Write | connection_id, action | confirm: true | Configure Zoho output for one task or group. Read get_agent_integration_flows and list_agent_zoho_fields first. Keep the exact connection, task/group and output revision. fields requires BOTH field_map and agent_fields and replaces that whole section; copy retained attribution mappings. Never send target_module with fields/stages or configure section=all. Leads identity automatically uses First_Name, Last_Name, Email and Phone; Mobile is separate. Exclude reserved catalog destinations. accounts selects Accounts or Leads and saves paused. Accounts never creates organizations. Booked stage requires a saved meeting. Configure-only requests need no lead or preview. Preview Accounts before separately authorized activation; activate/pause requires confirm=true. Read back Nexor settings; saving does not update Zoho records or start intake. On invalid input fix the same scoped command; never retry through account defaults. |
list_agent_zoho_preview_leads | workflows:read | Read | workflow_id | No contract flag | List recent leads and exact run IDs for an Accounts preview on one task. Requires workflows:read and leads:read. Does not write to Nexor or Zoho. |
preview_agent_zoho_accounts | workflows:read | Read | workflow_id, lead_id, workflow_run_id | No contract flag | Preview saved native Accounts settings for an exact task, lead and run, even while output is paused. Requires workflows:read and leads:read. Reads Zoho and returns proposed fields, stage eligibility, saved booking evidence and last verified update; never writes externally or internally. A preview is not a successful execution. Fix missing identifiers, duplicates, permissions or invalid values before activation. |
get_agent_salesforce_setup | workflows:read | Read | workflow_id | No contract flag | Read Salesforce for one task: connection (object Lead/Contact/Opportunity, object_confirmed, stage_field, opt_out_fields, field_map, health), this task intake (null when none), every task intake (to avoid overlaps), active campaigns, stages with closed/won/converted flags and, for Opportunity, pipelines (record types) with their own stages. connected=false: connect first with connect_crm(provider=salesforce). Reads Salesforce, writes nothing. |
list_agent_salesforce_fields | workflows:read | Read | workflow_id | No contract flag | Read fields of the connected Salesforce object (name, label, type, updateable, picklist, reference) before setting field_map, opt_out_fields or stage_field. Never invent field names. |
preview_agent_salesforce_intake | workflows:read | Read | workflow_id, patch | No contract flag | Count the Salesforce records an intake would match right now (mode campaign or stage; new always counts 0). Use before asking whether existing records should also be contacted. Writes nothing. |
change_agent_salesforce_connection | workflows:write | Write | workflow_id, patch | confirm: true | Change account-wide Salesforce settings shared by every task: object (Lead, Contact or Opportunity), object_confirmed, stage_field (picklist), opt_out_fields (checkboxes that mark the lead do-not-contact, and that Nexor checks on opt-out) and field_map (Salesforce field path to first_name, last_name, email, phone or company). Read get_agent_salesforce_setup and list_agent_salesforce_fields first. Changing object disables every task intake: the first call returns salesforce_object_change_requires_confirm with affected_workflow_ids; tell the operator and retry with confirm=true only after they agree. |
change_agent_salesforce_intake | workflows:write | Write | workflow_id, action | confirm: true | Configure which Salesforce records this task contacts and how its statuses flow back. Read get_agent_salesforce_setup first and get_workflow_status for status keys. mode: campaign (campaign_id), stage (stages, exact values; pipeline_id for Opportunity record types; dwell_minutes = minimum minutes in stage) or new (every new record). configure saves without changing on/off (new intakes start paused). activate turns it on and can start outreach; pause stops it; remove deletes it (imported leads stay). Those three require confirm=true. backfill=true (activate only) also contacts records already matching; default contacts only records that match after saving. Write-back: update_stage_enabled + status_map (Nexor status key to Salesforce stage). inbound_stage_map: Salesforce stage to Nexor status key. stop_on_closed: closed-not-won marks the lead lost. convert_status_key (Lead only): converts the Lead at that status. Two tasks cannot claim the same campaign, stage or new records (salesforce_intake_overlap). |
change_agent_hubspot_history | workflows:write | Write | workflow_id, connection_id, expected_revision, action, patch | confirm: true | Configure HubSpot activity history for exactly one task: enabled, notes, calls, meetings and WhatsApp attempts. Read its activity flow/revision first. Saving enabled=true requires confirm=true; other tasks and contact-field mappings are preserved. This affects future activity, not historical replay. |
change_agent_hubspot_intake | workflows:write | Write | workflow_id, connection_id, action | confirm: true | Operate this task’s HubSpot portal intake: activate/pause its owned default route, or explicitly import_all/import_selected contacts. Read flows first. Never steal another task’s portal route. Imports and activation can start lead contact and require confirm=true; pause also requires agreement. contact_ids is required for import_selected. A queued job is not completion; inspect get_hubspot_sync_status. crm_agent_inactive (next_action=activate_task): with agreement, set_workflow_active on its workflow_id, then retry. |
change_agent_hubspot_group | workflows:write | Write | agent_group_id, connection_id, revisions, kind, action | confirm: true | Change HubSpot inbound data or activity history for an entire agent group atomically. Read group flows and get_agent_variable_bindings; send each member’s exact revision. kind=inbound supports configure draft/apply/discard with phone_priority, extra_properties and optional variable_bindings. kind=history supports configure with history toggles. Apply or enabling history requires confirm=true. Affects only group members; no historical backfill. Reread committed group state. |
change_agent_custom_intake | workflows:write | Write | workflow_id, action | confirm: true | Create/configure/pause/activate/remove a custom INBOUND lead webhook for exactly one task. This is not an outbound event webhook. Read flows first; edits require the exact connection_id and revision. create saves paused; configure accepts name, field_mapping (payload path to canonical lead field or metadata key) and deduplicate. Activation requires confirm=true and may start outreach. Removal requires confirm=true, invalidates the receiving URL and preserves imported leads. Does not execute an HTTP request. Read back and retrieve the endpoint only when needed. crm_agent_inactive (next_action=activate_task): with agreement, set_workflow_active on its workflow_id, then retry. |
get_agent_custom_intake_endpoint | workflows:read | Read | workflow_id, connection_id | No contract flag | Retrieve the receiving URL for one task-owned custom intake after configuration. This URL contains its access token: share only with the authorized operator for configuring the sender; never put it in agent prompts or logs. Reading does not activate intake. |
CRM accounts (15)
CRM accounts (15)
| Tool | Scope | Mode | Required top-level input | Safeguard or availability | Canonical purpose |
|---|---|---|---|---|---|
get_crm_intake_details | workflows:read | Read | scope, provider, connection_id | No contract flag | Account-wide operation, including tasks that inherit defaults and future tasks, even when called from an agent chat. First inspect get_crm_account_configuration and explain all affected_workflows. Writes require their exact IDs, the revision, and explicit confirm=true. Locked tasks or changed configuration reject the whole action. Never drop an affected task to bypass authorization. Read the receiving URL of a custom entry or Kommo integration. The URL contains an access token: share only with the authorized operator for sender setup; never place it in prompts or logs. Custom entries also return recent payload paths and types for mapping, without payload values. |
rotate_kommo_webhook_token | workflows:write | Write | scope, provider, connection_id, expected_revision, affected_workflow_ids | confirm: true | Account-wide operation, including tasks that inherit defaults and future tasks, even when called from an agent chat. First inspect get_crm_account_configuration and explain all affected_workflows. Writes require their exact IDs, the revision, and explicit confirm=true. Locked tasks or changed configuration reject the whole action. Never drop an affected task to bypass authorization. Replace the Kommo webhook receiving token after explicit consent. The previous URL stops accepting events once committed. The new URL contains a secret. Preserves routes and imported records; does not run an import. Review the returned configuration and configure external senders with the new URL. |
get_crm_import_job | workflows:read | Read | scope, provider, connection_id, job_id | No contract flag | Account-wide operation, including tasks that inherit defaults and future tasks, even when called from an agent chat. First inspect get_crm_account_configuration and explain all affected_workflows. Writes require their exact IDs, the revision, and explicit confirm=true. Locked tasks or changed configuration reject the whole action. Never drop an affected task to bypass authorization. Read the exact queued import job for GHL, Kommo or Odoo. Reports queue state and safe aggregate counters. not_found does not prove completion; completed can still include skipped records or errors. Rejects jobs belonging to another connection or tenant. |
get_hubspot_sync_preview | workflows:read | Read | scope, provider, connection_id, operation | No contract flag | Account-wide operation, including tasks that inherit defaults and future tasks, even when called from an agent chat. First inspect get_crm_account_configuration and explain all affected_workflows. Writes require their exact IDs, the revision, and explicit confirm=true. Locked tasks or changed configuration reject the whole action. Never drop an affected task to bypass authorization. Inspect the saved scope before manually re-running HubSpot deal synchronization or one contact sync. contact requires a Nexor lead_id with one unambiguous active run and returns the current status to review. Neither operation executes during preview. Read both revision and sync_revision; the latter is required as expected_sync_revision. |
run_hubspot_sync | workflows:write | Write | scope, provider, connection_id, expected_revision, expected_sync_revision, affected_workflow_ids, operation | confirm: true | Account-wide operation, including tasks that inherit defaults and future tasks, even when called from an agent chat. First inspect get_crm_account_configuration and explain all affected_workflows. Writes require their exact IDs, the revision, and explicit confirm=true. Locked tasks or changed configuration reject the whole action. Never drop an affected task to bypass authorization. Execute the previously reviewed HubSpot sync. deals applies saved deal transitions to Nexor and can trigger their effects. contact syncs saved status, unsynced call/note/meeting history and enabled fields for the selected lead, possibly across its history; it is not task-local. Requires fresh get_hubspot_sync_preview, consent and both revisions. Reports skips/partial errors honestly; never retry an ambiguous failure automatically. |
list_odoo_sync_conflicts | workflows:read | Read | scope, provider, connection_id | No contract flag | Account-wide operation, including tasks that inherit defaults and future tasks, even when called from an agent chat. First inspect get_crm_account_configuration and explain all affected_workflows. Writes require their exact IDs, the revision, and explicit confirm=true. Locked tasks or changed configuration reject the whole action. Never drop an affected task to bypass authorization. Read Odoo conflicts, allowed resolutions and candidate fingerprints. Follow next_cursor while has_more. Missing provider visibility is not a business choice and cannot be ignored. Reading never resolves a conflict or runs a sync. |
resolve_odoo_sync_conflict | workflows:write | Write | scope, provider, connection_id, expected_revision, affected_workflow_ids, conflict_id, action, candidate_fingerprint | confirm: true | Account-wide operation, including tasks that inherit defaults and future tasks, even when called from an agent chat. First inspect get_crm_account_configuration and explain all affected_workflows. Writes require their exact IDs, the revision, and explicit confirm=true. Locked tasks or changed configuration reject the whole action. Never drop an affected task to bypass authorization. Resolve one persisted Odoo conflict with its current candidate_fingerprint. select_opportunity requires an exact opportunity_id offered by that conflict; ignore only when allowed_actions permits it. This records a decision, not an executed sync. A changed candidate, already different decision or unavailable binding rejects the operation. |
change_odoo_account_outputs | workflows:write | Write | scope, provider, connection_id, expected_revision, affected_workflow_ids, action, outputs | confirm: true | Account-wide operation, including tasks that inherit defaults and future tasks, even when called from an agent chat. First inspect get_crm_account_configuration and explain all affected_workflows. Writes require their exact IDs, the revision, and explicit confirm=true. Locked tasks or changed configuration reject the whole action. Never drop an affected task to bypass authorization. Prepare Odoo output mappings or request a read-only output preview. configure saves only disabled output configuration; enabling execution is blocked by the backend. preview uses the read-only scanner and may be incomplete; the outbound apply engine remains unavailable. Always report scan_complete and approval_eligible; zero operations from an incomplete scan is not proof that no work exists. Does not write to Odoo, advance a cursor, create activities or quotations, or enable an engine. Keeps incoming configuration intact. |
list_crm_account_connections | workflows:read | Read | scope | No contract flag | Account-wide operation, including tasks that inherit defaults and future tasks, even when called from an agent chat. First inspect get_crm_account_configuration and explain all affected_workflows. Writes require their exact IDs, the revision, and explicit confirm=true. Locked tasks or changed configuration reject the whole action. Never drop an affected task to bypass authorization. List exact connection IDs for supported CRMs and custom inbound entries, including unassigned entries, before inspecting account configuration. |
change_odoo_account_inputs | workflows:write | Write | scope, provider, connection_id, expected_revision, affected_workflow_ids, action | confirm: true | Account-wide operation, including tasks that inherit defaults and future tasks, even when called from an agent chat. First inspect get_crm_account_configuration and explain all affected_workflows. Writes require their exact IDs, the revision, and explicit confirm=true. Locked tasks or changed configuration reject the whole action. Never drop an affected task to bypass authorization. Preview, configure or pause shared Odoo intake. preview reads records and stores its fingerprint without importing; configure requires that same fresh successful preview and consent; pause needs no provider read. Always preserves task field overrides and output configuration. Legacy connections accept only enabled, cutover_at and routes with team_id/stage_id/workflow_id. For current connections, fields, lifecycle, limits and account ignore/observe rules are supported. An unavailable engine remains blocked. Saving is not an executed import. |
get_crm_account_configuration | workflows:read | Read | scope, provider, connection_id | No contract flag | Account-wide operation, including tasks that inherit defaults and future tasks, even when called from an agent chat. First inspect get_crm_account_configuration and explain all affected_workflows. Writes require their exact IDs, the revision, and explicit confirm=true. Locked tasks or changed configuration reject the whole action. Never drop an affected task to bypass authorization. Read account controls/defaults or saved import scope and the complete set of tasks that must be reviewed before a shared change. No credentials, writes or imports. |
change_zoho_account_defaults | workflows:write | Write | scope, provider, connection_id, expected_revision, affected_workflow_ids, patch | confirm: true | Account-wide operation, including tasks that inherit defaults and future tasks, even when called from an agent chat. First inspect get_crm_account_configuration and explain all affected_workflows. Writes require their exact IDs, the revision, and explicit confirm=true. Locked tasks or changed configuration reject the whole action. Never drop an affected task to bypass authorization. Replace Zoho defaults for metadata fields, collected Variables and statuses; preserve every per-task override. outbound_enabled controls account output. Resolve exact Zoho fields/options with list_agent_zoho_fields; agent_fields uses collected Variable keys, field_map uses metadata keys. Changes apply to future sync, without historical replay. |
change_hubspot_account_controls | workflows:write | Write | scope, provider, connection_id, expected_revision, affected_workflow_ids, patch | confirm: true | Account-wide operation, including tasks that inherit defaults and future tasks, even when called from an agent chat. First inspect get_crm_account_configuration and explain all affected_workflows. Writes require their exact IDs, the revision, and explicit confirm=true. Locked tasks or changed configuration reject the whole action. Never drop an affected task to bypass authorization. Change HubSpot account inbound webhook switch/default task or default activity output switches. Preserve list routes, task overrides and unrelated settings. Enabling intake can allow future incoming contacts to be managed/contacted. This does not import historical contacts or replay activities. Use task-scoped tools for task changes. |
reassign_crm_intake | workflows:write | Write | scope, provider, connection_id, expected_revision, affected_workflow_ids, target_workflow_id | confirm: true | Account-wide operation, including tasks that inherit defaults and future tasks, even when called from an agent chat. First inspect get_crm_account_configuration and explain all affected_workflows. Writes require their exact IDs, the revision, and explicit confirm=true. Locked tasks or changed configuration reject the whole action. Never drop an affected task to bypass authorization. Move a custom inbound entry, Kommo route or GoHighLevel route to another existing task. The route is saved paused (saved_paused=true); existing leads do not move. custom uses connection_id only. Kommo: route_key is the route UUID. GoHighLevel: connection_id is the location connection and route_key is an existing route key from get_agent_integration_flows (pipeline:<id>, ghl_workflow:<id>) or default for the catch-all task. Activate separately after reviewing the new task configuration; that task must be active and not paused. |
run_crm_account_import | workflows:write | Write | scope, provider, connection_id, expected_revision, affected_workflow_ids, mode | confirm: true | Account-wide operation, including tasks that inherit defaults and future tasks, even when called from an agent chat. First inspect get_crm_account_configuration and explain all affected_workflows. Writes require their exact IDs, the revision, and explicit confirm=true. Locked tasks or changed configuration reject the whole action. Never drop an affected task to bypass authorization. Queue a saved GHL dry_run/backfill Kommo run_now or Odoo inbound with the reviewed configuration pinned. GHL dry_run reads only; backfill imports historical contacts without assigning tasks or starting outreach. Kommo run_now scans all enabled routes, may import existing/new cards, move them, and trigger outreach. Odoo inbound uses its existing runtime gates, may enroll/contact leads, and cannot execute outbound sync. Explain those effects and get consent. queued/job_id is not completion. The worker rejects configuration drift. Inspect diagnostics or GHL import history afterward; do not retry an uncertain request blindly. |
CRM booking (4)
CRM booking (4)
| Tool | Scope | Mode | Required top-level input | Safeguard or availability | Canonical purpose |
|---|---|---|---|---|---|
list_agent_crm_booking_choices | workflows:read | Read | workflow_id, provider | No contract flag | List verified HubSpot meeting links or GHL calendars for an appointment task. GHL choices include location_id to distinguish sub-accounts. Resolve names here before setup; never guess a calendar ID. This reads the provider and does not change configuration. |
get_agent_crm_booking | workflows:read | Read | workflow_id, provider | No contract flag | Read the task’s saved native CRM booking provider, installed tool IDs, calendar/link IDs, active flags and exact revision. Saved configuration is not a successful booking or runtime verification. Use before configure/remove and reread on conflict. Booking belongs to the appointment goal. |
change_agent_crm_booking | workflows:write | Write | workflow_id, provider, action, expected_revision | confirm: true | Configure or remove native HubSpot/GHL booking for one appointment task. First read get_agent_crm_booking and list_agent_crm_booking_choices. configure requires a verified choice_id. Both actions require explicit user consent via confirm=true and expected_revision from the read. Installs/removes native booking tools and external-booking configuration atomically, with provider availability checks on setup. Locked tasks, changed revisions, another provider or hand-managed configuration may reject the change. Returns saved readback; does not book, cancel or reschedule a meeting. Never claim a real booking was tested. |
get_agent_ghl_import_status | workflows:read | Read | workflow_id, connection_id | No contract flag | Read the latest 20 stored GHL import runs for an exact connection/location, worker state, recurrence state and configuration validity. Resolve connection_id through get_agent_integration_flows. Evidence covers the whole connection, potentially several tasks; never attribute connection counters to this task or claim connected means synced. No stored runs means no execution evidence, not successful sync. Returns safe counters and errors without lead payloads or credentials. Does not start an import. recurring_state: not_configured = auto-sync was never set up (blocker not_configured), not an error; valid; or invalid. configuration_errors only matter when recurring_state=invalid. |
CRM diagnostics and inputs (6)
CRM diagnostics and inputs (6)
| Tool | Scope | Mode | Required top-level input | Safeguard or availability | Canonical purpose |
|---|---|---|---|---|---|
get_agent_crm_diagnostics | workflows:read | Read | workflow_id, connection_id, provider | No contract flag | Read safe stored execution evidence for an exact HubSpot, GHL, Kommo, Zoho, Odoo or custom inbound connection. Read connection_id from get_agent_integration_flows. Provider counters cover the connection, possibly several tasks; custom evidence covers that task-owned entry. Connected/configured is never proof of successful sync. No history is not success. Raw vendor exceptions, credentials and lead payloads are excluded. Odoo reports actual runtime gates and unavailable outbound execution. Read never_received and last_data_received_at/_source/_scope first: never_received=true (GHL: intake key never used) means the CRM never called Nexor, so check the customer’s CRM webhook/automation, not Nexor data; scope=client is a key shared across connections. GHL adds last_webhook_at, last_webhook_outcome (skipped:* = routing skip, e.g. paused route, not a failure), intake_key_last_used_at, intake_key_active and recurring_state (not_configured = auto-sync never set up, not an error). |
list_agent_hubspot_catalog | workflows:read | Read | workflow_id, catalog | No contract flag | Read verified HubSpot owners, lead/deal pipelines, or writable contact/deal property choices before configuring native tools and mappings. These are account choices read in a task context. No writes or imports. |
count_agent_kommo_source | workflows:read | Read | workflow_id, connection_id, route_key | No contract flag | Count cards currently in one saved task-owned Kommo source stage without importing or moving anything. has_more=true means the count is a lower bound, not the total. The source can change after this read. Use exact route_key and connection_id from get_agent_integration_flows. |
get_agent_odoo_inputs | workflows:read | Read | None | No contract flag | Read Odoo intake routes, inherited field mappings, lifecycle mappings, verified CRM catalogs and exact revision for one task or group. Reads provider metadata without importing records. Runtime apply availability is reported explicitly; saved configuration does not imply execution. Legacy connections only support route changes. |
preview_agent_odoo_inputs | workflows:write | Write | connection_id, expected_revision, patch | confirm: true | Preview replacing one Odoo intake section for the selected task/group, preserving sibling tasks and shared ignore/observe rules. First read get_agent_odoo_inputs. routes/lifecycle values must use workflow IDs inside the selected scope. fields maps provider fields to canonical lead fields or metadata; inherit=true restores shared fields. Requires current connection and revision. Reads provider records and stores a preview fingerprint, but never imports or contacts leads. Counts cover the full connection, including preserved sibling routes, not only the selected task. Review counts and blockers before saving. Odoo runtime gates still apply. |
change_agent_odoo_inputs | workflows:write | Write | connection_id, expected_revision, patch | confirm: true | Save the exact task/group Odoo intake patch after a fresh successful preview and explicit operator consent. Requires confirm=true, current revision and identical previewed patch. Saves through the same guarded service as the panel. Preserves sibling tasks, enforces task locks and available runtime gates. Returns committed scoped readback; never claim an import or outbound sync ran. Does not enable an unavailable Odoo engine. |
Session metadata (1)
Session metadata (1)
| Tool | Scope | Mode | Required top-level input | Safeguard or availability | Canonical purpose |
|---|---|---|---|---|---|
whoami | Authenticated key | Read | None | No contract flag | Return the authenticated Nexor client identity and the scopes this API key was granted. Call this first to discover which actions are permitted. |
Account readiness (1)
Account readiness (1)
| Tool | Scope | Mode | Required top-level input | Safeguard or availability | Canonical purpose |
|---|---|---|---|---|---|
get_account_readiness | Authenticated key | Read | None | No contract flag | MANDATORY FIRST-RUN TOOL. At the start of a new customer conversation, call this before the first substantive reply. Returns account/payment state, granted and missing setup scopes, saved onboarding context, agents/channels/template inventory, a factual readiness checklist, the safest next tools, external human touchpoints, and initial_dialogue with the exact opening behavior. account.sms_eligible reports account-level SMS eligibility: US/CA by default, or the explicit account flag elsewhere; it does not prove a number has SMS enabled or bound. Each appointment-capable agent carries a booking block (meeting_type, hosts with schedule/calendar state, activation blockers such as MEETING_TYPE_REQUIRED / BOOKING_AVAILABILITY_REQUIRED / CALENDLY_BINDING_REQUIRED, timezone warnings, and fix_tools). Follow initial_dialogue; do not ask for facts in resume_context, do not mutate while payment/account access is blocked, and do not claim the account is ready merely because dashboard onboarding was marked complete or because an agent is active: an active agent with booking blockers cannot book. |
Tasks (13)
Tasks (13)
| Tool | Scope | Mode | Required top-level input | Safeguard or availability | Canonical purpose |
|---|---|---|---|---|---|
list_workflows | workflows:read | Read | None | No contract flag | List the authenticated client’s workflows (the funnels leads move through), including each agent’s master_workflow_id group assignment, enabled channels, and status ids. Archived (soft-deleted) agents are hidden by default; pass include_archived:true to see them too — each row then carries archived:true and a deleted_at timestamp so you can find an archived agent to restore with restore_workflow. |
get_workflow | workflows:read | Read | None | No contract flag | Fetch one workflow/agent with prompts/config, ordered status summaries, fields, channels and tool execution settings. Each field includes its metadata_key and intake_value_map when configured. Pass workflow_id, or name to resolve a task name or an agent name without calling list_workflows first (an agent name returns each of its tasks as workflows[], up to 4). Status summaries do not include their full gates/timeouts/transfers; pass include_statuses:true to get every status’s full configuration (as get_workflow_status returns it) in the same call. Use both for verification before activation. workflow.escalation_state {enabled, reason} is the runtime answer to whether the agent can hand a lead to a human (Escalated to executive); trust it over raw config keys. |
create_workflow | workflows:write | Write | name, goal_type, statuses, master_workflow_id | No contract flag | Opt in with creation_mode:paused_unbound for task composition: no channel inheritance/assignment, newly created tasks mask all four contact channels (including shared availability), no activation, safe existing-task retries returned read-only. Returns composition_contract_version:1. Ordinary omitted mode preserves inherited channels. Create a new PAUSED workflow — ONE MODE (sub-agent) inside an AGENT (master workflow). master_workflow_id is REQUIRED: a workflow never exists without an agent, so create the agent first with create_agent_group (or pick one from list_agent_groups) and pass its id; a call without it is refused before any request is made. Provide an ordered list of statuses; each needs a key plus a name (or its label alias). If no is_initial/is_terminal flags are set, the first and last become entry/exit. Statuses accept the full stage config here — entry_hint, category, color, transition_rules, requires_all_fields/required_field_keys, timeout_config, transfer_config, pause_bot, can_return_on_reply (lost final stages), assignment_config and the is_* flags — so a funnel can be fully configured in one call instead of follow-up update_workflow_status PATCHes. Every non-initial status MUST carry an entry_hint (one sentence: when a lead enters it); a call missing one is refused before any request (status_entry_hint_required, listing the statuses). Unknown status fields are forwarded to the backend as-is. The statuses array is the COMPLETE funnel of YOUR stages: the backend seeds a default pipeline on create, so this tool reads the workflow back, deletes seeded statuses not in your list, and returns the workflow plus a pipeline_reconciliation report. Three core stages (new, contacted, engaged) and the virtual “discarded” stage ALWAYS exist on every agent and are NOT part of the statuses contract: they are never deleted and are listed under seeded_statuses_kept (reason core_stage/virtual) — do not try to remove them. The result carries a top-level status: “created” means the funnel is exactly what you asked; “created_with_warnings” means the report has REAL unresolved warnings (duplicate stage labels, non-core seeded stages that could not be removed, missing requested stages) — you MUST resolve those before telling the user the agent is built. Set prune_unrequested_statuses:false to keep seeded defaults. Pass timezone (IANA) and region_style: when omitted the backend anchors them to the ACCOUNT (country/host schedule), never to a Chilean default — read them back in the returned workflow. BORN WITH (inherited, never asked): the mode inherits its AGENT’s channels, contact schedule, persona name (agent_name = the agent’s human name), language and timezone. The tool resolves them itself before the create: from the agent’s other live modes when it has any, otherwise (first mode) from the account — every channel the account holds a verified resource for — with the backend’s schedule default. It then binds the resources (one WhatsApp number and one SMS route per agent, shared by its modes; the account-wide number for calls; the agent’s email sender on every mode) and returns inheritance (what was inherited and from where) plus channel_bindings (per channel: bound / already_bound_in_group / client_scoped_available / owned_by_other_agent / no_resource). A resource another agent owns is NEVER taken silently — it comes back as owned_by_other_agent for the operator to decide. So OMIT channels, contact_schedule and agent_name unless the operator explicitly asked for something different for this mode. When the first-contact channel has no verified resource on the account, the result carries a channel_not_verified warning with the fix tools (connect_whatsapp_number, provision_phone_number, register_email_sender). Idempotent on the backend (a guarded duplicate returns the existing id; stages holding leads are never deleted, only reported). Each call creates ONE MODE (sub-agent) of an agent; a build is normally 2–3 modes split by intent and register (sell → follow up → discount), never one broad mode unless the operator explicitly asked for exactly one, never 5+. Before the first create call describe_agent_configuration (mode_split) + review_agent_system_plan, resolve clarifications, and obtain explicit user approval of the final plan summary (“Does this look ok? Let me know and I’ll build it.”); never show the plan_fingerprint or the word “fingerprint” to the user. CONTACT HOURS: a mode inherits its agent’s windows when the agent already has modes; the first mode gets Mon–Fri 09:00–18:00 ONLY when nobody said anything about hours. If the operator hinted at hours anywhere (after-hours, overnight, 24/7, weekends, specific times, a use case that only exists outside office hours), pass contact_schedule explicitly — never let the default apply to such an agent. The result carries contact_schedule {source: explicit | inferred_from_description | default_business_hours, windows}: tell the operator what the agent was born with in one line, and if source is default_business_hours for an agent that should not keep business hours, fix it with set_workflow_cadence. CHANNELS AND HOURS ARE NEVER QUESTIONS, for any agent: they are inherited as described above. Tell the operator in one line what the mode was born with (channels, hours) from inheritance. |
set_workflow_prompt | workflows:write | Write | workflow_id, global_prompt | No contract flag | Replace a workflow’s base (global) prompt — the business rules and persona the agent follows across channels. Read the current one with get_workflow first if you want to edit rather than overwrite. Channel-specific overrides are not touched — so a BEHAVIOR CHANGE (a new rule, condition, or metadata-driven branch such as ‘if metadata X > 50 do Y’) is not finished here: also write it, in that channel’s register, into every channel prompt that has a body (get_workflow → channel_prompts) with set_channel_prompt, unless the operator scoped the change to one channel or to the base prompt only. SMS and iMessage outbound messages are composed from the channel prompt ALONE when one exists, so a rule left only in the base prompt never reaches them. |
set_workflow_active | workflows:write | Write | workflow_id, active | No contract flag | Turn one task on or off. For mutually dependent paused tasks, pass related_workflow_ids only after the operator explicitly agrees to activate every named task together; all are checked before one atomic activation. Activating contacts enrolled, not-yet-contacted leads per cadence (calls wait for the task’s contact hours; messages go right away unless restricted to its hours), and resumes leads paused mid-cadence at their next touchpoint. Do-not-contact leads and reply-only tasks are excluded. Use exact IDs from the selected agent, never another agent. Without related_workflow_ids, only workflow_id changes. Appointment tasks still need booking readiness. On TRANSFER_TARGET_PAUSED a handoff target is only paused, not missing: name the activate_together tasks to the operator, get agreement, then retry once with related_workflow_ids = activate_together plus any IDs already sent. |
update_workflow | workflows:write | Write | workflow_id | No contract flag | Update a workflow’s identity, metadata, agent assignment or reply-only switch: rename it, change its description, set the objective of a ‘custom’ goal workflow (goal_statement), move it into another agent (master_workflow_id — never null: a mode always belongs to an agent, so it is moved, not detached), adjust the agent’s identity (language, timezone, region_style, agent_name, agent_role, company_name, begin_message), or set inbound_only (true = the mode NEVER writes first: no first contact and no cadence when a lead enrols or is transferred in, while replies to inbound messages stay immediate; the canonical setting for a support mode). Pass only the fields you want to change. Use list_agent_groups to resolve a group name to its tenant-scoped id. |
set_channel_prompt | workflows:write | Write | workflow_id, channel, prompt | No contract flag | Set the per-channel prompt override for a workflow (e.g. WhatsApp vs email tone/format). Merges with existing channel prompts; doesn’t touch the global prompt. Use ‘call’ for the voice/call channel (‘retell’ is still accepted as an alias). For sms and imessage this prompt is the ONLY one the outbound composer reads when it exists, and the call/WhatsApp overlays are what the agent follows turn by turn — so a behavior change the operator asked for without naming a channel goes into the base prompt (set_workflow_prompt) AND into every channel that has a body, one set_channel_prompt per channel, read first so you merge the rule into the existing text instead of replacing it. Name a single channel only when the operator did. |
get_workflow_prompt_history | workflows:read | Read | workflow_id | No contract flag | Read one workflow’s prompt version history — snapshots of global + channel prompts, what changed, by whom, and when. workflow_id must be the exact UUID returned by list_workflows/get_workflow; never pass a name, change id, or placeholder text. Pass versions to read specific version numbers, including ones older than the latest 50. |
update_workflow_structure | workflows:write | Write | workflow_id | No contract flag | Add or edit a workflow’s basic funnel statuses and/or data fields. Upsert by key — new keys are added, existing ones updated; nothing is deleted. A field’s metadata_key prefills it from lead metadata, and intake_value_map can normalize incoming string values to canonical field values. Status order is deliberately unsupported here: use reorder_workflow_statuses. A new non-initial status needs an entry_hint (refused with status_entry_hint_required otherwise). After creating statuses, use update_workflow_status for qualification gates, timeouts, transfers, pause behavior and trigger flags. To remove one safely, use get_pipeline_impact then delete_workflow_status. |
update_workflow_config | workflows:write | Write | workflow_id, config | No contract flag | Update a workflow’s behaviour config (the config bag: flags like gate_outbound_to_hours and other non-prompt settings). Merges top-level keys by default — pass only the keys you want to change; existing keys are preserved. Set replace:true only to overwrite the entire config object (rare). Does not touch the prompt, statuses, fields, or channels. Reserved keys are REFUSED here (400 RESERVED_CONFIG_KEY) because the runtime reads them by exact key and a misspelled key would merge silently: use set_payment_link for payment_link, set_host_assigner for host_assigner and set_external_booking for external_booking — those validate the shape and the referenced tools. HUMAN HAND-OFF: pass escalation:{enabled:true} to turn it on (this also restores a deleted ‘Escalated to executive’ stage) or escalation:{enabled:false} to turn it off, then confirm with escalation_state in the response. escalation is deep-merged, so pass only the keys you change. escalation.trigger_text: the cases that hand off, one per line; it REPLACES the default cases (a question the agent cannot answer, a policy/eligibility question), so restate any default you still want. escalation.signoff_text: guidance for the goodbye/holding message the agent sends when it hands off. escalation.voice_enabled:true also hands off on phone calls (off by default): the agent says goodbye and the team follows up by message. Never emulate hand-off with a custom HTTP tool: only the built-in escalation pauses the agent and notifies the team. |
set_opening_message | workflows:write | Write | workflow_id, channel | No contract flag | Set the agent’s FIRST message for one channel — the fixed opener sent/spoken verbatim before the agent improvises. channel ‘call’ (voice): message is the opening line spoken when the call connects (flat variables {{lead_first_name}}, {{lead_full_name}}, {{agent_name}}, {{company_name}}; a variable the lead lacks is sent empty, never spoken; ” clears it and the agent opens with its own greeting from the prompt, e.g. ‘Hola, soy Valentina de Kaufmann. ¿Hablo con Raimundo?’); agent_speaks_first (default true) — set false to make the agent wait for the lead to speak, optionally with silence_ms (1000–30000, default 3000) before it opens anyway. channel ‘email’: a fixed first email subject + body sent verbatim (variables {{first_name}}, {{last_name}}, {{email}}, {{metadata.key}}); enabled:false with empty subject/body removes it so the agent composes the first email itself. channel ‘webchat’: message shown by the widget before the agent speaks. channel ‘sms’: message sent verbatim as the first outbound SMS (same variables as email; a legally required STOP notice is still appended for US numbers). channel ‘messenger’: message sent verbatim as the agent’s first reply in a new Messenger conversation. channel ‘imessage’: message sent verbatim as the first outbound iMessage (Apple Messages for Business: no STOP notice; variables {{first_name}}, {{lead_first_name}}, {{last_name}}, {{full_name}}, {{email}}, {{metadata.key}}, plus {{company_name}} and {{agent_name}}); without it the agent composes the opener from the workflow prompt, the iMessage channel prompt (set_channel_prompt channel ‘imessage’) and the lead’s metadata. For call/webchat/sms/messenger/imessage, ” clears the opener so the agent composes it from the prompt. NOT free text: WhatsApp openers are Meta-approved templates → set_opening_templates; Instagram campaign openers are dashboard-only. Returns the persisted opener as read-back; read every channel’s opener with get_workflow → opening_messages. / Configura el PRIMER mensaje del agente por canal: ‘call’ (línea de apertura de voz + quién habla primero), ‘email’ (asunto + cuerpo fijos), ‘webchat’, ‘sms’, ‘messenger’ e ‘imessage’ (texto fijo del primer mensaje). WhatsApp usa plantillas aprobadas (set_opening_templates). |
set_payment_link | workflows:write | Write | workflow_id, source | No contract flag | Set (or clear) where a ‘Send Payment Link’ agent gets the link it sends to leads — the backing for the dashboard’s Payment link section. Pick the source: ‘fixed’ = one static URL for every lead (needs a valid http(s) url; optional label); ‘tool’ = a tool generates a per-lead link (needs the tool name; optional capture dot-path into the tool’s JSON response, e.g. ‘data.url’); ‘lead’ = read the link from a lead metadata field (needs metadata_key, e.g. ‘payment_url’); ‘none’ = clear the configured link. Use this instead of writing config.payment_link through update_workflow_config: this validates the shape and reads the saved value back, so a success here means it actually persisted. / Configura de dónde saca el link de pago un agente de ‘Enviar link de pago’: ‘fixed’ (URL fija http(s), label opcional), ‘tool’ (una herramienta genera el link; capture opcional), ‘lead’ (leer de metadata_key del lead) o ‘none’ (borrar). Devuelve el valor guardado como verificación. |
set_conversion_destination | workflows:write | Write | destination_workflow_id | No contract flag | Set (or clear) where a lead goes when it converts — the agent and status Nexor moves it to after create_conversion or the public conversions endpoint fires. Configure it on one agent (workflow_id) or on a whole agent group (agent_group_id): precedence at conversion time is the conversion type’s destination, then the lead’s current agent, then its group; the first one configured wins, and with none the lead stays put. destination_workflow_id may be the same agent (status change only). Pass destination_workflow_id: null to clear (destination_status_key must then be omitted); when set, destination_status_key is required and must be a status of that destination agent. The response is a read-back of what the database now holds (conversion_destination with workflow name, status label and source), so a success here means it persisted. Read the effective value later with get_workflow / get_master_workflow. / Define a qué agente y estado se mueve un lead cuando convierte, en un agente (workflow_id) o en un grupo (agent_group_id). Precedencia: tipo de conversión > agente > grupo. null borra la configuración. Devuelve el valor guardado como verificación. |
Task tools (7)
Task tools (7)
| Tool | Scope | Mode | Required top-level input | Safeguard or availability | Canonical purpose |
|---|---|---|---|---|---|
list_workflow_tools | workflows:read | Read | workflow_id | No contract flag | List a workflow’s custom tools (name, method, url, active, stage gate, on-entry, call-once). |
create_workflow_tool | workflows:write | Write | workflow_id, name, description, url | No contract flag | Create a CUSTOM tool that lives only in THIS workflow (no catalog inheritance). Prefer create_client_tool + assign_tool_to_workflow when the tool should be reusable across workflows. name is the snake_case identifier the agent references (immutable). description tells the agent when to call it. parameters is a JSON Schema for the call arguments. URL rule: tool ARGUMENTS go in the url with SINGLE braces (/citas/{id_cita}). Double braces are ONLY for context values resolved before the call: {{env.KEY}} for secrets, {{lead.metadata.X}}, {{lead_id}}. Never {{arg}} for an argument: it is rejected with 400 invalid_url_placeholder and a suggested_url. call_once caches the result per lead; auto_run_on_entry fires it when a lead enters the workflow; available_in_statuses gates it to funnel stages. Create it with is_active=false, run test_workflow_tool, and activate it (update_workflow_tool is_active=true) only after the test returns passed=true. |
update_workflow_tool | workflows:write | Write | workflow_id, tool_id | No contract flag | Edit a custom tool’s config (url, method, description, parameters, headers, timeout, flags, is_active). The name cannot change; delete and recreate to rename. URL rule: tool ARGUMENTS go in the url with SINGLE braces (/citas/{id_cita}). Double braces are ONLY for context values resolved before the call: {{env.KEY}} for secrets, {{lead.metadata.X}}, {{lead_id}}. Never {{arg}} for an argument: it is rejected with 400 invalid_url_placeholder and a suggested_url. After changing url, method, parameters, headers or query_parameters, run test_workflow_tool and set is_active=true only after the test returns passed=true. |
test_workflow_tool | workflows:write | Write | workflow_id, tool_id | No contract flag | Run one custom HTTP workflow tool once through the same path the agent uses: secrets, context, path and query parameters, and headers. The external system is called for real, but no Nexor lead or run changes. Works on inactive tools. Returns request (secrets redacted), response, what the agent sees, unresolved placeholders, and passed. called=false means the request never left; read agent_sees. Use args for model arguments and lead_metadata for {{lead.metadata.X}}. There is no lead, so test tools that need {{lead_id}} or other lead properties in Playground. GET runs directly. POST, PUT, PATCH, and DELETE need confirm_write=true after explicit operator approval, test data, and a cleanup path defined before execution. Never activate a tool whose test did not pass. Nexor platform tools return internal_tool_not_testable; test them in Playground. |
set_workflow_tool_execution | workflows:write | Write | workflow_id, tool_id, mode | No contract flag | Choose exactly how an assigned workflow tool runs. mode=“on_entry” makes it a pre-agent/pre-execution hook: it fires as soon as a lead enters the workflow, before the first agent message, and therefore clears stage gating. mode=“agent_decides” lets the conversational agent call it and optionally gates it to specific status keys. These modes are mutually exclusive. call_once limits successful execution per workflow run; is_active is an independent kill switch. |
delete_workflow_tool | workflows:write | Write | workflow_id, tool_id | No contract flag | Remove a custom tool. Soft-disables by default (keeps audit); pass hard=true to delete permanently. |
set_tool_stage_gate | workflows:write | Write | workflow_id, tool_id | No contract flag | Gate a tool to specific funnel stages: it becomes callable only when the lead is in one of available_in_statuses. Pass null to clear the gate (callable anywhere). |
Reusable client tools (6)
Reusable client tools (6)
| Tool | Scope | Mode | Required top-level input | Safeguard or availability | Canonical purpose |
|---|---|---|---|---|---|
list_client_tools | workflows:read | Read | None | No contract flag | List the client’s reusable tool catalog. Tools here can be assigned to multiple workflows and stay in sync. |
create_client_tool | workflows:write | Write | name, description, url | No contract flag | Create a reusable tool in the client catalog. This is the RECOMMENDED low-level path for an existing customer API operation that should be available across workflows; configure_customer_api_tool is the guided create-and-assign path. name is the immutable snake_case function identifier. description is loaded into the agent and must say when/how to call the API without containing credentials. parameters is the agent-visible JSON Schema. Use {{env.KEY}} in url/headers for secrets configured with set_function_environment_variable; lead/context placeholders are also supported. |
configure_customer_api_tool | workflows:write | Write | name, purpose, when_to_use, url | No contract flag | Turn one operation from an API the customer owns or already uses into a reusable Nexor agent tool, then optionally assign it to workflows. Creates the catalog tool, composes scoped agent instructions from purpose/when-to-use/when-not-to-use/response rules, and configures per-workflow stage gates, call-once behavior, and response-field allowlisting. Model one focused API operation per tool. Store credentials with set_function_environment_variable and reference them as {{env.KEY}} in headers; NEVER put credentials in purpose/instructions/parameter descriptions. This creates a new immutable name; use list_client_tools + update_client_tool when that name already exists. |
update_client_tool | workflows:write | Write | tool_id | No contract flag | Edit a catalog tool’s config. Changes propagate to every workflow that has assigned (inherited) this tool. The name cannot change — delete + recreate to rename. |
delete_client_tool | workflows:write | Write | tool_id | No contract flag | Remove a tool from the client catalog. |
assign_tool_to_workflow | workflows:write | Write | client_tool_id, workflow_id | No contract flag | Assign a catalog tool to a workflow; it inherits and stays in sync with the catalog tool. Idempotent — re-assigning an already-assigned tool returns the existing assignment. |
Web browsing (1)
Web browsing (1)
| Tool | Scope | Mode | Required top-level input | Safeguard or availability | Canonical purpose |
|---|---|---|---|---|---|
read_page | workflows:read | Read | url | No contract flag | Read ONE public web page and get its text content back (as markdown) — like the web-fetch tool in Claude/Codex. Use this to reference a website while helping a client build or configure their agent: e.g. read their homepage/services/pricing page so you can summarize it, seed a knowledge base, or draft prompt copy from it. Give the full http(s) URL of a single public page. One page per call, no crawling and no link-following: to read another page (including one linked from this one), call read_page again with that URL. The content is returned to YOU, the assistant — it is never inserted into a lead conversation. Public pages only (login-walled or empty pages come back as an error), and it runs on Nexor’s own scraper, so the client is not charged. Optional max_chars (1-100000, default 50000) caps how much text is returned. For ‘the agent should know my whole site’, use the knowledge base tools instead — that ingests many pages the agent then draws on at answer time. |
Leads (17)
Leads (17)
| Tool | Scope | Mode | Required top-level input | Safeguard or availability | Canonical purpose |
|---|---|---|---|---|---|
list_leads | leads:read | Read | None | No contract flag | Page through the authenticated client’s leads with optional search, workflow and human-assignee filters. When looking up specific people (search), pass include_detail:true: if 3 or fewer leads match, each comes back with its recent history (newest 20 items) and run_state in the same call. A workflow_id includes active and settled/inactive membership by default, matching get_pipeline_impact; pass run_state=active only for current runs. Every lead includes assigned_to plus assigned_user when assigned; use list_team (people:read) for the directory. For recurring polls, pass updated_since with sort_by=updated_at sort_dir=asc and resume from the max updated_at seen. in_support: the lead is waiting on a person (pending escalation or stage handoff) — the agent does not reply, even if is_paused is false; it does not mean someone is assigned. |
get_lead | leads:read | Read | lead_id | No contract flag | Fetch one lead by id, including its assigned human owner (assigned_to and assigned_user id/name, or null), field values, per-channel engagement and active workflow run. Use list_team (people:read) for the complete user directory. in_support: the lead is waiting on a person (pending escalation or stage handoff) — the agent does not reply, even if is_paused is false; it does not mean someone is assigned. |
get_leads | leads:read | Read | lead_ids | No contract flag | Batch read many leads by id in ONE call (1-500 per call), each with the same field values, per-channel engagement and workflow runs as get_lead. Always prefer this over calling get_lead in a loop — N sequential get_lead calls burn the rate limit. Unknown ids come back in missing_ids. in_support: the lead is waiting on a person (pending escalation or stage handoff) — the agent does not reply, even if is_paused is false; it does not mean someone is assigned. |
get_lead_history | leads:read | Read | lead_id | No contract flag | Read what was actually said or sent to ONE lead. The unified timeline returns full WhatsApp and SMS text, email subject/body plus delivery details, and call summary/transcript, with direction and timestamps; it also includes activities, meetings and conversions when unfiltered. Use channel=call,whatsapp,email,sms (one or comma-separated) to isolate communication content. The current stage is in current_stages (one per active run, unaffected by filters and paging; null if unreadable) and get_lead (newest active run only). Never infer it from history: stage changes are stored under the channel that triggered them (many under system), so a channel filter can hide some. Paging mode uses limit/offset and order_by; when pagination.has_more is true, keep paging before claiming the history is complete. Conversation-window mode uses anchor_ts with before/after (0-20 each) to inspect the messages around one moment. Use list_transcripts/get_transcript only for meeting transcripts, not phone calls. |
upsert_leads | leads:write | Write | leads | No contract flag | Create or update one or more leads (idempotent upsert on email/phone). When workflow_id is provided, enrollment has MOVE semantics: every other active run is deactivated before the target run is created, and the result is verified by reading each successful lead back. Use assign_lead_to_workflow for an already-known lead id. If the task is ACTIVE, enrolled leads are contacted right away per its cadence (calls wait for the contact hours of the task; messages go right away unless the task restricts messages to its hours); do-not-contact leads and reply-only tasks are excluded. If it is paused, contact starts when it is turned on. WARNING: first_message sends a real outbound message immediately (no agent composition) and also requires messages:send; first_channel only pins the first cadence channel. |
update_lead | leads:write | Write | lead_id | No contract flag | Update one lead. Put identity/contact values in standard fields (first_name, last_name, email, phone), and other agent-readable context in metadata. Metadata is shallow-merged and becomes available to the agent on its next execution; it does not change contact destinations or send data externally. Archived leads are rejected. |
sync_lead_tags | leads:write | Write | tags | No contract flag | Set the exact tag set for a lead (empty clears all tags). Identify the lead by id or email. |
assign_lead_to_workflow | leads:write | Write | lead_id, workflow_id | No contract flag | Move a lead into a workflow: deactivates the current run, creates a fresh run and starts its cadence. If the task is ACTIVE the lead is contacted right away per its cadence (calls wait for the contact hours of the task; messages go right away unless the task restricts messages to its hours); do-not-contact leads and reply-only tasks are excluded. If paused, contact starts when it is turned on. |
stop_automation | leads:write | Write | lead_id | No contract flag | Human takeover ON for a lead: pause its cadence and cancel pending scheduled tasks. The active workflow is resolved automatically; only pass workflow_id if the lead is in more than one. |
resume_automation | leads:write | Write | lead_id | No contract flag | Human takeover OFF for a lead; optionally reactivate its cadence (may resume outbound contact). |
set_lead_status | leads:write | Write | lead_id, status_key | No contract flag | Force a lead’s funnel status (move it forward or back). The active workflow is resolved automatically; pass workflow_id only if the lead is in more than one. |
bulk_set_lead_status | leads:write | Write | lead_ids, status_key | confirm_transfer_side_effects: true | Set the funnel status for many leads at once (1-500 per call). Applies the same per-lead status change (with history) as set_lead_status; leads that can’t be updated come back in failed with a reason. When the target status auto-messages (transfer_config), those leads are withheld with reason transfer_side_effects_require_confirmation — confirm with the operator, then re-call with confirm_transfer_side_effects=true to include them. |
bulk_assign_leads_to_workflow | leads:write | Write | lead_ids, workflow_id | No contract flag | Move many leads (1-500 per call) into a workflow: each gets its current run deactivated and a fresh run with cadence started. If the task is ACTIVE, leads are contacted right away per its cadence (calls wait for the contact hours of the task; messages go right away unless the task restricts messages to its hours); do-not-contact leads and reply-only tasks are excluded. If paused, contact starts when it is turned on. Failures come back per lead in failed. |
bulk_archive_leads | leads:write | Write | lead_ids | No contract flag | SOFT delete (archive) many leads at once (1-500 per call). REVERSIBLE: the leads disappear from active views and their automation stops, but the records are kept and can be restored. This does NOT permanently erase anything — for that, use bulk_hard_delete_leads. When the operator asks to “delete”/“remove”/“borrar”/“eliminar” leads and it is not crystal clear whether they mean archive (reversible) or permanent erase (irreversible), ASK before calling either tool. Confirm before calling. Failures come back per lead in failed. |
delete_lead | leads:write | Write | lead_id | No contract flag | SOFT delete (archive) one lead. REVERSIBLE: the record is kept and can be restored; this does NOT permanently erase it — for that, use hard_delete_lead. When the operator asks to “delete”/“remove”/“borrar”/“eliminar” a lead and it is not crystal clear whether they mean archive (reversible) or permanent erase (irreversible), ASK before calling either tool. |
hard_delete_lead | leads:delete | Write | lead_id | confirm: true | PERMANENTLY delete one lead. IRREVERSIBLE AND NOT RECOVERABLE: the lead and ALL of its data — every conversation, message, meeting, call, field value, note, and task — are erased forever. There is no undo and no restore. This is NOT archiving (use delete_lead for reversible archiving). Preview-then-confirm: call with confirm:false (or omit it) to get a { status:‘needs_confirmation’ } preview that writes NOTHING; only call again with confirm:true after the operator explicitly confirms permanent erasure of this exact lead. When “delete”/“remove”/“borrar”/“eliminar” is ambiguous between archive and permanent erase, ASK first — never assume hard delete. |
bulk_hard_delete_leads | leads:delete | Write | lead_ids | confirm: true | PERMANENTLY delete many leads at once (1-500 per call). IRREVERSIBLE AND NOT RECOVERABLE: each lead and ALL of its data — every conversation, message, meeting, call, field value, note, and task — are erased forever. There is no undo and no restore. This is NOT archiving (use bulk_archive_leads for reversible archiving). Preview-then-confirm: call with confirm:false (or omit it) to get a { status:‘needs_confirmation’ } preview that writes NOTHING; only call again with confirm:true after the operator explicitly confirms permanent erasure of these exact lead ids. When “delete”/“remove”/“borrar”/“eliminar” is ambiguous between archive and permanent erase, ASK first — never assume hard delete. Failures come back per lead in failed. |
Rules (9)
Rules (9)
| Tool | Scope | Mode | Required top-level input | Safeguard or availability | Canonical purpose |
|---|---|---|---|---|---|
get_reminder_catalog | rules:read | Read | None | No contract flag | The reminder contract for THIS account: channels with per-account availability (available_for_account + reason, e.g. retell needs an active callable number, sms an SMS-enabled number, whatsapp an active WhatsApp number, email a verified sender), trigger events the runtime actually dispatches (with which ones are reconciled onto existing bookings), delay references and default templates. Call it before set_reminder_rule when choosing a channel; pass workflow_id for the workflow-scoped answer. |
list_reminder_rules | rules:read | Read | None | No contract flag | List lead-facing reminder rules (booking confirmations, pre-meeting reminders). |
set_reminder_rule | rules:write | Write | trigger_event, template_name | No contract flag | Create or update a lead reminder rule (idempotent). Channels: whatsapp | retell | sms | email — whether each one can actually send on this account comes from get_reminder_catalog (available_for_account); a rule on an unavailable channel is stored but the response carries warning ‘channel_not_available’ until the sender is provisioned. trigger_event ‘call_analyzed’ fires post-CALL, not post-meeting; there is no ‘reschedule’ event (a reschedule re-fires event_created). delay_minutes is signed: negative with delay_reference=‘event_start’ means before the meeting. Example: {trigger_event:‘event_created’, channel:‘whatsapp’, template_name:‘confirm_booking’, delay_minutes:0}. |
list_host_reminder_rules | rules:read | Read | None | No contract flag | List host (sales rep) notification rules. Email-only. Note: cancellation notifications are on by default and may not appear here. |
set_host_reminder_rule | rules:write | Write | trigger_event, template_name | No contract flag | Create or update a host booking-notification rule (notify the rep by email when a meeting is booked; idempotent). Omit workflow_id for a global rule. Note: host cancellation and reschedule alerts are already sent by default and are not configured here. |
list_recontact_rules | rules:read | Read | None | No contract flag | List re-engage (recontact) rules that drive the AI scanner re-contacting stale leads. Each rule carries cadence_owned (true when its stage belongs to the initial outreach cadence, so it can never be active). |
set_recontact_rule | rules:write | Write | name, stale_after_hours | No contract flag | Create or update a re-engage rule (idempotent). The initial outreach cadence OWNS the stages new, contacted and the workflow’s initial stage: an active rule there returns 409 CADENCE_OWNED_STAGE (fix: target a later custom stage such as engaged/proposal_sent, or send is_active:false). prompt_hint is a binding instruction to the AI. A rule is identified by workflow_id + trigger_status_key: editing an existing one changes only the fields you send and keeps the rest (send prompt_hint "" to clear it). Defaults apply only when creating: stale_reference ‘last_touchpoint_at’ (recommended; ‘last_response_at’ silently freezes silent leads), cooldown 24, max_attempts 5, priority 5, on_exhausted mark_cold, active. |
list_status_timeout_rules | rules:read | Read | None | No contract flag | List status auto-timeout configs: the per-stage delays ({timeout, unit, target_status_key}) that move a lead to another status after time in a stage. This is the native delay primitive — read it before proposing any wait or delayed-handoff timing. |
set_status_timeout_rule | rules:write | Write | workflow_id, status_key | No contract flag | Set or clear the auto-timeout on a workflow status — the NATIVE way to add a delay between stages (dashboard: “If the lead does not reply → After N hrs → Move to”). After timeout unit (minutes|hours|days) counted from the moment the lead entered status_key (a reply does not reset it; a status change does), the lead moves to target_status_key, which must be an existing status key in the SAME workflow. Delayed handoff to another agent: point it at a terminal status that carries transfer_config — the transfer fires on arrival. Chain statuses for multi-step waits (each timer starts on entry). Use this before any Scheduled Function, Background Job or recontact rule for “wait N hours, then move/transfer”. The source status must not be terminal or the goal stage (the timeout would never fire). Pass clear:true to disable. |
People and invitations (7)
People and invitations (7)
| Tool | Scope | Mode | Required top-level input | Safeguard or availability | Canonical purpose |
|---|---|---|---|---|---|
list_team | people:read | Read | None | No contract flag | List the authenticated client’s active team members (sales reps / hosts) with user id, name, email, CRM external id and can_receive_escalations (whether escalation routing can assign them); pass include_inactive:true to also get removed members (is_active:false) so you can name a former teammate. Use these user ids with assigned_to filters; lead and conversation reads expose the matching assigned_user by default. |
get_team_availability | people:read | Read | None | No contract flag | Owners and admins only. Read who is Active or Away for lead assignment. Returns members (user_id, name, role, availability active|away, changed_at = since when, changed_by self|idle|admin, last_seen_at = last used the app, in_rule_stage, open_leads, assigned_today), waiting_leads (leads that arrived when nobody in the stage’s list was Active; max 100, oldest first), stages that assign an owner on entry (active_only = whether “only Active” is on, members, active_members) and idle_minutes. How it works (accounts where this answers): new members start Away; a member who does not use the app for idle_minutes is set Away automatically (checked every 5 min); waiting leads are handed out automatically, oldest first, as people turn Active. Going Away never moves leads already assigned. Change the idle time with set_availability_idle_time; set someone Away with set_member_away. |
set_member_away | workflows:write | Write | user_id | No contract flag | Owners and admins only. Set a team member Away, so stages with “only Active” stop giving them new leads. Away only: this tool never sets anyone Active; members turn themselves Active in the app. Leads already assigned to them stay with them. Use a user_id from get_team_availability or list_team. Returns { user_id, availability, changed_at, changed_by }. |
set_availability_idle_time | workflows:write | Write | idle_minutes | No contract flag | Owners and admins only. Set how many minutes a member can go without using the app before they are set Away automatically (default 50). Whole number from 10 to 480; applies to the whole account. Never sets anyone Active. Read the current value with get_team_availability. Returns { idle_minutes }. |
list_pending_invitations | people:read | Read | None | No contract flag | List outstanding invitations (not yet accepted, not cancelled, not expired). Consult this before inviting to avoid duplicates. |
invite_user | invites:write | Write | email, role | dry_run preview | Invite a person to the client’s organization by email and role. Idempotent: a still-valid pending invite to the same email is reused, not re-sent. Returns status: created | reused | already_member. |
revoke_invitation | invites:write | Write | None | No contract flag | Cancel a pending invitation by id or email (preserves audit; does not hard-delete). |
Messaging (8)
Messaging (8)
| Tool | Scope | Mode | Required top-level input | Safeguard or availability | Canonical purpose |
|---|---|---|---|---|---|
list_whatsapp_templates | leads:read | Read | None | No contract flag | List the client’s WhatsApp templates with components, variables, status, internal_type, language, quality_score, rejection_reason, is_in_pool and sync timestamps, plus totals { total, by_status }. Defaults to APPROVED; pass status=ALL for a complete terminal-readable approval dashboard, or select PENDING/REJECTED/etc. Filters: internal_type, language prefix, and q (name/body substring). For fresh Meta state call check_whatsapp_template_approvals. |
get_whatsapp_template | whatsapp:read | Read | None | No contract flag | Fetch one WhatsApp template in full detail: status, internal_type, language, category, components, variables, quality_score, rejection_reason (when Meta rejected it), whether it is in a cadence pool, and sync timestamps. Look it up by template_id (from list_whatsapp_templates) or by exact name. |
review_whatsapp_template_drafts | whatsapp:read | Read | templates | No contract flag | Read-only preflight for one or many WhatsApp template drafts. Use it as the conversational back-and-forth loop: generate drafts from the user requirement, call this tool, show errors/warnings and normalized_templates, revise, and repeat. It verifies the connected WhatsApp account, Meta formatting, examples for every variable, buttons, duplicate names/bodies, and cadence purpose. When all_valid=true it returns a review_id; show the exact normalized_templates to the user and get final sign-off before create_whatsapp_templates_batch. |
create_whatsapp_templates_batch | whatsapp:write | Write | templates, review_id, confirm | confirm: true | Submit 1-20 reviewed WhatsApp templates to Meta in one confirmed operation. REQUIRED FLOW: review_whatsapp_template_drafts → show normalized drafts and review_id → obtain explicit user sign-off → call this tool with those exact drafts, review_id, confirm=true. Never invent confirmation. Meta writes are not atomic, so the result reports every accepted, already-existing, or failed item; then use check_whatsapp_template_approvals to refresh approval states. |
create_whatsapp_template | whatsapp:write | Write | name, body | No contract flag | Create a new WhatsApp template and submit it to Meta for approval (usually minutes to 48h). Templates are AGENT-SPECIFIC: first resolve the target agent (ask, or list_workflows) and read it with get_workflow so the copy matches that agent’s persona, goal, product, and language — never write generic copy. After creation, wire the template into THAT agent’s cadence with set_whatsapp_template_purpose plus set_template_pool / set_opening_templates, or it is never auto-used. Body text uses {{variable}} placeholders — variables cannot start/end the text nor be consecutive. Name must be lowercase_with_underscores. PREFER the canonical variable names Nexor auto-resolves at send time: {{nombre}} (lead first name), {{agente}} or {{ejecutivo}} (agent name), {{empresa}} (company), {{producto}} (product), and for meeting reminders {{fecha}}, {{hora}}, {{asesor}}, {{link_reunion}}. Other names still work but fall back to LLM resolution. channel_id is optional when the client has a single WhatsApp business account (use list_whatsapp_numbers to disambiguate). |
send_message | messages:send | Write | lead_id, channel | No contract flag | Send an outbound message to a lead. WhatsApp/email/sms/imessage accept free text; outside the 24h WhatsApp window you must pass an approved template_id instead of text. channel=“sms” sends via the workflow’s SMS-enabled number. channel=“imessage” sends a blue-bubble iMessage via the workflow’s bound iMessage number (free text, no templates). channel=“call” triggers an outbound call. workflow_id is optional — it is resolved from the lead’s active run when omitted. |
send_whatsapp_template_bulk | messages:send | Write | lead_ids, template_id, confirm | confirm: true | Send one APPROVED WhatsApp template to up to 500 leads in one operation. Each lead gets the same send as send_message with a template_id. REQUIRED FLOW: call with confirm=false first. It sends nothing and returns the template (name, language, category) and lead_count. Show that to the user, get explicit sign-off, then call again with the same arguments and confirm=true. Never invent confirmation. The confirmed call returns bulk_id right away and sends in the background, one lead every ~3 s per WhatsApp number (500 leads take ~25 min). Nexor’s warm-up caps do not apply, except on a number with RED quality or a strict safety profile: there, if a cap is hit, the remaining leads are marked not_sent and can be sent later with a new call. Meta’s own daily messaging limit for the number still applies. Variables resolve per lead automatically. workflow_id is optional: omit it to use each lead’s active workflow. Track progress with get_whatsapp_template_bulk_send. |
get_whatsapp_template_bulk_send | messages:send | Write | bulk_id | No contract flag | Progress of a bulk send started with send_whatsapp_template_bulk. Returns status (queued | running | completed), lead_count, pending, counts by lead status and every lead’s status: sent (with message_id), failed or not_sent (with error; rate_limit:* means the cap of a RED-quality or strict number was reached), ambiguous_delivery or delivery_pending. Never re-send to an ambiguous_delivery or delivery_pending lead: the message may already have arrived. Results are kept for 7 days. |
Account (8)
Account (8)
| Tool | Scope | Mode | Required top-level input | Safeguard or availability | Canonical purpose |
|---|---|---|---|---|---|
list_lead_meetings | leads:read | Read | lead_id | No contract flag | List a lead’s calendar events with host and meeting type. |
create_meeting | meetings:write | Write | lead_id, starts_at, ends_at | No contract flag | Log a booked meeting against an existing lead (no Google Calendar sync). Idempotent via external_event_id. |
ingest_meeting_notes | meetings:write | Write | external_meeting_id, provider | No contract flag | Attach an external transcript / summary / action items to an existing meeting. The meeting is resolved via calendar_event_id, external_calendar_provider + external_calendar_event_id, meeting_url, or lead_email (+ optional meeting_date) — at least one is required. external_meeting_id only dedupes the notes (idempotency), it does NOT locate the meeting. Reserved providers (fireflies, diio, gemini, retell) are rejected by the backend. |
list_conversion_types | leads:read | Read | None | No contract flag | List the client’s active conversion types (optional; create_conversion works without one). A type is a named label for reporting plus a currency default; pass its id as conversion_type_id when a conversion should carry that label. |
set_conversion_type | leads:write | Write | name | No contract flag | Create or update a conversion type by name (idempotent upsert). Types are optional labels for reporting and a currency default (e.g. ‘Cuenta abierta’, ‘Primer depósito’); create_conversion works without one — untyped events are recorded and filterable on their metadata. Never deletes — deactivate with is_active:false; full removal is dashboard-only. / Crea o edita un tipo de conversión por nombre. Los tipos son etiquetas opcionales para reportes y una moneda por defecto; create_conversion no los necesita. |
create_conversion | leads:write | Write | None | No contract flag | Record that a lead converted. Only a lead identifier is required (exactly one of lead_id, lead_email, lead_phone); conversion_type_id, amount, currency, description and metadata are optional. Put every fact about the conversion (plan, order id, seller, branch, campaign) in metadata: it shows on the lead, reaches Cloud Functions (conversion.detected) and is filterable with list_conversions. Nexor moves the lead to the agent/status configured on the conversion type, else the lead’s current agent, else its group (set_conversion_destination); with no destination anywhere the lead stays where it is. Credit: pass workflow_id to credit one agent, or master_workflow_id alone for a GROUP-level conversion (no agent credited, the group’s destination applies); an explicit target beats the type’s scope, which beats the lead’s active agent. / Registra que un lead convirtió. Solo hace falta un identificador del lead; tipo, monto, moneda, descripción y metadata son opcionales. Pon todos los datos de la conversión en metadata: se ven en el lead, llegan a las Cloud Functions y se pueden filtrar. Nexor mueve el lead al agente/estado del tipo, si no al del agente actual, si no al del grupo (set_conversion_destination). |
list_conversions | leads:read | Read | None | No contract flag | List conversion events for the client, typed and untyped, newest first. Filter by lead, agent (workflow_id), group (master_workflow_id), run, conversion type (conversion_type_id, or ‘none’ for untyped events only) and exact-match top-level metadata keys (metadata: { plan: ‘anual’ }). Use it to verify a conversion landed (list_conversions({ lead_id })) and for revenue/attribution questions. / Lista los eventos de conversión del cliente con filtros por lead, agente, grupo, tipo (‘none’ = sin tipo) y metadata. |
list_campaigns | leads:read | Read | None | No contract flag | List the client’s campaigns. |
Background jobs (10)
Background jobs (10)
| Tool | Scope | Mode | Required top-level input | Safeguard or availability | Canonical purpose |
|---|---|---|---|---|---|
list_background_jobs | workflows:read | Read | None | No contract flag | List the client’s background jobs (scheduled or forced lead automations). |
get_background_job | workflows:read | Read | job_id | No contract flag | Fetch a background job by id with its recent executions. |
create_background_job | workflows:write | Write | name, steps | dry_run execution mode | Create a background job: a scheduled/forced automation that filters leads and runs steps on each. trigger_type “cron” needs a cron_expression; “api” runs only when forced (run_background_job). A step can evaluate a date/condition — on a metadata key (evaluate_metadata), a collected funnel field (evaluate_field), or a tag (evaluate_tag) — and act, OR run an action directly. Actions include sending a WhatsApp template (send_message), set_lead_status, assign/transfer workflow. lead_filters/workflow_filters select candidates; max_leads_per_cycle caps each run (≤500); cooldown_minutes avoids re-acting on the same lead; dry_run logs without acting. See the steps field for the full vocabulary and lead_filters / workflow_filters for how candidates are selected. Filters and steps are validated server-side: an unresolvable one is rejected with code invalid_filters / invalid_steps and a details[] naming each problem. Common use: send a survey template once to everyone sitting in a given status. |
update_background_job | workflows:write | Write | job_id | dry_run execution mode | Update a background job (any subset of its config). Filters and steps are validated server-side (invalid_filters / invalid_steps with details[]). See lead_filters / workflow_filters for candidate selection and steps for the action vocabulary (send_message, evaluate_field, set_lead_status, …). |
set_background_job_active | workflows:write | Write | job_id, active | No contract flag | Pause or activate a Background Job without changing the rest of its configuration. Keep dry_run:true until execution logs are verified. |
delete_background_job | workflows:write | Write | job_id | No contract flag | Delete a background job (cascades its execution history). |
run_background_job | workflows:write | Write | job_id | Operator approval in instructions | Force-run a Background Job now (bypasses schedule/active timing). A non-dry-run job can mutate real leads; inspect config and get explicit operator confirmation first. |
list_background_job_executions | workflows:read | Read | job_id | No contract flag | A background job’s recent execution history (counts of candidates/acted/errored per run). |
get_background_job_execution | workflows:read | Read | execution_id | No contract flag | Get one Background Job execution with every per-lead action, tool response, condition result, mutation result, skip, and error. |
analyze_background_job_template | workflows:read | Read | template_name | No contract flag | Inspect an APPROVED WhatsApp template used by send_message: shows each {{variable}}, whether it resolves automatically or via a workflow tool, and configuration errors. |
Reports (12)
Reports (12)
| Tool | Scope | Mode | Required top-level input | Safeguard or availability | Canonical purpose |
|---|---|---|---|---|---|
get_reminder_report | reports:read | Read | date_from, date_to | No contract flag | Reminder scheduling and WhatsApp delivery metrics by total, local day, hour and failure code. Use bucket=total for totals; never sum different buckets. Requires an explicit period of at most 93 days: ISO timestamps with timezone, date_to exclusive. Scheduled reminders (all channels) and tagged WhatsApp message attempts are separate populations; completed jobs do not prove delivery. Includes sent, delivered, read, failed, pending, unique/reached leads and delivery_rate (delivered / recorded attempts). Receipt status is current; untagged historical messages are excluded. Empty rows mean no matching records. Does not measure Teams confirmation or attendance. |
export_leads_report | reports:read | Read | workflow_ids | No contract flag | Create a complete CSV export of every active, non-test lead in one or more exact workflows, including each lead current stage. Use for requests such as “todos los leads”, “exporta”, “descarga” or “dame un CSV”. First resolve workflow names to their UUIDs with list_workflows, then pass those UUIDs here. Returns a signed download URL. |
query_insights | reports:read | Read | None | No contract flag | Chart Insights numbers for leads, meetings and the team: rows, spec, range and notices. Prefer a template: it fixes the chart and default period. For period numbers use these ids: leads_new = distinct people created; task_entries = each entry into a task, transfers, reassignments, deleted tasks and HubSpot bulk imports included, split by entry_kind (never call an entry a lead); leads_contacted = distinct leads Nexor contacted, the usage count (contacts on HubSpot bulk-import runs not counted); leads_replied = distinct leads who wrote, answered a call or replied to an email; leads_uncontacted = new leads not contacted yet. Contacted and replied do not add up across days or agents; quote the total. Old ids keep their old meaning and numbers (see metric) and add a METRIC_REPLACED notice. period is in the client timezone; never compute dates for it. Without a template pass metric, x, group_by and a period or from/to. Pass the returned spec and range to the chart. For a period summary use get_period_report. |
get_period_report | reports:read | Read | date_from, date_to | No contract flag | Server-computed summary for weekly or period reports. New leads: distinct people created. Task entries: each entry into a task, transfers, reassignments and HubSpot bulk imports included, split into new and existing leads. Contacted leads: same count as usage, a Nexor message or call, or a Nexor move to a contacted stage; a Nexor email counts only through that move, and a contact on a HubSpot bulk-import run is not counted. Replied leads: distinct leads who wrote, answered a call or replied to an email. Days are the account time zone; bare dates are whole days; at most 366 days. as_of before the window end means the period is not complete: say up to when it counts. Only tasks[].entries add up, to totals.entries; lead counts do not add up across tasks, so quote totals.leads. tasks[] kind deleted = deleted tasks, kind none = replies with no task. definitions states each unit. If it returns PERIOD_REPORT_UNAVAILABLE, retry once, then say the report could not be computed; never replace it with other tools. |
get_funnel_report | reports:read | Read | None | No contract flag | Current snapshot of active runs per stage, with how many were contacted/connected, per workflow (or across all workflows). Use for “how many leads are at each stage right now” questions. date_from/date_to filter by lead creation in UTC days. These are not period totals; for a weekly or period summary use get_period_report. |
get_field_distribution | reports:read | Read | field_key | No contract flag | Distribution of a captured lead field (e.g. a disqualification reason) with counts per value and an example evidence quote. Ideal for “top reasons why…” style questions. |
get_call_stats | reports:read | Read | None | No contract flag | Call statistics (dials, connected, discovery calls, duration) for a date range, totaled or broken down by day. |
get_lead_report | reports:read | Read | lead_id | No contract flag | Full report bundle for ONE lead: profile, current status, captured field values with evidence, insights, a summary of each call and scheduled tasks — all in one call. Prefer this over get_lead + get_lead_history when the goal is writing a report about a lead. |
get_engagement_metrics | reports:read | Read | None | No contract flag | Engagement snapshot for a date range (default: trailing 7 days): total leads, new leads, meetings booked, and outbound/inbound activity. Test leads are excluded. messages_inbound/messages_outbound count MESSAGES, not leads: one lead can send many. For “how many leads replied” or “how many leads we messaged” use leads_inbound/leads_outbound (distinct leads over the same messages, window and filters); definitions states each unit. The counts span every messaging channel together, including call transcript turns (what the lead said on a call counts as inbound), and there is no channel filter, so never attribute a total to one channel. Emails (sent or replied) and Instagram/Messenger DMs are not counted (they live in a separate store). Days are the account time zone. Use it for activity questions; for a weekly or period summary use get_period_report, and for per-status funnel breakdowns use get_funnel_report. |
get_seller_assignment_metrics | reports:read | Read | None | No contract flag | Analyze how the client’s leads are distributed across human sellers. Returns assignment coverage (total, assigned, unassigned and assignment rate) plus one row per seller with assigned leads, share of assigned leads, current funnel-stage breakdown, unanswered conversations, meetings booked/completed, conversions, conversion value and conversion rate. Assignment is a CURRENT-OWNER snapshot: historical activity is attributed to the lead’s current assigned_to seller, not necessarily the seller who owned it when the activity happened. Date filters select leads by created_at and activity by each event’s timestamp. Use list_team (people:read) when you need the complete user directory. |
get_team_performance | reports:read | Read | None | No contract flag | What each teammate did in a period. Per member: leads_assigned_now (current owner snapshot), leads_assigned_in_range (leads newly assigned to them in the period), human_messages (messages the teammate typed in Nexor; WhatsApp Business app replies cannot be tied to a person and are counted in unattributed.business_app_messages), escalations_resolved, escalations_overdue (escalations on their leads that went overdue in the period), escalations_answered and median_first_reply_minutes (median minutes from an escalation opening to the teammate’s first reply; null when none were answered). Default period is the last 30 days, max 92. For current lead ownership, meetings and conversions per seller use get_seller_assignment_metrics. |
analyze_lead_fields | reports:read | Read | None | No contract flag | Statistical analysis of captured lead field values: numeric fields get min/max/mean/median/p25/p75/stddev/outlier_count, boolean/categorical fields get top-15 value frequencies. Filter by workflow, specific field keys, lead statuses, or an explicit lead list (max 50). Ideal for “what is the average budget of qualified leads” or comparing field values across a segment. If your filters match nothing, the response includes available_field_keys as a hint. For a simple one-field value distribution with evidence quotes, prefer get_field_distribution. |
Meetings (8)
Meetings (8)
| Tool | Scope | Mode | Required top-level input | Safeguard or availability | Canonical purpose |
|---|---|---|---|---|---|
list_meetings | leads:read | Read | None | No contract flag | Page through the client’s meetings (booked calls/appointments) with lead, workflow, time and status for each. Ideal for questions like “what meetings are scheduled this week”, “which meetings were no-shows”, or listing a single lead’s meetings. For aggregate counts/rates use get_meeting_stats instead. |
get_meeting_stats | reports:read | Read | None | No contract flag | Aggregate meeting statistics for a date range: totals per status (completed, no_show, cancelled, scheduled, rescheduled) plus show_rate, completion_rate and no_show_rate (0-1, null when the denominator is 0). Ideal for “what is our show rate” or “how many meetings did we book last month” questions. For individual meetings use list_meetings. |
set_meeting_status | meetings:write | Write | meeting_id, status | No contract flag | Record the outcome of a meeting: ‘no_show’ (the lead did not attend) or ‘completed’. Runs the same side effects as the dashboard — the no-show re-engagement rule (when configured), the meeting webhook, Cloud Function events and the lead timeline — then reads the meeting back with its provider sync status. Idempotent: re-marking the same outcome is a no-op. meeting_id is the calendar event id from list_meetings / list_lead_meetings. To cancel a meeting use cancel_meeting; to move it use reschedule_meeting. |
cancel_meeting | meetings:write | Write | meeting_id | confirm: true | Cancel a booked meeting. DESTRUCTIVE and lead-facing: deletes the event from the host’s calendar (provider-first — if that fails nothing is cancelled), releases the slot, cancels lead and host reminders, emails the lead a cancellation and notifies the host, fires the meeting webhook and any cancellation re-engagement rule. Preview-then-confirm: call with confirm:false (or omit it) to get a { status:‘needs_confirmation’ } preview that writes NOTHING; only call again with confirm:true after the operator explicitly confirms cancelling this exact meeting. Meetings owned by an external provider (Calendly, GoHighLevel…) come back { status:‘skipped’ }. Reads the meeting back afterwards. |
get_workflow_slots | workflows:read | Read | workflow_id, from, to | No contract flag | Free booking slots for a workflow’s hosts between two dates, in the workflow’s timezone — the same slot engine the dashboard meetings board uses (host calendars, availability schedules, buffers, tier rules). Use it to verify a host produces slots and to pick a starts_at for book_meeting / reschedule_meeting. meeting_type_id defaults to the workflow’s first active meeting type; host_id restricts to one host (must be an active agent of the workflow). |
book_meeting | meetings:write | Write | workflow_id, lead_id, host_id, starts_at | confirm: true | Book a meeting for a lead with a host at starts_at, with the SAME side effects as booking from the dashboard: calendar event on the host’s connected calendar (Google/Outlook/Calendly), conferencing link, lead invite + confirmation email (unless invite_lead:false), host notification and reminders, availability block, and the workflow status transition. Pick starts_at from get_workflow_slots. A slot already taken returns CONFLICT with same-day alternatives. Pass the same idempotency_key to retry safely — a replay returns the original booking without booking again. Preview-then-confirm: when the lead will be invited, call with confirm:false (or omit it) to get a { status:‘needs_confirmation’ } preview that writes NOTHING; call again with confirm:true only after the operator explicitly approves. The response includes provider_sync — check its status; ‘sync_failed’ means the row exists but the calendar write failed. |
reschedule_meeting | meetings:write | Write | meeting_id | confirm: true | Move a booked meeting to a new time (starts_at, or a slot object from get_workflow_slots). Provider-aware: the host’s calendar event is updated first and the meeting link is kept when the host is unchanged; keep_host:false with a host_id rebooks on the new host (new link). The lead receives a reschedule email and the host is notified. Preview-then-confirm: call with confirm:false (or omit it) to get a { status:‘needs_confirmation’ } preview that writes NOTHING; call again with confirm:true only after the operator explicitly approves. Meetings owned by an external provider come back CONFLICT/MANAGED_EXTERNALLY. Returns the meeting read-back with provider_sync. |
change_meeting_host | meetings:write | Write | meeting_id, host_id | confirm: true | Reassign a booked meeting to another host (active agent of the same workflow) without changing the time. Provider-aware: the calendar event is moved to the new host’s calendar first (new organizer/link where the provider requires it); if that move fails nothing changes. The lead’s invite is updated. Preview-then-confirm: call with confirm:false (or omit it) to get a { status:‘needs_confirmation’ } preview that writes NOTHING; call again with confirm:true only after the operator explicitly approves. Returns the meeting read-back with provider_sync. |
Transcripts (2)
Transcripts (2)
| Tool | Scope | Mode | Required top-level input | Safeguard or availability | Canonical purpose |
|---|---|---|---|---|---|
list_transcripts | leads:read | Read | None | No contract flag | Page through meeting transcripts: per row the lead, meeting date, title, a short summary (<=500 chars), whether it has action items, and duration. Ideal for “what was discussed in recent meetings” or finding a transcript by keyword before drilling in with get_transcript. |
get_transcript | leads:read | Read | transcript_id | No contract flag | Fetch ONE meeting transcript by id: lead, meeting date, title, full summary, action items and duration. Set include_full_text/include_sentences only when you actually need the verbatim conversation — they can be very large. Use list_transcripts first to find the id. |
Conversations (3)
Conversations (3)
| Tool | Scope | Mode | Required top-level input | Safeguard or availability | Canonical purpose |
|---|---|---|---|---|---|
search_conversations | leads:read | Read | None | No contract flag | Search messages across ALL leads at once (get_lead_history covers a single lead). Results include the lead’s assigned human owner by default (assigned_to plus assigned_user id/name, or null); filter by assigned_to or unassigned_only, and use list_team (people:read) to resolve the full user directory. Two modes: normal mode returns matching messages with lead, channel, direction and a content preview — ideal for “who mentioned pricing this week”. Each normal-mode row is one MESSAGE, not one lead: to count leads, count distinct lead ids (a full page of limit rows means the count may be higher). unanswered=true instead returns leads whose LAST message is an unanswered inbound (waiting on a reply) — ideal for “which leads are waiting on us”. |
get_inbox_summary | leads:read | Read | None | No contract flag | Inbox workload per teammate, plus an unassigned row and totals. Counts: conversations (leads with at least one touchpoint), unanswered (the lead wrote last and no one concluded the conversation), escalated_open (the agent handed the lead to a human and it is still pending), escalated_overdue (leads with an unresolved escalation that passed its response deadline), human_takeover (a teammate took over and the AI is paused). Rows follow the lead’s current owner, sorted by unanswered. Use list_escalations for the escalations themselves, search_conversations with unanswered=true for the waiting leads, and get_team_performance for activity over a period. |
list_escalations | leads:read | Read | None | No contract flag | List escalations: moments the AI agent handed a lead to a human (question, reason, channel). status: open (pending, default), overdue (pending and past its response deadline), resolved, or all. Each row has lead, agent, the lead’s current owner (assigned_to), overdue flag and, once closed, resolved_at, resolution_outcome and resolved_by. Open and overdue are sorted oldest first (longest wait on top); resolved and all newest first. Paginate with limit and offset against total. Use get_inbox_summary for counts per teammate. |
Integrations (1)
Integrations (1)
| Tool | Scope | Mode | Required top-level input | Safeguard or availability | Canonical purpose |
|---|---|---|---|---|---|
get_integration_status | workflows:read | Read | None | No contract flag | One-call health summary of the client’s integrations: connected CRMs (kommo, hubspot, gohighlevel, zoho and odoo; provider, status, connected_at, last_synced_at, error), counts of WhatsApp numbers, phone numbers and email senders, calendars[] (one per host calendar connection: user_id, name, provider google|outlook|calendly, status active|expired|revoked|error|needs_reauth, role, calendar_email, last_error, connected_at) and booking_providers[] (one per appointment-capable agent: provider native|calendly|gohighlevel|external_booker, binding summary, host_count, excluded_hosts = Calendly hosts with no event type bound, which booking silently skips) and google_sheets (active and paused automation counts; detail in get_google_sheets_status). Ideal for “is our CRM synced”, “is the calendar connected” or “why can’t the agent book” questions; drill into a channel with its own list tool (list_whatsapp_numbers, list_phone_numbers, list_email_senders). |
Phone numbers (7)
Phone numbers (7)
| Tool | Scope | Mode | Required top-level input | Safeguard or availability | Canonical purpose |
|---|---|---|---|---|---|
search_available_numbers | numbers:read | Read | country | No contract flag | List phone numbers available to buy in a country (ISO code, e.g. “CL”, “MX”). Read-only preview — buying one is provision_phone_number. |
list_phone_numbers | numbers:read | Read | None | No contract flag | List the client’s voice and SMS phone numbers. workflow_id is the call owner; sms_enabled and sms_workflow_id independently show whether SMS is active and which agent receives it. A call assignment alone never proves the number can send SMS. Check get_account_readiness.account.sms_eligible before offering SMS: US/CA are eligible by default; other accounts require client.settings.sms_enabled === true. A number’s country is not the account eligibility test. This list does not report iMessage state; use list_imessage_numbers for that channel. |
provision_phone_number | numbers:write | Write | phone_number, country_code | No contract flag | Buy and provision a phone number for the client (Twilio purchase + Retell import). Billable and capped per client (default 3 active). Pass a workflow_id to bind the number to that workflow (workflow-scoped); omit it for an account-wide client-scoped number. Fails with NUMBER_LIMIT_REACHED at the cap — release or deactivate one first. Buying does NOT make the number answer inbound calls: for an agent’s voice task, once that task is active and does not exclude calls (identity and voice come from the agent), connect it with set_inbound_entry_point (channel “phone”, id = the returned number id, destination {type:“group”, id: the agent id}), which also turns the agent’s router on. Never use assign_number_to_workflow for a task that belongs to an agent. |
assign_number_to_workflow | numbers:write | Write | number_id | No contract flag | Reassign one of the client’s numbers to a workflow (workflow-scoped) or, with no workflow_id, make it the account-wide client-scoped number. Only reassigns within the client’s own workflows. This does NOT connect inbound calls, and a task that belongs to an agent (has master_workflow_id) is never bound here: connect the number to its agent with set_inbound_entry_point (channel “phone”, destination {type:“group”, id: the agent id}). |
set_number_sms | numbers:write | Write | number_id, enabled | No contract flag | Activate SMS on an existing active Twilio number and bind its separate sms_workflow_id to the intended agent. First check get_account_readiness.account.sms_eligible: US/CA accounts are eligible by default; a non-US/CA account needs client.settings.sms_enabled === true. Eligibility does not mean a number is ready. Read list_phone_numbers or get_number_health after activation and verify sms_enabled === true and sms_workflow_id matches the agent. workflow_id only routes calls. Telnyx numbers cannot carry SMS. |
get_number_health | numbers:read | Read | number_id | No contract flag | Non-destructive health/read-back for one of the client’s numbers: reports the number’s active state, provider, its call binding and its SMS binding (enabled + owner workflow), and any issues — without placing a call or sending a message. |
deactivate_number | numbers:write | Write | number_id | No contract flag | Soft-deactivate one of the client’s numbers (stops it being used; does NOT release it from Twilio, so billing continues). Reversible. |
WhatsApp numbers (11)
WhatsApp numbers (11)
| Tool | Scope | Mode | Required top-level input | Safeguard or availability | Canonical purpose |
|---|---|---|---|---|---|
list_whatsapp_numbers | whatsapp:read | Read | None | No contract flag | List the client’s WhatsApp numbers with connection status, quality rating, messaging-limit tier, account restrictions, last health-check time, connection type, and bound workflow. |
connect_whatsapp_number | whatsapp:write | Write | None | No contract flag | Start connecting a WhatsApp number for the client: returns a hosted Kapso setup link the client opens to finish onboarding (choose dedicated/coexistence, Meta login). IMPORTANT — give the returned setup URL to the user DIRECTLY as a clickable link (e.g. “Connect your WhatsApp number here: <url>”) and tell them to open it; the authorization happens entirely on that page and CANNOT be completed in chat, so never withhold the URL or claim you’ll connect it for them. Works even when a number is already connected — this adds a NEW one (several allowed per client). Once the user finishes on the hosted page, Nexor records the number and registers its inbound webhook + events automatically (no extra call needed); confirm with list_whatsapp_numbers. Capped per client (default 10) — fails with WHATSAPP_LIMIT_REACHED at the cap. Then bind it with assign_whatsapp_to_workflow. |
assign_whatsapp_to_workflow | whatsapp:write | Write | number_id | No contract flag | Bind one of the client’s WhatsApp numbers to a workflow (agent) — this is what makes inbound WhatsApp messages on that number reach the agent. Omit workflow_id to unbind. Makes the number the default for that workflow. |
deactivate_whatsapp_number | whatsapp:write | Write | number_id | No contract flag | Soft-deactivate one of the client’s WhatsApp numbers (stops it being used; reversible; does NOT disconnect it from Kapso). |
rename_whatsapp_number | whatsapp:write | Write | number_id, internal_name | No contract flag | Set the operator-facing internal label of one of the client’s WhatsApp numbers (does not change the WhatsApp display name shown to leads — for that use set_whatsapp_display_name). Pass an empty internal_name to clear it. |
reconcile_whatsapp_number | whatsapp:write | Write | number_id | No contract flag | Re-check a WhatsApp number against the provider and repair its route status — the fix for a number that shows a broken/invalid connection or after a failed setup return. Returns the refreshed state; run get_whatsapp_health afterwards to confirm. If the number needs a fresh Meta authorization, reconnect via connect_whatsapp_number (a new hosted setup link). |
get_whatsapp_business_profile | whatsapp:read | Read | number_id | No contract flag | Read the WhatsApp business profile shown to leads for one number: display name, its Meta review status (APPROVED / PENDING_REVIEW / etc.), and profile picture. Use before set_whatsapp_display_name to see the current name and whether a review is pending. |
set_whatsapp_display_name | whatsapp:write | Write | number_id, display_name | No contract flag | Submit a new WhatsApp display name (the name leads see) to Meta for review. Must be 3-256 characters. Meta review can take minutes to a couple of days; the response reports displayNameStatus=PENDING_REVIEW. Re-check with get_whatsapp_business_profile. |
set_whatsapp_profile_photo | whatsapp:write | Write | number_id, image_url | No contract flag | Replace the WhatsApp profile picture for a number from a public HTTPS image URL (Nexor ingests it into Meta). The image must already be hosted at an https:// URL — this tool does not upload local files. |
get_whatsapp_business_verification | whatsapp:read | Read | number_id | No contract flag | Read the Meta business verification of the business that owns one WhatsApp number: status (not_verified / in_review / changes_requested / verified / attempts_exhausted / ineligible …), the business legal name Meta expects (business_name), attempts_left of 3, whether a new submission is allowed, accepted file types/limits, and the latest submission with Meta’s rejection_reasons or a last_error (file could not be downloaded, no attempt used). Verified businesses get higher messaging limits. Only numbers connected through Nexor can be verified here; a sandbox number returns not_found. |
submit_whatsapp_business_verification | whatsapp:write | Write | number_id, documents, authorized | No contract flag | Send 1-3 documents (PDF/JPG/PNG, max 5 MB each, public HTTPS URLs) to Meta to verify the business that owns a WhatsApp number. Together they must show the legal name AND address exactly as business_name from get_whatsapp_business_verification. IRREVERSIBLE: each submission Meta receives uses 1 of 3 lifetime attempts, so first tell the customer the documents go to Meta and use one attempt, get their explicit confirmation, then pass authorized=true. Returns the submission: state pending (Meta reviews in minutes to hours; re-check with get_whatsapp_business_verification) or failed with last_error (file unreadable, no attempt used). |
WhatsApp health (3)
WhatsApp health (3)
| Tool | Scope | Mode | Required top-level input | Safeguard or availability | Canonical purpose |
|---|---|---|---|---|---|
get_whatsapp_health | whatsapp:read | Read | number_id | No contract flag | Live health and risk for one WhatsApp number. Returns quality_rating (GREEN/YELLOW/RED — RED means the account is at risk of Meta restriction), messaging_health (can_send_message AVAILABLE/LIMITED/BLOCKED with per-entity WABA/phone errors and suggested fixes), messaging_limit tier + daily ceiling, route_verification (whether the provider route is valid or needs reconnect/resync), and inbound_traffic: messages the provider received vs messages that reached Nexor in the last 7 days, with a verdict. no_inbound_at_provider means nobody is writing to this number, so the ads or the number the business publishes point to another one (a configuration fix, not an outage); provider_received_not_in_nexor is a real delivery incident to escalate; receiving means inbound flows; provider_unavailable means the provider could not be read, so do not conclude either way. This is the tool for ‘is my WhatsApp at risk / why can’t it send / what’s my sending limit / leads say they write and the agent never answers’. One call triggers several Meta calls, so results are briefly cached — don’t poll it in a tight loop. |
get_whatsapp_response_timing | whatsapp:read | Read | None | No contract flag | Read the client’s inbound WhatsApp debounce (buffer window): how long Nexor waits to group a lead’s rapid consecutive messages into a single AI reply. Returns buffer_window_seconds, whether it’s the default, and the allowed min/max. |
set_whatsapp_response_timing | whatsapp:write | Write | buffer_window_seconds | No contract flag | Set the client’s inbound WhatsApp debounce (buffer window) in seconds — larger groups more messages into one reply (more natural, slightly slower); smaller replies faster but may fragment. The change fans out to every active number’s webhook; the response reports per-number apply status. Typical range is 5-60 seconds. |
iMessage numbers (8)
iMessage numbers (8)
| Tool | Scope | Mode | Required top-level input | Safeguard or availability | Canonical purpose |
|---|---|---|---|---|---|
get_imessage_offer | imessage:read | Read | None | No contract flag | Read the iMessage number add-on offer for the client BEFORE provisioning: the recurring monthly price (USD), the amount charged today (dueTodayUsd — the full first month, never prorated; 0 in a sandbox/test environment where no charge happens), whether the client can buy (canPurchase) and if not why (reason, e.g. no_subscription / trial_not_allowed / no_payment_method / external_billing / purchase_disabled), the card on file (brand + last4), how many iMessage numbers they already own, and a state of active | purchasable | unavailable. ALWAYS call this first and confirm the recurring charge with the user before calling provision_imessage_number. If state is “unavailable” the add-on is not enabled for this client — do not attempt to provision. |
list_imessage_numbers | imessage:read | Read | None | No contract flag | List the client’s iMessage numbers with their E.164 phone number, setupStatus (provisioning | ready | failed), setup error if any, the workflow (agent) each is bound to, display identity (displayFirstName, displayLastName, avatarUrl), and active state. imessageWorkflowId is the single OWNER; owner adds its name and agent group (masterWorkflowId, masterName) and sharedWith lists every sibling agent in that group that already sends and receives through this number without owning one — a number is shared across an agent group exactly like WhatsApp, so an agent listed in sharedWith is connected and needs no assign call. Use this to poll until a freshly provisioned number reaches setupStatus “ready”, and to find a number id for get_imessage_number, assign_imessage_to_workflow, set_imessage_display_name or set_imessage_profile_photo. |
provision_imessage_number | imessage:write | Write | accept_charge | accept_charge: true | Buy and provision a NEW iMessage number for the client. THIS CHARGES MONEY: it charges the FULL first month today (never prorated) and adds a recurring monthly line (see get_imessage_offer for the exact price) to the client’s Stripe subscription. You MUST first call get_imessage_offer, show the user the recurring price and the amount charged today, and get their explicit confirmation — only then call this with accept_charge:true. Fails with imessage_consent_required if accept_charge is not true, and with an eligibility code (e.g. imessage_no_subscription, imessage_no_payment_method, imessage_purchase_disabled) when the client cannot be charged. The charge is idempotent per call. On success the number provisions asynchronously — poll list_imessage_numbers until setupStatus is “ready”, then bind it with assign_imessage_to_workflow. |
assign_imessage_to_workflow | imessage:write | Write | number_id | No contract flag | Bind one of the client’s iMessage numbers to a workflow (agent) — this is what makes inbound iMessages on that number reach the agent. The number is then shared by the agent’s whole agent group (master_workflow_id): every sibling sends and receives through it automatically (new inbound leads land on the owner agent; existing leads follow their active run), so bind ONCE per group and never re-assign it to a sibling that list_imessage_numbers already shows in sharedWith. Unless a display identity was set by hand (set_imessage_display_name), the number’s display name follows the owner agent’s persona. Omit workflow_id to unbind (the number stays owned/billed, just detached). A group (or a standalone agent) keeps at most one iMessage number, so binding a number to an agent whose group already has one replaces it. |
get_imessage_number | imessage:read | Read | number_id | No contract flag | Read one iMessage number’s live details: E.164 phone number, setupStatus (provisioning | ready | failed) and setup error, the workflow (agent) it is bound to plus its agent group (owner) and the sibling agents sharing it (sharedWith), and the blue-bubble display identity leads see — firstName, lastName, avatarUrl — plus active state. whatsappStatus “ready” means the same line also runs WhatsApp and shares this identity (whatsappName / whatsappAvatarUrl show what WhatsApp currently displays). Use before set_imessage_display_name / set_imessage_profile_photo to see the current identity. Fails with imessage_number_not_found for a number outside this client. |
reconcile_imessage_number | imessage:write | Write | number_id | No contract flag | Re-check one iMessage number against Dial (the provider) and repair its local setupStatus — the fix for a number stuck on “provisioning” or “failed” in list_imessage_numbers even though it is actually ready. list_imessage_numbers reads a locally cached status that is normally advanced only by Dial’s setup webhook, so a single missed webhook leaves the number permanently desynced; get_imessage_number reads the live truth from Dial but does not persist it. This tool fetches the live Dial status and writes it back, so the list/capabilities path matches reality. Returns the refreshed number; re-run list_imessage_numbers or get_imessage_number afterwards to confirm. Fails with imessage_number_not_found for a number outside this client. |
set_imessage_display_name | imessage:write | Write | number_id | No contract flag | Set the first and/or last name shown beside an iMessage number’s messages in recipients’ Messages apps (max 30 characters each; pass an empty string to clear one). Propagates to devices within minutes. Once set by hand the identity is authoritative: it no longer follows the agent persona when the number is (re)assigned. If the line also runs WhatsApp (whatsappStatus “ready”) the same name is written to its WhatsApp profile as one line — first + last joined must be at most 25 characters, otherwise the call fails with fieldErrors.whatsappName = too_long and NOTHING changes on either channel. Fails with imessage_number_invalid_fields (+ fieldErrors) when a value is rejected. Read the current identity first with get_imessage_number. |
set_imessage_profile_photo | imessage:write | Write | number_id, image_url | No contract flag | Replace the profile photo shown beside an iMessage number’s messages from a public http(s) image URL (jpeg/png/gif/webp, ≤5 MB; the platform mirrors it and returns its stable avatarUrl). Photos can be replaced but NOT removed. This tool does not upload local files — the image must already be hosted; the dashboard’s iMessage identity editor can upload a file from the operator’s computer instead. If the line also runs WhatsApp (whatsappStatus “ready”) the photo is applied to both profiles at once, so it must also satisfy WhatsApp’s rules — a square JPG or PNG between 192 and 640 px — or the call fails with fieldErrors.whatsappAvatarUrl and NOTHING changes on either channel. Propagates to devices within minutes. |
Email senders (9)
Email senders (9)
| Tool | Scope | Mode | Required top-level input | Safeguard or availability | Canonical purpose |
|---|---|---|---|---|---|
list_email_senders | senders:read | Read | None | No contract flag | List the client’s registered email senders (domains and individual mailboxes) with their verification status and whether each can send. Each domain sender carries dns_records[]: the SES records (ownership token, DKIM, return path) are verified by AWS and gate can_send; the SPF (@) and DMARC (_dmarc) entries are checked by Nexor against public DNS on each verify and never affect can_send — status not_set means the record is absent in DNS, mismatch means an SPF exists without include:amazonses.com, verified means a valid policy exists (a third-party DMARC counts). last_checked_at is the time of that lookup. |
register_email_domain | senders:write | Write | sender_email, sender_name | No contract flag | Register a sender under a domain the client owns (e.g. sales@acme.com), for sending at scale. Returns the DNS records (SPF/DKIM) the client must add to that domain — adding them is a human step outside this tool. Once added, call verify_email_domain, or poll check_email_sender_status. |
register_email_sender | senders:write | Write | sender_email, sender_name | No contract flag | Register a personal mailbox (e.g. Gmail/Outlook) as a sender via a magic-link. Nexor emails a verification link to that mailbox — the mailbox owner must open it and click to confirm; that click is a human step outside this tool. Poll check_email_sender_status afterwards to see when it completes. |
check_email_sender_status | senders:read | Read | sender_email | No contract flag | Check whether a sender’s verification (DNS records or magic-link click) has completed and it can now send. Verification itself happens outside this tool, by a human — use this to poll the result after register_email_domain or register_email_sender. |
verify_email_domain | senders:write | Write | domain | No contract flag | Trigger a DNS verification check for a domain sender, AFTER the client has already added the DNS records returned by register_email_domain. This tool only checks — adding the records is a human step outside this tool. |
get_email_domain_dns_records | senders:read | Read | domain | No contract flag | Re-fetch the DNS records (SPF/DKIM) for a pending domain sender — e.g. if the client lost the ones returned by register_email_domain. Only reads; adding the records to the domain is a human step outside this tool. SPF and DMARC come back with a verdict from Nexor’s own public-DNS lookup (not_set = absent in DNS, mismatch = SPF without include:amazonses.com, verified = valid policy), never from AWS. |
resend_email_verification | senders:write | Write | sender_email | No contract flag | Resend the magic-link verification email for a pending sender mailbox. |
rename_email_sender | senders:write | Write | sender_id, sender_name | No contract flag | Change the display name leads see on emails from one of the client’s registered senders (the From name, e.g. “Sophie” in Sophie <hi@acme.com>). Only the name changes: the address, verification and DNS stay as they are and the sender keeps sending without interruption. Takes sender_id (from list_email_senders) and sender_name. Never delete and re-register a sender just to change its name — deleting a domain sender removes the domain’s verification. |
delete_email_sender | senders:write | Write | sender_id | No contract flag | Remove a registered sender. To change only the display name use rename_email_sender instead; deleting a domain-owner sender removes the domain’s verification at the provider and it must be re-verified with DNS. |
Template pools (8)
Template pools (8)
| Tool | Scope | Mode | Required top-level input | Safeguard or availability | Canonical purpose |
|---|---|---|---|---|---|
get_template_pool | whatsapp:read | Read | workflow_id | No contract flag | Read a workflow’s WhatsApp template pool state in one call: the active rotation pool (name, weight, category), the opening-template config (mode auto|only|subset + names), and what’s available to add (approved openers and all templates with status + internal_type). Use it before set_template_pool / set_opening_templates to see current state. An empty rotation pool does not mean follow-ups stop: they fall back to Nexor-managed backup templates (names starting with nx_) and approved follow-up templates. Before saying templates are not going out, check the lead’s history (get_lead_history lists template sends). |
set_template_pool | whatsapp:write | Write | workflow_id, templates | No contract flag | Replace a workflow’s WhatsApp cadence template pool with EXACTLY the given list — full-state replace, so a single call covers adding AND removing (retiring) templates atomically: anything omitted is removed from the pool. Each entry: { name, weight? (0.01-10, default 1) } and must be an APPROVED template on the client’s WhatsApp business account. Read the current pool with get_template_pool first, then send the complete desired list. |
set_opening_templates | whatsapp:write | Write | workflow_id, mode | No contract flag | Configure which WhatsApp templates a workflow may use as the OPENING (first-contact) message. mode ‘auto’ lets the cadence pick any eligible opener; ‘only’ locks it to exactly one template (template_names must have exactly 1 entry); ‘subset’ restricts it to the given names (at least 1). Names must be APPROVED templates with internal_type greeting, opening, legacy_greeting or outbound. Fails with WOULD_EMPTY_OPENING if the change would leave the workflow with no valid opener. |
sync_whatsapp_templates | whatsapp:write | Write | None | No contract flag | Pull the latest template state from Meta for all of the client’s WhatsApp business accounts: imports new templates, refreshes statuses (PENDING -> APPROVED/REJECTED) and quality scores. Returns { synced, created, updated, channels, warnings }. Run it when a template you expect is missing from list_whatsapp_templates or its status looks stale. |
check_whatsapp_template_approvals | whatsapp:write | Write | None | No contract flag | Terminal-friendly approval inspection. By default first syncs every connected WhatsApp business account from Meta, then returns ALL templates in one response with status, quality_score, rejection_reason, timestamps, and totals.by_status. Set refresh=false only when you intentionally want the cached local state. Use after batch submission until each template is APPROVED or REJECTED; rejected drafts can be revised through review_whatsapp_template_drafts under a new name. |
get_whatsapp_template_approval_status | whatsapp:read | Read | None | No contract flag | THE tool for “have my templates been approved?” / “how long until they’re approved?” — in Nexor a bare “template” ALWAYS means a WhatsApp template, so route those questions here. Refreshes from Meta by default, then returns a decision-ready summary — NOT a raw dump: counts { total, approved, pending, rejected, … }, all_approved / none flags, each PENDING template with how long it has actually been pending (pending_hours, so you answer with real data instead of a guessed ETA), longest_pending_hours, some_pending_over_24h, each REJECTED template with its Meta reason, and review_window { typical, max_hours }. Also returns numbers[] — ONLY the verified, fully-connected WhatsApp number(s) (a number still finishing setup is excluded), each with phone_number and whether it is bound to an agent. Templates only exist for a fully connected WhatsApp number: if none is connected the response is { no_whatsapp: true, numbers: [] } — then tell the customer to connect a WhatsApp number first (connect_whatsapp_number), do NOT say they have zero templates. Otherwise answer with the counts + the canonical window (approval is asynchronous and Meta-owned: usually minutes to ~1 hour, occasionally up to 24-48h) — never invent a precise time. If some_pending_over_24h is true, say it is taking longer than usual. For the full raw list use list_whatsapp_templates / check_whatsapp_template_approvals; for one template use get_whatsapp_template. Set refresh=false to skip the Meta sync and read cached state. |
set_whatsapp_template_purpose | whatsapp:write | Write | template_id, internal_type | No contract flag | Assign the cadence purpose of an existing or Meta-synced WhatsApp template. This is how an already-connected account can make a pre-existing template eligible for opening, follow-up, reminder, or reactivation behavior without recreating it. The template content and Meta approval status are unchanged. Use get_whatsapp_template first; only APPROVED greeting templates can subsequently be selected by set_opening_templates. |
delete_whatsapp_template | whatsapp:write | Write | template_id, confirm | confirm: true | Soft-delete a WhatsApp template (tenant-scoped; best-effort delete on Meta too). Preview-then-confirm flow: call with confirm=false first — it returns { requires_confirm: true, template: { name, status, internal_type, is_in_pool } } and writes NOTHING, so you can show the user what would be removed (especially whether it is still in a cadence pool). Only after reviewing that preview, call again with confirm=true to actually delete; the response reports removed_from_pools and meta_deleted. |
Analysis (3)
Analysis (3)
| Tool | Scope | Mode | Required top-level input | Safeguard or availability | Canonical purpose |
|---|---|---|---|---|---|
get_analysis_snapshot | reports:read | Read | None | No contract flag | Precomputed conversation-quality snapshot for the client (or one workflow): eval summary (scored conversations, average score, per-dimension averages, failure buckets), accuracy signals, seeker findings, the worst conversations (with reasons, transcript excerpts for the top 3) and system context. Fast — use it FIRST for “how is the agent doing” questions; only use run_deep_analysis when you need a fresh investigation of a specific question. |
list_analysis_findings | reports:read | Read | None | No contract flag | List the analysis engine’s stored findings/corrections/preferences for the client: title, summary, class, status, client impact, confidence and recommendation. Defaults to status ‘open’ (actionable backlog); pass status ‘all’ or a specific status to see history. Findings are produced by prior analysis runs — use run_deep_analysis to generate new ones. |
run_deep_analysis | reports:read | Read | question | No contract flag | Run a fresh deep analysis of recent conversations to answer a specific question (e.g. “why are leads ghosting after the price question”). LONG-RUNNING: this call is synchronous and may take 1-3 minutes — tell the user it is in progress and do not retry while waiting. Expensive and rate-limited to 5 runs per day per API key; when capped it returns { rate_limited: true } with the most recent run’s findings instead. For a quick health overview prefer get_analysis_snapshot. |
Lead diagnostics (9)
Lead diagnostics (9)
| Tool | Scope | Mode | Required top-level input | Safeguard or availability | Canonical purpose |
|---|---|---|---|---|---|
list_test_conversations | leads:read | Read | None | No contract flag | List the most recent Playground test conversations (the operator’s own tests, which list_leads hides), newest activity first: lead_id, name, the agent mode it ran on (workflow_id, workflow_name), start and last activity, and the last messages. Use it whenever the operator says they tested the agent and something failed or looked wrong: find the test, then read what the agent actually did with list_lead_turns / get_lead_turn on that lead_id BEFORE changing any prompt or tool. Never diagnose a failed test from the saved configuration alone. Filters: workflow_id, limit (1-25, default 10). |
send_test_message | workflows:write | Write | message | No contract flag | Run one simulated test turn against an agent mode, like Playground: you write as the lead, the agent answers. Nothing is ever sent on a real channel. Start a conversation with workflow_id (plus optional channel and metadata: first_name, last_name, email, phone set the test lead; other keys become lead data), then continue it by passing the returned conversation_id. Returns reply, messages, tool_calls (name, args, success, error), status (stage key) and conversation_id, which works with list_lead_turns / get_lead_turn. The agent’s HTTP tools run for real with the X-Nexor-Playground: true header. One turn at a time per conversation: on a CONFLICT that says the previous turn is still running, wait and resend; any other CONFLICT names why the agent refused the turn and resending will not change it. On RATE_LIMITED (30 turns/min per key) wait the seconds it says. If a turn fails or times out it may still finish: read it with list_test_conversations before resending. |
list_lead_turns | leads:read | Read | lead_id | No contract flag | List a lead’s agent turns (one turn = the agent processing one message): trace id, timestamp, channel, model, message/response previews, tools used, errors, latency and token usage. Two modes: (1) paging — use limit + next_before_ts to walk back in time; (2) search — pass message_text, provider_message_id, direction or around_ts to locate WHICH turn handled a specific message (the response includes match.trace_id with a confidence label). Pass include_detail:true to get the full get_lead_turn detail of the matched turn (search mode) or the newest turn (paging mode) as turn_detail in the same call. |
get_lead_turn | leads:read | Read | lead_id, trace_id | No contract flag | Full detail of one agent turn (by trace_id from list_lead_turns): metadata (model, tokens, duration, errors), the lead message + final response + agent reasoning, whether internal content leaked, tools used, the final gate decision, LLM outputs and a step-by-step timeline. Secrets are redacted and URLs reduced to host-only. This is THE tool for “why did the agent say that” questions. |
get_lead_run_state | leads:read | Read | lead_id | No contract flag | A lead’s current automation state in one call: the active workflow run (status, pause/human-takeover/escalation/dispatch state, next action time), the agent’s memory (summary + recent interaction log) and the collected field values with confidence + evidence quotes. Use include to fetch only some sections. This is the first stop for “why isn’t the agent messaging this lead” questions. |
get_lead_verdicts | leads:read | Read | lead_id | No contract flag | Quality-judge verdicts and alert events for a lead’s conversations: per-turn judge results (pass/fail, score, severity, reason) plus raised alerts (ai / workflow-config / whatsapp categories, redacted previews). Filter by trace_id or run_id to inspect one turn/run, or by a time window. Pairs with get_lead_turn to see WHAT the agent did vs how it was judged. |
get_lead_call | leads:read | Read | lead_id, call_id | No contract flag | Full detail of one call with a lead (call id from get_lead_history, which lists the calls): status, duration, success flag, sentiment, disconnection reason, summary, transcript and the AI call analysis. |
list_offers | workflows:read | Read | None | No contract flag | The client’s offer catalog (products/services the agent can pitch): name, description, category, status, source and top items. Pass workflow_id to see only the offers linked to that workflow (an empty result means the workflow has none linked — there is no fallback to the full catalog). Pass offer_id for one offer’s detail including its items. |
get_client_profile | workflows:read | Read | None | No contract flag | The authenticated client’s business profile as the agent sees it: name, industry, company size, country (+ secondary countries), timezone, language, website, primary communication channel, lifecycle stage, notes and which settings keys are configured. Useful context before diagnosing agent behavior or drafting client-facing copy. |
Tool health (1)
Tool health (1)
| Tool | Scope | Mode | Required top-level input | Safeguard or availability | Canonical purpose |
|---|---|---|---|---|---|
get_tool_health | workflows:read | Read | None | No contract flag | How the agent’s tools behaved in REAL conversations and calls over the last N days: per tool calls, ok, failed, empty, blocked, rates, last ok/failure, top errors and redacted samples of args and results. Use it BEFORE saying a tool or integration works, when a client says the agent ‘doesn’t give the info’ or ‘doesn’t book’, and to find silently failing tools (only_problems=true). Filters: workflow_id, tool_name, channel, days (1-14, default 7). Playground/test traffic is excluded; include_test=true returns it separately, labeled, in test_tools: read that before launch, when there are no real conversations yet. Reading it: many empty results on a search/lookup tool can be normal (new patient not found), so check the sample args before blaming parameter names or filters; 401/403 = expired or wrong credential; blocked = the platform stopped the call before the integration (excluded from rates); no rows = never called, which proves nothing. truncated=true: scan capped (window.scanned_from); narrow filters. |
Documentation (1)
Documentation (1)
| Tool | Scope | Mode | Required top-level input | Safeguard or availability | Canonical purpose |
|---|---|---|---|---|---|
search_docs | Authenticated key | Read | None | No contract flag | Search Nexor’s product documentation (bundled advanced-feature guides + the live docs site) or read one doc. Pass EXACTLY ONE of: q (search — returns up to 6 results with title, description and path) or path (read — returns the doc content, truncated at ~9000 chars with a marker). Typical flow: search with q and read_top:true to get the best-matching result’s content (top_result, from top_result_path) in the same call; read another path only if that one is not the answer. Public docs only — no tenant data. |
Pipeline (2)
Pipeline (2)
| Tool | Scope | Mode | Required top-level input | Safeguard or availability | Canonical purpose |
|---|---|---|---|---|---|
reorder_workflow_statuses | workflows:write | Write | workflow_id, ordered_status_keys | No contract flag | Replace the order of every mutable status after the protected Lead created, Contacted, and Engaged stages. First call get_workflow, then pass every remaining persisted status key exactly once in ordered_status_keys; omission, duplication, an unknown key, or a changed pipeline fails without mutation. The backend keeps the protected head at sort_order 0–2 and assigns the submitted tail contiguously from 3. Read back with get_workflow and compare the exact order before reporting success. Do not include synthetic Discarded stages. |
get_pipeline_impact | reports:read | Read | workflow_id | No contract flag | Impact preview of a workflow’s pipeline BEFORE a destructive change (deleting statuses, moving leads, deactivating the workflow): total board-visible leads bucketed by run state — early, active, settled (terminal/inactive collapsed), ai_paused and awaiting_human — plus the top statuses by count. Use it to tell the user “this affects N active leads” and get confirmation. For per-status funnel metrics use get_funnel_report instead. |
Knowledge bases (15)
Knowledge bases (15)
| Tool | Scope | Mode | Required top-level input | Safeguard or availability | Canonical purpose |
|---|---|---|---|---|---|
list_knowledge_bases | workflows:read | Read | None | No contract flag | List the client’s knowledge bases with status and document/size counts. Pass workflow_id to see only the KBs attached to that workflow, ordered by retrieval priority (each row then includes its priority). Ideal for “what knowledge bases exist”, “which KBs feed this workflow’s agent”, or finding a KB id before attaching or adding documents. |
create_knowledge_base | workflows:write | Write | name | No contract flag | Create a new, empty knowledge base for the client. After creating, add content with add_kb_document and make it live for an agent with attach_knowledge_base. Ideal for setting up a fresh document collection (e.g. “Pricing FAQ”, “Product docs”). |
update_knowledge_base | workflows:write | Write | knowledge_base_id | No contract flag | Edit a knowledge base’s own fields: its name, its description (what it contains / when the agent should use it), and its status (‘archived’ shelves it so agents stop using it without deleting; ‘active’ restores it). Provide only the fields you want to change; at least one is required. This is the ONLY way to change a KB’s description or rename a KB, there is no dashboard-only field. Returns 404 if the KB does not belong to this client. Ideal for “rename this KB”, “set its description to …”, or “archive the old pricing KB”. |
attach_knowledge_base | workflows:write | Write | workflow_id, knowledge_base_id | No contract flag | Attach an existing knowledge base to a workflow so that workflow’s agent can retrieve from it. priority orders retrieval when several KBs are attached (lower = consulted first); omitted, it appends after the current lowest-priority KB. Returns 409 CONFLICT if already attached, 404 if the KB does not belong to this client. Ideal for “make the pricing KB available to the sales workflow”. |
detach_knowledge_base | workflows:write | Write | workflow_id, knowledge_base_id | No contract flag | Detach a knowledge base from a workflow. The KB and its documents are NOT deleted — the workflow’s agent just stops retrieving from it. Returns 404 if the KB was not attached to that workflow. Ideal for “stop the sales agent from using the old pricing KB”. |
list_kb_documents | workflows:read | Read | knowledge_base_id | No contract flag | Page through the documents inside one knowledge base: name, source type (file/web/text), processing status, chunk count and timestamps. Ideal for “what’s in this KB”, checking whether a just-added document finished processing (status ready), or finding a document id to rename/delete. |
add_kb_document | workflows:write | Write | knowledge_base_id, name, text | No contract flag | Add a text document to a knowledge base. The text (max 200KB) is chunked and embedded asynchronously — the response is { document_id, status: “pending” }; poll list_kb_documents until status is “ready”. Ideal for ingesting FAQs, policy text, product descriptions or any copy the agent should be able to cite. |
rename_kb_document | workflows:write | Write | knowledge_base_id, document_id | No contract flag | Rename a document and/or replace its text content — this is the ONLY tool that rewrites a document’s text, there is no separate update-text tool. Pass name to rename (embeddings untouched), text to replace the content entirely (max 200KB), or both. Changing content re-indexes the document: it is re-chunked and re-embedded asynchronously, status goes back to ‘pending’ and returns to ‘ready’ when done (poll list_kb_documents). Only text documents (source type ‘text’) accept new content: file/web documents return 409. Returns 404 if the document is not in that KB. Ideal for tidying names after bulk ingestion or updating a FAQ/pricing doc in place. |
delete_kb_document | workflows:write | Write | knowledge_base_id, document_id | No contract flag | Permanently delete a document (and its chunks/embeddings) from a knowledge base. The agent stops retrieving it immediately. Returns 404 if the document is not in that KB. Ideal for removing outdated or wrong content the agent keeps citing. |
create_kb_upload_url | workflows:write | Write | knowledge_base_id, filename, content_type, size_bytes | No contract flag | Step 1 of 2 to put a FILE in a knowledge base: mint a short-lived, signed upload target for one file. Upload it with an HTTP POST to upload_url as multipart/form-data: send every entry of the returned fields as form fields, then the file itself as a final field named “file”. Then call add_kb_file_document with the returned storage_path to register it. Supported formats: PDF, TXT, MD, CSV, XLSX, PNG, JPG, WEBP (images are read with OCR and a visual description), max 100MB — storage rejects a larger body. Returns { upload_url, method, fields, storage_path, expires_in_seconds }; the target expires and grants write access to that one object only. |
add_kb_file_document | workflows:write | Write | knowledge_base_id, storage_path | No contract flag | Step 2 of 2: register a FILE (PDF, TXT, MD, CSV, XLSX, PNG, JPG or WEBP, max 100MB) you already uploaded to the target from create_kb_upload_url, by its storage_path. This tool never accepts file bytes, base64 or a URL, and cannot read a local path. Text is extracted, chunked and embedded asynchronously: the response is { document_id, status: “pending” }, and the document only starts answering questions once get_kb_document reports “ready”. For plain text you already have, add_kb_document is one call instead of three. |
import_kb_website | workflows:write | Write | knowledge_base_id, url | No contract flag | Crawl a public website and ingest it into a knowledge base: Nexor follows up to 30 pages from the given URL, writes their text as one document plus a generated company profile, and embeds both. Asynchronous — poll list_kb_documents or get_kb_document until status is “ready”. EXPENSIVE and rate-limited to 3 crawls per day for the whole account, shared by all its API keys, so do not re-crawl a site that is already ingested. Two different refusals, two different waits: “Rate limit exceeded” means the daily budget is spent (it carries crawl_budget with resets_at — tell the user to try again tomorrow, retrying sooner cannot succeed), while “Too many requests” means another crawl for this client is still running (retry in a few minutes). Only public http(s) URLs are reachable. Ideal for “load our website into the agent’s knowledge”. |
get_kb_document | workflows:read | Read | knowledge_base_id, document_id | No contract flag | Read one document: its name, source type (file/web/text), chunk count, timestamps, any ingestion error, and its status — pending, processing, ready or error. The status is the honest one: a document is reported ready only once both its text and its embeddings are in place, so it is answerable by the agent exactly when this says “ready”. Use it to follow an upload, an import or a reindex through to completion. Returns 404 if the document is not in that KB. |
reindex_kb_document | workflows:write | Write | knowledge_base_id, document_id | No contract flag | Re-run ingestion for one document: it is re-extracted, re-chunked and re-embedded from its original source, status returns to ‘pending’ and then ‘ready’ (poll get_kb_document). Use it to recover a document stuck in ‘error’, not as routine maintenance: the old chunks are deleted before the new ones are written, so while it runs the agent retrieves fewer chunks from this document (never wrong ones). Content is unchanged — to replace it, pass text to rename_kb_document. Returns 404 if the document is not in that KB. |
delete_knowledge_base | workflows:write | Write | knowledge_base_id | No contract flag | Permanently delete a knowledge base AND everything in it: every document, every chunk and every embedding go with it, and any workflow it was attached to stops retrieving from it immediately. There is no undo. To stop an agent using a KB while keeping its content, use update_knowledge_base with status “archived”, or detach_knowledge_base to remove it from one workflow only. Returns 404 if the KB does not belong to this client. Confirm with the user before calling this. |
Agent files (4)
Agent files (4)
| Tool | Scope | Mode | Required top-level input | Safeguard or availability | Canonical purpose |
|---|---|---|---|---|---|
list_agent_files | workflows:read | Read | None | No contract flag | List the files your agents can SEND to leads (images and PDFs in the company file library), each with its id, handle, name (label), filename, type and its sending instructions (agent_instruction: when the agent sends it). Pass workflow_id to also get enabled: whether that workflow may send each file. Files are company-wide; a file removed from a workflow is still in the library. legacy_folder_handle is set when an older folder @handle also sends the file. This is not the knowledge base: knowledge documents are read by the agent, these files are attached to messages. Ideal for “which files does this agent send”, finding a file id before renaming, editing or removing it, or spotting duplicates. |
update_agent_file | workflows:write | Write | file_id | No contract flag | Rename a file your agents can send and/or rewrite its sending instructions (when the agent sends it). Pass label to rename (the name operators see in Nexor and leads see on a document; the file’s extension is added automatically when sent, so never include or require one; empty string clears it back to the filename) and/or agent_instruction to change when it is sent (cannot be empty). The handle never changes, so rules that reference the file keep working. The file is company-wide: the change applies to every agent that sends it. Returns the updated file; 404 if it does not belong to this client. |
set_agent_file_availability | workflows:write | Write | file_id, workflow_ids, enabled | No contract flag | Let or stop specific workflows (tasks) sending one file. enabled:false removes the file from those workflows only; it stays in the library and in every other workflow. enabled:true lets them send it again. To remove a file from an agent (a group of tasks), pass every task id of that agent. Other files’ availability is untouched. Nothing is written if any workflow does not belong to this client (404). Confirm with the user before removing a file from an agent. |
delete_agent_file | workflows:write | Write | file_id | No contract flag | Permanently delete a file from the company file library: NO agent can send it afterwards, and any rule that references its handle stops sending it. There is no undo. To stop only one agent sending it, use set_agent_file_availability instead. Returns 404 if the file does not belong to this client. Confirm with the user before calling this, naming the file. |
Webhooks (7)
Webhooks (7)
| Tool | Scope | Mode | Required top-level input | Safeguard or availability | Canonical purpose |
|---|---|---|---|---|---|
list_webhooks | workflows:read | Read | None | No contract flag | List the client’s outbound webhooks: name, target URL, subscribed events, active flag and delivery health. Secrets are never included. Ideal for “what webhooks are configured”, “is anything listening to meeting.completed”, or finding a webhook id to update/test/delete. |
configure_status_webhook | workflows:write | Write | workflow_id, status_key, name, url | No contract flag | Create an outbound webhook that fires only when a lead enters one specific status in one specific workflow/agent. It subscribes to workflow_run.status_changed and installs exact workflow_id + to_status.key filters, plus any extra filters. The signing_secret is returned EXACTLY ONCE. Use one webhook per destination/behavior when different statuses need different payloads or receivers. |
get_webhook | workflows:read | Read | webhook_id | No contract flag | Get one webhook’s full configuration: events, filters, auth type, retry setting and payload template. auth_config is redacted to key names and the signing_secret is never returned (it is only shown once, at create time). Ideal for auditing exactly what a webhook sends and when. |
create_webhook | workflows:write | Write | name, url | No contract flag | Create an outbound webhook. url must be https and publicly reachable (private/metadata IP ranges are rejected server-side). The response includes the signing_secret EXACTLY ONCE — surface it to the user immediately; it cannot be retrieved later. Ideal for “notify my CRM when a meeting completes” style integrations. |
update_webhook | workflows:write | Write | webhook_id | No contract flag | Update an existing webhook. Only the fields you pass change; use is_active to pause (false) or resume (true) deliveries without deleting the webhook. Returns the updated, redacted configuration — the signing_secret is never re-issued. Ideal for pointing a webhook at a new URL, changing its event list, or toggling it. |
delete_webhook | workflows:write | Write | webhook_id | No contract flag | Permanently delete a webhook; deliveries stop immediately. Returns 404 if no webhook matched. To pause temporarily instead, use update_webhook with is_active:false. |
test_webhook | workflows:write | Write | webhook_id | No contract flag | Fire a synthetic test event at a webhook’s URL and report the outcome: { delivered, response_status, duration_ms, error }. The remote response body is never reflected back. Ideal for verifying a newly created or just-edited webhook actually receives events before relying on it. |
Tags (3)
Tags (3)
| Tool | Scope | Mode | Required top-level input | Safeguard or availability | Canonical purpose |
|---|---|---|---|---|---|
list_tags | leads:read | Read | None | No contract flag | Page through the client’s tag catalog (id, name, slug, description, color). search matches name, slug and description. Ideal for “what tags exist”, finding a tag id before set_tag/delete_tag, or checking a slug before creating a similar tag. To tag an individual lead use sync_lead_tags instead. |
set_tag | leads:write | Write | None | No contract flag | Create or update a tag in the catalog (upsert). OMIT tag_id to CREATE: name is required and slug is auto-generated from it unless given. PASS tag_id to UPDATE that existing tag’s name/slug/description/color (only provided fields change). Returns the tag; 409 CONFLICT if the slug already exists for this client. Leads already carrying an updated tag keep it — renaming is safe. Color is account-wide and applies wherever this tag appears; null restores the name-based default. Read list_tags after editing to verify persistence. |
delete_tag | leads:write | Write | tag_id | No contract flag | Permanently delete a tag from the catalog AND remove it from every lead that carries it (cascade). Returns 404 if no tag matched. Ideal for retiring obsolete tags; to merely rename one, use set_tag with tag_id instead. |
Processors (6)
Processors (6)
| Tool | Scope | Mode | Required top-level input | Safeguard or availability | Canonical purpose |
|---|---|---|---|---|---|
list_processors | workflows:read | Read | None | No contract flag | List the client’s pre-workflow processors (lead-routing rule engines): name, default workflow, active flag and rule count. Deactivated processors are hidden unless include_inactive is true. Ideal for “how are incoming leads routed”, or finding a processor id before get_processor / set_processor_rule. |
get_processor | workflows:read | Read | processor_id | No contract flag | Get one processor with its full rule list: each rule’s conditions, target workflow, evaluation position and active flag. Rules are evaluated in position order (1 first); the first match wins. Ideal for auditing routing logic before editing it with set_processor_rule. |
set_processor | workflows:write | Write | None | No contract flag | Create or update a pre-workflow processor (upsert). OMIT processor_id to CREATE: name and default_workflow_id are required, and you may seed up to 50 rules atomically (if any rule fails, the whole create rolls back). PASS processor_id to UPDATE name/description/default_workflow_id/is_active — rules cannot be passed on update; manage them with set_processor_rule / delete_processor_rule. default_workflow_id must belong to this client. |
delete_processor | workflows:write | Write | processor_id | No contract flag | Soft-deactivate a processor: it stops evaluating rules and routing leads, but the processor and its rules are kept (visible via list_processors include_inactive:true) and can be reactivated with set_processor is_active:true. Returns { deactivated: true }. |
set_processor_rule | workflows:write | Write | processor_id | No contract flag | Create or update one routing rule on a processor (upsert). OMIT rule_id to CREATE: name, workflow_id and conditions (1-20, ALL must match) are required. PASS rule_id to UPDATE — only provided fields change; passing position (1-based, 1 = evaluated first) also reorders the rule, which is how rules are reordered. workflow_id must belong to this client. Empty condition lists are rejected: they would match every lead. |
delete_processor_rule | workflows:write | Write | processor_id, rule_id | No contract flag | Permanently delete one routing rule from a processor. Leads that would have matched it fall through to later rules or the default workflow. Returns 404 if the rule is not on that processor. |
Meeting types (5)
Meeting types (5)
| Tool | Scope | Mode | Required top-level input | Safeguard or availability | Canonical purpose |
|---|---|---|---|---|---|
list_meeting_types | workflows:read | Read | workflow_id | No contract flag | List a workflow’s meeting types exactly as the dashboard form shows them: name, duration, meeting buffer, min notice, max days ahead, calendar title/invite templates, type (video with video_provider google_meet/teams, phone, in_person with location_details), overbooking + maximum per time slot, color, is_active, the free-text agent_selection_criteria and the enforced agent_selection_rules (see set_meeting_type_routing). Ideal for “what appointment kinds can this workflow book” or finding a meeting type id before update_meeting_type / delete_meeting_type. |
create_meeting_type | workflows:write | Write | workflow_id, name | No contract flag | Create the first and only meeting type for an appointment workflow that currently has none. Requires a name; omitted fields receive the dashboard defaults (30 min, 15 min buffer, 2 h notice, 14 days ahead, video). The type is created ACTIVE; it becomes bookable once a host with availability is assigned (add_executive). If one already exists, returns it explicitly with status=“existing” and never creates another. If several exist, fails with MULTIPLE_MEETING_TYPES so the operator can consolidate them. Bad values fail with 400 listing the allowed options (e.g. location_type must be video, phone or in_person). |
update_meeting_type | workflows:write | Write | workflow_id, meeting_type_id | No contract flag | Update one meeting type by id (at least one field required; only provided fields change) — every field of the dashboard meeting form. Pass null for description / event_description_template / location_details / video_provider / max_bookings_per_slot to clear them. is_active switches the type on or off: activating while another type is active fails with 409 MT_EXISTS; deactivating the only active type of a live appointment agent fails with 409 LAST_ACTIVE_MEETING_TYPE. Bad values fail with 400 listing the allowed options. Returns 404 if the meeting type is not in that workflow. Ideal for “make demos 45 minutes”, “require 24h notice”, “make it in person at the showroom”, “use Teams instead of Meet”. |
set_meeting_type_routing | workflows:write | Write | workflow_id, agent_selection_rules | No contract flag | Write the enforced host routing rules (agent_selection_rules) of a meeting type and read them back. Unlike agent_selection_criteria (free text the AI interprets), these rules are applied server-side when slots are offered and booked. Every host reference is validated against the hosts assigned to the meeting type (list_executives; pass user ids, names are resolved to the assigned host and stored by name). Examples: two hosts strictly alternating → {routing:“cycle”, tiers:[{agents:[A,B], mode:“cycle”, pattern:[0,1]}]}; leads with renta >= 50000 to Ana, the rest split 2:1 between Bruno and Carla, below 0 disqualified → {field:“renta”, tiers:[{min:50000, agents:[ana]}, {min:0, agents:[bruno, carla], weights:[2,1]}, {min:-1e9, action:“disqualify”}]}. Pass agent_selection_rules: null to clear. meeting_type_id may be omitted when the workflow has exactly one meeting type. 400 lists what is wrong (unassigned host, unordered tiers, unknown mode). |
delete_meeting_type | workflows:write | Write | workflow_id, meeting_type_id | No contract flag | Delete a meeting type from a workflow. The response reports impact: agent_assignments_removed and future_events_orphaned (already-booked meetings keep their calendar events but lose the type link). Returns 409 LAST_APPOINTMENT_TYPE when the workflow’s goal is ‘appointment’ and this is its only remaining type — an appointment workflow must keep at least one. 404 if the id is not in that workflow. |
Task configuration (12)
Task configuration (12)
| Tool | Scope | Mode | Required top-level input | Safeguard or availability | Canonical purpose |
|---|---|---|---|---|---|
get_workflow_status | workflows:read | Read | workflow_id, status_key | No contract flag | Read one workflow status’s complete configuration without changing it: label/category/flags, entry_hint, on_enter_instructions, required-field and transition gates, timeout, transfer, pause and assignment behavior. Use this before update_workflow_status and preserve exact labels/casing unless the user explicitly asks to rename them. |
update_workflow_status | workflows:write | Write | workflow_id, status_key | No contract flag | Configure one existing funnel status exactly like the dashboard stage editor. entry_hint is the natural-language qualification/entry gate for that status (required on non-initial statuses: clearing it is refused with status_entry_hint_required); on_enter_instructions is what the agent does once the lead is in that stage (e.g. thank, say you will reconnect later, say goodbye) — never put behavior in entry_hint; requires_all_fields or required_field_keys adds a deterministic variable gate; transition_rules adds structured qualification rules; timeout_config is the per-stage delay (after N minutes/hours/days since entering this status, move to target_status_key in the same workflow — the native way to wait, never a Scheduled Function or Background Job); transfer_config on an is_terminal status hands the lead to another task of the same agent group (conversation history and a read-only snapshot of collected fields carry over) — for a delayed handoff put the timeout on the waiting status and point it at the terminal transfer status; pause_bot stops the current agent; can_return_on_reply (lost final stages only, else 400 can_return_on_reply_requires_lost_stage) lets a lead who writes again come back to an active stage; assignment_config ({mode, agent_ids, restrict_booking_to_assignee}) assigns a human team member on entry — only ONE status per workflow may carry it (409 ASSIGNMENT_CONFIG_EXISTS with holder_status_key; clear it there with assignment_config:null first). On the escalation stage, assignment_config.on_escalation:true routes new escalations to those people; a routing save there returns warnings (routing_off, escalation_off) when it reaches nobody yet. category must be active/won/lost/paused/deferred. System stages other than the escalation stage and the virtual Discarded stage refuse writes with 409 PROTECTED_STATUS. Read get_workflow_status first and change only intended fields; preserve the exact label unless renaming was explicitly requested. |
list_workflow_voices | workflows:read | Read | workflow_id | No contract flag | List the voice catalog usable by a workflow’s call agent: public voices plus the client’s private voices, each with id, voice_id, name, provider, language, gender and a preview_url (a playable .mp3 sample link you can hand the user to hear the voice). Use this to pick a voice_id for set_workflow_voice, or to show the user samples before switching. |
set_workflow_voice | workflows:write | Write | workflow_id | No contract flag | Switch and/or tune the workflow’s call voice. To CHANGE which voice the lead hears, pass ONE of: gender (‘male’/‘female’ — the server picks a matching voice in the workflow’s language, e.g. a male voice for ‘voz de hombre’), voice_id (an exact id from list_workflow_voices), or voice_name (a name to match). The server writes the effective voice where the call runtime actually reads it and returns resolved_voice with a preview_url (.mp3) you should share with the user so they can hear it. To TUNE the current voice, pass a voice object with knobs (voiceSpeed, voiceTemperature, volume); these are key-level merged and preserved. Provide at least one of gender/voice_id/voice_name/voice. Unknown voice_id or no gender match returns INVALID_VOICE with available_voices. Version-snapshotted. |
get_workflow_cadence | workflows:read | Read | workflow_id | No contract flag | Read a workflow’s outreach cadence (block-config): the sequenced contact blocks (channel, delay, templates), timing/business-hours config and retry behaviour. |
set_workflow_cadence | workflows:write | Write | workflow_id, block_config | No contract flag | Replace a workflow’s outreach cadence (block-config). Read the current one with get_workflow_cadence first and send the full edited object — this is a whole-document PUT, not a merge. It does NOT set the WhatsApp opening template: dayConfig.config.opening_template is ignored when unchanged and REJECTED when changed (use set_opening_templates, which validates the opener). WhatsApp template names referenced by blocks must exist and be APPROVED on the client’s WABAs; business hours are re-derived server-side. |
get_workflow_qualification | workflows:read | Read | workflow_id | No contract flag | Read a workflow’s lead-qualification model (futurology): the scoring categories and the conditions that classify a lead into them. |
set_workflow_qualification | workflows:write | Write | workflow_id | No contract flag | Write a workflow’s lead-qualification model (futurology). categories and conditions address the SAME rows under two vocabularies (category_key/category_name/description = condition_key/condition_name/condition_description), so a key may appear once per call. Every row needs its key AND its human name (condition_name / category_name — never invented by the server); threshold_type, timing_type and scope are closed enums and wrong types are refused with 400 naming the index and field. Default is a merge (upsert by key, unsent columns keep their stored value); pass replace:true to clear the whole model and write what you send. get_workflow_qualification returns rows under the same field names, so a read-modify-write needs no translation. Provide at least one of categories/conditions. |
delete_workflow_status | workflows:write | Write | workflow_id, status_key | No contract flag | DESTRUCTIVE: permanently delete a funnel status from a workflow. Call get_pipeline_impact FIRST to see how many leads sit on each status. If any leads are on the status you must pass migration_target (the status key those leads are moved to) or the call fails with STATUS_HAS_LEADS and the lead count. The only initial status and the last terminal status can never be deleted. The escalation stage cannot be deleted either (409 escalation_stage_not_deletable): turn escalation off with update_workflow_config (escalation:{enabled:false}) instead. |
delete_workflow_field | workflows:write | Write | workflow_id, field_key | No contract flag | DESTRUCTIVE: permanently delete a data field (variable) from a workflow. Leads’ previously collected answers are preserved (detached from the field but kept in history); the field is removed from the funnel and the agent stops collecting it. Refuses with FIELD_IN_USE (409) when the field still gates a status (required fields / transition rules) or a qualification rule — remove those references first, then delete. There is no undo — prefer editing the field with update_workflow_structure over deleting it. |
delete_workflow | workflows:write | Write | workflow_id | confirm: true | DESTRUCTIVE / IRREVERSIBLE: archive one mode/workflow and release its channels. If it is the last non-archived mode, its master workflow (the named agent) is ALSO deleted, automatically, with no keep-agent option. Before sign-off, read list_workflows and list_agent_groups (paused modes count), name the affected agent and warn explicitly; pass its id as confirm_master_workflow_id after approval. Do not detach the mode to bypass this rule. confirm:false previews without writes; confirm:true deletes after approval. Active pipeline leads block deletion: status:‘blocked’, reason:‘agent_has_leads’, lead_count. Move or discard them explicitly first. / DESTRUCTIVO: archiva un modo. Si es el último, también elimina su agente, sin opción de conservarlo. Antes de confirmar, lee los modos (incluidos pausados) y agentes, nombra al agente y avisa de la eliminación conjunta. No desvincules el modo para evitarla. confirm:false previsualiza; confirm:true elimina tras aprobación. Leads activos bloquean con agent_has_leads. |
restore_workflow | workflows:write | Write | workflow_id | No contract flag | Un-archive (restore) an agent that was previously deleted with delete_workflow. Archive is a soft-delete, and this is its inverse: it clears the archive so the agent is listable and editable again. The agent comes back PAUSED and inactive — the channels it had (WhatsApp / phone / Instagram / Meta) were released when it was archived and are NOT re-attached, and its old leads/runs stay paused; reconnect channels and activate explicitly afterwards. Find the archived agent’s id first with list_workflows include_archived:true. Idempotent: restoring an agent that isn’t archived returns { status:‘already_live’ } without error. / Restaura (desarchiva) un agente eliminado con delete_workflow. El borrado es suave y esto es su inverso: el agente vuelve a aparecer y a ser editable, pero PAUSADO e inactivo; sus canales fueron liberados al archivar y NO se reconectan solos. Usa list_workflows include_archived:true para encontrar su id. |
Executives (4)
Executives (4)
| Tool | Scope | Mode | Required top-level input | Safeguard or availability | Canonical purpose |
|---|---|---|---|---|---|
list_executives | workflows:read | Read | workflow_id | No contract flag | List a workflow’s executives — the human hosts who take its meetings — with their user, active flag and assigned meeting types. |
add_executive | workflows:write | Write | workflow_id, user_id | No contract flag | Add a team member as an executive (meeting host) of a workflow, optionally restricted to specific meeting types. The user must belong to the client’s team (see get_team); adding someone who is already a host fails with a conflict. Assigning the host to a meeting type that was created inactive (seeded in the dashboard before any host existed) activates it, unless another type is already active; the response lists meeting_types_activated. Pass meeting_type_ids explicitly for that to happen — omitting it links no meeting type. |
update_executive | workflows:write | Write | workflow_id, executive_id | No contract flag | Update a workflow executive: toggle is_active and/or replace their full meeting-type set (meeting_type_ids overwrites the current assignments — pass the complete list). Provide at least one field. Linking the host (or switching them back on) activates a meeting type that was created inactive, unless another type is already active; the response lists meeting_types_activated. |
remove_executive | workflows:write | Write | workflow_id, executive_id | No contract flag | Remove an executive (meeting host) from a workflow. Their existing meetings are untouched; they just stop receiving new ones. |
Advanced (1)
Advanced (1)
| Tool | Scope | Mode | Required top-level input | Safeguard or availability | Canonical purpose |
|---|---|---|---|---|---|
describe_advanced_features | workflows:read | Read | None | No contract flag | Map every surface in the dashboard Advanced hub to its purpose, execution model, MCP tools, and safety considerations. Use this as the entry point for Advanced configuration. |
Agent system (2)
Agent system (2)
| Tool | Scope | Mode | Required top-level input | Safeguard or availability | Canonical purpose |
|---|---|---|---|---|---|
describe_agent_configuration | workflows:read | Read | None | No contract flag | Complete reference for designing and configuring one or many Nexor agents through MCP: prompts, statuses and qualification gates, variables, cadence, tools, pre-execution hooks, stage gates, webhooks, transfers, Cloud/Scheduled Functions, and the required clarification/sign-off workflow. Call this before proposing a non-trivial or multi-agent build. |
review_agent_system_plan | workflows:read | Read | plan | No contract flag | Opt in with plan.composition_policy=task_composition_v1 for 1–20 independent tasks created paused_unbound: validates real graph reachability and forbids activation/channel bindings; missing booking resources are pending_setup, invalid configuration still blocks. Only this opt-in returns composition_contract_version:1. Otherwise: Preflight a complete agent configuration (its modes) before any mutations. Gates mode decomposition deterministically: one mode per intent, 2–3 by default; a single-mode plan is BLOCKED unless plan.decomposition carries the operator’s explicit single-mode instruction, 5+ modes are blocked unless explicitly requested, and every non-entry mode must be reachable by a transfer. Also finds missing identities, goals, status gates, transfer targets, language/timezone (every agent needs an IANA timezone — it anchors booking slots; channels are never asked — a mode inherits its agent’s channels at birth, see birth_defaults in the result), a contact_schedule missing on a mode whose own description hints at after-hours / 24-7 / weekend hours (such a mode must never be born with the Mon–Fri business-hours default), planned channels with no verified resource on the account, webhook destinations, booking prerequisites for appointment agents (meeting type, host, calendar plan or external provider), and operational risks; returns an internal plan_fingerprint (never shown to the user) and the exact final sign-off prompt. Do not create/update agents, tools, hooks, webhooks, functions, schedules, jobs, or transfers until this review is clean and the user explicitly approves the summarized plan (“Does this look ok? Let me know and I’ll build it.”). |
Agents (10)
Agents (10)
| Tool | Scope | Mode | Required top-level input | Safeguard or availability | Canonical purpose |
|---|---|---|---|---|---|
get_agent_inbound_calls | numbers:read | Read | agent_group_id | No contract flag | Read incoming-call settings, eligible numbers, linked numbers affected by the same setting, and activation status for an agent group. Resolve the group with list_agent_groups or the selected task master_workflow_id. Read before changing anything and after saving. status=ready confirms configuration is ready; pending is not active and error requires attention. No call is placed. |
set_agent_inbound_calls | numbers:write | Write | agent_group_id, number_id, mode, confirm | confirm: true | Configure incoming calls for the whole agent group. The agent keeps its number in every mode. ai = AI answers; ai_human = AI answers and transfers on request; forward = direct forwarding without AI; off = stop incoming calls without changing the router or other channels. ai/ai_human enable a missing or inactive router with AI routing off; an active router stays unchanged. Read get_agent_inbound_calls first. Explain the selected number and linked numbers affected, and obtain consent for the exact mode and destination. Pass an observed number_id; ai_human and forward require an international transfer_to. Do not unassign the number or turn off the router to resolve a conflict. Read back after saving or an error; changes may be partially applied. Report pending as preparation and never claim pending/error is active. This makes the real API request, not a prompt edit. Does not buy numbers, place test calls, or change outbound schedules. |
list_agent_groups | workflows:read | Read | None | No contract flag | List the account’s AGENTS (master workflows — what the operator sees and names in the sidebar, each with its own chat) with their ids, names, descriptions and ivr_navigation (phone-menu navigation on calls, see update_agent_group). This is the answer to “how many agents do I have” and “which agent is X”; never count workflows for that. A workflow is a MODE / sub-agent of one of these agents: list_workflows returns each mode’s agent as master_workflow_id. |
create_agent_group | workflows:write | Write | None | No contract flag | Create an AGENT (a master workflow — the named entry the operator sees in the sidebar). This is the FIRST write of any agent build: every workflow is a mode INSIDE an agent (create_workflow requires master_workflow_id; a workflow never exists without an agent), so create the agent here, then create at least one mode inside it with the returned id — an agent with no modes is unfinished. BORN WITH: Nexor picks the agent’s name — a human first name from its pool, skipping names the account’s other agents already carry — so never ask the operator to name the agent and never pass one (a name argument is ignored and reported back as requested_name_ignored; rename later with update_agent_group only if the operator explicitly asks). The result’s birth_defaults lists the channels the agent has (every channel the account holds a verified resource for) — every mode created inside it inherits those channels, the contact schedule and the agent’s name automatically through create_workflow, so channels and hours are never questions. Modes are created or moved under it afterwards: create_workflow with master_workflow_id = the returned id, or update_workflow with that id; then read back both lists. Plan its modes by intent before creating any: a typical agent has 2–3 modes (one per distinct goal or register, e.g. sell → follow up → discount), one mode only when the operator explicitly asks for exactly one, never 5+; review_agent_system_plan enforces this. |
update_agent_group | workflows:write | Write | agent_group_id | No contract flag | Rename an AGENT (master workflow), change its description, or turn phone-menu (IVR) navigation on/off for its calls (ivr_navigation). Pass only the fields to update. This does not move modes (sub-agent workflows) between agents; use update_workflow.master_workflow_id for that. |
delete_agent_group | workflows:write | Write | agent_group_id | Operator approval in instructions | Delete (deactivate) an AGENT — the master workflow the operator sees in the sidebar; “delete this agent” inside that agent’s chat means this tool on that id — only after the operator’s explicit yes to a one-line confirmation. Soft delete: its modes (sub-agent workflows) are detached, not deleted, and their leads stay. To delete one mode use delete_workflow instead. Read back list_agent_groups and list_workflows after the write. |
get_agent_group_catalog_settings | workflows:read | Read | agent_group_id | No contract flag | Read the agent group catalog default inherited by its tasks. Null means no group default. |
set_agent_group_catalog_settings | workflows:write | Write | agent_group_id, enabled, offer_ids | No contract flag | Set catalog defaults for current and future tasks. Explicit task overrides remain unchanged. enabled=false disables the group default; offer_ids=null selects all active catalogs. Read back after saving. |
get_task_catalog_settings | workflows:read | Read | workflow_id | No contract flag | Read effective task catalogs and whether they inherit the agent group default. |
set_task_catalog_settings | workflows:write | Write | workflow_id, enabled, offer_ids | No contract flag | Set task catalog override, disable products with enabled=false, or resume the agent group default with inherit_from_group=true. Read back after saving. |
Inbound routing (9)
Inbound routing (9)
| Tool | Scope | Mode | Required top-level input | Safeguard or availability | Canonical purpose |
|---|---|---|---|---|---|
get_inbound_router | workflows:read | Read | agent_group_id | No contract flag | Read an agent group’s inbound router: whether it is on, the default task (the task that answers when no rule or AI decision picks one), AI routing and thresholds, which tasks it may route to, the shared identity, and every task of the group with paused status. Read before any change and after saving. inbound_router_not_enabled means the account does not have the router; say so and stop. |
set_inbound_router | workflows:write | Write | agent_group_id, confirm | confirm: true | Change an agent group’s inbound router. Pass only changed fields. default_workflow_id must come from get_inbound_router; paused tasks are allowed. Without a default, activation picks the arrival task, else the oldest. Turning the router on does not enable incoming calls. Turning it off stops AI call reception; direct forwarding stays on. Explain this before disabling. Use set_agent_inbound_calls to change call mode while keeping the number assigned. candidate_workflow_ids limits task selection (null = all). confidence_threshold and clarify_threshold are 0-1; clarify must not exceed confidence. Read get_inbound_router first, show before and after, and pass confirm=true only after approval. Read back after saving. New inbound messages fall back to the default task when the router is off; conversations already running stay with their task. |
get_inbound_router_rules | workflows:read | Read | agent_group_id | No contract flag | Read the fixed routing rules of an agent group, in evaluation order. A rule sends a new inbound conversation to target_workflow_id when all its conditions match, before AI routing and the default task. |
set_inbound_router_rules | workflows:write | Write | agent_group_id, rules, confirm | confirm: true | Replace ALL routing rules of an agent group; array order is evaluation order. To add, edit or remove one rule, read get_inbound_router_rules, change that entry, and send the whole list. An empty list removes every rule. target_workflow_id must be a task of the same group. Show the operator the full resulting list and pass confirm=true only after they approve. Read back after saving. |
set_inbound_router_identity | workflows:write | Write | agent_group_id, confirm | confirm: true | Replace the shared identity every task of the agent group presents to a new inbound lead before routing: name, voice, language, identity prompt and per-channel prompts. Full replacement: read get_inbound_router first and resend fields you keep. Confirm the exact text with the operator and pass confirm=true. Read back after saving. |
get_inbound_router_activity | workflows:read | Read | agent_group_id | No contract flag | Read how the router has been deciding: the latest decisions (channel, layer that decided, chosen task, confidence, the first message, any correction) and aggregates for a time window. Use it to explain why a lead landed on a task or to check a change worked. |
test_inbound_router | workflows:read | Read | agent_group_id, channel, first_message_text | No contract flag | Dry-run the router with a sample first message and see which task would answer and why. Nothing is sent, no lead is created and no decision is stored. Use it after changing rules, the default task or AI routing. channel is whatsapp, webchat, email or api. |
list_inbound_entry_points | workflows:read | Read | None | No contract flag | List the account’s inbound entry points (WhatsApp, phone, SMS, iMessage, Instagram, Messenger, email senders; with agent_group_id also the group’s website chat and email) and where each one lands today: a single task (type agent), an agent group’s router (type group) or nowhere. available=false comes with unavailable_reason. |
set_inbound_entry_point | workflows:write | Write | channel, id, destination, confirm | confirm: true | Choose where one inbound entry point lands: destination {type:“group”, id} sends new conversations through that group’s router, {type:“agent”, id} sends them straight to one task, {type:“none”} disconnects it. Use the channel and id from list_inbound_entry_points; email and webchat also need agent_group_id. A 409 with required_confirmation means another number or group is affected: explain conflict to the operator and, only if they approve, retry with confirmation set to required_confirmation exactly as returned. Pass confirm=true only after approval. Read back after saving. A phone number answers calls only once connected: connect a new number (id from provision_phone_number) to an agent with channel “phone” and destination {type:“group”, id: the agent id}; this turns the agent’s router on and needs an active task of the agent that does not exclude calls (else agent_not_active / no_call_task). |
Subaccounts (7)
Subaccounts (7)
| Tool | Scope | Mode | Required top-level input | Safeguard or availability | Canonical purpose |
|---|---|---|---|---|---|
list_sub_accounts | sub-accounts:read | Read | None | No contract flag | List the sub-accounts of the connected main account: each one’s id, name, country, owner and invitation, state (active, invited, paused, inactive), agents and leads, plus the family’s usage this period (every sub-account adds to the main account’s plan). A null usage number means the meter could not be read, not zero. Call this first: it also tells you whether the account has sub-accounts at all. sub_accounts_not_enabled means this account does not have sub-accounts: tell the user they can ask Nexor support to enable them, and stop. sub_account_cannot_manage_sub_accounts means the connected account is itself a sub-account: tell the user to do this from the main account. |
create_sub_account | sub-accounts:write | Write | name, country, language, timezone, owner_name, owner_email, confirm | confirm: true | Create a sub-account under the connected main account and invite its owner by email (the invitation lasts 7 days). The sub-account starts empty, with no card or plan of its own: its usage adds to the main account. country is ISO 3166-1 alpha-2, language is es or en, timezone is IANA (e.g. America/Santiago). The owner email cannot already belong to the main account’s team. Confirm every field with the operator before passing confirm=true. If the response shows email_sent=false, give the operator invite_url to share. sub_accounts_not_enabled means this account does not have sub-accounts: tell the user they can ask Nexor support to enable them, and stop. sub_account_cannot_manage_sub_accounts means the connected account is itself a sub-account: tell the user to do this from the main account. |
resend_sub_account_invitation | sub-accounts:write | Write | sub_account_id, confirm | confirm: true | Send the sub-account owner’s invitation again with a fresh 7-day link. owner_already_accepted means the owner already joined. If email_sent=false, give the operator invite_url to share. sub_accounts_not_enabled means this account does not have sub-accounts: tell the user they can ask Nexor support to enable them, and stop. sub_account_cannot_manage_sub_accounts means the connected account is itself a sub-account: tell the user to do this from the main account. |
copy_agent_to_sub_account | sub-accounts:write | Write | sub_account_id, confirm | confirm: true | Copy one of the main account’s agents into a sub-account. Pass exactly one source: master_workflow_id for an agent group, or workflow_id for a single agent (ids from list_agent_groups / list_workflows of the main account). The copy arrives paused, with its configuration, stages, fields, tools and rules. Connections bound to the main account (numbers, channels, integrations) are not copied: next_steps and missing_connections say what the sub-account must connect before going live. status=existed means the same copy was already made. sub_accounts_not_enabled means this account does not have sub-accounts: tell the user they can ask Nexor support to enable them, and stop. sub_account_cannot_manage_sub_accounts means the connected account is itself a sub-account: tell the user to do this from the main account. |
pause_sub_account | sub-accounts:write | Write | sub_account_id, confirm | confirm: true | Pause every agent of a sub-account; its team keeps access and nothing is deleted. failed_workflow_ids lists agents that could not be paused. sub_accounts_not_enabled means this account does not have sub-accounts: tell the user they can ask Nexor support to enable them, and stop. sub_account_cannot_manage_sub_accounts means the connected account is itself a sub-account: tell the user to do this from the main account. |
deactivate_sub_account | sub-accounts:write | Write | sub_account_id, confirm | confirm: true | Deactivate a sub-account: pauses all its agents and its team stops seeing the account. No data is deleted and reactivate_sub_account undoes it. pause_incomplete means some agents could not be paused and nothing was deactivated. sub_accounts_not_enabled means this account does not have sub-accounts: tell the user they can ask Nexor support to enable them, and stop. sub_account_cannot_manage_sub_accounts means the connected account is itself a sub-account: tell the user to do this from the main account. |
reactivate_sub_account | sub-accounts:write | Write | sub_account_id, confirm | confirm: true | Reactivate a deactivated sub-account so its team sees it again. Its agents stay paused until someone resumes them. sub_accounts_not_enabled means this account does not have sub-accounts: tell the user they can ask Nexor support to enable them, and stop. sub_account_cannot_manage_sub_accounts means the connected account is itself a sub-account: tell the user to do this from the main account. |
Calendars (3)
Calendars (3)
| Tool | Scope | Mode | Required top-level input | Safeguard or availability | Canonical purpose |
|---|---|---|---|---|---|
connect_calendar | calendars:write | Write | user_id, provider | confirm: true | Start connecting a team member’s Google or Outlook calendar (the host’s busy time and conferencing link for bookings). Returns connect_url, expires_at (10 min) and connection_request_id. IMPORTANT — hand connect_url to the user DIRECTLY as a clickable link and say who must open it (the host signs in and grants calendar access there; it cannot be completed in chat). When the target user is NOT the operator you are talking to, you MUST first tell the operator whose calendar will be linked and get an explicit yes, then call again with confirm=true — the backend refuses with CONFLICT/CONFIRMATION_REQUIRED otherwise. Other refusals: USER_NOT_ACCEPTED (fix: invite_user and wait for acceptance), PROVIDER_UNAVAILABLE (Outlook not enabled here), OTHER_PROVIDER_ACTIVE (disconnect the other provider first). Afterwards poll get_calendar_connections until status=active and scopes_ok=true. |
get_calendar_connections | calendars:read | Read | None | No contract flag | List calendar connections (Google, Outlook, Calendly) for the account or one team member: provider, status (active / needs_reauth / revoked / error), role, calendar_email, scopes_ok (false = reconnect with connect_calendar), last_error, connected_at. Poll this after connect_calendar; the host is bookable with busy-time awareness once a row is active with scopes_ok=true. |
disconnect_calendar | calendars:write | Write | connection_id, confirm | confirm: true | Revoke a host’s calendar connection (the agent stops reading their busy time and creating events there; Outlook accounts are also removed from the provider). Preview-then-confirm: call with confirm=false first — returns { requires_confirm: true, connection } and changes NOTHING; show the operator whose calendar it is, then call again with confirm=true. Reads the connection back after revoking. |
Availability (5)
Availability (5)
| Tool | Scope | Mode | Required top-level input | Safeguard or availability | Canonical purpose |
|---|---|---|---|---|---|
get_host_availability | people:read | Read | user_id | No contract flag | Read a team member’s booking availability: timezone (host’s own or seeded from the account), schedule flags, weekly slots grouped by weekday (0=Sunday), blocked dates, and slot_count. A host with slot_count 0 and no Calendly cannot be booked (BOOKING_AVAILABILITY_REQUIRED). |
set_host_schedule | calendars:write | Write | user_id, slots | No contract flag | Replace a team member’s whole weekly schedule in one call (atomic: the previous slots are removed). slots = [{ weekday 0-6, start ‘HH:MM’, end ‘HH:MM’ }] — e.g. Monday-Friday 09:00-17:00 is five entries with weekday 1..5. Overlapping slots on one weekday, end before start, or an unknown IANA timezone are refused with the offending field. timezone defaults to the host’s current one, else the account timezone (seeded). Returns the persisted availability; readiness recomputes and BOOKING_AVAILABILITY_REQUIRED clears once slot_count > 0. |
set_host_timezone | calendars:write | Write | user_id, timezone | No contract flag | Set (or clear with null) a team member’s availability timezone without touching their slots. Unknown IANA zones are refused. Setting a zone also turns respect_own_timezone on unless you pass it explicitly. Returns the persisted availability. |
set_host_blocks | calendars:write | Write | user_id | No contract flag | Add and/or remove a team member’s blocked dates (time off). add = [{ date ‘YYYY-MM-DD’, start?, end?, all_day?, reason? }] (omit times for all-day); remove = block ids from get_host_availability. Applied in order (removes first, then adds); returns the persisted availability with the final block list. |
auto_assign_solo_host | workflows:write | Write | workflow_id | No contract flag | Make a team member the meeting host of an appointment workflow and cover all its meeting types — the one-call setup for a single-host account. Omit user_id when the account has exactly one eligible member (owner/admin/human_agent); with several, the backend answers MULTIPLE_HOSTS with candidates and you pass user_id. Idempotent. Returns the assignment plus that host’s availability; follow with set_host_schedule and connect_calendar if slot_count is 0 or no calendar is active. |
Calendly (9)
Calendly (9)
| Tool | Scope | Mode | Required top-level input | Safeguard or availability | Canonical purpose |
|---|---|---|---|---|---|
connect_calendly | workflows:write | Write | None | No contract flag | Start connecting the client’s Calendly account: returns a hosted Composio authorization URL (connect_url, expires in ~10 min) the operator opens to grant access. IMPORTANT — give connect_url to the user DIRECTLY as a clickable link and tell them to open it; the authorization happens entirely on that page and CANNOT be completed in chat. After they finish, Nexor registers the webhook subscription and starts provisioning automatically. Poll get_calendly_status until state=connected (plan_required means the Calendly plan has no webhook support). Fails with already_connected when an active connection exists — pass reconnect=true to re-authorize. Next: list_calendly_event_types, then set_calendly_binding per host per meeting type. |
get_calendly_status | workflows:read | Read | None | No contract flag | Read the client’s Calendly connection: state (not_connected / connected / plan_required / disconnected), webhook health_status, plan_tier, host_mode, last provisioning report (per-host outcomes: wired / needs_mapping / no_event_type / primary_conflict) and the Composio account status. The poll target after connect_calendly and the place to read provisioning results. |
list_calendly_event_types | workflows:read | Read | None | No contract flag | List the connected Calendly account’s event types: uri (the API uri set_calendly_binding needs), name, duration_minutes, active, scheduling_url, kind and owner. Defaults to the connecting user’s event types; pass owner_uri (a Calendly user uri from the provisioning report hosts[].uri) to list another host’s. Only an ACTIVE event type whose duration equals the meeting type’s duration can be bound. |
set_calendly_binding | workflows:write | Write | workflow_id, meeting_type_id, host_user_id, event_type_uri | No contract flag | Bind a Calendly event type to ONE host for ONE meeting type of a workflow (the per-host model; there is no per-workflow link to manage). The backend validates the event type is active and its duration equals the meeting type’s duration_minutes (400 duration_mismatch otherwise), assigns the host to the workflow/meeting type if needed, writes the binding and reads it back. The first binding on a workflow switches that workflow to Calendly mode: native booking tools are gated and get_available_slots reads Calendly. Pass event_type_uri=null to clear a host’s binding (the host then appears under excluded_hosts). Repeat per host per meeting type; verify with list_calendly_bindings. |
list_calendly_bindings | workflows:read | Read | workflow_id | No contract flag | Read a workflow’s Calendly wiring: workflow_mode (calendly / native), the per-host bindings (host, meeting type, event_type_uri) and excluded_hosts — hosts assigned to a meeting type WITHOUT an event type (reason no_event_type_binding) who are silently missing from availability until set_calendly_binding fixes them. Optionally filter by meeting_type_id. |
set_calendly_host_mode | workflows:write | Write | mode | No contract flag | Set the Calendly host mode. ‘teams’ is the only value: hosts are the Calendly organization members, each mapped to a Nexor user and wired per meeting type by provisioning. Enqueues a provisioning pass; read the outcome with get_calendly_status or run provision_calendly for an immediate report. |
map_calendly_hosts | workflows:write | Write | calendly_user_uri, host_user_id | No contract flag | Map a Calendly host (calendly_user_uri from the provisioning report hosts[] with outcome needs_mapping) to a Nexor user, or pass host_user_id=null to unassign. The uri must come from the last provisioning report — run provision_calendly first. Fails with primary_conflict when the user already books through another calendar (e.g. Google) and cross_client_primary when they are a host in another client. Enqueues a provisioning pass afterwards. |
provision_calendly | workflows:write | Write | None | No contract flag | Run Calendly provisioning now and return the report: discovers the organization’s hosts, maps them to Nexor users (explicit mapping > email match > needs_mapping), resolves each host’s event type and wires workflow_agent_meeting_types for every workflow in Calendly mode. Report hosts[] outcomes: wired / needs_mapping (→ map_calendly_hosts) / no_event_type (→ set_calendly_binding) / primary_conflict / cross_client_primary. Requires host mode set and at least one workflow bound. Pass wait=false to enqueue instead and poll get_calendly_status. |
disconnect_calendly | workflows:write | Write | None | confirm: true | Disconnect Calendly for the client: deletes the webhook subscription, deactivates the integration and revokes the Composio account. Workflows bound to Calendly stop receiving Calendly bookings; per-host bindings are kept for a later reconnect. Preview-then-confirm: call with confirm:false (or omit it) to get a { status:‘needs_confirmation’ } preview that writes NOTHING; only call again with confirm:true after the operator explicitly confirms. |
Booking settings (8)
Booking settings (8)
| Tool | Scope | Mode | Required top-level input | Safeguard or availability | Canonical purpose |
|---|---|---|---|---|---|
get_workflow_booking_settings | workflows:read | Read | workflow_id | No contract flag | Read a workflow’s booking settings in one call: default_attendees (people invited to every booked meeting), host_assigner (CRM seller-assigner config) and external_booking (client-owned booker config). Use it before set_default_attendees / set_host_assigner / set_external_booking to see the current state. |
set_default_attendees | workflows:write | Write | workflow_id, attendees | No contract flag | Replace the people invited to EVERY meeting booked on this workflow (e.g. a sales manager who sits in on all calls). Full-state: the list sent IS the list afterwards; send [] to clear. Entries are {email, name?}; emails are validated and deduped. They appear on the next booked event’s calendar invite alongside the host and the lead. |
get_meeting_confirmation_email | workflows:read | Read | workflow_id, meeting_type_id | No contract flag | Read a meeting type’s lead confirmation email settings (email_config) and the list of allowed keys. Use before set_meeting_confirmation_email; the write replaces the whole object. |
set_meeting_confirmation_email | workflows:write | Write | workflow_id, meeting_type_id, email_config | No contract flag | Configure the confirmation email the lead receives when a meeting of this type is booked — subject, title, greeting, CTA label, calendar note, extra sections, disclaimer, sender name, or send_to_lead:false to suppress it. Same keys as the dashboard’s email panel; unknown keys are rejected (400) because the renderer never reads them. Replaces the whole email_config (read it first to keep other fields); null clears it. Use preview_meeting_confirmation_email to see the result before/after saving. |
preview_meeting_confirmation_email | workflows:read | Read | workflow_id, meeting_type_id | No contract flag | Render the lead confirmation email (subject + HTML) for a meeting type with sample data, using a draft email_config if given or the persisted one otherwise. Sends nothing. Use it to show the operator what the lead will receive before calling set_meeting_confirmation_email. |
set_host_assigner | workflows:write | Write | workflow_id | No contract flag | Declare the workflow’s CRM seller assigner: an existing ACTIVE workflow tool whose response names the seller, so bookings go to that seller’s calendar and the lead’s owner mirrors the CRM. tool = the workflow_tools name; id_field = the response field carrying the seller id; external_key = the client_users.external_ids key that maps it to a Nexor user (e.g. hubspot_owner_id), or identity:true when the tool already returns a Nexor user_id. Validates keys and that the tool exists and is active (400 otherwise), writes config.host_assigner, then RUNS the test connection (real call to the client’s endpoint) and returns its report — the config is persisted even when the test fails (ok:false with the failing step) so you can iterate; test:false skips it. clear:true removes the assigner. Never write host_assigner through update_workflow_config. |
test_host_assigner | workflows:write | Write | workflow_id | No contract flag | Dry-run the configured host assigner without touching any lead: calls the assigner tool for real, extracts the seller id (id_field), maps it to a Nexor team member and checks their calendar connection. Returns ok plus per-step checks, the fields the response actually carries (to pick id_field), and the resolved user. Pass tool/id_field/external_key/identity to test a variant before saving with set_host_assigner. |
set_external_booking | workflows:write | Write | workflow_id, external_booking | No contract flag | Declare that the client’s OWN booker (their HTTP tools) owns the calendar for this workflow, so Nexor mirrors every booking into a meeting with reminders and confirmation emails. All three verbs are REQUIRED — tool (create), reschedule_tool and cancel_tool — because an omitted verb is silently never mirrored (phantom meetings); reschedule_tool must differ from tool. fields maps dot-paths in the RAW tool response (data.slots.0.start style, never brackets): starts_at is required, ends_at/meeting_url/external_id/title/timezone optional. Every referenced tool (incl. slots_tool/slots_tools) must exist and be active on the workflow (400 TOOL_NOT_FOUND otherwise). provider defaults to external_booker (auto-gates native booking tools); gohighlevel needs no fields. Replaces the whole section and reads it back; null clears. Never write external_booking through update_workflow_config. |
CRM connections (3)
CRM connections (3)
| Tool | Scope | Mode | Required top-level input | Safeguard or availability | Canonical purpose |
|---|---|---|---|---|---|
connect_crm | workflows:write | Write | provider | No contract flag | Start connecting the client’s CRM (hubspot, zoho, kommo, gohighlevel, odoo or salesforce). Returns connect_url + connection_request_id. IMPORTANT — give connect_url to the user DIRECTLY as a clickable link and tell them to open it: HubSpot/Zoho/Salesforce authorize on the vendor’s consent page; Kommo/GoHighLevel/Odoo paste their credentials into a Nexor-hosted form. The credentials are entered on that page only — never ask the user to paste a token in chat, and never claim you connected it for them. Then poll get_crm_connection_status with the connection_request_id until status=completed (last_error explains a rejected attempt; the same link stays valid until expires_at). Reconnecting an already-connected CRM issues a fresh link. For Odoo the same URL/database/user preserves configuration while rotating credentials; a different identity is rejected. Odoo output execution is not available. |
get_crm_connection_status | workflows:read | Read | provider | No contract flag | Connection state of one CRM provider (account identity, sync status, errors; never tokens). setup_context describes supported configuration options and recorded scope grants: unknown permissions are NOT granted, and execution_readiness=not_checked is not proof an operation will succeed. Zoho supports output only; Kommo output moves the imported card. Ask which agent and which supported input or output the operator wants; do not activate flows or import existing leads merely because a CRM connected. Pass connection_request_id to verify THAT attempt: pending | completed | expired | failed. An existing connected account does not prove a new attempt succeeded. Kommo returns last_sync_at and last_error from its latest sync. Odoo returns connection_id, base_url, connected_at, last_sync_at, last_imported_at, last_error (a machine code), auth_blocked and api_key_expires_at. GoHighLevel returns one entry per location in locations[] with its connection_id. get_integration_status gives the cross-provider summary. |
disconnect_crm | workflows:write | Write | provider | confirm: true | Disconnect the client’s CRM (stops its sync immediately; configuration is kept so a reconnect restores it). Destructive for the live sync: ask the user first and call with confirm=true only after they explicitly agree. Without confirm=true nothing changes and the response explains what would be disconnected. GoHighLevel only: pass connection_id (from get_crm_connection_status locations[].connection_id) to disconnect one location; without it EVERY location is disconnected, so say so before confirming. |
Google Sheets (3)
Google Sheets (3)
| Tool | Scope | Mode | Required top-level input | Safeguard or availability | Canonical purpose |
|---|---|---|---|---|---|
get_google_sheets_status | workflows:read | Read | None | No contract flag | List the account’s Google Sheets automations (one spreadsheet tab linked to one task) with mode import|write, active, task_running, column_map, imported_rows, and the service_account_email the customer shares sheets with. Pass workflow_id to filter one task. An automation only imports while it is active AND its task runs (task_running). Reading changes nothing. |
inspect_google_sheet | workflows:read | Read | sheet_url | No contract flag | Check a Google Sheets URL before connecting it. accessible=false with reason=private means the customer must share the sheet with service_account_email as Editor: give them that address and share_instructions, wait for them to confirm, then inspect again. Without sheet_name it returns the tabs; with sheet_name it returns columns, sample_rows, data_row_count and suggested_column_map. Show the operator the suggested mapping and let them correct it; never save a mapping they did not see. automations lists what this spreadsheet already feeds. Read only. |
change_google_sheet_automation | workflows:write | Write | action | confirm: true | Create, configure, activate, pause or remove ONE Google Sheets automation. create links sheet_url + sheet_name to workflow_id with mode (import default, or write) and column_map, and saves it PAUSED. import_existing_rows=false imports only rows added from now on. configure changes any of those fields on connection_id. activate first returns confirmation_required with pending_rows: tell the operator how many rows become leads and that a running task may contact them, then repeat with confirm=true. pause stops future imports and keeps the position. remove deletes the automation; imported leads stay. activate, pause and remove need operator agreement. Report success from the returned automation, and say when task_running=false means nothing imports yet. |
Odoo (8)
Odoo (8)
| Tool | Scope | Mode | Required top-level input | Safeguard or availability | Canonical purpose |
|---|---|---|---|---|---|
get_odoo_connection | workflows:read | Read | None | No contract flag | Inspect the saved Odoo connection and obtain its secure browser setup entry. Open connect_url when supplied; otherwise open panel_path under the active Nexor platform origin. Browser sign-in is required. Credentials are entered only in that form, never chat or tool arguments. This does not connect or activate anything. Read again after browser setup; stored connection state is not proof of successful synchronization. |
get_odoo_outputs | workflows:read | Read | None | No contract flag | Inspect Odoo output settings, connection revision and actual execution availability. Requires an active account owner/admin/partner key. This is connection-wide, not task-scoped. Saved mappings do not prove synchronization. Credentials belong in the Odoo integration panel; never request or pass a key in chat. Read this before changing or previewing outputs. |
set_odoo_outputs | workflows:write | Write | connection_id, expected_revision, outputs | No contract flag | Replace the complete Odoo outputs configuration for the connection while preserving Inputs. Read get_odoo_outputs first and preserve unrelated mappings. Send its exact connection_id and revision. Saves disabled only; existing linked records only. Explain the account-wide scope and obtain agreement before calling. A revision conflict requires a fresh read. Report the committed read-back, never claim Odoo was updated or activated. |
preview_odoo_outputs | workflows:read | Read | connection_id, expected_revision | No contract flag | Read actual linked records and preview a candidate Odoo output configuration without writing to Odoo or starting outreach. Omit outputs to preview saved configuration. scan_complete=false means the bounded scan did not finish, never zero changes. Counts and fingerprints are evidence for this revision and expire; approval_eligible=false cannot authorize activation. |
get_odoo_output_history | workflows:read | Read | None | No contract flag | Read persisted Odoo output runs and open conflicts. Queued, partial, uncertain and preview results are not successful synchronization. A verified receipt is required to claim a record was updated. History is connection-wide and requires an account administrator key. |
resume_odoo_outputs | workflows:write | Write | connection_id, expected_revision, expected_pause_token, confirm | confirm: true | Resume a paused Odoo connection only after explicit agreement. Read get_odoo_outputs first and send its connection_id, revision and status.pause_token unchanged, with confirm=true. Refuses an obsolete pause, unresolved dispatched writes or unavailable execution. Current release gates remain off. Never clear a pause or resend uncertain writes through another tool, and never claim activation from a blocked response. |
pause_odoo_outputs | workflows:write | Write | connection_id, expected_revision, confirm | confirm: true | Pause new connection-wide Odoo writes after explicit agreement. Requires the connection and revision from get_odoo_outputs and confirm=true. Preserves mappings, revisions and audit history so already admitted changes can finish and reconcile. Report unsettled_count explicitly; a successful pause does not cancel a write already sent. |
start_odoo_output_sync | workflows:write | Write | connection_id, expected_revision, confirm | confirm: true | Request Odoo output synchronization after explicit agreement. The current release gate blocks execution and returns odoo_outbound_apply_disabled. Never promise execution or bypass that response. Requires the exact connection and revision plus confirm=true; this is not inbound import or calendar setup. |
HubSpot (11)
HubSpot (11)
| Tool | Scope | Mode | Required top-level input | Safeguard or availability | Canonical purpose |
|---|---|---|---|---|---|
get_hubspot_config | workflows:read | Read | None | No contract flag | Read the client’s whole HubSpot post-connect configuration in one call: connection (hub, auth mode, scopes, sync health), default_workflow_id, per-field outbound mappings (field_mappings), the INBOUND property → lead-metadata mapping (inbound_properties), the stage → lifecyclestage mapping (lifecycle_mapping), list routing rules (HubSpot list → workflow), deal_sync settings, sync_back, and owner_mappings (team members with the HubSpot owner id stored on them under external_key). Fails with not_connected until connect_crm(provider=hubspot) completes. Start here before any set_hubspot_* call so you never overwrite what the dashboard configured. |
set_hubspot_field_mappings | workflows:write | Write | mappings | No contract flag | Write outbound field mappings (Nexor field → HubSpot contact property), one row per nexor_field; rows not listed are left untouched. hubspot_property=null removes that field’s mapping. Optional per row: nexor_field_type (text/number/date/boolean…), write_once (never overwrite a value already in HubSpot), value_mapping ({ nexor_value: hubspot_option }), is_active, hubspot_property_label, hubspot_property_type. Use get_hubspot_config first; the stage → lifecycle mapping is set_hubspot_lifecycle_mapping, not this. Returns applied rows and the full read-back. |
set_hubspot_inbound_properties | workflows:write | Write | properties | No contract flag | Write the INBOUND mapping: HubSpot contact properties copied into lead.metadata by every intake door (list sync, imports, webhooks) — the lever for “bring X from HubSpot so the agent doesn’t re-ask it”. One row per hubspot_property; rows not listed are left untouched; metadata_key=null removes that property’s row. Property names are validated against the portal (404 property_not_found with suggestions) and read-only/calculated properties ARE valid here — form data lives in recent_conversion_event_name / recent_conversion_date / hs_analytics_first_url, and hs_object_id gives the contact id. Applies to leads created or updated from then on; it does not rewrite existing leads. This is NOT set_hubspot_field_mappings (that one is outbound, Nexor → HubSpot). Read get_hubspot_config.inbound_properties first. |
set_hubspot_lifecycle_mapping | workflows:write | Write | value_mapping | No contract flag | Set how Nexor stages map onto a HubSpot contact property (default lifecyclestage): value_mapping = { nexor_status_key: hubspot_option_internal_value }, e.g. { qualified: ‘salesqualifiedlead’, booked: ‘opportunity’ }. Pass value_mapping=null to clear. Stage keys come from get_workflow; option values are the HubSpot property’s internal option values. Returns the stored row. |
set_hubspot_list_routing | workflows:write | Write | rules | No contract flag | Replace the HubSpot list → workflow routing with the given rules (FULL replace: a list omitted here stops being routed; pass rules=[] to clear). Each rule: list_id (numeric HubSpot list id, or v3:<id>), workflow_id (the agent that receives contacts entering the list), optional name, recurring (keep pulling new members), pause_on_exit (pause the lead when it leaves the list), sync_interval_minutes (supported intervals only). Read the current rules with get_hubspot_config and send them back with your change — this is not a merge. Then run_hubspot_import(list_id) to pull the current members. |
set_hubspot_deal_sync | workflows:write | Write | enabled | No contract flag | Configure deal sync (HubSpot deal stage changes → Nexor conversions/lost). enabled=true requires pipeline_id (a HubSpot DEAL pipeline id); active_stages are the stage ids that count as won (creates a conversion of conversion_type_id when the deal reaches them), lost_stages the ones that mark the lead lost. Optional workflow_id pins which agent’s leads are swept (default: the connection’s default workflow). Ids are validated against HubSpot (404 pipeline_not_found / stage_not_found with the available ones). Runtime keys (cursor, last_swept_at) are preserved. Returns the stored deal_sync. |
map_hubspot_owners_to_hosts | workflows:write | Write | mappings | No contract flag | Map HubSpot owners (sales reps) to Nexor team members so a lead assigned to a rep routes to that host’s calendar and outbound sync writes the right hubspot_owner_id. Each mapping names the owner (owner_email or owner_id, matched against the portal’s owners) and the member (user_id from list_team, or user_email). Writes the owner id on the member (client_users.external_ids[external_key], the same field the dashboard member form edits, so both resolve the same host). Returns applied, unmatched (owner_not_found / user_not_found) and advisory warnings: no_calendar_connected, calendar_email_mismatch (the member’s connected calendar email differs from the owner’s) — warnings never block. Verify with get_hubspot_config.owner_mappings or list_team. |
install_hubspot_agent_tools | workflows:write | Write | workflow_id, tools | No contract flag | Install platform HubSpot tools on an agent with their fixed parameters — the same rows the dashboard HubSpot agent-tools panel creates, so list_workflow_tools / list_hubspot_agent_tools show them. tools: create_contact (no params), create_communication (no params; optional summary_instructions), assign_owner (optional owner = HubSpot owner id for a fixed owner; omitted = the lead’s Nexor assignee), create_deal (REQUIRES pipeline + stage: deal pipeline/stage ids), update_deal (REQUIRES stage; only if the catalog carries it), sync_lead_stage (REQUIRES lead_pipeline + status_map), sync_deal_stage (REQUIRES pipeline + status_map). Ids are validated against HubSpot and status_map keys against the workflow’s stages (400 missing_fixed_parameter lists what is missing per tool; 404 pipeline_not_found / stage_not_found / lead_pipeline_not_found / owner_not_found return the available ids; 409 tool_unavailable = the connection lacks the scope). Idempotent: re-installing updates the fixed params. A booking agent that must log to HubSpot needs at least create_contact + create_communication. |
list_hubspot_agent_tools | workflows:read | Read | workflow_id | No contract flag | List the platform HubSpot tools installed on a workflow with their fixed config read back in install vocabulary (create_deal → pipeline/stage; sync_*_stage → pipeline or lead_pipeline + status_map; assign_owner → owner_source; create_communication → summary_instructions), plus is_active, inherited, auto_run_on_entry, tool_available_for_agent and available_in_statuses. Also returns installable (the tool names) and fixed_parameters (required/optional per tool). Same rows list_workflow_tools shows, filtered to HubSpot. |
run_hubspot_import | workflows:write | Write | None | confirm: true | Import HubSpot contacts into Nexor as leads. Exactly one selector: list_id (a routed or any HubSpot list; queued in the background, returns job_id), contact_ids (specific contact ids; runs inline and returns stats), or all=true (every contact in the portal; queued, 409 import_in_progress if one is running). Optional workflow_id pins the agent the new leads enter (default: the list’s routing rule, else the connection’s default workflow; null = no auto-assignment). This creates leads and may start outreach — it is an operational run: call with confirm:false (or omit it) to get a needs_confirmation preview that does nothing; only pass confirm:true after the operator explicitly approves. Track with get_hubspot_sync_status. |
get_hubspot_sync_status | workflows:read | Read | None | No contract flag | Read HubSpot sync health: connection (sync_status, last_sync_at, last_sync_error, token_expired), inbound_enabled, import_all progress, per-list import stats for routed lists, deal_sync sweep state (last_swept_at, rate_limited_until), last_7_days counts per direction/status and recent_failures (event, error, contact). The poll target after run_hubspot_import and the first read when a client says HubSpot is not syncing. |
Cloud Functions (19)
Cloud Functions (19)
| Tool | Scope | Mode | Required top-level input | Safeguard or availability | Canonical purpose |
|---|---|---|---|---|---|
describe_cloud_functions | workflows:read | Read | None | No contract flag | Explain Cloud Functions: supported triggers, runtime globals, buffered effects, environment variables, the draft → test → publish lifecycle, and test safety. Call before authoring code. |
list_cloud_functions | workflows:read | Read | None | No contract flag | List Cloud Functions with trigger, active/deployment health summary, and last-run metadata. |
get_cloud_function | workflows:read | Read | function_id | No contract flag | Get one Cloud Function, including its published code and pending draft (code_draft, draft_hash, has_draft). |
create_cloud_function | workflows:write | Write | name, trigger_event, code | No contract flag | Create an event-driven Cloud Function, inactive unless is_active is passed. Read the triggering lead from ctx.lead/lead and use native effects instead of refetching it through the public leads API. Test it with test_cloud_function, then activate with update_cloud_function. |
update_cloud_function | workflows:write | Write | function_id | No contract flag | Update a Cloud Function. A code change replaces the entire draft code string and returns draft_hash: production keeps the published code until test_cloud_function and a user-approved publish_cloud_function. Other fields save immediately; activation runs the published code, not the draft. |
test_cloud_function | workflows:write | Write | function_id | No contract flag | Test the draft (or the published code when there is no draft) without real effects. Pass an event-shaped ctx. HTTP reads go out for real; other methods get a synthetic 200 and are listed in outbound.would_send; Nexor effects are preview-only. Show the user what would be sent and the previewed effects before asking to publish. |
publish_cloud_function | workflows:write | Write | function_id, expected_draft_hash, confirm | confirm: true | Publish the pending draft of a Cloud Function so production runs it and record a version. Requires confirm:true after the user explicitly approves the tested draft, and expected_draft_hash (the draft_hash from update_cloud_function or get_cloud_function). CONFLICT draft_changed_since_preview: re-read, re-test and ask again. Does not activate an inactive function. |
discard_cloud_function_draft | workflows:write | Write | function_id | No contract flag | Discard the pending code draft of a Cloud Function. The published code keeps running. Idempotent. Ask the user first: unpublished edits are lost. |
list_cloud_function_versions | workflows:read | Read | function_id | No contract flag | List the published versions of a Cloud Function, newest first, without code. is_published marks the version production runs. |
get_cloud_function_version | workflows:read | Read | function_id, version_number | No contract flag | Get one published version of a Cloud Function, including its code. |
restore_cloud_function_version | workflows:write | Write | function_id, version_number | No contract flag | Copy a published version of a Cloud Function into the draft. Production is unchanged until the draft is tested and published. A CONFLICT with draft_already_open means unpublished edits exist: pass replace_draft:true only after the user agrees to lose them. |
delete_cloud_function | workflows:write | Write | function_id | Operator approval in instructions | Permanently delete a Cloud Function, its run history, and its deployed Worker. Destructive: confirm with the operator first. |
run_cloud_function | workflows:write | Write | function_id | No contract flag | Alias of test_cloud_function kept for existing callers: tests the draft without real effects. Prefer test_cloud_function. |
list_cloud_function_runs | workflows:read | Read | None | No contract flag | List compact Cloud Function run summaries; filter by function, lead, trigger source, or status. |
get_cloud_function_run | workflows:read | Read | run_id | No contract flag | Get full Cloud Function trace detail: ctx, logs, result/error, network requests, proposed/applied effects, and lead snapshots. |
clear_cloud_function_runs | workflows:write | Write | None | Operator approval in instructions | Permanently clear Cloud Function run history, optionally for one function. Destructive: confirm with the operator first. |
list_function_environment_variables | workflows:read | Read | None | No contract flag | List names and timestamps of client-wide, write-only environment variables shared by Cloud and Scheduled Functions. Values are never returned. |
set_function_environment_variable | workflows:write | Write | key, value | No contract flag | Create or replace a shared secret. Key must match ^[A-Z][A-Z0-9_]{0,63}$. The value is encrypted, never echoed, and triggers redeployment of active Cloud/Scheduled Functions. |
delete_function_environment_variable | workflows:write | Write | key | Operator approval in instructions | Delete a shared environment variable and redeploy active functions without it. Destructive and may break code that reads env.KEY; confirm first. |
Scheduled Functions (18)
Scheduled Functions (18)
| Tool | Scope | Mode | Required top-level input | Safeguard or availability | Canonical purpose |
|---|---|---|---|---|---|
describe_scheduled_functions | workflows:read | Read | None | No contract flag | Explain Scheduled Functions, cohort lookup syntax, runtime/effects, scheduling, the draft → test → publish lifecycle, and the real-effect manual run. |
list_scheduled_functions | workflows:read | Read | None | No contract flag | List Scheduled Functions with cron, timezone, next/last run, active state, and cohort cap. |
get_scheduled_function | workflows:read | Read | function_id | No contract flag | Get one Scheduled Function including its published code, pending draft (code_draft, draft_hash, has_draft) and lookup configuration. |
create_scheduled_function | workflows:write | Write | name, cron_expression, timezone, code | No contract flag | Create a cron function, inactive unless is_active is passed. Put lead filtering/order/limit in lookup_config, preview the schedule and cohort, then make code consume ctx.leads; never refetch that cohort through the public leads API. Test it with test_scheduled_function before activating. |
update_scheduled_function | workflows:write | Write | function_id | No contract flag | Update schedule, cohort, code, metadata, or active state. A code change is saved as a draft and returns draft_hash: production keeps the published code until test_scheduled_function and a user-approved publish_scheduled_function. Other fields save immediately; cron/timezone changes recompute next_run_at; activation runs the published code, not the draft. |
test_scheduled_function | workflows:write | Write | function_id | No contract flag | Test the draft (or the published code when there is no draft) without real effects. Without ctx it resolves the saved cohort read-only. HTTP reads go out for real; other methods get a synthetic 200 and are listed in outbound.would_send; Nexor effects are preview-only. Show the user what would be sent and the previewed effects before asking to publish. |
publish_scheduled_function | workflows:write | Write | function_id, expected_draft_hash, confirm | confirm: true | Publish the pending draft of a Scheduled Function so production runs it and record a version. Requires confirm:true after the user explicitly approves the tested draft, and expected_draft_hash (the draft_hash from update_scheduled_function or get_scheduled_function). CONFLICT draft_changed_since_preview: re-read, re-test and ask again. Does not activate an inactive function. |
discard_scheduled_function_draft | workflows:write | Write | function_id | No contract flag | Discard the pending code draft of a Scheduled Function. The published code keeps running. Idempotent. Ask the user first: unpublished edits are lost. |
list_scheduled_function_versions | workflows:read | Read | function_id | No contract flag | List the published versions of a Scheduled Function, newest first, without code. is_published marks the version production runs. |
get_scheduled_function_version | workflows:read | Read | function_id, version_number | No contract flag | Get one published version of a Scheduled Function, including its code. |
restore_scheduled_function_version | workflows:write | Write | function_id, version_number | No contract flag | Copy a published version of a Scheduled Function into the draft. Production is unchanged until the draft is tested and published. A CONFLICT with draft_already_open means unpublished edits exist: pass replace_draft:true only after the user agrees to lose them. |
delete_scheduled_function | workflows:write | Write | function_id | Operator approval in instructions | Permanently delete a Scheduled Function, run history, and Worker. Destructive: confirm first. |
preview_scheduled_function_schedule | workflows:read | Read | cron_expression, timezone | No contract flag | Validate a five-field cron in an IANA timezone and return its next 1-10 UTC occurrences. |
preview_scheduled_function_cohort | workflows:read | Read | lookup_config | No contract flag | Resolve a lookup_config without running code. Returns matching count and bounded sample so you can verify who would enter ctx.leads. |
run_scheduled_function | workflows:write | Write | function_id, confirm | confirm: true | Run the PUBLISHED version of a Scheduled Function immediately. WARNING: unlike test_scheduled_function, this applies buffered effects to real tenant data and sends real HTTP writes. Use test_scheduled_function to try a draft. Only call after the operator explicitly confirms the cohort from preview_scheduled_function_cohort; pass confirm:true. The result omits run.ctx (the resolved cohort echoed back); read it with get_scheduled_function_run, or pass include_ctx:true. |
list_scheduled_function_runs | workflows:read | Read | None | No contract flag | List Scheduled Function execution summaries by function/status with pagination. |
get_scheduled_function_run | workflows:read | Read | run_id | No contract flag | Get a full Scheduled Function trace: resolved cohort context, logs, network, result/error, and applied/failed effects. |
clear_scheduled_function_runs | workflows:write | Write | None | Operator approval in instructions | Permanently clear Scheduled Function run history, optionally for one function. Destructive: confirm first. |
Pinned source and regeneration
Generated fromgetnexor-ai/nexor-public-mcp at 2ae64b97252d1263472c223bf055d4ee907dbbc6, using docs/tool-manifest.json (SHA-256 2e64adc926eac7adca75463e0de2aa9b173c821167abfd27148540e26c7be19c).
After checking out that exact commit locally:
npm run mcp:snapshot -- /absolute/path/to/nexor-public-mcp
npm run mcp:check -- /absolute/path/to/nexor-public-mcp