check_debug_server

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

N annotations are provided, so the description bears the behavioral disclosure burden. It does convey a useful behavior: the server must already exist and no debugger UI is registered. It does not disclose return values, error behavior, or whether any connection state is created, but the 'check' wording reasonably implies a non-mutating operation.

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 one concise sentence, properly front-loaded with the action and resource, and contains no repeated or unnecessary information. For a simple two-parameter tool, this is appropriately sized.

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?

With no annotations and no output schema, the description needs to explain what a 'check' returns or reports, such as success/failure, status details, or error behavior. The current description tells the agent what to call but not what to expect back, leaving important context missing.

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 only provides types and bounds for host and port, while the description adds the context that these identify an HTTP debug server. This adds some meaning beyond the schema, but it does not provide any parameter-specific detail beyond that, so the compensation for the 0% schema description coverage is only partial.

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 clearly identifies the action ('Check') and the resource ('existing 1C HTTP debug server'), and the modifier 'without registering a debugger UI' helps distinguish it from sibling tools like connect_debuger. However, 'check' is somewhat generic and could be more explicit about whether it means availability, connectivity, or configuration status.

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 phrase 'existing server without registering a debugger UI' implies the tool is for lightweight verification rather than full debugger attachment. It does not explicitly name alternatives or provide clear when-to-use/when-not-to-use guidance, so the agent must infer the intended scenario.

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