Your context.
Scoped access.
Claude Code accesses one approved memory context through a Descope-protected MCP server. It can search, read and append evidence—not promote that evidence into trusted instructions.
1. Which Descope use case?
Secure MCP servers with auth and access control. This is delegated user access: Claude is the OAuth client, Descope is the authorization server, and our FastMCP gateway is the protected resource.
Not an autonomous agent-identity deployment, a Descope credential vault, or a full enterprise policy platform. Local scope checks and audit events do not establish those additional Hub use cases. Pending memory review is not per-action human approval.
2. One flow, clear responsibilities
The client discovers Descope through public MCP resource metadata. The intended login flow is authorization code + PKCE. Each protected request is authenticated; discovery and consent do not replace tool-level enforcement.
3. What can it actually do?
Bounded lexical search within the connected context. Not vector search.
Fetch an eligible record by ID. Results include provenance and use policy.
Store generated, pending evidence. No overwrite, deletion or trust promotion.
Read and write permissions are independent. After an uncertain write, retry with the same key and exact content; a new key creates a new append.
Current mismatch: eight scopes are advertised and nine tools are registered, but only one context’s three tools are connected. Two context families fail closed; another scope family has no tools. Listed does not mean usable.
4. Is it implemented correctly?
Core resource-server pattern: sound. End-to-end assurance: incomplete. No reason to replace the architecture; there is unfinished verification and discovery cleanup.
- Enforced in reviewed code: signed JWT validation, exact issuer/resource audience, approved user, a 15-minute maximum accepted token lifetime, independent scope checks, fixed backend routes and native record membership.
- Previously demonstrated: the October 7 review records 40 Python + 12 native tests passing, authenticated searches and a durable generated/pending write. Those tests were not rerun for this documentation update.
- Checked October 12: gateway, adapter and native source; current vendor guidance; live public resource metadata. This is not a fresh authenticated end-to-end test.
- Still unproven: captured PKCE/resource exchange, refresh and expiry recovery, key rotation, Descope client-to-scope issuance/registration restrictions, live tool listing and exact read-result delivery.
Threat boundary: wrong-resource tokens and scope overreach are rejected. A stolen valid bearer can still be replayed; there is no per-request introspection or demonstrated instant revocation. Prompt injection can misuse already-granted permissions. A compromised gateway identity can exercise its backend capabilities.
5. Keep the pattern. Finish the proof.
- Align discovery with working capabilities. Recommend advertising only the connected context’s scopes/tools, coordinated with Descope configuration. Not applied in this docs update.
- Verify the client lifecycle. Capture login, live listing and read delivery; test refresh, expiry, rotation and revocation behavior.
- Confirm issuance policy. Verify which clients can obtain which scopes. Client identity is recorded by our gateway, not separately allowlisted there.
Recommendation: retain Descope + FastMCP for this bounded connector. Bespoke OAuth adds protocol maintenance without a demonstrated benefit; a broader Hub policy/credential platform is justified only when downstream services or agent governance require it.