This MCP server exposes 4 tools with significant quality gaps. Tool definitions lack comprehensive schema documentation, parameter descriptions are sparse or missing critical details, and descriptions are generic without actionable guidance for LLM selection. The server appears to be a workflow orchestrator with tools for calling other MCP servers, inspecting media, and sending HTTP/WebSocket requests, architecturally interesting, but the tool definitions fall well short of production quality. No error handling guidance is visible. Transport mechanism is UNKNOWN, which severely limits evaluation.
Tools (4)
call_toolwrite45/100
Call an MCP server tool with specified arguments
inspect_mediaread only50/100
Inspect media files using exiftool to extract metadata including file size, dimensions, duration, creation date, camera information, and GPS data
send_http_requestwrite47/100
Send HTTP request to a server and optionally wait for completion via polling or callback
websocket_send_receivewrite50/100
Send and receive messages over WebSocket connection with support for streaming, collecting, or single message receive
CRITICAL: Credentials and authentication mechanism unclear across all HTTP/WebSocket tools. No evidence of server-side secret injection; 'headers' parameter in send_http_request likely exposes Authorization tokens to agent logs.
Tool descriptions are too generic and lack LLM-selection guidance. 'Call an MCP server tool' and 'Send HTTP request' do not answer: when should I use this tool? What is it better at than alternatives? What are prerequisites?
Parameters lack type constraints and validation guidance. 'method' in send_http_request accepts any string; should be enum [GET, POST, PUT, DELETE, PATCH, HEAD, OPTIONS]. 'format' in websocket_send_receive lacks description of its effect.
send_http_requestwebsocket_send_receive
Recommendations
Add explicit enums to send_http_request.method: ['GET', 'POST', 'PUT', 'DELETE', 'PATCH', 'HEAD', 'OPTIONS']. Add minimum/maximum for numeric query params and request body size.
Document return schemas for all tools. Include field names, types, and whether fields are always present or conditional. For inspect_media, document the structure of 'metadata' field and what top-level keys are always returned.
Rewrite tool descriptions to be LLM-optimized (50-200 chars) and answer: (1) What does this tool do? (2) When should I use it instead of similar tools? (3) What does it return? Example for send_http_request: 'Send HTTP requests to external APIs and extract results via JSONPath. Use this for REST APIs; use websocket_send_receive for persistent connections. Returns response body, status code, and headers.'
Add recovery guidance to error scenarios. Document: (a) which errors are retryable (network timeout, 429 rate limit); (b) which are user-fixable (404 not found, invalid parameters); (c) which are fatal (5xx server errors, auth failure). Provide actionable hints like 'If method is GET but you have a body parameter, try POST instead.'
For send_http_request and websocket_send_receive: explicitly state whether Authorization headers are injected server-side or expected in the 'headers' parameter. If passed as params, document that secrets should NEVER be used with these tools. If server-injects, document the secret sources (environment variables, vault, etc.).
Split websocket_send_receive into two tools: (a) websocket_send_message(path, message, headers, params) → {status, message_id}; (b) websocket_receive_messages(path, format, timeout, collect) → {messages: []}. This enables agents to compose send→receive workflows explicitly.
Output/return schemas are not documented. Tools return data but no schema is visible, LLMs cannot plan downstream use or extract the right fields. This violates the pattern that documented schemas enable tool chaining.
No error handling guidance. Tools provide no recovery instructions. If send_http_request times out, or websocket_send_receive fails to connect, what should the agent do? Retry? Use a different tool? Inform the user?
websocket_send_receive combines 'send' and 'receive' into one tool, violating single-responsibility. Should be split: websocket_send_message and websocket_receive_message, allowing agents to compose them independently.
call_tool parameter 'arguments' accepts 'object' with no shape constraints. This is a catch-all that invites hallucinated argument structures. Should document expected schema or accept typed parameters per tool.
inspect_media lacks enumeration of supported formats. Description mentions 'media files' but does not say: does it support MP4, PNG, WEBP, FLAC, WAV, etc.? What happens if you pass an unsupported type?
inspect_media
Add per-source error reporting to inspect_media. Return: [{path, status: 'success'|'error', metadata: {...}}, {path, status: 'error', error_code, error_message: '...'}]. This lets agents know which files failed vs succeeded and why.
For call_tool, document the expected 'arguments' object structure or create overloaded variants: call_tool(tool_name, json_arguments) for flexibility, but also add typed tool-specific wrapper functions. Alternatively, require tool_name → schema lookup before call to validate arguments.
Add rate-limit and timeout parameters to send_http_request (timeout_seconds: 30, max_retries: 3) and document defaults. Add timeout_seconds to websocket_send_receive with explicit guidance: 'Timeout in seconds for receiving messages (5-300). If 0, wait indefinitely.'
Add permission/scope declarations to each tool. Example: send_http_request requires 'network:write'; inspect_media requires 'files:read'; websocket_send_receive requires 'network:write'. This enables least-privilege agent configuration and audit trails.