Dextalo MCP connector

1. Claude (web, desktop and Cowork)

Claude adds remote MCP servers as custom connectors. A connector added once is available in claude.ai, the Claude desktop app, Cowork and the mobile apps, and can be switched on per conversation from the “+” menu → Connectors. Dextalo supports Claude's standard OAuth sign-in, so there is no token to create or paste.

Free, Pro and Max

1. Go to Customize → Connectors and click Add custom connector.
2. Name it “Dextalo” and enter the server URL https://dextalo.com/api/mcp/knowledge, then click Continue. Claude checks the server and detects that sign-in is required.
3. Leave Authentication on the detected option (“Always required”). For the OAuth client, choose “No client ID — register one automatically”: Dextalo supports Dynamic Client Registration, so Claude registers itself. Do not add request headers.
4. Click Add, then Connect. A browser window opens Dextalo: sign in if you are not already, review what the connector will be able to do, and click Allow.
5. You are sent back to Claude. Enable the connector in a chat and ask: “List the pages in our wiki.”

Team and Enterprise (an owner sets it up)

1. Go to Organization settings → Connectors and click Add, then Custom.
2. Name it “Dextalo” and enter https://dextalo.com/api/mcp/knowledge. Keep the detected OAuth authentication and the automatic OAuth client.
3. Click Add. Each member then opens Customize → Connectors, clicks Connect on Dextalo, and signs in with their own account — so every page change is attributed to the person who made it.

Tool permissions

After adding the connector, open it under Customize → Connectors to set a permission per tool. We recommend Allow for the read tools (list, get, search, history, revision) and Ask for the writing tools, so you confirm each change before it lands. Dextalo re-checks your permissions on every call either way.

2. ChatGPT

ChatGPT's custom MCP connectors (Settings → Apps & Connectors, with Developer mode enabled) support OAuth sign-in, which is exactly what Dextalo offers.

1. Open Settings → Apps & Connectors → Create (Developer mode must be on).
2. Name it “Dextalo”, enter https://dextalo.com/api/mcp/knowledge as the MCP server URL, and set Authentication to OAuth. Leave the client ID and secret empty — ChatGPT registers itself.
3. Click Create, then Connect. Sign in to Dextalo in the browser window, click Allow, and you are returned to ChatGPT.
4. Enable the connector in a conversation and ask it to search the wiki.

3. Personal access tokens (Grok, scripts, header-only clients)

Clients that send a fixed header with every request instead of signing in use a personal access token. Tokens are created in the Knowledge app and are tied to your user account. You need the permission to edit pages (knowledge_page:update) or to manage the Knowledge app to create one.

1. Open Dextalo and go to Knowledge → Settings.
2. Under Personal access tokens, give the token a name (for example “Claude Code on my laptop”) and pick an expiry: 30, 90 or 365 days. Only Knowledge managers can create tokens that never expire.
3. Click Create token. The full secret (dxk_…) is shown once — copy it now. Dextalo only stores a hash and cannot show it again.
4. Paste it into your client as described below. If you lose it, revoke it and create a new one.

Good to know

• A token can never do more than you can in the app. If your role is read-only, the assistant only sees the read tools.
• Each user can hold up to 25 live tokens. Revoked tokens stay listed (greyed out) for the audit trail.
• Knowledge managers can see and revoke every token in the workspace. Everyone else sees only their own.
• Tokens cannot be created while “Simulate user” is active.
• When your account is deactivated or you leave the workspace, all of your tokens — and your OAuth connections — stop working immediately.

4. Claude Code

Claude Code's HTTP transport discovers the sign-in from the URL and registers itself, so no token is needed — add the server, then run /mcp in a session and authenticate in the browser that opens:

claude mcp add --transport http dextalo-knowledge https://dextalo.com/api/mcp/knowledge

If you would rather use a fixed header — an unattended agent, or a machine with no browser — add a personal token instead:

claude mcp add --transport http dextalo-knowledge https://dextalo.com/api/mcp/knowledge \
  --header "Authorization: Bearer dxk_…"

Add --scope user to make the server available in every project instead of just the current folder. Run claude mcp list to check it connected, and /mcp inside a session to see the tools. The same settings block works for the project-level .mcp.json file if you prefer to keep it in the repository (without the token — reference an environment variable instead, as in the example):

{
  "mcpServers": {
    "dextalo-knowledge": {
      "type": "http",
      "url": "https://dextalo.com/api/mcp/knowledge",
      "headers": { "Authorization": "Bearer ${DEXTALO_TOKEN}" }
    }
  }
}

5. Grok

Grok's custom connectors accept a server URL plus an authorization value, so the personal token works directly. (Grok's OAuth form asks for a Client ID rather than registering itself, which Dextalo does not support yet.)

1. Open grok.com/connectors and click New Connector, then Custom.
2. Name it “Dextalo Knowledge”.
3. Server URL: https://dextalo.com/api/mcp/knowledge.
4. In the authentication field enter Bearer dxk_… as the Authorization header value.
5. Save the connector and ask Grok what it can see in the wiki.

6. Cursor, VS Code and other clients

Any client that supports the MCP Streamable HTTP transport can connect. Clients that implement MCP's OAuth sign-in (MCP Inspector, recent Cursor and VS Code builds) can simply be pointed at the URL; otherwise use a personal token in the same JSON shape as for Claude Code:

{
  "mcpServers": {
    "dextalo-knowledge": {
      "url": "https://dextalo.com/api/mcp/knowledge",
      "headers": { "Authorization": "Bearer dxk_…" }
    }
  }
}

• Cursor: Settings → MCP → Add new global MCP server, then paste the block above.
• VS Code (Copilot agent mode): add the server to .vscode/mcp.json with "type": "http".
• Windsurf, Zed, Cline and similar: use their remote/HTTP server option with the same URL and header.
• Clients that only support the older SSE transport (a GET that opens a stream) are not supported — Dextalo answers 405 to GET.

Quick check with curl

curl -s https://dextalo.com/api/mcp/knowledge \
  -H "Authorization: Bearer dxk_…" \
  -H "Content-Type: application/json" -H "Accept: application/json" \
  -d '{"jsonrpc":"2.0","id":1,"method":"tools/list"}'

7. Tool reference

All tools are prefixed knowledge_. Page bodies are exchanged as Markdown: headings, lists, task lists, tables, code fences, links, images, callouts and toggles round-trip; text colours do not. Every tool returns a human-readable text block plus a structuredContent.data object with the same information in snake_case, and every write also returns an audit_id.

A tool is only listed to a client when the token's role holds the permission in the last column. A tool the role cannot use is reported as unknown.

Reading

Writing

Destructive (preview first, then confirm)

Not available over MCP (app only): permanently deleting from the trash, renaming or moving pages, discarding a draft, managing tokens, and role administration.

8. How the assistant works with pages

Drafts and publishing

Every page has a published version and, optionally, a pending draft. Creating a page or updating it in draft mode is invisible to readers until it is published; search only covers published content. Ask the assistant to “save as draft” when you want to review in the app before it goes live, or “publish” to make it immediately visible.

Confirmation for destructive actions

Revert, trash and restore never act on the first call. Without confirm they return a preview (what would be restored, or which sub-pages would be trashed) together with a confirm_token bound to the page's current state. The assistant is instructed to show you the preview and only re-call with confirm: true and that token after you agree. If the page changes in between, the token no longer matches and the call is rejected.

Nobody's work gets overwritten

Updates and confirmed reverts require expected_revision_count, the count the assistant last read. If someone edited the page in the meantime the call fails with a conflict error and nothing is written; the assistant re-reads and applies its change again.

History

Every draft save, publish and revert appends a numbered revision with the author and an optional note. Nothing is rewritten, so the app's History view shows the assistant's changes next to everyone else's.

Resources

Besides tools, the server lists every published page as an MCP resource at knowledge://pages/{slug} with text/markdown content. Clients that support resources can attach a page to a conversation without calling a tool.

9. Security and audit

• OAuth connections use the standard Authorization Code flow with PKCE. The sign-in happens on dextalo.com — the client never sees your password — and what the client receives is a short-lived access token that names only your Dextalo account and workspace.
• Tokens are stored as a keyed hash; the secret is shown once and never stored in clear.
• Every request is authenticated on its own. There is no browser cookie fallback, so a web page cannot call the endpoint as a signed-in user.
• The workspace is derived from the credential, never from a tool input. A token or connection is pinned to the workspace it was created in.
• Every OAuth connection is recorded in the workspace audit log (who connected which client, and when), and each request it makes is marked as coming through that client.
• Permissions are checked three times: when listing tools, when calling a tool, and again inside the service that performs the change.
• Every write is recorded in the workspace audit log with the acting user and a marker that it came through a token, and the audit_id is returned to the client.
• Page bodies are sanitised on the way in exactly like editor input: allow-listed formatting only, http(s) links and images, 256 KiB per page.
• Requests from browsers with an unknown Origin are refused; non-browser clients are unaffected.
• Expected failures (validation, not found, conflict, missing permission) are returned to the assistant as readable tool errors. Unexpected failures are logged server-side and never leak details.

10. Troubleshooting

11. Protocol details

For developers integrating directly rather than through an off-the-shelf client.

• One JSON-RPC 2.0 message per POST. Batch arrays are rejected with -32600.
• Responses are application/json. If the Accept header lists only text/event-stream, the same single response is wrapped as one SSE message event and the stream closes.
• Notifications (notifications/initialized, notifications/cancelled) are acknowledged with 202 and an empty body.
• Protocol versions 2025-06-18, 2025-03-26 and 2024-11-05 are negotiated; the client's MCP-Protocol-Version header is echoed back.
• Methods: initialize, ping, tools/list, tools/call, resources/list, resources/templates/list, resources/read, prompts/list (empty). Anything else answers -32601.
• Error codes: -32001 unauthorized, -32002 resource not found, -32003 forbidden, plus the standard JSON-RPC codes.
• Server identity: serverInfo.name is dextalo-knowledge. The initialize result carries an instructions string that explains drafts, publishing and the confirm flow to the model.
• Request bodies are capped at 2 MiB; a page body at 256 KiB.