Loading ToolBench
A remote Model Context Protocol Server for Snowflake deployed as AWS Lambda
This server exhibits critical definition quality issues across multiple dimensions. While 10 tools are nominally present, the actual MCP server implementation is unclear from the provided source. The codebase appears to be a FastAPI authentication and data application (backend) with a React frontend, but no explicit MCP protocol implementation is visible. Tools appear to be inferred from FastAPI endpoints rather than explicitly registered as MCP tools. Descriptions are present but often lack clarity and depth. Input schemas are inconsistently documented. No tool explicitly declares its output schema. Error handling guidance is absent. The naming conventions follow REST patterns (login, oauth_callback, logout) rather than MCP agentic patterns (authenticate_user, complete_oauth_flow, terminate_session). Critical security concerns: oauth_callback and update_preferences lack proper CSRF/state validation documentation. No evidence of MCP-specific features like tool annotations, structured error reporting, or proper schema registration.
Health check for authentication system.
Get current user information.
Get current user profile.
Health check endpoint for liveness probes.
Initiate Google OAuth login flow.
Logout user by clearing JWT cookie.
Handle OAuth callback from Google.
Readiness check endpoint for deployment readiness.
No output schemas documented for any tool. Tools return unstructured responses without documenting expected fields, types, or pagination. Agents cannot plan downstream tool calls or extract necessary data.
Health check, readiness, and root tools are infrastructure concerns, not user-facing actions. They should not be exposed as MCP tools. They clutter the tool namespace and distract from actual capabilities.
Tool names do not follow agentic patterns. 'login' and 'oauth_callback' are REST-style names; should be 'authenticate_with_google', 'complete_oauth_flow'. 'oauth_callback' is not a direct user action, it's an internal handler.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 0 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 21 | - | v1 |
Root endpoint providing API information.
Update user preferences.
No descriptions for get_current_user_info, get_profile, auth_health_check, health, readiness, root explain WHEN to use them or how they differ from each other. get_current_user_info and get_profile appear to be duplicates with no documented distinction.
oauth_callback description does not mention CSRF protection or state parameter validation. Security-critical parameter validation is undocumented.
update_preferences lacks guidance on valid enum values for 'default_output_format' parameter. Agents cannot know what formats are acceptable without trial-and-error.
No error handling guidance. Tool descriptions do not explain what happens on failure, what error messages are returned, or what the agent should do next (retry, ask user, abort).
No evidence that logout is idempotent. If called twice in rapid succession, does the second call fail, succeed silently, or return an error? Agents need to know if they can safely retry.
Duplicate functionality: get_current_user_info and get_profile both return user data with no documented distinction. Agents will wastefully call both to determine which contains needed data.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint) visible in schema. Agents cannot determine safe retry boundaries or scope of side effects.