Loading ToolBench
OAuth 2.1 authorization server with support for multiple identity providers, token management, PKCE, refresh token rotation, and Client ID Metadata Documents (CIMD) for MCP (Model Context Protocol) applications
This MCP server exposes OAuth 2.0 infrastructure as tools, but suffers from fundamental misalignment with agentic tool patterns. The tool set (ServeAuthorization, ServeToken, etc.) are designed as HTTP endpoint handlers, not agent-callable operations. Naming violates verb_noun convention, 'ServeAuthorization' is a transport abstraction, not an action an agent would invoke. Parameters are present with descriptions, but the tools themselves are not designed for LLM composition. No input validation, error recovery guidance, or structured output handling is evident. The server appears to be an OAuth reference implementation exposed via MCP, not a tool suite optimized for agent interactions.
Registers RFC 8414 Authorization Server Metadata endpoint at /.well-known/oauth-authorization-server. Advertises OAuth endpoints, supported grant types, PKCE methods, and scopes.
Registers RFC 9728 Protected Resource Metadata endpoint at /.well-known/oauth-protected-resource. Advertises authorization server and required scopes to clients.
Handles OAuth 2.0 authorization requests. Processes authorization code flow with PKCE support, validates request parameters, and manages authorization consent.
Handles OAuth 2.0 authorization code callback. Exchanges authorization code for tokens from the configured identity provider.
OAuth 2.0 dynamic client registration endpoint. Allows clients to register themselves and obtain a client_id.
Serves RFC 9728 Protected Resource Metadata document describing OAuth protection and required scopes for a resource.
OAuth 2.0 token endpoint. Handles authorization code exchange and refresh token flow. Issues access tokens and refresh tokens.
Tools use 'Serve*' naming pattern (ServeAuthorization, ServeToken, ServeCallback) which reflects HTTP endpoint abstractions, not agentic actions. LLMs expect verb-noun patterns like 'exchange_authorization_code', 'revoke_token', 'validate_bearer_token'. Current names do not convey what action the agent performs.
Tool definitions are inferred from code examples (examples/basic/main.go) rather than explicitly discoverable in the source. No explicit tool registration, JSON Schema definitions, or description metadata visible in server implementation.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 49 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 0 | 2025-11-25+ | v1 |
OAuth 2.0 token revocation endpoint. Revokes access tokens and refresh tokens, invalidating them immediately.
Extracts authenticated user information from request context after ValidateToken validation. Returns UserInfo object with ID, Email, and Name.
Middleware that validates OAuth 2.0 bearer tokens in Authorization header. Returns 401 with WWW-Authenticate header if invalid. Adds validated UserInfo to request context.
'ServeProtectedResourceMetadata' has no input schema visible in the provided source. This tool cannot be reliably invoked without understanding its parameters.
No error handling or recovery guidance present. Tools like 'ServeToken' and 'ServeCallback' will fail in various ways (invalid code, expired state, client mismatch) but descriptions do not indicate what errors are possible, when they are retryable, or what the agent should do next.
Metadata registration tools (RegisterProtectedResourceMetadataRoutes, RegisterAuthorizationServerMetadataRoutes) accept HTTP mux objects as parameters. Agents cannot introspect or construct HTTP router objects, these tools are infrastructure helpers, not agentic operations. They should not be exposed as agent-callable tools.
No documented output schemas for any tool. Agents cannot determine what fields to expect, preventing composition of downstream tools. E.g., ServeToken should document that it returns 'access_token', 'refresh_token', 'expires_in', and 'id_token' (OIDC), but no schema is provided.
No input validation constraints documented. Many parameters (like 'code_challenge_method', 'grant_type', 'token_type_hint') accept only specific enum values, but these are not stated in parameter descriptions. LLMs may pass invalid values without clear feedback.
Parameter descriptions are generic and lack actionable detail. E.g., 'code_challenge' is described as 'PKCE code challenge' without mentioning it must be base64url-encoded SHA256 hash of the code_verifier, or that S256 is the required method. Descriptions should include format, encoding, and validation rules.