Loading ToolBench
MCP SDK for Descope authentication providing token management and connection token retrieval for OAuth applications
The Descope MCP server exhibits significant quality gaps across naming, descriptions, and schemas. While 11 tools are defined, only 4 have complete input schemas visible in the source code. Most tools have minimal descriptions (under 50 chars), parameter descriptions are sparse or missing entirely, and output schemas are not documented. The server lacks proper error handling guidance, permission declarations, and security posture documentation. Tool naming follows verb_noun convention but descriptions fail to explain WHEN to use each tool or what happens as a result. No tool annotations (readOnlyHint, destructiveHint) are present despite some tools performing read operations. The server appears to be an early-stage implementation (v0.1.0) without production-quality documentation.
Get authenticated user information. Requires a valid MCP access token.
Fetch latest tenant token
Fetch tenant token with specific scopes
Fetch latest user token
Fetch user token with specific scopes
Get Google Calendar events for the authenticated user. Requires 'calendar.read' scope in the MCP access token. Uses Descope connection token to access Google Calendar API.
Output schemas not documented. LLMs cannot predict response structure, plan downstream tool calls, or know which fields to extract. 11/11 tools lack documented return schemas.
Tool descriptions too brief (10-70 chars). Missing WHEN to use each tool, what happens, and any prerequisites. Descriptions like 'Fetch latest user token' and 'Fetch latest tenant token' do not explain the difference or when to select one over the other.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 48 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 39 | 1.0.0+ | v1 |
Get Slack workspace information using tenant token
Get tenant token using management key. No user session required - uses management key for tenant-level access.
List user's Google Calendars. Requires 'calendar.read' scope in the MCP access token.
Get public information - no authentication required
Read data - requires 'read' scope
Parameter descriptions missing or incomplete. Many parameters ('options', 'scopes', 'tenant_id') lack descriptions explaining their purpose, constraints, and valid values. 'options' is vague, does not clarify what keys are accepted or their effects.
No tool annotations present. All tools marked READ_ONLY in the risk field, but no readOnlyHint, destructiveHint, or idempotentHint metadata in MCP tool definitions. This prevents protocol-compliant clients from applying proper handling.
No error handling guidance. Responses do not tell LLMs what to do on failure: retry, ask user, or give up. No recovery paths or clarification of retryable vs fatal errors.
No scope/permission declarations. Tools accept 'mcp_access_token' but do not declare what OAuth scopes or permissions they require (e.g., 'calendar.read', 'read:email'). Agents cannot configure least-privilege access.
Ambiguous tool naming for token fetching. Tools 'fetch_user_token' and 'fetch_user_token_by_scopes' are too similar, LLMs may confuse them. Also, 'fetch_tenant_token' vs 'get_tenant_token' (example) both exist with overlapping intent. Consider unified naming (e.g., fetch_token_for_user_with_scopes, fetch_token_for_user_all_scopes).
Incomplete input schemas. Tools like 'public_info' and 'get_slack_workspace_info' have empty property objects, no schema constraints visible. 'options' parameters are typed as object without property definitions, allowing arbitrary keys.
Credentials passed as parameters. Token parameters ('mcp_access_token') are tool inputs, which means they appear in logs and traces. Should use server-side secret injection via environment or configuration instead.
No pagination or result limits documented. 'get_calendar_events' accepts 'max_results' but does not specify a reasonable cap (e.g., max 100). No mention of pagination cursors or whether results could exceed context limits.
Missing tool composition and chaining IDs. If 'get_calendar_events' returns events, do they include calendar_id, email, or other IDs needed for follow-up operations? Not documented.