Loading ToolBench
MCP server for managing todos with create, update, and list functionality, integrated with AWS Bedrock LLM and Okta authentication
This MCP server has critical deficiencies across all dimensions of tool quality. While tools have names and basic descriptions, the implementation shows severe gaps in parameter definition, schema clarity, and LLM usability. The server appears to be a demo/example implementation rather than production-grade. Key issues: (1) Tools 6 and 7 (add_todos, update_todos) have NO visible input schema properties despite declaring required parameters, schema extraction fails entirely. (2) Multiple descriptions are vague or misleading (e.g., update_todos says 'Update status of todos' but actually requires id and todoStatus with no explanation of what these mean). (3) Parameter descriptions are almost entirely missing, LLMs cannot infer what 'todoStatus' should be (boolean? string? enum?). (4) Tool names are inconsistent: create_reminder vs add_todos (mix of past-tense and plural). (5) No output schema documentation visible for any tool. (6) No error handling or recovery guidance. (7) The tool descriptions do not follow the 'WHAT-WHEN-WHY' pattern needed for LLM selection.
Add new todos and it requires a name of todo as string
Create a new reminder with a title
Fetch a list of all todos from the API, show only incompleted task unless asked otherwise
Print all environment variables available to the server
Update a reminder's status
user may ask you to tick it off or get off my plate or Update status of todos requires id and status, convert todoStatus to true or false when calling the tool
Greet the user with a welcome message to Okta
Tools add_todos (tool #6) and update_todos (tool #7) declare required parameters ('todoName' and 'id', 'todoStatus') but have empty input schema properties ({}). This is a critical contradiction, the schema cannot validate or document what the LLM should pass. Pattern:tool requires schemas with explicit types and descriptions.
Parameter 'todoStatus' in update_todos (tool #7) lacks any description. LLMs cannot infer whether this should be a boolean, string enum ('pending'/'complete'), or numeric status code. The tool description says 'convert todoStatus to true or false' but the schema provides no type or enum, mixing implicit boolean with string identifiers.
Parameter 'todoName' in add_todos (tool #6) is mentioned in the required array but missing from the schema properties entirely. Without a type annotation or description, LLMs cannot determine the expected input format, max length, or constraints.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 49 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 0 | - | v1 |
Tool descriptions lack the WHAT-WHEN-WHY pattern. E.g., update_todos says 'user may ask you to tick it off or get off my plate or Update status of todos...' which reads as a comment, not a tool description. Descriptions should explicitly state WHAT the tool does, WHEN to use it instead of similar tools, and what it returns. Baseline: 194 chars average, this server ranges 20-80.
No output schema is documented for any tool. LLMs cannot plan downstream tool calls or extract required fields without knowing the response structure. Pattern:tool-description requires documenting what fields are returned and their types.
Tool naming is inconsistent: create_reminder vs add_todos (mix of verb_noun and verb_plural). Also, 'welcome_to_okta' is unusual, reads like a greeting, not an action. Names should start with clear action verbs (get_, list_, create_, update_) to help LLMs infer intent from the name alone.
Parameter 'userName' in welcome_to_okta is marked as optional (not in required array) but the description says 'optional', redundant and confusing. Additionally, the tool's purpose (greeting) does not align with the MCP principle that tools should be composable, stateless operations that enable agent workflows. A greeting tool is typically cosmetic, not agent-actionable.
No error handling or recovery guidance. For example, list_todos says it 'show[s] only incompleted task unless asked otherwise' but provides no schema clarification (boolean flag? string filter?) and no error response guidance if the API fails. Pattern:recovery-guide requires error responses to tell the LLM what to do next.
Tool 'print_env_variables' exposes environment variables, which may include secrets (API keys, tokens). Pattern:secret-injection forbids credentials in tool parameters, and by extension, tools should not directly expose secrets in responses. This tool needs access controls and output filtering.