Skip to main content
Nexor’s public MCP (Model Context Protocol) server lets an AI client inspect and operate your Nexor account. It uses the same underlying resources as the REST API, but the two catalogs are not identical. Production server URL: https://mcp.getnexor.ai/mcp

Browse every listed tool

Review the 384 non-admin tools listed to customer sessions, including scopes, required inputs, operation mode, safeguards, and the current availability exception.

REST authentication

Use this separate guide for REST API keys. REST and MCP keys are not interchangeable.

Watch the connection walkthrough

The configurations below are the current reference for each supported client.

Create an MCP key

  1. Click MCP in the left sidebar. The window creates a key named MCP access with full setup access, so your assistant can finish the setup.
  2. Copy the snippet for your client. It includes the key; the full key is not shown again. Store it in a password manager or secret store.
  3. To reduce the key’s access, trim its scopes in the same window or open Manage keys. Revoke the keys you no longer use: opening the window again in a new session can create another key.
MCP keys start with nxr_mcp_. They are separate from REST keys and carry their own scopes. Use least privilege: when a client only needs to inspect the account, keep only read scopes.
Send the key only through the X-API-Key header. The public MCP server does not authenticate Authorization: Bearer. Never paste a real key into source control, screenshots, or shared chat.

Connect a client

Use one of the four client-specific configurations below. Replace nxr_mcp_YOUR_KEY locally.

Claude Code

Run in a terminal:

Codex

Add this to ~/.codex/config.toml:

Cursor

Add this to ~/.cursor/mcp.json:

Claude Desktop

Claude Desktop uses a local stdio bridge for this header-authenticated remote server. Open Developer → Edit Config and add this to claude_desktop_config.json:
Keep the header argument exactly space-free in the Claude Desktop configuration. mcp-remote substitutes ${NEXOR_MCP_KEY} from env when it starts.

How the connection works

Nexor implements session-based Streamable HTTP:
  1. The client sends an MCP initialize request by HTTP POST with X-API-Key.
  2. Nexor authenticates the key, binds its client identity and scopes to the new session, and returns an mcp-session-id.
  3. Later POST requests reuse that session. GET opens the server event stream, and DELETE closes the session.
Most MCP clients manage the session header and reconnect automatically. A customer-callable tool never accepts a client ID as authority; Nexor derives the tenant from the authenticated session. Seven internal-administration tools exist outside the generated customer catalog, and only trusted internal-admin sessions may use their tenant-context controls.

Scopes

An MCP key can call a tool only when it has the tool’s required scope. Tools without a named scope still require a valid MCP key.
The server’s tools/list response contains 391 tools at the revision pinned by this documentation. Seven are reserved for internal administration and reject customer keys. The generated non-admin catalog contains the other 384.
The pinned 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.

Confirmations and sensitive actions

Enrolling leads into an active task, for example with upsert_leads and workflow_id, or with the bulk and single assign tools, starts contact right away per its cadence; calls wait for the task’s contact hours, and messages go right away unless the task restricts messages to its hours. Do-not-contact leads and inbound-only tasks are excluded. Activating a paused task starts contacting every lead waiting in it. Explain this and get approval before you enroll leads or activate a task.
A write scope authorizes a class of actions. It does not replace operator approval. Before a destructive, billable, outbound, or operational action, explain the effect and obtain explicit approval. The generated catalog shows these safeguards directly from the tool contract: Some destructive tools require approval in their instructions but do not expose a common confirmation field: run_background_job, delete_agent_group, delete_cloud_function, clear_cloud_function_runs, delete_function_environment_variable, delete_scheduled_function, and clear_scheduled_function_runs. Ask first and do not infer approval from the absence of a schema field.

Function drafts, tests, and publishing

Code changes to Cloud Functions and Scheduled Functions go through a draft, so production keeps running the published code while a client works:
  1. update_cloud_function and update_scheduled_function save code as a draft and return its draft_hash. Other fields save immediately.
  2. test_cloud_function and test_scheduled_function run the draft without real effects. Reads are sent, other HTTP methods get a synthetic 200 and are listed in outbound.would_send, and lead changes are only previewed. run_cloud_function remains as an alias of the test.
  3. Show the operator what would be sent and the previewed effects. After explicit approval, call publish_cloud_function or publish_scheduled_function with confirm: true and the tested draft_hash as expected_draft_hash. A CONFLICT with draft_changed_since_preview means the draft changed: read it, test it, and ask again.
list_cloud_function_versions, get_cloud_function_version, list_scheduled_function_versions, and get_scheduled_function_version read the version history. restore_cloud_function_version and restore_scheduled_function_version copy a version into the draft, never into production. discard_cloud_function_draft, discard_scheduled_function_draft, and a restore with replace_draft: true lose unpublished edits, so ask first. run_scheduled_function runs the published version for real and still requires confirm: true.

Tool errors

A tool failure sets MCP isError: true and returns JSON text shaped as { "error": { "code": "...", "message": "..." } }.

Transport errors

Handshake and session failures are JSON-RPC errors, separate from tool errors.

Troubleshooting

The client connects but a tool returns FORBIDDEN

Compare the tool’s scope in the catalog with the key’s granted scopes. Add only the missing scope. If the tool is reserved for internal administration, a customer key cannot call it.

Claude Desktop does not start the server

Use the stdio mcp-remote configuration above, not Cursor’s remote { "url", "headers" } shape. Confirm that Node.js and npx are available, and keep X-API-Key:${NEXOR_MCP_KEY} free of spaces.

The client reports an invalid session

Restart or reconnect the MCP client so it sends a new initialize request. Do not reuse a saved mcp-session-id across client processes. Tool calls and error rates for the last 30 days are available per tool, across all MCP keys, under Manage keys.
Last modified on October 6, 2026