Descope + FastMCP: give two Claude connections different scopes

Separate user identity from client permissions

Thanks to Descope for sponsoring this video.

The demonstration uses staged Scripti data. The same signed-in user has a Viewer connection and an Editor connection with different capabilities.

1. Define the protected resource and the actions each client needs.
2. Configure the demonstrated projects:read and scripts:write scopes and corresponding policies.
3. Inspect the protected-resource metadata and OAuth discovery path shown in the video.
4. Use separate scoped access tokens for the two client configurations.

Enforce the scope at the tool boundary

The Viewer never receives the update tool; the Editor can make the requested change. A hidden button in a frontend would not establish that server enforcement exists.

1. Configure the Viewer with read scope and the Editor with read and write scope.
2. Have the MCP server validate the token and enforce scope requirements per tool.
3. Inspect the tools exposed to each connection.
4. Try the same small edit with both clients and verify that the read-only route cannot perform it.

Check the saved result and the workspace boundary

The recorded Editor change persists as revision 3. Workspace ownership is a separate condition from having a write scope.

1. Read back the saved revision after the allowed update.
2. Use the separate workspace check shown at 5:51 and verify access is refused where ownership does not match.
3. Inspect audit logs for both allowed and denied requests.
4. Keep the test on demo records before connecting production customer work.

The takeaway

A scoped token and a workspace check solve different access questions. Verify both against actual server responses and saved records.