Loading ToolBench
Production-ready Vercel MCP server integrating with Atlas Monolith Agent, CRM, AgentMail, DCA, OpenClaw Gateway, and Tailscale
This server has 8 tools with schemas and descriptions visible in src/index.ts. However, there are significant quality gaps: (1) Several tool descriptions are under 100 chars and lack actionable context for LLM tool selection; (2) Most tools lack output schema documentation, only input schemas are defined; (3) Parameter descriptions are minimal or missing context; (4) Error handling patterns are not visible in the tool definitions; (5) Security-critical tools (query_crm with SQL, openclaw_execute) lack safeguard documentation; (6) No tool annotations (readOnlyHint, destructiveHint, idempotentHint) are present despite clear risk levels. The server reads as a functional baseline but lacks the LLM-optimization necessary for reliable agent composition.
Get current status of Monolith Agent and its subsystems
Execute a command through OpenClaw Gateway for infrastructure operations
Query the Atlas CRM database for customer, lead, or opportunity data
Request decision analysis from DCA (Decision Clarity for Agents) service
Send a message via AgentMail for agent-to-agent communication
Authorize a new device on the Tailscale network
SQL injection vulnerability: query_crm exposes raw SQL query parameter to LLM without documented sanitization or parameterization enforcement. 'params' array lacks schema detail, LLM cannot validate parameter order or types.
openclaw_execute is dangerously underspecified: generic 'execute' verb, no enum of allowed commands, no safeguard documentation, no audit logging mentioned, no confirmation pattern. A WRITE/IRREVERSIBLE tool that could run arbitrary infrastructure commands with zero guardrails visible to the LLM.
No output schemas documented for any tool. LLMs cannot plan downstream tool calls or extract relevant data without knowing what fields are returned. This violates the documented-return-types baseline (100% of A+ tools have documented return types).
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 57 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 47 | - | v1 |
List all devices in the Tailscale network
Revoke access for a device on the Tailscale network
No tool annotations present: readOnlyHint, destructiveHint, or idempotentHint. Despite metadata showing clear risk levels (READ_ONLY, WRITE, IRREVERSIBLE, REVERSIBLE), these are not communicated to the LLM via tool annotations.
Ambiguous parameter types and formats: 'recipientAgentId', 'deviceId', 'target' lack format specification (UUID? name? ARN? hostname?). LLMs will guess, leading to incorrect calls. 'criteria' object and 'parameters' object lack any schema detail.
Most descriptions are under 100 chars and lack LLM-optimized context: WHEN to use the tool, WHAT it returns, WHEN it's idempotent, what dependencies exist. Baseline for A+ tools is 50-200 chars with clear selection context.
No error handling or recovery guidance visible in tool definitions. No mention of rate limits, timeouts, partial failures, or how to handle retry scenarios. Pattern requires errors to tell the LLM what to do next.
No pagination or result limits documented for list/query tools. 'query_crm' can return arbitrary result sets; 'tailscale_list_devices' offers no page/limit parameters. Returning thousands of records would exhaust context and degrade LLM reasoning.
Confirmation and idempotency not documented for destructive/risky operations. 'tailscale_revoke_device' is labeled REVERSIBLE but no confirmation pattern or undo guidance. 'send_agent_mail' lacks idempotency guarantee, retrying could send duplicate messages.