Skip to main content
MCP clients can connect to Decoda after a user signs in and approves the connection. The client receives short-lived access for the selected tenant, so it can only use the Decoda tools available to that tenant.
Prerequisites: Use an approved MCP client and sign in with a Decoda account that has access to the tenant you want to connect.

​
What the user sees

1

Start the connection from the MCP client

Open the MCP client and choose the Decoda connection. The client opens a Decoda sign-in page if you are not already signed in.
2

Sign in if prompted

Sign in with your Decoda account. After sign-in, Decoda sends you to the connection approval screen for the same MCP client, so you can finish the request without starting over.
3

Review the request

Decoda shows the client name and the access it is requesting. Confirm that the client name is one you recognize.
4

Approve the connection

Click Connect to Decoda. Decoda sends you back to the MCP client after the connection is approved.

​
What connected clients can do

A connected client can use Decoda’s MCP tools for the tenant included in the connection. Decoda checks the tenant on each request and blocks access to other tenants. Access tokens are short-lived. If a token expires, the client must send the user through the connection flow again.

​
Register a client

Integrators can register a public client with Decoda before starting the user connection flow. The registration includes:
  • Client name shown to users during approval.
  • One or more secure return URLs.
  • The requested access scope. Decoda currently supports mcp:access.
Return URLs must use HTTPS. Local development URLs may use localhost, 127.0.0.1, or ::1 over HTTP.

​
Disconnect or revoke access

The current MCP connection uses short-lived access tokens. A revoke request is recorded for audit history, but existing access tokens are not immediately invalidated yet. Tokens stop working when they expire.