doctorCheck the external Harness Host and relay policy without reading credentials, enabling safe connectivity and policy validation before task submission.
Check the external Harness Host and relay policy without reading credentials.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Changes observed during successful MCP inspections.
v0.2.18-dsh021a2.14Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is well covered. The description adds meaningful behavioral context beyond annotations, especially that it operates 'without reading credentials,' which is important for security-conscious agents. This extra disclosure makes the behavior more transparent than the schema alone.
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 a single focused sentence that front-loads the tool's purpose and includes the most critical security-related caveat ('without reading credentials'). Every word earns its place, and the title provides useful additional framing without bloating the description.
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 zero-parameter, read-only tool, the description is mostly adequate and the annotations carry the safety context. However, there is no output schema and the description does not indicate what the return payload looks like, whether it is a simple status, a policy report, or a boolean pass/fail. This missing expected-output information leaves an agent slightly uncertain about how to interpret the result.
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 tool has zero parameters and required parameters are zero, so the schema has 100% coverage trivially. There are no parameter semantics to document, and the description correctly avoids inventing meaningless parameter details. Baseline of 4 is appropriate for a no-parameter tool.
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 uses a specific verb ('Check') and identifies a clear resource ('external Harness Host and relay policy'). It also distinguishes itself from sibling setup_doctor by framing this as a verification action rather than a setup action. It loses one point because it does not state what a successful check returns or what exact conditions are being validated.
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 implies this tool is for verifying external Harness connectivity and relay policy, and the sibling name setup_doctor suggests an alternative for installation/configuration. However, there is no explicit when-to-use versus when-not-to-use guidance, and no mention of when to prefer sibling tools such as status_run or get_operation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.