Loading ToolBench
MCP server for Limbi, an omni-agent orchestration platform with 87 specialized AI agents for DevOps, Git, Jira, AWS, and multi-domain automation.
Limbi MCP server has 13 tools with basic schemas and descriptions, but significant quality gaps. Most tools have descriptions (10-50 chars, below the 50-200 char baseline for LLM optimization), and input schemas are present but minimal. Parameter descriptions are sparse or missing entirely. No tool annotations (readOnlyHint/destructiveHint). Error handling is not evident in the code sample. Tool naming follows verb_noun convention (limbi_health, limbi_list_agents, approval_agent__create_request), but some names are overly prefixed (approval_agent__* pattern is verbose). No output schema documentation visible. The tool_builder_agent tools are self-referential (generating specs for other tools) rather than domain-focused, which is unusual for an MCP server.
Build an approval policy with name and rules.
Create an approval request with title, risk level, and approvers.
Evaluate whether an action requires approval based on risk factors.
Record an approval decision for a request.
Summarize the approval request queue with counts by status.
Return Limbi backend and registry health information.
List all registered Limbi agents and their actions.
Use the Limbi router agent to classify and route a natural-language query.
Descriptions are too short (10-50 chars vs. baseline 50-200 chars). LLMs cannot determine when/why to select tools. Examples: 'Return Limbi backend and registry health information' (52 chars), 'List all registered Limbi agents and their actions' (50 chars). Add context on WHEN to call, WHAT it returns, and any prerequisites.
No output schemas documented. Tools return dict[str, Any] with no specification of fields, types, or structure. LLMs cannot plan downstream calls or extract required data. Example: limbi_route_query returns results but structure is undocumented.
Inferred effective spec: 2025-06-18+.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 39 | 2025-06-18+ | v2 |
Generate an OpenAPI stub for a tool endpoint.
Generate a tool specification with name, purpose, input/output schemas, and safety notes.
Return common tool patterns and their best use cases.
Scaffold a function implementation for a tool in the specified language.
Validate a tool contract JSON for required fields and structure.
Parameter descriptions are missing or minimal. 'inputs' and 'outputs' in tool_builder_agent__generate_tool_spec lack detail on expected structure. 'contract_json' in validate_tool_contract has no format guidance. LLMs cannot infer parameter meaning from names alone.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint). Risk field is present in metadata but not exposed as MCP tool annotations. Agents cannot determine which tools are safe to retry or have side effects.
Tool naming uses verbose agent-prefixed convention (approval_agent__create_request vs. create_approval_request). Underscores in names reduce clarity. Consider flattening to verb_noun pattern: create_approval, record_decision, build_approval_policy.