Loading ToolBench
MCP server providing compliance and content guardrail checking capabilities for agent-generated content
This server exhibits critical failures across nearly all definition quality dimensions. The single tool 'execute_skill_action' has a minimal description (51 chars), a basic input schema with only one parameter, no documented output schema, and no error handling guidance. The implementation itself is non-functional, the mcp_server.py file only prints a hardcoded JSON response and never actually processes MCP protocol messages or invokes the client. The tool registration appears to be hardcoded in the startup message rather than properly registered via the MCP protocol. This is a demonstration/skeleton implementation, not a production-ready server.
Execute compliance and content guardrail checking on provided text
Tool description is minimal and lacks context for LLM decision-making. At 51 characters, it provides no guidance on WHEN to use this tool, WHAT it returns, or HOW it differs from other content validation approaches. Baseline for A-grade tools is 50 - 200 chars with explicit WHAT/WHEN/WHY framing.
Input schema lacks type definitions for the 'text' parameter. While the parameter name is present with a basic string type, the schema contains no constraints (min/max length, format, examples of valid/invalid input) or guidance on what content violations the tool detects (spam, profanity, PII, etc.). Parameter descriptions must state expected format, range, and constraints explicitly.
No documented output schema. LLMs cannot plan downstream actions or extract results without knowing what fields to expect. The client.py stub returns {'passed_filters': ...} but this structure is not declared in the tool definition, and there is no specification of what values 'passed_filters' can take, what additional fields may be returned, or what error responses look like.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 25 | 2026-07-28+ | v2 |
No error handling or recovery guidance. The tool definition contains no documentation of failure modes (invalid input, service unavailable, etc.) or what the LLM should do if the tool fails. Production tools must include error-classification (retryable vs user-fixable vs fatal) and actionable guidance.
Tool name 'execute_skill_action' is overly generic and does not clearly convey the compliance/guardrail checking action. Names like 'check_compliance' or 'validate_content_compliance' would be more specific and help LLMs infer intent from the name alone (pattern baseline: 90% of A+ tools start with a specific action verb like get_, check_, validate_).
Implementation is non-functional. The mcp_server.py script does not implement the actual MCP protocol, it only prints a hardcoded startup message and exits. There is no message loop, no request/response handling, no actual invocation of the client.check() method, and no protocol message serialization. This is a skeleton stub, not a working MCP server.