Static source inference · medium confidence · detected: Logging
Deprecated protocol patterns detected
Summary
The MCP-Atlas Agent Environment is a meta-layer that wraps 36 external MCP servers and exposes them through 6 management tools. The tool definitions are minimal and generic. Tool schemas are present but descriptions are sparse and lack LLM-optimization guidance. Most critically, the tools operate as proxies with dynamic payloads (tool_args is an untyped object), which violates the principle that each tool should do exactly one thing. The descriptions fail to provide actionable context for when/why to use each tool. Parameter descriptions are largely absent. Error handling guidance is minimal. Security considerations around arbitrary tool invocation are not addressed in the schema.
Tools (6)
call-toolwriteauth42/100
Call a specific tool with the provided arguments. Supports response caching for whitelisted servers.
clear-cachewrite50/100
Clear the entire cache
get-cache-statsread only50/100
Get cache statistics for monitoring
get-enabled-serversread only50/100
Get list of configured MCP servers with their status (OK or ERROR_NOT_ONLINE)
healthread onlysource verified63/100
Simple health check that verifies client is also ok. Timeout is 5 seconds.
call-tool accepts untyped 'tool_args' object parameter with no schema constraints, allowing arbitrary and potentially malicious payloads to be forwarded to wrapped servers. This violates input validation and security boundaries.
Parameter descriptions are largely absent or minimal. 'tool_name' in call-tool has a description but 'tool_args' lacks guidance on what structure it expects, forcing LLMs to guess.
Tool descriptions are under-specified for LLM optimization. Average should be 194 chars (rubric baseline); most descriptions here are 30-60 chars. E.g., 'List all available tools from the MCP server' (46 chars) lacks context on WHEN to call it or what the LLM should do with the result.
list-toolsget-cache-statsclear-cachehealth
Recommendations
Refactor call-tool: instead of a single meta-tool accepting arbitrary tool_args, expose each wrapped tool directly with its own schema and description. This follows single-responsibility and makes each tool self-documenting. If 36 servers is too many to list statically, consider a discovery tool (list-tools already does this) and client-side registration.
Expand tool descriptions to 100-200 characters (baseline: 194 chars). Include context on WHEN to call the tool and WHAT the result means. Example: 'Retrieve a list of all MCP servers currently registered in this agent environment. Call this first to understand available capabilities before invoking call-tool.'
Add per-parameter descriptions and type constraints. For call-tool's tool_args, specify: 'An object containing the arguments required by the specified tool. Structure depends on the tool's input schema (retrieve via list-tools). Required fields vary by tool.'
Document side-effects and state changes. Mark clear-cache as destructive and explain potential race conditions with concurrent tool calls. Mark call-tool's behavior when use_cache=true vs false.
Add error recovery guidance. For example: 'If call-tool returns "tool not found", call list-tools() to verify the tool exists and the name matches exactly. If a server is offline, call get-enabled-servers() to identify which servers have status ERROR_NOT_ONLINE.'
Implement tool annotations in the schema: tool definitions should include readOnlyHint (true for list-tools, get-cache-stats, get-enabled-servers, health; false for call-tool, clear-cache) and destructiveHint (true for clear-cache, false for call-tool if the wrapped tool is non-destructive). Add idempotentHint where appropriate (health, get-* tools are idempotent).
Spec posture evidence
Inferred effective spec: <=2025-11-25.
Relies on Logging (deprecated) - log to stderr or use OpenTelemetry
call-tool is a meta-tool that violates single-responsibility principle. It accepts arbitrary tool names and arguments, making it a generic proxy rather than a well-defined tool. This forces the LLM to compose the correct tool_name and schema at runtime, increasing error likelihood.
No error handling guidance in tool descriptions. When call-tool fails (e.g., invalid tool_name, wrong tool_args schema), the LLM has no hint on recovery steps. E.g., 'If tool not found, call list-tools() first' should be in the description.
clear-cache has no description explaining side effects. Agents need to know this modifies state and may impact concurrent operations. The description should state: 'Clears all cached results from whitelisted MCP servers. This is a destructive operation; use with caution in multi-agent environments.'
get-enabled-servers description mentions 'ERROR_NOT_ONLINE' status but does not explain what conditions trigger this or what the LLM should do if servers are offline. Should include: 'If a server shows ERROR_NOT_ONLINE, it is not currently reachable. Call health() to verify the agent-environment itself is online.'
No tool annotations (readOnlyHint, destructiveHint, idempotentHint) in the schema. These are current-spec features (2026-07-28) that help clients understand side-effects and caching. call-tool should be marked destructiveHint: false/true depending on the wrapped tool; clear-cache should be destructiveHint: true.
call-toolclear-cache
Document the caching strategy explicitly. The description of call-tool should explain: 'When use_cache=true (default), results for the same tool_name and tool_args are cached for whitelisted servers. Cache TTL and server whitelist are server-configured. Call get-cache-stats() to monitor cache hit rates and clear-cache() to flush all cached results.'
Add validation and error messages. When call-tool receives an invalid tool_name, return a structured error: 'Tool "xyz" not found. Call list-tools() to see available tools: [list]'. Include the available tool names in the error response so the LLM can self-correct.
Separate health check concerns. The health tool checks both agent-environment and client. Consider splitting into two tools: health-environment (checks agent-environment only) and health-roundtrip (checks client via a 5-second timeout). This allows independent monitoring.
Document the use_cache parameter better. Specify: 'When true (default), return cached results if available for the same tool_name and tool_args. When false, always fetch fresh results. Cache is managed server-side and shared across concurrent requests. Use false when results must be current (e.g., real-time data).'
Add examples (outside descriptions, in documentation or OpenAPI extensions). Show sample call-tool requests with real tool names and expected tool_args structures for 2-3 common use cases (e.g., list-tools call, a read-only tool, a write tool with cache usage).
Implement request-scoped _meta logging level support (current spec feature). Allow callers to request DEBUG or TRACE logging via _meta.io.modelcontextprotocol/logLevel to troubleshoot tool invocations without server-side config changes.