Skip to main content
Toolsets let a Didit MCP connection load a short list of tools instead of the whole catalog, and read-only mode gives you a connection that can never change data. Both are a parameter on the server URL:
Without a parameter the server lists every tool your role may use, so nothing changes for a connection you already have.

​
Why load fewer tools

Your client sends the definition of every listed tool to the model before your first question. For the whole Didit catalog that is tens of thousands of tokens on every request: roughly 50,000 to 115,000, depending on the model’s tokenizer. Some clients also cap how many tools they accept. The trade-off is one extra step. A tool outside the list is not lost, but the model has to find it with tool search before it can run it, and a model that sees every tool picks the right one a little more often than a model that has to search. Load everything when a conversation works across many areas and the context cost does not matter. Load core, plus the toolsets you use most, when it does.

​
Choose your toolsets

Add toolsets to the server URL with a comma-separated list:
core is the short list most work starts from. It covers your organizations and applications, verification sessions (create, find, decide, explain, simulate in the sandbox, read webhook deliveries), finding workflows, analytics and balance, your application’s API key and webhooks, finding cases, users, businesses and transactions, and the documentation search.
  • core: the short list above.
  • account: organizations, applications, API keys, members and roles.
  • billing: plan, credit balance, payment methods, receipts and billing details.
  • sessions: verification sessions (create, find, decide, review, share, import, PDFs and webhook deliveries).
  • workflows: verification workflows and questionnaires (build, edit, validate and publish).
  • lists: custom lists, the blocklist and the allowlist.
  • vendors: the people and companies you verify (vendor users and vendor businesses).
  • transactions: transaction monitoring (transactions, wallet screening and rules with backtesting).
  • cases: case management (create, assign, escalate and resolve cases).
  • investigator: the Investigator (its review queue, reports, decisions, policy questions and performance).
  • webhooks: webhook destinations and alerts.
  • reports: analytics, exports and the audit log.
  • branding: white-label branding of the verification flow.
  • verification: standalone verification APIs (ID document, face, AML, proof of address, phone, email, database and business checks).
  • travel_rule: Travel Rule (settings, the VASP directory, networks, wallet addresses, transfers and messages).
  • marketplace: the provider marketplace (the catalog, your connections and integration requests).
  • networks: fraud networks (linked sessions, users and businesses that share a device, document or contact).
  • compliance: the compliance assistant (your regulatory profile, its requirements and workflows generated from them).
  • docs: search of the Didit documentation.
  • all: every tool your role may use. This is the default.
The tools reference lists every tool with its type and the role permission it needs. How the selection behaves:
  • Toolsets are opt-in. A URL with no toolsets lists everything.
  • Naming toolsets lists exactly those. ?toolsets=cases lists the case tools, plus didit_context_get, which every connection gets. Add core to keep the short list too.
  • A toolset decides what is listed, not what you may run. A tool outside your selection still runs when the model calls it by name, with the same role permissions as always.
  • A name the server does not know is ignored. The connection still works, and the server tells the model which name it ignored and which ones are valid.
  • Your role still applies. A toolset never grants a permission: see roles and permissions.

​
Connect in read-only mode

Add read_only=true to the server URL:
A read-only connection lists only tools that read, and the server refuses every call that would create, change or delete something. The refusal happens on the server for every call, so it holds even if your client remembers a tool from an earlier connection. Use it for reporting, for exploring an account, or for an agent you do not want to act on its own. To allow changes again, connect without read_only.

​
Reach the tools you did not load

When a connection lists only part of the catalog, the server adds four tools so that nothing is out of reach:
  • didit_tool_search (read): finds tools by what you want to do (“export sessions to CSV”), or lists one toolset. Each match says what the tool does, its parameters and whether it reads, writes or is destructive.
  • didit_tool_describe (read): returns the full description and input schema of up to five tools.
  • didit_tool_call_read (read): runs a read-only tool that is not in the list. It refuses a tool that changes data.
  • didit_tool_call_write (destructive): runs a tool that creates, changes or deletes data and is not in the list. Not offered on a read-only connection.
A call through didit_tool_call_read or didit_tool_call_write is checked exactly like a direct call: your role permissions, read-only mode and every confirm: true requirement still apply. The two are separate so that your client can ask you before a change and let a lookup through. With core loaded, a request such as “invite a new teammate to my organization” goes like this:
  1. The model calls didit_tool_search with invite a teammate and gets didit_org_invite_member, marked as a write.
  2. It calls didit_tool_call_write, passing didit_org_invite_member as name together with that tool’s own arguments.
  3. Your client asks you to approve the call, as it does for any tool that changes data.
When everything is loaded there is nothing left to discover, so these four tools are not listed.

​
Set it up in your client

Use the same steps as the installation guide, with the parameters added to the URL.
Keep the quotes: your shell would otherwise read the ? and & itself.
If your client lets you set headers but not edit the URL, send X-MCP-Toolsets: core,workflows and X-MCP-Readonly: true instead. A value in the URL wins over the header for toolsets, and read-only is on when either one asks for it.
The ChatGPT plugin uses its own fixed, reduced catalog at https://mcp.didit.me/mcp/chatgpt. Toolsets and read-only mode do not apply to it. See Connect ChatGPT.
The server helps the model start in the right place:
  • Instructions. On connect, the server tells the model to begin with didit_context_get, how organization_id and application_id resolve, to build in a sandbox application, and which toolsets this connection loaded.
  • Prompts. Clients that support MCP prompts show five starting points: integrate_didit, review_queue, explain_session, build_workflow and verification_report. In Claude Code they appear as slash commands.
  • Documentation search. didit_docs_search searches these docs and returns the matching sections with their links, so questions about how Didit works are answered from the current pages.

​
Check what a connection loaded

Ask your client:
The model answers from the server’s instructions. To check that a server supports toolsets before you rely on them, read its health endpoint:
The answer lists toolsets and read_only under features.

​
Next steps

Installation

Connect Claude, ChatGPT, Cursor, VS Code, Codex or any MCP client.

Tools reference

Every tool, its type and the role permission it needs.

Authentication

Log in with Didit, scopes and role permissions.

Example prompts

Prompts that work on day one.
Last modified on November 11, 2026