Loading ToolBench
MCP server for Nora — deploy, monitor, and operate self-hosted OpenClaw and Hermes agent fleets on Docker or Kubernetes.
The Nora MCP server exhibits severe quality gaps across all definition dimensions. Tool definitions are sourced from a static .mcp.json file (mcp-server/copilot-plugin/.mcp.json) rather than explicit TypeScript registration, meaning tool presence is inferred rather than directly visible in runnable code. Descriptions are uniformly minimal (8-40 chars), parameter schemas are absent or skeletal, and output schemas are undocumented. No error recovery guidance, no actionable error messages, and no security annotations. The server is READ_ONLY across all tools (positive signal), but the definitions lack the rigor expected for even basic agent integration.
Get details of a specific agent
Get cost information for a specific agent
Get detailed metrics for a specific agent
Get a summary of metrics for a specific agent
Get statistics for a specific agent
Get version history of a specific agent
Get overall status of the agent fleet
Tool definitions inferred from static .mcp.json rather than explicit TypeScript registration. Tool presence cannot be verified in the source code, tool names and schemas are declared in a configuration file, not visible in the MCP server handler code. Per hard scoring rule, all tools must be capped at 50 overall.
Descriptions are uniformly minimal (8-40 characters): 'List all agents in the fleet' (29 chars), 'Get details of a specific agent' (31 chars), 'Get statistics for a specific agent' (34 chars). All descriptions fall far below the 50-200 char baseline for LLM-optimized tools. Per hard scoring rule, descriptions under 20 chars score 0-20; descriptions under 50 chars without context typically score 20-40.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 42 | 2026-07-28+ | v2 |
Get platform-level metrics
List all agents in the fleet
List monitoring events
Input schemas for parameterized tools (get_agent, get_agent_stats, get_agent_versions, get_agent_metrics, get_agent_metrics_summary, get_agent_cost) declare only agent_id with minimal description ('The agent ID'). No validation rules (format, pattern, length), no guidance on how to obtain an agent_id, no error recovery hints ('Try list_agents() first'). Per hard scoring rule, schemas without type definitions cannot exceed 30; single-field schemas with no constraints score near 10.
Output schemas are completely undocumented. No field-level descriptions, no type declarations, no indication of what list_agents returns (array of objects? what fields?), what pagination/count fields are included, or what format dates use (ISO 8601, Unix timestamps, human-readable?). LLMs cannot plan downstream calls or extract relevant data without documented output structure.
No error handling guidance. No tool response documents what happens if agent_id is invalid, if metrics are unavailable, or how an agent should self-correct. LLMs receive raw API errors (404, 500) with no recovery hint.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint). While all tools are READ_ONLY, this is not declared in the schema. Clients cannot automatically determine tool safety profile.
list_agents and list_monitoring_events lack pagination parameters (limit, offset, page_size, cursor). Large result sets will blow the context window. No indication if results are capped or how many total results exist.
Tool names reveal minimal context about what metrics/stats/cost represent. 'get_agent_metrics' vs 'get_agent_stats' vs 'get_agent_metrics_summary' are confusingly similar. LLMs will conflate them. The distinctions (raw vs summarized, all metrics vs specific stats, cost metrics) should be explicit in names or descriptions.