The built-in API cards
MCP — plug the assistant into Claude and other AI tools
MCP (the Model Context Protocol) is the open standard AI tools use to reach outside systems. Naxis Assistant speaks it natively: point Claude, Cursor or any other MCP client at this deployment and it can ask the assistant questions — every answer grounded in your documents, access-controlled and audited exactly like the web chat — and, with an ingestion key, push documents into the knowledge base. Same keys, same access rules, same audit trail as the two HTTP APIs; MCP adds a protocol, never a new capability.
The endpoint and the keys
Everything lives at one address: your deployment's base URL plus /mcp. The Bearer key decides what the connected tool can do, and there are two kinds to hand out: an ADMIN key can do everything — ask, add documents, and run the console — while a PERSONAL key only asks, with that person's own document access. Both live on the API & MCP page — its own item in the left menu, next to Settings — together with the exact connection lines to paste into your client. The underlying catalog cards (the API channel and the API source, each with its own card-level key) still exist for advanced setups and are created automatically the first time they are needed.
Connecting from Claude
Claude Code (terminal):
claude mcp add --transport http assistant \
https://YOUR-DEPLOYMENT/mcp \
--header "Authorization: Bearer nx_ak_YOURKEY"
Claude.ai and Claude Desktop accept the same URL as a custom connector; Cursor and other clients take it in their MCP settings with the Authorization header. The server is stateless HTTP — no session set-up, nothing to keep alive.
Testing the connection directly
The client apps above talk MCP for you, but underneath it is one JSON-RPC method, tools/call, POSTed to /mcp — useful for a quick sanity check before wiring up a client, in curl:
curl -X POST https://YOUR-DEPLOYMENT/mcp \
-H "Authorization: Bearer nx_ak_YOURKEY" \
-H "Content-Type: application/json" \
-d '{"jsonrpc":"2.0","id":1,"method":"tools/call",
"params":{"name":"ask",
"arguments":{"question":"What is the refund window?"}}}'
The same call in Python:
import requests
resp = requests.post(
"https://YOUR-DEPLOYMENT/mcp",
headers={"Authorization": "Bearer nx_ak_YOURKEY"},
json={
"jsonrpc": "2.0",
"id": 1,
"method": "tools/call",
"params": {"name": "ask",
"arguments": {"question": "What is the refund window?"}},
},
)
if resp.status_code == 401:
print("invalid or missing key")
elif not resp.ok:
print(resp.status_code, resp.text)
else:
result = resp.json()["result"]
print(result["content"][0]["text"])
And in JavaScript, using fetch on Node 18 or later:
const resp = await fetch("https://YOUR-DEPLOYMENT/mcp", {
method: "POST",
headers: {
"Authorization": "Bearer nx_ak_YOURKEY",
"Content-Type": "application/json",
},
body: JSON.stringify({
jsonrpc: "2.0",
id: 1,
method: "tools/call",
params: { name: "ask", arguments: { question: "What is the refund window?" } },
}),
});
if (resp.status === 401) {
console.error("invalid or missing key");
} else if (!resp.ok) {
console.error(resp.status, await resp.text());
} else {
const { result } = await resp.json();
console.log(result.content[0].text);
}
What a Messaging key unlocks (asking)
| ask | The complete pipeline: the assistant investigates the knowledge base with the caller’s document access and returns a cited answer or an honest “not in the documents”. Takes question (required), plus conversation_id and end_user. Returns a conversation_id for follow-ups. |
|---|---|
| recall | The same grounded answer in one call, with a choice of where to look and up to twenty sources back — for an application or agent that already knows it is asking, no conversation kept. Takes question (required), where, limit, context and end_user. See Recall. |
| search_knowledge_base | The assistant’s own search instrument: numbered source excerpts with document, date, kind and state — for a connected agent that wants to dig itself. |
| read_document | One document’s full text, paged — for contracts and anything where exact wording matters. |
| list_documents | The corpus map: document records filtered by name, date window and kind — timelines, “everything about X”, open-items sweeps. |
A person’s own key sees exactly what that person may see; the shared channel key sees the channel’s guest groups (none chosen = it stays silent). The three investigation tools respect the same access on every call — a connected tool can never surface a passage its key holder couldn’t open in the web chat.
What an Ingestion key unlocks (pushing)
| push_document | Create or replace a document (inline text, or base64 for PDF/DOCX); it indexes into that source with the groups you name (default: the source’s own). Takes external_id (required), plus title, text or content_base64, filename, content_type, acl and metadata. |
|---|---|
| get_document_status / list_pushed_documents | One pushed document’s indexing status, or the listing (list_pushed_documents takes limit, offset, prefix). |
| delete_document | Remove a document; purge=true erases it immediately, index included. |
| sync_now / ingestion_status | Trigger indexing; store and index counts. |
What an Admin key unlocks (everything)
An Admin API/MCP key is the everything key. It carries all the tools above — asking with the owning admin's own document access, pushing into the automatically-created API documents source, writing the Internal docs (write_internal_doc and its siblings — the pages and files kept on this server, which recall reads back with where set to internal) — plus fifty-odd management tools covering people and groups, sources and channels, documents and access, settings, keys, the knowledge graph and the audit trail. Connect Claude — Cowork, Desktop or Code — with one admin key and simply say what you want: “create a finance group, add these five people, connect our Notion, and issue one of them their own key” — the assistant does it tool by tool, each step validated and audited like a console click.
The key is minted on the API & MCP page and acts with the minting admin's OWN authority: every action lands in the audit log under that admin plus the key's mark, and the key dies the moment the account is deactivated, demoted or deleted. The same key also authenticates the whole admin REST surface and the two data APIs (send it as Authorization: Bearer against /api/admin or /api/v1) for scripts that prefer plain HTTP. Personal keys never gain any of this — they stay ask-only.
Rate limits and audit are shared with the HTTP APIs (60 questions/min per caller, 300 pushes/min per source key, 120 admin calls/min per admin key), and every question, push and change lands in the same audit trail. Model and vendor identifiers never appear on the wire. A bad or missing key on /mcp itself returns HTTP 401 with an error field naming which key kind is expected; a bad call to a known tool comes back as a normal 200 JSON-RPC result with isError true, so check that field too, not just the HTTP status.
Last updated 20 Sep 2026