MCP server

AISAR exposes a Model Context Protocol server — this lets any MCP-capable AI client (Claude Code, claude.ai, Cursor, and others) work with your workspace through self-describing tools, without hand-writing an integration against every REST endpoint.

Endpoint and authentication

The server speaks Streamable HTTP:

POST https://mcp.aisar.app/mcp/company

Authentication uses the same company API token as the REST API (created in the cabinet: Settings → Systems → API, requires the Business plan), sent in the Authorization header:

Authorization: Bearer 123|xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

Transport is Bearer-only — there is no cookie/session path and no OAuth flow. A request without a valid token gets 401; a token of the wrong class gets 401/403.

Connecting a client

Claude Code

claude mcp add --transport http aisar https://mcp.aisar.app/mcp/company \
  --header "Authorization: Bearer YOUR_API_TOKEN"

claude.ai

Settings → Connectors → Add custom connector, URL https://mcp.aisar.app/mcp/company, header Authorization: Bearer YOUR_API_TOKEN.

Generic MCP client (e.g. Cursor)

{
  "mcpServers": {
    "aisar": {
      "url": "https://mcp.aisar.app/mcp/company",
      "headers": {
        "Authorization": "Bearer YOUR_API_TOKEN"
      }
    }
  }
}

After connecting, call the whoami tool first — it confirms which company the token maps to.

Server tools

Documentation

These read the platform's live documentation straight from the server — answers are always in sync with the latest deploy.

Reads

Every response uses an explicit field allow-list — channel credentials, provider keys, integration secrets, tokens and passwords are never returned.

Writes

Every write tool enforces the matching permission, is scoped to the token's company, and is audited.

Webhook self-service

The webhook URL passes the same SSRF guard as the REST integration-creation endpoint (private/loopback/link-local/metadata addresses are refused, including DNS-rebinding and encoded-IP forms); there is a per-company cap on the number of integrations; event names are validated against the platform's event catalogue.

AI agents & voice

Managing a company's AI agents (including the voice profile) is the same functionality available on the "AI agents" tab in the cabinet. list_ai_agents/get_ai_agent/create_ai_agent/update_ai_agent/activate_ai_agent/deactivate_ai_agent manage the text/chat side of an agent (prompt, enabled tools, guardrails, budgets); list_knowledge_documents/create_knowledge_document/delete_knowledge_document manage its knowledge base; get_voice_agent/update_voice_agent manage the optional voice profile. As with every tool on this server, the company id is never passed as an argument — the scope is always "your own company" from the token.

In update_voice_agent, the voice_tools field covers only voice-exclusive settings with no text-agent equivalent — currently the single key history ({enabled: bool}, reading back the chat tail during a call). Every other voice agent tool (CRM, messaging, human transfer) is switched on through the same enabled_tools on update_ai_agent used for the text agent on the same instance_id.

Editing the system prompt (update_ai_agent) or the knowledge base (create_knowledge_document/delete_knowledge_document) automatically queues a resync with the voice vendor for agents that have a voice profile — no separate publish step is needed.

Named external actions

A named external action is a saved recipe for calling one operation on one external HTTP API (host, path, method, auth, response handling) with typed parameters the AI agent fills in itself when it calls the action by name. create_external_action/update_external_action/list_external_actions/get_external_action/delete_external_action manage the action itself; bind_external_action/unbind_external_action attach it to a specific agent instance — creating an action does not, by itself, let any agent call it; test_external_action sends one real test call with sample parameter values. create_ai_agent_secret/list_ai_agent_secrets create and list the credentials an action authenticates with: the secret value is write-only and is never returned anywhere, the response carries only an id (for secret_id) and a masked hint — creating a secret used to require leaving MCP for REST, now the whole "secret → action → test → bind" path stays inside MCP. update_ai_agent_secret updates a secret in place, keeping its id — this is the rotation path: secret is optional, sending it replaces the value and recomputes the masked hint, omitting it changes only the name, header_name/query_param, or allowed_domains, and the value is still never returned either way; the response carries a rotated flag showing whether the value actually changed. delete_ai_agent_secret deletes a secret but refuses while any action still references it — listing their slugs in the error — because external_actions.secret_id is a plain reference, and deleting the secret out from under an action would leave it looking configured while failing every call with an authentication error that explains nothing; the actions need to be pointed at another secret or removed first. In practice that means a compromised key gets rotated with update_ai_agent_secret, not deleted and recreated — the actions bound to it keep working throughout. list_external_action_calls reads the call log with filters by action, outcome, and transport — without it there was no way to find out why an agent-visible call failed. Thirteen tools in total. Whether a call is a write is derived by the server from the HTTP method and is never accepted as an input — force_write may only ratchet a GET action UP to write status, never downgrade a POST/PUT/PATCH/DELETE to a read. All of this requires the ai_action.manage permission, which by default is granted only to the company's admin role — DIFFERENT from ai_agent.update, holding one does not imply the other. Not available for companies on the Kids product. Calling an action works over both transports — from a live chat and during a voice call (governed by the available_in field, see the table below).

base_url is scheme+host only, no {{...}} (the action's destination never depends on the model); path_template/query_template/header_template/body_template are templates with {{name}} substitutions. Headers get a tighter rule: header_template may only reference names from context_bindings (what the server fills in), never parameters (what the model fills in) — a model-supplied value can never physically reach an HTTP header, and Authorization/Host/Cookie plus a few other names are reserved outright. A secret passed as secret_id must have a non-empty allowed_domains covering base_url's host — this is checked already at create_external_action/update_external_action, not only at call time.

Limits & behaviour

• Rate limits (per token, per company): search_messages — 30/min, send_message and send_template_message — 60/min, create_webhook_integration — 10/min, create_knowledge_document — 20/min, named external action calls (chat and voice combined) — 60/min per company, test_external_action — a separate 10/min, documentation tools — 120/min.
• External-action call ceilings (independent of the rate limit above): at most 3 calls per model conversation turn, 20 per conversation per hour, 5 per voice call — bounding the blast radius of a looping call or a successful prompt injection.
• Pagination: per_page is capped at 50.
• No bulk send: messaging tools only reach an existing conversation or a single contact — there is no mass-broadcast surface here (use the Broadcasts feature in the cabinet for that).
• Untrusted content: message bodies, contact names and notes returned by these tools are third-party data, not instructions for the model.

Troubleshooting