Loading ToolBench
A monorepo containing multiple MCP servers for incident management: mcp-logs for searching service logs and requesting restarts, and mcp-slack for posting messages and reading recent messages from Slack channels.
Server has 4 tools with basic schemas and descriptions. All tools have input schemas with Zod validation and descriptions present. However, descriptions are minimal (10-60 chars), parameter descriptions lack detail on constraints and use cases, and output schemas are undocumented. No error handling guidance, no parameter enums despite constrained inputs (e.g., service names), and no security annotations. Tools are well-named with action verbs (search_, request_, post_, read_) but lack the depth expected for production use. Fixture-backed logs and Slack integration are functional but lack robustness patterns.
Post a message to a Slack channel
Read recent messages from a Slack channel
Request restart for a service (should be policy-gated)
Search logs by service + pattern (fixture-backed)
Descriptions are too brief (10-60 chars) and lack context on when/why to use each tool. LLMs cannot distinguish between search_logs and read_recent_messages without richer guidance.
No output schemas documented. Callers cannot predict response structure (e.g., does search_logs return an array or object? What fields?). Forces LLMs to guess.
Parameter descriptions lack constraint details. 'service' param has no enum or validation guidance; 'pattern' has no length/format constraints; 'channel' accepts any string without validation.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 52 | 2026-07-28+ | v2 |
No error handling guidance. If search_logs finds no matches, if request_restart fails due to policy, or if post_message hits rate limits, the LLM receives no recovery hints.
request_restart is a destructive operation but lacks confirmation/dry-run pattern. No idempotentHint or destructiveHint annotations. Agents could restart services unintentionally.