Loading ToolBench
LLM Wrapper API for Gemini, OpenAI, Claude with MCP (Model Context Protocol) support for tool integration
The Rini API Server defines 9 tools with basic HTTP FastAPI endpoints. Most tools have descriptions (10/9 have non-empty text), but they are brief and lack the depth required for reliable LLM reasoning. All tools expose input schemas with type information, which is a strength. However, critical gaps exist: (1) parameter descriptions are present but often minimal (e.g., 'Number of records to skip' lacks range constraints); (2) output schemas are not explicitly documented in the tool definitions, they appear as Pydantic response_model annotations, not as JSON Schema accessible to MCP clients; (3) error handling is generic (HTTP 500 with bare 'Internal server error') with no recovery guidance; (4) tool naming includes a compound verb pattern ('create_new_simple_user_and_get_token') that signals multiple concerns; (5) no tool annotations (readOnlyHint, destructiveHint, idempotentHint) are visible, though risk labels are correctly assigned in the prompt. The average tool description length is ~90 characters, below the ideal 194-char baseline, and several parameters lack actionable constraints. This server is functional but falls short of production-grade LLM tooling standards.
Create a new conversation session
Create a new user and generate an access token for authentication
Create an API key for a specific LLM provider (Gemini, OpenAI, Claude)
Delete an API key
Retrieve a specific API key by ID
Retrieve all API keys for the authenticated user
Retrieve all conversation sessions for the authenticated user
Compound verb naming: 'create_new_simple_user_and_get_token' combines user creation and token generation, two distinct concerns. LLMs will struggle to decide when this tool is appropriate vs. separate create_user and generate_token tools.
Output schemas are not documented in MCP tool definitions. Response types are declared as Pydantic models (e.g., response_model=schemas.UserWithToken) but not exposed as JSON Schema accessible to MCP clients. LLMs cannot plan downstream operations without knowing what fields are returned.
Parameter descriptions lack actionable constraints. For example, 'skip' is described as 'Number of records to skip (default: 0)' but does not specify minimum (0), maximum, or what happens if skip exceeds total count. 'limit' lacks bounds (min 1, max 100 recommended).
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 56 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 0 | - | v1 |
Retrieve authenticated user information
Update an existing API key information
Error responses are generic and non-actionable. Most exceptions return HTTP 500 with 'Internal server error while [action]', no guidance on what the LLM should do next (retry, ask user, try alternative). See create_new_simple_user_and_get_token and read_users_me exception handlers.
No tool annotations visible. Tools that modify state (create_user_api_key, delete_user_api_key, create_new_session) or are read-only should declare this via tool annotations (destructiveHint, readOnlyHint). Risk labels in the prompt are noted but not registered in the MCP tool schema.
Pagination tools (read_user_api_keys, read_user_sessions) do not return total_count or next_cursor. LLMs cannot determine if more results exist and whether to fetch subsequent pages. No guidance on maximum result set (e.g., 'Returns up to 10 items').
Tool description lengths average ~90 chars, well below the production baseline of 194 chars. Descriptions lack context on WHEN to use the tool, what dependencies exist, and what the tool returns. Examples: 'Retrieve authenticated user information' (39 chars) does not explain how this differs from read_single_api_key or why an LLM would call it.