> ## Documentation Index
> Fetch the complete documentation index at: https://mcpjam-docs-coming-from-mcp-inspector.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.
# XAA Debugger
> Configure and debug Cross-App Access flows with MCPJam as the test identity provider and client/agent
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:
| URL | Purpose |
| ----------------- | ---------------------------------------------------- |
| **Issuer URL** | The issuer MCPJam puts in its signed tokens. |
| **OpenID Config** | Metadata describing the issuer and its signing keys. |
| **JWKS URL** | MCPJam's public signing keys. |
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.
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:
| Session | Issuer path | Trust model |
| ------------- | -------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Signed in** | `/o/` | Membership-gated. Only org members can mint assertions under it. |
| **Guest** | `/g/` | **Anonymous test issuer.** Its discovery document is marked `mcpjam:issuer_kind: anonymous-test`. Your authorization server must explicitly allowlist this issuer. Assertions prove control of an anonymous session — this is a testing convenience, not enterprise-managed authorization. Sign in to use the membership-gated issuer instead. |
When a guest session is active, the hosted-issuer toggle shows an **Anonymous test issuer** badge as a reminder of this distinction.
## Add Your MCP Server
In the XAA Flow tab, select **Configure Server to Test**.
### 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 its hosted client metadata URL as
the client ID, so no client credentials are required. Your authorization
server must advertise CIMD support.
* **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](https://www.rfc-editor.org/rfc/rfc8414) 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:
| Claim | What it identifies |
| ----------------------- | ------------------------------------------------------- |
| `iss` | MCPJam's test identity provider |
| `sub` and `email` | The test user's identity |
| `aud` | The authorization server that should receive the ID-JAG |
| `resource` | The MCP server the access is for |
| `client_id` | The client identity used in the test |
| `jti`, `iat`, and `exp` | Replay protection and token lifetime |
| `scope` | The permissions requested for the MCP server |
### 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 when it was
pre-registered or dynamically registered with DCR.
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](https://modelcontextprotocol.io/specification/draft/basic/authorization)
* [OAuth 2.0 Authorization Server Metadata (RFC 8414)](https://www.rfc-editor.org/rfc/rfc8414)
* [OAuth 2.0 JWT Bearer Token Grant (RFC 7523)](https://www.rfc-editor.org/rfc/rfc7523)
* [OAuth 2.0 Dynamic Client Registration (RFC 7591)](https://www.rfc-editor.org/rfc/rfc7591)