Code MCP Server

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden of behavioral disclosure but offers minimal information. 'Operations and information' implies both read and write capabilities, but doesn't specify which actions are destructive (like 'prune') versus informational (like 'info', 'version'). No context about permissions, side effects, rate limits, or what happens during execution is provided. The description doesn't compensate for the lack of annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise at just 5 words, with zero wasted language. It's appropriately sized for what it attempts to communicate, though it's under-specified rather than truly concise. The structure is simple and front-loaded, though it lacks the detail needed for effective tool selection.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with 4 parameters, no annotations, and no output schema, the description is inadequate. It doesn't explain what 'system operations' encompasses, what information is returned, or how this tool differs from other Docker tools. The description fails to provide sufficient context for an agent to understand when and how to use this tool effectively, especially given the rich ecosystem of sibling Docker tools.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema description coverage is 100%, so all parameters are documented in the schema itself. The description adds no parameter-specific information beyond what's already in the schema properties. It doesn't explain the relationship between parameters (e.g., how 'all', 'volumes', and 'force' interact with different 'action' values). Baseline score of 3 is appropriate since the schema does the heavy lifting.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description 'Docker system operations and information' is a tautology that essentially restates the tool name 'docker_system'. It provides a vague category ('operations and information') but lacks a specific verb-resource combination that clarifies what this tool actually does. It doesn't distinguish this tool from sibling Docker tools like docker_containers or docker_images.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance about when to use this tool versus alternatives. There are multiple Docker-related sibling tools (docker_build, docker_containers, docker_images, docker_networks, docker_volumes, docker_compose, docker_run, docker_cleanup), but the description offers no context about which system-level operations belong here versus in other tools. No explicit when/when-not guidance or alternative recommendations are provided.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.