Loading ToolBench
SuperOps.ai MCP server for Claude with decision tree tool loading
The SuperOps MCP server defines 3 tools with basic structure but significant quality gaps. Tool naming follows verb_noun convention (superops_navigate, superops_status, superops_test_connection), which is correct. However, descriptions are minimal (averaging ~50-60 chars), input schemas are extremely sparse with no parameter validation, and output schemas are completely undocumented. The server provides no error handling guidance, field-level documentation, or composition hints. The tools appear to be discovery/status helpers rather than domain-specific operations, and the actual domain tools (clients, tickets, assets, technicians, custom) are lazy-loaded but not visible in the provided source code, only their existence is inferred from the loadDomain() switch statement. This caps evaluation at what can be verified in the provided code.
Discover available SuperOps.ai tools by domain. Returns tool names and descriptions for the selected domain. All tools are callable at any time — this is a help/discovery aid, not a prerequisite.
Show credentials status and available domains
Test the connection to SuperOps.ai API using configured credentials.
superops_status and superops_test_connection have empty or missing input schemas. Both tools accept no parameters (properties: {}, required: []), which is correct, but there is NO documented output schema. LLMs cannot predict what fields these tools return, forcing them to guess or call them blindly.
Tool descriptions are too short and lack context. 'Show credentials status and available domains' (48 chars) does not explain what 'available domains' means, what the output structure is, or when to call this vs other tools. 'Test the connection to SuperOps.ai API using configured credentials' (68 chars) lacks guidance on what 'test' entails (which GraphQL query? what does success look like?). Descriptions should be 50-200 chars and answer WHAT, WHEN, and WHY.
No error handling or recovery guidance. If superops_test_connection fails, LLMs receive no guidance on whether to retry, check credentials, or contact support. If superops_navigate returns an unknown domain, there is no recovery path documented. Error responses must guide the LLM to the next action.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 56 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 49 | - | v1 |
Domain tools (clients, tickets, assets, technicians, custom) are lazy-loaded but NOT visible in the provided source code. Only their existence is inferred from the loadDomain() switch statement. Cannot verify that these tools have proper schemas, descriptions, or error handling. Per hard scoring rules, inferred tools are capped at 50. Production evaluation would require examining src/domains/*.ts files.
superops_navigate input schema documents the 'domain' parameter with an enum, which is good. However, the description of the enum values is stuffed into a single multi-line string within the parameter description, making it hard for LLMs to parse. Better: separate descriptions for each enum value, or use a JSON Schema 'examples' field.
No documented output schemas. None of the three visible tools declare what fields they return. LLMs cannot plan downstream operations or extract specific values.
superops_navigate is described as a 'help/discovery aid', but no guidance on when an LLM should call it. Should it be called before every domain-specific operation? Or only once at the start? This ambiguity forces the LLM to guess and risks calling unnecessary discovery tools.