Loading ToolBench
OAuth 2.0 Server with Dynamic Client Registration and Google OAuth Integration
MCP-OAuth exposes 11 OAuth/OIDC endpoints as tools via fastmcp HTTP transport. Tool naming follows verb_noun convention (register_client, authorize, token_endpoint). However, critical gaps undermine quality: (1) Parameter descriptions are minimal (5-15 chars avg, well below 72-char baseline); (2) No output schemas documented for any tool, LLMs cannot plan downstream calls or extract structured data; (3) No error handling guidance, tools return raw HTTP errors without recovery hints; (4) Security-critical tools (token_endpoint, revoke_endpoint) expose client_secret as a parameter, violating secret-injection pattern; (5) No tool annotations (readOnlyHint, destructiveHint) despite clear WRITE vs READ_ONLY risk classifications. The server implements OAuth correctly as a backend service, but the MCP tool interface is underdeveloped for agent consumption.
OAuth 2.0 Authorization endpoint
Health check endpoint
OAuth 2.0 Token Introspection endpoint
JSON Web Key Set endpoint
OAuth callback endpoint for handling authorization code from OAuth provider
OAuth 2.0 Authorization Server Metadata endpoint
OpenID Connect Discovery endpoint
No output schemas documented. LLMs cannot infer response structure, plan chained calls, or extract required fields (e.g., access_token from token_endpoint, user_id from userinfo_endpoint). This violates the documented-return-types baseline (100% of A+ tools have them).
client_secret exposed as tool parameter in token_endpoint, revoke_endpoint, introspect_endpoint. Secrets in parameters leak into agent logs and prompt history. Must use server-side secret injection via Authorization header or environment variables.
Parameter descriptions are minimal (5-15 chars, e.g., 'Client ID', 'Redirect URI'). Baseline is 72 chars. Descriptions lack context on format, constraints, or when to use. E.g., 'scope' param has no guidance on valid values (openid, profile, email) or mutual exclusivity.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 47 | <=2025-11-25 | v2 |
Dynamic Client Registration endpoint
OAuth 2.0 Token Revocation endpoint
OAuth 2.0 Token endpoint for exchanging authorization codes and refresh tokens
User info endpoint for retrieving authenticated user information
No error handling guidance. Tools return raw HTTP errors without recovery hints. E.g., if token_endpoint fails with 'invalid_grant', LLM has no guidance on whether to retry, ask user for new code, or abort. Missing pattern:recovery-guide.
No tool annotations despite clear risk classifications. token_endpoint and revoke_endpoint are marked WRITE but lack destructiveHint annotation. userinfo_endpoint is READ_ONLY but lacks readOnlyHint. Annotations enable agent safety policies.