This server registers 4 tools with complete Zod schemas and descriptions. Naming follows verb_noun patterns (check_intent, expand_intent, review_action, list_actions). However, definitions have moderate gaps: descriptions are functional but generic (111-156 chars), parameter descriptions lack context about expected formats and constraints, and output schemas are undocumented. The tools proxy requests to an external API and return JSON blobs as text, which bypasses structured output patterns. Error handling returns JSON blobs on failure but provides minimal recovery guidance. No tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite all tools being read-only. Security is moderate, no secrets in params, but no audit logging or permission gates visible. Tool composition is sound (each does one thing), but the lack of output schema documentation and minimal error guidance push the score into the C/D range.
Tools (4)
check_intentread onlysource verified75/100
Pre-flight safety check before an autonomous agent executes an action. Returns risk level, risk factors, and a checklist of safety considerations.
expand_intentread onlysource verified75/100
Surface implied requirements from a human instruction that an autonomous agent might miss. Returns categorized requirements with confidence scores.
list_actionsread onlysource verified62/100
List all action types with safety checks, grouped by domain. Free endpoint — no payment required.
review_actionread onlysource verified75/100
Post-action verification checklist after an autonomous agent completes an action. Returns verification items to confirm the action was safe and correct.
Output schemas are not documented. All tools return JSON responses from an external API as plain text in a content field, but the LLM cannot see what fields will be in that JSON. Tools should document their response structure so agents can extract data reliably.
Parameter descriptions lack format and constraint details. For example, 'action' is described as 'Short action identifier (e.g. delete_records, send_email)' but does not specify minimum/maximum length, allowed pattern, or what happens if the action is invalid. Similar issues for 'description' and other string params.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite all tools being read-only safety checks. Adding readOnlyHint: true would help agents understand these tools are safe to call speculatively without side effects.
check_intent
Recommendations
Document the output schema for each tool. For example, check_intent should specify: 'Returns an object with fields: risk_level (string: low|medium|high|critical), risk_factors (array of strings), checklist (array of objects with title and description).' This enables agents to extract and reason about the response.
Add minimum/maximum length constraints and format patterns to string parameters. E.g., 'action: 2-50 characters, alphanumeric and underscores, e.g. delete_records, send_email' and 'description: 10-500 characters, natural language description of the intended action'.
Add readOnlyHint: true to all 4 tools via the MCP SDK. Since these are safety checks with no side effects, agents can call them speculatively. Example: server.tool(..., { readOnlyHint: true }, async ({...}) => {...})
Enhance error handling to include recovery guidance. When API returns 4xx error, return: { content: [{type: 'text', text: 'API returned error: <message>. Ensure action and description are valid strings 2-500 characters. If the issue persists, the safety check service may be unavailable.'}], isError: true }. When timeout occurs, suggest: 'Request timed out. The safety check service is slow or unreachable. Retry in a moment or try a different action type.'
Add brief documentation for the domain enum. Example: domain parameter description: 'Business domain for targeted safety checks. Use database for CRUD operations, communications for email/messaging, file_system for file operations, deployment for CI/CD, financial for billing/payments, user_management for user/auth changes, api for API calls, content for web/document changes, commerce for orders/checkout, infrastructure for cloud/network changes. Optional, omit if domain is unclear.'
Error responses provide minimal guidance for recovery. When a fetch fails or API returns an error, the tool returns a JSON blob with 'error' and 'message' fields but does not suggest what the agent should do next (retry? try a different action? contact support?). Agents have no actionable path forward.
The 'domain' enum is underspecified. It lists 10 values but does not explain when or why to use each. 'financial' is clear, but 'api' and 'infrastructure' are ambiguous, does an API call fall under 'api' or 'deployment'? A description for the domain param and brief enum documentation would improve clarity.
check_intentexpand_intentreview_action
Consider wrapping API responses with JSON.parse and validation. Currently, the tool returns the raw API JSON as a text blob. If the API response format is known, validate and structure it (e.g., extract risk_level, risk_factors, checklist as separate fields) so agents can reason about specific fields.
Add timeout/retry logic. Currently, setTimeout + AbortController aborts at 10s and returns a generic 'request_failed' error. Wrap this in retry logic: on first timeout, retry once with exponential backoff; if second attempt times out, return a clear message and suggest trying again later.
Document dependencies between tools. E.g., expand_intent returns categorized requirements, does check_intent use those categories? If so, the description could say: 'Call expand_intent first to understand all requirements, then call check_intent to verify safety for each requirement.'
For list_actions, describe what the response contains and when to call it. Currently, the description says 'List all action types with safety checks, grouped by domain' but does not explain the response structure. Consider: 'Lists all supported action types and their associated safety checks, grouped by domain. Response includes action names, descriptions, recommended domain categorization, and associated risk levels. Call this first to discover available actions if you are unsure what to check.'
Add example outputs (not values, but structure) in tool descriptions. E.g., check_intent description could mention: 'Returns risk_level (low|medium|high|critical), risk_factors (list of concerns), and a checklist (list of verification items).' This helps agents understand what they will get back without guessing.