XAA Debugger

The XAA (Cross-App Access) Debugger tests an MCP server and its authorization setup. MCPJam acts as both:

• The identity provider, which signs the ID token and ID-JAG.
• The client/agent, which presents the ID-JAG and uses the access token.

​

Before You Run the Test

​

Trust MCPJam’s Identity Provider

The XAA Flow header shows three URLs: Configure your authorization server with the values it requests. The Issuer URL identifies MCPJam’s test identity provider, the OpenID Config URL provides discovery metadata, and the JWKS URL provides the public signing keys.

​

Identity assertion format

The header also shows an Identity assertion toggle that lets you choose the format MCPJam uses when minting the identity assertion for a run: Selecting a format saves it as the per-server preset immediately (the same setting you can also change in Configure Server to Test). The two surfaces always agree: changing one updates the other. When SAML is active, a note appears below the header explaining that the discovery and JWKS URLs above are unchanged. The ID-JAG is still a JWT minted under this issuer in both formats; only the identity assertion inside it changes shape. The toggle is unavailable in these situations:

• Registered app target: runs against a registered app always use the OIDC ID token; the per-server preset does not apply.
• Run in progress: wait for the current run to finish before switching.
• No server configured: configure a server to test first.

If MCPJam is running locally and your authorization server is hosted in the cloud, turn on Use hosted issuer in the XAA Flow header. A cloud server cannot reach a local Issuer URL. The hosted issuer is available to both signed-in users and guest (not-signed-in) sessions, provided an organization is active. The issuer used depends on your session: When a guest session is active, hover the info icon next to the hosted-issuer toggle to see a reminder of this distinction.

​

Add Your MCP Server

In the XAA Flow tab, click Configure Server to Test to open the server modal prefilled with the currently selected server, or click Add in the logger toolbar to open a blank form and save a new target without changing the current selection.

​

Server Configuration

Enter a name and URL for the MCP server. Then choose a registration method and provide credentials if that method requires them. Scopes are optional. The identity provider is fixed to MCPJam test identity provider for this test.

​

Registration Method

Use the Registration menu to choose how MCPJam identifies itself to your authorization server:

• Pre-registered client: Register MCPJam in your authorization server first, then enter the client ID and optional client secret it gives you.
• Client metadata URL (CIMD): MCPJam uses a client metadata URL as the client ID. Your authorization server must advertise CIMD support. When running the local inspector, a Client authentication control appears with two options:
  • Public (no client auth): MCPJam presents its hosted metadata URL as the client ID with no client authentication. This is the default.
  • Confidential (private_key_jwt): The local inspector holds a client key and signs a client_assertion. The client_id is a reflector document publishing the matching public key. Use this when your authorization server requires a confidential client. The private key never leaves the local inspector process.
• Open dynamic registration (DCR): MCPJam registers a client during the test, so no client credentials are required beforehand. Your authorization server must provide an open registration endpoint; protected registration requiring an initial access token is not tested.

​

Scopes

Enter the permissions MCPJam should request, separated by spaces. MCPJam includes them when requesting the ID-JAG and access token. Leave blank to omit scopes from those requests.

​

Advanced Settings

Open Advanced to override authorization server discovery or test a specific user identity. Most tests can leave these settings unchanged.

​

Authorization Server Issuer

Leave Authorization Server Issuer blank to use the authorization server MCPJam discovers from the MCP server. Enter a URL to use a different authorization server instead. Leave Allow non-standard issuer mismatch disabled for normal RFC 8414 behavior. Use it only for compatibility testing when the discovered authorization server URL and the metadata issuer differ but belong to the same origin. RFC 8414 requires an exact match, so enabling this setting relaxes that check.

​

Simulated Identity

The Simulated identity fields let you choose the user that MCPJam, acting as the test identity provider, puts in the ID token. Leave them blank to use your signed-in account. Change them to test how your authorization server handles a specific user. Your authorization server must validate MCPJam’s ID-JAG before issuing an access token. It may also apply its own policy to decide which users are allowed.

​

Inspect the ID-JAG

Before MCPJam sends the ID-JAG to the authorization server, the right panel opens the ID-JAG Inspector. Use it to inspect exactly what MCPJam created and identify problems before the token exchange. MCPJam checks each piece of information inside the ID-JAG and shows whether it looks correct or broken. It also shows the relevant RFC or ID-JAG requirement for each check.

​

Header

The JWT header shows:

• alg: the signing algorithm.
• typ: the token type.
• kid: the signing key identifier.

​

Payload

The payload shows the values MCPJam puts into the ID-JAG:

​

Signature

The inspector shows the signed JWT and provides Copy JWT for further inspection. The authorization server verifies the signature using MCPJam’s public signing keys.

​

Negative Tests

The Negative-test scorecard sends invalid ID-JAGs to your authorization server and checks that it refuses the assertions that the ID-JAG profile requires it to reject. It also reports two policy-dependent probes separately. Run a successful flow first to unlock it. The scorecard reuses the client identity resolved by that flow, whether it was pre-registered, dynamically registered with DCR, or resolved via CIMD. Click Run negative tests to send intentionally broken ID-JAGs to the authorization server’s token endpoint. The MCP server is not called during these probes. A strict rejection check passes when the authorization server rejects the broken assertion. It fails when the authorization server issues an access token for one. The scorecard runs these nine strict rejection checks:

• Bad Signature
• Wrong Audience
• Expired
• Missing Claims
• Invalid typ Header
• Wrong Issuer
• Resource Mismatch
• Client ID Mismatch
• Unknown kid

It also reports these policy probes without treating acceptance or rejection as a security verdict:

• Unknown Subject
• Scope Denial

An authorization server may resolve or JIT-provision an unknown subject. It may also reject a scope request or issue a token containing only an allowed subset. Inspect these rows against your deployment’s intended subject-resolution and authorization policy. These are targeted security and policy checks, not a full conformance test.

​

The XAA Flow

The debugger shows the flow in the sequence diagram and logs each request and response:

1. Discover the MCP server and authorization server. MCPJam asks the MCP server which authorization server protects it, then reads the authorization server metadata.
2. Resolve the client identity. MCPJam uses the pre-registered client, performs DCR, or uses its CIMD URL.
3. Simulate sign-in at MCPJam’s identity provider. MCPJam issues a test ID token.
4. Request an ID-JAG. MCPJam’s identity provider exchanges the ID token for an ID-JAG.
5. Request an access token using the ID-JAG. MCPJam sends the ID-JAG to the authorization server’s token endpoint using the JWT-bearer grant.
6. Call the MCP server. MCPJam sends the resulting access token to the MCP server.

​

Debugging Failures

The right panel shows each flow step, its request and response details, and any available token information. If a step fails, it also provides guidance for diagnosing the problem. This may include:

• The authorization server does not advertise or accept the JWT-bearer grant.
• MCPJam’s issuer or signing keys are not trusted.
• The client identity is missing, unregistered, or not allowed to use the grant.
• The aud, resource, or client_id claim does not match the authorization server’s configuration.
• The authorization server issues a token, but the MCP server rejects it.

Use the compatibility results after discovery and expand each flow step to inspect the exact request, response, and token claims.

​

Related Standards

• MCP Authorization
• OAuth 2.0 Authorization Server Metadata (RFC 8414)
• OAuth 2.0 JWT Bearer Token Grant (RFC 7523)
• OAuth 2.0 Dynamic Client Registration (RFC 7591)