Connect to a local Harness Web instance, starting it in the background if offline, to enable session reuse without duplicating unauthenticated services.
Connect to existing local Harness Web, or start it in background if offline. Never duplicates an unauthenticated existing service. Run this first. No model call.
| Name | Required | Description | Default |
|---|---|---|---|
| auto_start | Yes |
Changes observed during successful MCP inspections.
v0.3.1Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden and does disclose a side effect (starting a background process), a safety property (never duplicating an unauthenticated existing service), and the fact that no model call occurs. It does not cover output, errors, or permissions, but it provides meaningful behavior beyond the schema.
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?
Four short sentences, with the core behavior front-loaded and the key constraint stated directly after. Every sentence earns its place and there is no filler.
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?
The description is adequate for a simple connect step: it states purpose, ordering, and a key invariant. However, it omits any mention of return values, failure modes, or how auto_start=false behaves, and there is no output schema to fill those gaps.
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 only parameter, auto_start, is never named or explicitly explained. The phrase 'start it in background if offline' implies what auto_start=true does, but it says nothing about auto_start=false, and schema description coverage is 0%, so the description does not compensate for the missing schema documentation.
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 names a specific action ('Connect') and a specific resource ('local Harness Web'), and clarifies the fallback behavior of starting it in the background. The 'Run this first' note and the no-duplication rule help distinguish it from session-management siblings even though no sibling is named.
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?
It gives explicit sequencing guidance ('Run this first') and tells the agent this tool makes no model call, which is useful for deciding when to invoke it. It does not explicitly list alternatives or exclusion conditions, but the context is clear enough for a setup step.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.