easyeda_doctorDiagnoses the local MCP bridge, EasyEDA Pro extension connection, protocol compatibility, and active document context, then returns suggested next steps to resolve connection issues.
Returns a structured diagnosis of the local MCP bridge, EasyEDA Pro extension connection state, protocol compatibility, active document context, and suggested next steps.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Changes observed during successful MCP inspections.
v1.4.1Input schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"v1.0.2Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so safety is covered. The description adds useful scope beyond that by naming the five things inspected and noting it returns 'suggested next steps', but it says nothing about failure modes (e.g. what is returned when the extension is not connected), latency, or how the structured result is shaped.
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?
A single front-loaded sentence with the key noun phrase ('structured diagnosis') first and a compact enumeration of what is diagnosed. No filler, no restatement of the title.
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 input parameters and no output schema, the description carries the burden of explaining what comes back, and the enumerated diagnostic surfaces plus 'suggested next steps' do most of that work. It stops short of describing the result structure or the expected remedy path, which would close the remaining gap for a troubleshooting entry point.
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 takes zero parameters, so there is nothing for the description to disambiguate; the baseline of 4 applies. No misleading parameter language is present.
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?
States a specific verb and resource: it 'returns a structured diagnosis' and enumerates the diagnosed surfaces (local MCP bridge, EasyEDA Pro extension connection state, protocol compatibility, active document context, suggested next steps). An agent can tell this is a health-check tool, but the description never distinguishes it from overlapping siblings such as easyeda_live_status and easyeda_get_context.
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?
Use is only implied by the diagnostic framing (call it when the bridge or extension state is in question). There is no explicit when-to-use, when-not-to-use, or 'prefer this over easyeda_live_status / easyeda_get_context' routing guidance, which matters given how many sibling tools report related state.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.