Skip to main content
The Verisoul MCP server connects an AI client to your Verisoul data. Claude, Cursor, VS Code, and anything else that speaks the Model Context Protocol can work with your accounts, sessions, rules, lists and dashboards directly. There are two ways in, and both reach exactly what you reach in the dashboard: The endpoint is https://dashboard.verisoul.ai/api/mcp. For Sandbox, use https://dashboard.sandbox.verisoul.ai/api/mcp.

​
Signing in from your client

Nothing to create or paste. Point the client at the endpoint, and it opens a browser tab where you sign in to Verisoul and approve the connection. The approval screen names the client asking and, if you belong to more than one organization, asks which one this connection is for.
Then run /mcp inside Claude Code, choose verisoul, and sign in when the browser opens.
What the client gets is your access: the organization you chose, the projects you reach, and the permissions your role gives you there. Change your role and the connection follows within seconds. Leave the organization and it stops.
To work with a different organization, disconnect the server in the client and connect again. The approval screen asks which organization each time.
You can end a connection from the client at any time. Signing out of Verisoul does not affect it, and it lasts until you disconnect or an Admin removes you.

​
Keys, for clients that run on their own

A key reaches exactly what you reach. It is created from your own access, so a client holding it can do what you can do in the dashboard, and that is its limit. Keys are managed from Settings → MCP access. Any member can create one.

​
Creating a key

1

Open Settings → MCP access

The list shows every key you have created, the role it holds, the projects it reaches, and when it was last used. Admins see every key in the organization; everyone else sees their own.
2

Name it after the client that will hold it

The name appears in this list and in the audit trail. Fraud ops agent or Nightly export script will mean something to you in six months. My key will not.
3

Choose when it expires

30 days, 90 days, one year, or does not expire. An expired key stops working on its own, which is the simplest way to limit a credential you need for a while.
4

Decide what it can reach

The same as your access gives the key everything you have today. This suits a client that works alongside you.Only certain projects narrows it. Pick the projects and the role for each, which is useful when a script reads one project and you would rather keep the rest out of its hands.In both cases the key stays inside your own access.
5

Copy the secret

The secret is shown once, at creation, and cannot be retrieved afterwards. Copy it into your client’s configuration straight away. A client that loses it needs a new key.

​
Keep the key secret

Never share an MCP key directly. Do not paste it into a chat, a ticket, a shared document, a screenshot, or source code you commit.A key is a live credential. It carries your access and needs no sign-in, so anyone holding it can read and change whatever you can, and the audit trail will show your key as the actor.Give it to your MCP client through a secrets manager or an environment variable. If a key does get out, revoke it from this list and create another. Revoking takes effect immediately.

​
Connecting a client with a key

Send the key as a bearer token against the MCP endpoint.
Keep the key in an environment variable, as shown above. Configuration files get synced between machines and committed to repositories.

​
What a connection can reach

Two things decide what a call is allowed to do, and both have to agree: The limit can only narrow. Choosing Only certain projects on a key takes projects away from what it reaches, and everything offered there is already within your own access. The client’s first call should be access_context_get, which returns the permissions and the project IDs the connection reaches. Every project-scoped tool needs a project ID from that list. A project outside its reach comes back as not found, which is the same answer an unknown project ID gets, so a client has no way to enumerate the rest. Around 88 tools exist in total. The server offers each client the ones its connection can use, so a client that sees fewer tools than a colleague’s has a narrower key, a narrower role, or both.

​
Limits

Some tools start work that runs for a while: analytics queries, agent runs, signed-URL query results, and exports. Each family has a ceiling on how many can be in flight at once, so one runaway client cannot crowd out the rest of your organization. A connection is one person’s sign-in or one key. A client that fans out across several projects gets five runs at once, not one. When a ceiling is reached the tool answers RUN_LIMIT_REACHED with retry_after_seconds, and the right response is to wait and poll rather than resubmit. Short bursts of ordinary calls are bounded separately and answer RATE_LIMITED. Operations that spend money, such as email deep research and agent runs, also draw on a monthly quota for the organization. Call usage_get at any time for the live ceilings, the quota that remains, and what is currently in flight.

​
Every call is recorded

Each tool call and resource read is written to your organization’s audit trail with who made it, which tool, which project, whether it was allowed, and how long it took. A sign-in is recorded as the person; a key is recorded as the key, under the name you gave it. Your client can read the trail with the audit_events_list tool, which is the quickest way to answer what an agent actually did.

​
Keys follow your access

A key holds a role the same way a person does, and it is tied to the access you had when you created it. Reduce or remove your access and every key you created is retired at the same moment, and stops working immediately. That covers a change to your project grants, a change to your organization role, and leaving the organization.
For an integration that has to keep running through changes to your own access, have it created by someone who will keep that access. A shared service account is the usual answer for a long-lived integration.

​
Managing keys

The list shows each key’s state: Expired and revoked keys stay in the list, so it also answers what has ever been able to reach your account. Revoking a key stops it at once and clears the roles behind it. It cannot be undone: a client that still needs access needs a new key. You can revoke your own keys, and an Admin can revoke anyone’s. Revoking is worth doing even for a key that already expired. It clears the roles the key still holds, which matters when you are trying to delete a role.

​
Sandbox and Production are separate

A connection reaches one environment. A key is created in one environment and works only there, and a sign-in against the Sandbox endpoint reaches Sandbox data only.
This follows the same rule as project access: Sandbox projects and Production projects are different projects holding different data. If your client needs both, connect it to each endpoint separately.

​
Troubleshooting

The connection reaches very little. Call access_context_get to see what it holds. The usual causes are a key narrowed to projects your access has since dropped, or an organization role with zero project grants behind it.
For a key, check it is still active in Settings → MCP access. A key is retired automatically when the access of the person who created it is reduced or removed, and it shows as revoked here.For a sign-in, disconnect the server in the client and connect again. If sign-in completes but calls are still refused, you may no longer hold a role in that organization; ask an Admin.
The client is older than the current MCP authorization standard. Update it, or use a key instead.
The approval screen at sign-in asks which organization to use. Disconnect the server in the client and connect again to choose another.
The project sits outside what the connection can reach. Use a project ID from access_context_get.
That family has as many runs in flight as the ceiling allows, for you or for the organization. Wait retry_after_seconds and poll the run you already started rather than starting another. usage_get shows what is in flight.
Roles are still being switched on for your organization, so there is nothing yet to build a key from. Contact support@verisoul.ai.
You hold an organization role with zero project grants. Ask an Admin to grant the projects you need, then create the key.
Revoke the key and create another. The secret is shown once at creation and cannot be retrieved.
That is intended. Revoked keys stay in the list as the record of what existed and what it could reach. They are inert.

​
Need Help?

If you have any questions about MCP access, please contact our support team at support@verisoul.ai.