easyeda-mcp-pro

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.19.1
Disambiguation4/5
Most tools have clearly distinct purposes, but there are some pairs (e.g., connect_pin_to_net vs connect_pins_by_net, drc_run vs erc_run) that could cause minor confusion for an agent. The overall high specificity helps maintain differentiation.
Naming Consistency5/5
All tools consistently use the 'easyeda_<category>_<action>' snake_case pattern, making it easy for an agent to infer function from the name. No mixing of conventions.
Tool Count3/5
With 70 tools, the server is on the heavier side. While the domain (EDA/PCB design) is complex and requires many operations, the sheer number may overwhelm agents and increase selection difficulty. Still within plausible bounds for a comprehensive toolset.
Completeness5/5
The tool surface covers nearly all facets of PCB design: schematic editing, board layout, BOM management, design rules, production review, and even transaction management. Only niche features might be missing, but core workflows are fully supported.
Average 3.8/5 across 70 of 70 tools scored. Lowest: 2.4/5.
See the Tool Scores section below for per-tool breakdowns.
- 49 of 52 community issues answered or closed in the last 6 months
- 395 commits in the last 12 weeks
- Last stable release on August 28, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds minimal behavioral context beyond the annotations. Annotations indicate it is idempotent and not destructive, but the description does not explain side effects, state changes, or file generation behavior. The description does not contradict annotations, so no contradiction flag.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief (one sentence), but it is too minimal given the tool's complexity. It is front-loaded with the action but lacks structure or details. Conciseness should not sacrifice completeness, so it scores a 3.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is insufficient for the tool's complexity. It fails to explain what Gerber files are, how the export works, what the parameters do, or how the output is provided. An output schema exists but is not referenced. The description is incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 6 parameters with 0% description coverage. The description provides no information about any parameter, including the required projectId. Therefore, it fails to add meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Export', the resource 'PCB design to Gerber files', and the purpose 'for PCB fabrication'. It distinguishes from sibling tools, as no other tool focuses on Gerber export. However, it could be more precise about what Gerber files are, but it's effective.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidelines are provided. The description does not specify when to use this tool, prerequisites, or alternatives. Sibling tools like easyeda_board_layers and easyeda_pcb_production_review exist, but there is no guidance on when to choose this tool over others.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true. The description adds a list of checks performed, which provides some behavioral context but does not disclose additional traits like permissions, data modification (already none), or response format.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence listing many aspects, which is efficient and front-loaded. No wasted words, though could be more structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complex input schema with numerous nested optional properties and high parameter count, the description fails to provide sufficient context for correct usage. No mention of output or expected data format.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%. The tool description does not explain either parameter (boardData or projectId) or their nested structure, leaving the agent with no guidance beyond the schema names and types.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it runs PCB constraint validation and enumerates specific checks (board outline, layer stackup, etc.). However, it does not explicitly differentiate from similar sibling tools like easyeda_drc_run or easyeda_pcb_constraint_report.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. No prerequisites, exclusions, or context about ideal scenarios provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true and idempotentHint=true, so the description adds no additional behavioral context. It does not describe what happens if no checks have been run or the format of the summary.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that is front-loaded with the key purpose. No wasted words, though a bit more structure could be beneficial.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema, the description does not need to explain return values. However, it lacks context about when results are available and the relationship to DRC/ERC tools. It is minimally adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter 'projectId' has no description in the schema (0% coverage), and the tool description does not explain its meaning or format. The description should compensate but fails to do so.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves a summary of design and electrical rule check results. It uses verb 'Get' and specifies the resource. However, it does not explicitly differentiate from sibling tools like easyeda_drc_run or easyeda_erc_run, which perform the checks themselves.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It does not mention prerequisites such as running DRC/ERC checks first, nor does it indicate scenarios where this tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true and idempotentHint=true, informing the agent of safe, side-effect-free behavior. The description adds that layers include signal, power, plane, and mechanical types, but this is already implied. No additional behavioral traits (e.g., pagination, caching) are disclosed. Score 3 as description adds minimal value beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence (12 words), making it concise. However, it omits parameter details, making it too brief for the complexity of the tool. Conciseness is valued, but not at the expense of necessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has only one parameter and an output schema (not shown), but the description only lists layer types without describing the return format or behavior. While minimal, it covers the basic purpose. Given the simplicity, the description is adequate but could mention the output structure or data shape.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has a single required parameter 'projectId' with type string, but the description does not mention it at all. Schema description coverage is 0%, so the description should compensate, but it fails to explain what projectId is or how to obtain it. This leaves the agent without essential parameter information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'List' and the resource 'layers in the PCB design', specifying types (signal, power, plane, mechanical). It distinguishes this tool from siblings like 'easyeda_board_stackup' which deals with stackup. This provides a specific and clear purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide any guidance on when to use this tool versus alternatives, nor does it mention prerequisites or exclusions. It only states the basic function, leaving the agent to infer usage context from the tool name and sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate idempotentHint=true and destructiveHint=false. The description adds little beyond stating it runs a check; it does not disclose safety implications, side effects, or confirm idempotency. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short at two sentences, but the second sentence is dense and could be clearer. Still, it is efficient and avoids unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has two parameters with no schema descriptions and an output schema (not shown). The description does not explain what the tool returns or how to interpret results, leaving significant gaps for an agent to understand the full context of using this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning no parameter descriptions. The tool description does not explain the two parameters (checks, projectId) or their expected values, leaving the agent without semantic guidance beyond the schema's basic structure.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool runs the native electrical rule check (ERC). It distinguishes from alternatives by mentioning that native counts are coarse and that inferred_floating_pins supplements them, but does not explicitly differentiate from the sibling easyeda_drc_run.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides guidance on when to use this tool by noting that native counts are coarse and that inferred_floating_pins is a supplement, and mentions that other categories still need the DRC panel. This implies when not to rely solely on this tool. However, it could be more explicit about when to prefer this tool over others.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly and idempotent. The description adds context about the report contents (what issues are identified), which is useful but not extensive. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence (22 words) that front-loads the main purpose. It could be more structured (e.g., listing the identified issues in a clearer format), but it is not verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 6 parameters, 1 required, and 0% schema coverage, the description is too short to provide sufficient context. It does not cover parameter meanings or usage constraints. The presence of an output schema does not justify the lack of parameter context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning no parameter descriptions in the schema. The description does not explain any of the 6 parameters (projectId, require_mpn, etc.), placing full burden on the description which it fails to meet.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses specific verb 'Generate' and resource 'BOM quality report', listing the categories it identifies (unavailable, single-source, missing-MPN, etc.). It is clear what the tool does, but does not explicitly distinguish from sibling tools like easyeda_bom_validate or easyeda_bom_sourcing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for quality assessment, but provides no explicit guidance on when to use this tool versus alternatives, nor any exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (destructiveHint=true), the description adds important behavioral details: the operation is snapshot-backed, any failure triggers a full rollback, and deletions are limited to safely recreatable primitives. This provides useful context not available from annotations alone.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three front-loaded sentences, each serving a clear purpose: core function with limit, rollback behavior, and delete constraint. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the high complexity (many operation types, transaction semantics, required fields like confirmWrite), the description is too brief. It omits crucial details like the purpose of dryRun, the need for confirmWrite=true, and how this relates to transaction management sibling tools (e.g., project_begin_transaction). The agent would have significant gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage for its 6 parameters, yet the description does not explain any of them (projectId, operations, confirmWrite, dryRun, transactionId, atomic). The agent must rely entirely on the schema, which is insufficient for correct usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it applies up to 200 validated schematic operations (create/modify/delete) in a snapshot-backed transaction with rollback, distinguishing it from individual operations by emphasizing batch and atomicity. However, it could be more explicit about when to use this tool over alternatives like easyeda_schematic_place_component.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no when-to-use or when-not-to-use guidance relative to the many sibling tools (e.g., individual schematic operations). It only mentions a constraint on delete but does not explain the trade-offs or prerequisites for using this batch tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=false and destructiveHint=false, so the tool is a write operation but not destructive. The description adds that it writes to a file on disk, providing context beyond annotations. However, it does not disclose potential side effects like overwriting existing files or required permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no wasted words. It is front-loaded with the action and resource. However, it is overly terse and omits parameter details, so it sacrifices completeness for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 3 parameters (2 required), no schema descriptions, and an output schema (not shown), the description should provide more guidance on parameter usage and expected output. It fails to compensate for the lack of schema descriptions, making the tool definition incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, meaning no parameter descriptions in the schema. The description fails to explain any parameters: it does not mention projectId, filePath, or the format enum (csv, json, xlsx). This leaves the agent without crucial information for correct invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Export' and the resource 'bill of materials' to a file, with the specified format. This distinguishes it from sibling tools like easyeda_bom_generate or easyeda_bom_validate, which focus on generation or validation rather than file export.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for exporting a BOM to a file, but it provides no explicit guidance on when to use this tool versus alternatives such as easyeda_bom_generate or easyeda_bom_sourcing. No exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate idempotent (idempotentHint=true) and non-destructive (destructiveHint=false). The description adds valuable behavioral context: a visible side effect (DRC panel opens/refreshes) and the limitation that only coarse counts are returned, with specific details only in the panel. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with purpose. Efficient but could benefit from slightly more structure (e.g., listing the side effect and return behavior separately). No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the description notes the visible side effect and coarse return, it omits parameter semantics entirely. Given that an output schema exists (from context), the return value limitation is described, but the tool's behavior regarding the 'rules' parameter is absent. Incomplete for effective agent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and the description provides no explanation for the two parameters (projectId and rules). The agent is left guessing what 'rules' array does and that projectId is required. This is a critical gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it runs the native DRC, analog to clicking 'Check DRC', and specifies return of coarse per-severity counts. Distinguishes from siblings like easyeda_erc_run and easyeda_rule_check_summary by mentioning the interaction with EasyEDA Pro's DRC panel and the limited return data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides context by comparing to clicking 'Check DRC' and noting coarse returns, but does not explicitly specify when to use this tool over siblings such as easyeda_erc_run or easyeda_rule_check_summary. No exclusions or alternative guidance given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, covering safety. The description adds context about returning metadata and its purpose, but does not disclose additional behavioral traits beyond what annotations provide. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, 14 words, with no superfluous content. It is front-loaded with the action and resource, making it efficient for the agent to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the existence of an output schema, the description reasonably lists returned metadata fields. However, it does not explain the parameter or the 'active sheet' context, and with 0% schema coverage on the parameter, the description is incomplete for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one parameter (projectId) with 0% description coverage and it is not required. The description fails to mention or explain the parameter, leaving the agent unsure of its role or whether it is optional (the description says 'active' without clarifying).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns read-only active schematic sheet metadata, listing specific items (page size, frame, origin, grid hints). It distinguishes from sibling tools that deal with components or nets, though it does not explicitly contrast them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description hints at usage for 'safer component placement' but provides no explicit guidance on when to use this tool versus alternatives like easyeda_schematic_components. No when-not-to-use or alternative names are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint as true, so the safety profile is covered. The description adds that it inspects the 'live' runtime and lists 'documented' APIs, implying dynamic behavior. However, it does not disclose details like performance impact or scope of what is listed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, concise and free of fluff. However, it omits critical information about the filter parameter, which would improve clarity. It is efficient but could be more comprehensive without sacrificing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that the tool has an output schema (not shown) and one optional parameter, the description provides a basic understanding of the tool's purpose. However, it fails to explain the filter parameter, which is necessary for correct usage. The presence of an output schema somewhat mitigates the need to describe return values, but the filter gap remains.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single 'filter' parameter has no description in the schema (0% coverage), and the tool description does not mention it at all. This leaves the agent with no clue about its purpose, allowed values, or how to use it. The description must compensate for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists 'documented API classes, runtime paths, and methods' from the live EasyEDA extension runtime. The verb 'inspect' and 'list' are specific, and the resource is well-defined. This distinguishes it from sibling tools that focus on board dimensions, schematic editing, or other tasks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for discovering available APIs, but it does not provide explicit guidance on when to use it versus alternatives, nor does it mention when not to use it. The context is clear enough for most agents, but lacks explicit usage boundaries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, so the agent knows it's safe and idempotent. The description adds that it produces a human-readable report, which is useful context. However, it does not detail what 'manual review' entails or any side effects, but annotations cover the safety profile adequately.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, clear sentence with no wasted words. It front-loads the action and purpose efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (nested object with many properties), the description is too brief. It does not explain the relationship to constraint checking tools, what constraints are involved, or how the report is generated. The output schema may compensate, but the description alone lacks sufficient context for effective tool selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description provides no information about the parameters. The boardData object has many nested properties without explanations, and the description does not help the agent understand how to fill these parameters or what they represent.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Generate' and the resource 'PCB constraint report', and explains what the report does (explains which constraints applied and which need review). It distinguishes from sibling tools like easyeda_pcb_constraint_check, which likely runs the check rather than producing a report.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage after constraints are applied, but does not explicitly state when to use it versus siblings like easyeda_pcb_constraint_check or easyeda_rule_check_summary. No exclusions or alternatives are mentioned, leaving room for ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are minimal (readOnlyHint=false, idempotentHint=false). The description does not disclose side effects, permission requirements, or what exactly happens during the self-test, missing an opportunity to inform the agent beyond the basic action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of 12 words, front-loaded with the verb and resource, and every word contributes to the purpose. No wasted text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no parameters, has output schema), the description covers the essential purpose. However, it could mention the nature of the output (e.g., pass/fail report) but is not required since output schema exists.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no parameters, and schema description coverage is 100%. The description adds meaning by specifying what the test verifies (integrity, config, connectivity), which is sufficient given the parameterless schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'run' and resource 'internal self-test', with specific goals: verify server integrity, config, and bridge connectivity. However, it does not explicitly differentiate from sibling tools like 'easyeda_health_check' which may have similar purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as 'easyeda_health_check' or 'easyeda_bridge_status'. The description lacks context for appropriate usage scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the description need not repeat that. It adds useful behavioral context by detailing the returned device identity fields and mentioning 'place_component deviceItem in this project', which helps the agent understand the tool's role in cloning operations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the core function and lists fields efficiently. However, the inline list could be more readable with line breaks or bullet points. It earns its place with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema, the description does not need to explain return values in detail, but it does. However, it misses important context about pagination (limit/offset) and lacks guidance on usage among sibling tools. It is adequate for a straightforward listing tool but not comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33% (only projectId described). The description does not explain the limit and offset parameters, which are critical for pagination. Without elaboration, the agent cannot understand how to control the number of results or page through them.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool lists schematic components, and enumerates the specific fields returned (primitiveId, reference, value, footprint, x/y/rotation, device identity for cloning). This specificity distinguishes it from sibling tools like easyeda_schematic_component_pins or easyeda_pcb_components.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, nor does it specify exclusions or prerequisites. Among many schematic tools, the agent receives no help in selecting this one over others like easyeda_schematic_nets or easyeda_schematic_place_component.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint and idempotentHint. Description adds some behavioral context (what data is retrieved) but does not disclose further traits beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence that is clear and to the point, with no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one parameter and annotations, but the description omits explaining the required projectId parameter. It adequately covers the output but lacks parameter context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain the projectId parameter or its role, failing to compensate for the lack of schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves PCB board outline dimensions, shape, and mounting hole information, using a specific verb and resource. It distinguishes from siblings like board_features and board_stackup.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives. The description only states what it does, without mentioning context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true and idempotentHint=true. Description adds list of feature types counted, but does not mention edge cases like invalid projectId or performance. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence of 12 words, efficient and front-loaded. Could add more context without becoming verbose, but not overly sparse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Simple tool with one parameter, output schema, and annotations. Description is adequate but missing parameter semantics and does not mention that output schema documents return values. Slightly incomplete for a complete picture.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, and description does not describe the sole parameter projectId. The description implies the tool operates on a board identified by projectId, but provides no format, validation, or usage guidance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states verb 'get' and resource 'counts of board features' and lists examples (vias, tracks, copper zones, pads). Distinguishes from sibling tools like easyeda_board_dimensions or easyeda_board_layers which handle different aspects.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or when-not-to-use guidance. Implied usage is for retrieving summary feature counts, but with many sibling tools, more context on selection would help.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint and idempotentHint as true, so the tool is safe and idempotent. The description uses 'Generate', which might imply mutation, but it's not a strong contradiction. It does not add behavioral context beyond what annotations provide, such as no side effects or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that conveys the core purpose without any extraneous information. Every word is necessary and contributes to understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has an output schema, so return values are covered. It has 3 parameters with enums. The description mentions grouping and formatting but does not explain that projectId is required or its format. Given the complexity (simple BOM generation) and presence of output schema, the description is adequate but lacks differentiation from sibling tools like easyeda_bom_export.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the burden is on the description. It mentions 'grouping and formatting options', which partially describes the 'groupBy' and 'format' parameters. However, it does not explain the 'projectId' or the enum values. The schema already defines enums, so the description adds some meaning but not full compensation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it generates a bill of materials for the project, mentioning grouping and formatting options. The title 'Generate BOM' directly conveys the action. It distinguishes from siblings like easyeda_bom_export and easyeda_bom_validate, which focus on exporting or validating, not generating.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. There is no mention of prerequisites, context, or when not to use it. For example, it does not differentiate from easyeda_bom_export for outputting the BOM.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint and idempotentHint, so the tool is safe. The description adds behavioral details: the unit assumption (native unit, not verified against physical dimensions) and the error-handling behavior (empty list vs. error for inactive tab). These go beyond annotations and provide useful transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences that convey the core functionality, prerequisites, behavior, and output details. It is concise and front-loaded, though the second sentence could be slightly more precise. No superfluous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the purpose, prerequisite (active PCB tab), output fields, and a behavioral note. However, it lacks any documentation for input parameters, which is necessary for correct invocation since schema coverage is 0%. The output schema exists but is not shown in this evaluation. Overall, it leaves a significant gap in parameter understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 3 parameters (projectId required, limit with default 100, offset default 0), but schema description coverage is 0%. The description does not explain any of these parameters or their semantics. The tool description only mentions output fields, not input parameters. This is a significant gap for agent usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The tool name and title clearly indicate listing PCB vias. The description specifies the resource (vias on active PCB layout) and provides details on the returned fields (primitiveId, net, position, hole/outer diameter). While it distinguishes from sibling tools implicitly by focusing on vias, it does not explicitly differentiate from similar listing tools like easyeda_pcb_components or easyeda_pcb_tracks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states the requirement for a focused PCB tab and the behavior when none is active (returns empty list, not an error). This provides clear context for when to use the tool. However, it does not mention alternatives or explicitly state when not to use this tool versus other listing tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the description's role is reduced. It adds that the tool returns 'machine-readable issues' and 'human-readable summary', which is useful context about output format but does not disclose additional behavioral traits beyond what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads key actions and resources, achieving maximum conciseness without filler. Every word contributes to describing functionality.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema and detailed input schema, the description lacks details about the analysis methodology, issue detection scope, or result interpretation. For a complex tool with 8 parameters, nested objects, and power tree analysis, more context (e.g., 'Checks for dropout violations, thermal margins, and capacitance adequacy') would make it complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description should compensate. While it mentions some elements (sources, regulators, loads, etc.) that align with schema arrays, it does not explain each parameter's purpose, requirements, or how to structure inputs. The schema itself is detailed, but without guidance, an AI agent may struggle to construct valid inputs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses specific verb 'analyze' and explicitly lists the resources involved: supply sources, regulators, loads, protection, bulk capacitance, current budget, dropout, and thermal risk. It clearly distinguishes from sibling tools which focus on schematic, BOM, or board features.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this tool is used for power tree analysis but does not explicitly state when to use it versus alternatives. No exclusions or prerequisites are mentioned, and given many sibling tools, some guidance (e.g., 'Use after schematic completion') would help.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate this is a non-read-only, non-idempotent write operation. The description adds that fillColor 'none' leaves the circle unfilled, which is a useful behavioral detail but does not cover other traits (e.g., side effects, coordinate system, or permission requirements). No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loads the core action and purpose, and the second sentence adds targeted guidance on fillColor. No fluff or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 9 parameters and low schema coverage, the description omits critical context such as coordinate units, line type interpretation, constraints on radius, and the fact that confirmWrite must be a literal boolean true. The presence of an output schema does not compensate for missing usage context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With only 22% schema coverage, the description should compensate by explaining parameter meanings. It only addresses fillColor, clarifying that 'none' means unfilled. Other parameters (centerX, centerY, radius, confirmWrite, etc.) are left unexplained, leaving agents to rely on parameter names, which may be insufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Draw a circle'), the target location ('on the schematic sheet'), and the purpose ('decorative marker or custom symbol element'). It distinguishes from electrically meaningful siblings by emphasizing that it is cosmetic only with no electrical meaning.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for decorative purposes only ('Cosmetic only, no electrical meaning'), but it does not explicitly state when not to use it or provide alternative tools for electrically significant shapes or other decorative primitives like rectangles or polygons.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate a write operation (readOnlyHint=false) and idempotentHint=false; the description confirms creation. However, it does not disclose potential side effects (e.g., overwriting existing ports with the same net name), authorization needs, or impact on the netlist beyond the basic statement.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of two concise, front-loaded sentences. Every sentence adds value: the first states the action, the second explains behavior and netlist implications. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (7 parameters, 5 required, enums, output schema exists), the description covers the core concept but does not integrate parameter details. It is adequate but could more explicitly state that coordinates (x,y), netName, and portType are required, and that confirmWrite must be true.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so each parameter has a description. The tool description adds no additional context to parameters; it only mentions the net name concept. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: placing a hierarchical net port (off-sheet connector) on a schematic. It explains that net ports create named connections across multiple sheets and become SCH_Net entries in the netlist. This specificity distinguishes it from sibling tools like net flags or wire addition.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives (e.g., easyeda_schematic_create_net_flag). It does not mention prerequisites, context, or situations where this tool is preferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the agent knows it's safe. The description adds context about the types of rules checked, but does not disclose additional behavioral traits like permissions or latency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that efficiently conveys the core functionality and specific detection categories without any filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (4 parameters, nested objects, 0% schema coverage), the description is incomplete. It does not indicate the optional nature of 'devices', 'interfaces', and 'projectId', and relies entirely on the output schema to explain return values, making the description insufficient for proper agent usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description does not explain the structure of required 'nets' parameter or optional parameters (devices, interfaces, projectId). It mentions 'netlist' generically but fails to detail the required schema fields, leaving the agent to infer from the schema itself.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool runs semantic electrical-rule validation (verb+resource) and lists specific detection outcomes (output contention, floating inputs, etc.), distinguishing it from basic ERC tools like easyeda_erc_run.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when a netlist with pin electrical types is available and semantic checks are needed, but it lacks explicit when-to-use/when-not-to-use guidance or mentions of alternatives like easyeda_erc_run.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the description adds no behavioral safety info beyond specifying the return fields. It does not contradict annotations, but provides minimal additional behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of 10 words, front-loading the purpose without any extraneous information. Every word is necessary and contributes to clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers what the tool returns but fails to mention that it operates on a specific project (projectId) or any context about the output schema. Given the presence of an output schema, the omission of project context is a reduction in completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%. The description does not explain the sole parameter 'projectId' or its purpose, leaving the agent without guidance on how to correctly invoke the tool despite a required parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Get') and resource ('PCB layer stackup') with included fields (thickness, material, dielectric constants). It clearly distinguishes from sibling tools like easyeda_board_dimensions and easyeda_board_layers, which cover different board properties.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide explicit guidance on when to use this tool versus alternatives. No when-to-use, when-not-to-use, or alternative tool mentions are included, leaving the agent to infer context from the purpose alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate a write operation (readOnlyHint=false, idempotentHint=false). The description adds that the polygon is cosmetic and has no electrical meaning, which is useful. However, it doesn't disclose any side effects, required permissions, or behavior on invalid inputs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence followed by a clarifying phrase. It is concise, front-loaded, and contains no redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the core purpose and cosmetic nature well. Given the tool has 6 parameters and an output schema, it lacks details on parameter semantics and error conditions, but overall is adequate for a simple shape-drawing tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is low (33%) with only fillColor and confirmWrite described. The tool description mentions '3+ vertices' aligning with points minItems, but does not explain color, lineType, lineWidth, or fillColor beyond schema. More parameter guidance is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool draws a closed polygon from 3+ vertices on the schematic sheet. It provides specific use cases (decorative shapes, callout arrows, block diagram elements) and distinguishes from electrical tools by noting 'cosmetic only, no electrical meaning'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for decorative non-electrical elements but does not explicitly state when not to use or provide alternatives. While it differentiates from electrical tools, it doesn't compare with sibling drawing tools like add_circle or add_rectangle.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true and idempotentHint=true, so the description's claim of 'Get' aligns. However, the description adds only minor behavioral context beyond annotations (e.g., 'including all connected pins and components'). Since an output schema exists, return details are likely documented there.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single concise sentence of 16 words that front-loads the action ('Get full details...'). No superfluous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and the presence of an output schema, the description is minimally adequate but lacks parameter details (especially netName) and prerequisites. It covers the basic purpose but not enough context for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 50% (only projectId has a description). The description does not explain the netName parameter or its format, leaving half of the parameters undocumented. No additional meaning is provided beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states that the tool gets full details for a specific net, including connected pins and components. The verb 'Get' and resource 'full details for a specific net' are clear, and it distinguishes from sibling tools like 'easyeda_schematic_nets' which likely lists nets.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when full net details are needed, but does not provide explicit guidance on when to use this tool versus alternatives such as 'easyeda_schematic_nets' or 'easyeda_schematic_component_pins'. No when-not-to-use or context is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint. The description adds useful behavior: returns empty list (not error) if no PCB tab is focused, and explains multi-point track representation. No additional safety or performance details are provided.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loading the purpose and adding behavioral context without redundancy. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a list tool with read-only annotations and an output schema (not shown), the description is fairly complete, covering output fields and a special case. It lacks parameter explanations, but overall is adequate for its purpose.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description does not explain the parameters (limit, offset, projectId). The description only covers the output, leaving parameter semantics entirely to the schema. This is a significant gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists copper track segments on the active PCB layout, specifying the fields returned (primitiveId, net, layer, coordinates, width). It distinguishes from siblings like easyeda_pcb_components and easyeda_pcb_vias by explicitly focusing on tracks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when track data is needed and clarifies that an empty list is returned if no PCB tab is focused, guiding proper usage. It does not explicitly contrast with alternatives, but the context is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds behavioral context beyond annotations: transaction is in-memory, document-scoped, snapshot-backed, and does not modify EasyEDA. Annotations show destructiveHint=false but description clarifies non-modification and scope.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences with no wasted words. First sentence states core action, second adds constraint, third clarifies non-modification. Front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While annotations and output schema exist, the description fails to document parameters. For a multi-parameter transaction tool, leaving parameters unexplained reduces completeness significantly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and the description does not explain any of the 4 parameters (projectId, label, ttlSeconds, maxOperations). The schema provides names and constraints but the description adds no semantic value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Open an in-memory, document-scoped transaction') and the resource ('snapshot-backed schematic writes'). It distinguishes from sibling tools like commit/rollback by noting only one active transaction per document.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage before write operations by stating 'transaction for snapshot-backed schematic writes' and the constraint 'only one active transaction'. However, it does not explicitly mention when not to use it or name alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare destructiveHint=true, and the description adds valuable behavioral details: restoring snapshots in reverse order, verifying hashes, and explicitly reporting partial rollbacks. This goes beyond annotations without contradicting them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence with no filler. Every part adds meaning: controlled write, restoration order, verification, and explicit reporting.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's role in a transaction workflow, the description covers the core action and verification. Though it omits details on failure handling and return values (output schema exists), it provides sufficient context for an AI to infer usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain the two parameters (transactionId, confirmWrite). While the transactionId is implicit, the confirmWrite constant and its role in confirming the destructive action are not clarified.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool performs a controlled write to restore schematic primitive snapshots in reverse order, which is a specific verb-resource combination. It distinguishes itself from other project transaction tools (begin, commit, validate) by focusing on rollback.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly state when to use this tool versus alternatives like easyeda_project_validate_transaction. There is no guidance on prerequisites or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate a write operation (readOnlyHint=false) and no idempotency. The description adds value by clarifying that save is never implicit and that it persists specific types of changes. However, it does not disclose failure modes, concurrency behavior, or consequences of missing confirmWrite, which would be helpful for an AI agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences long, front-loading the core purpose in the first sentence. Every sentence provides relevant information without redundancy or fluff. The structure is efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's relative simplicity and the presence of an output schema (not shown but noted), the description covers the essential behavior. However, it lacks details on error handling, return values, or prerequisites beyond confirmWrite. For a critical write operation, agents might benefit from knowing what happens on failure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, so the description does not need to add much. It mentions confirmWrite but provides no additional meaning beyond the schema's constraint (must be literal true). The baseline of 3 is appropriate as the schema already defines the parameters adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: saving the current EasyEDA Pro project. It specifies what is persisted (netlist changes, net flags, pin connections, etc.), making the resource and action unambiguous. The tool is distinct from sibling tools like transaction managers or read-only inspectors, as it focuses on explicit persistence.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains that save is explicit and requires confirmWrite, providing context for when to use it. However, it does not mention when not to use it or compare it to alternative persistence mechanisms like transactions. Some guidance on avoiding confusion with commit/rollback would improve this dimension.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the read-only nature is clear. The description adds that it returns component-count delta and optional netlist validation, but does not disclose further behavioral details such as side effects or required permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at two sentences and 20 words, with no extraneous information. Every sentence adds value: the first explains the core action, the second specifies outputs and use case.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the existence of an output schema, the description adequately explains return values (component-count delta, netlist validation) and the purpose. However, it omits any discussion of the 5 parameters, which for a verification tool would help agents understand configuration options.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 5 parameters with 0% schema description coverage, meaning no parameter documentation exists in the schema. The description provides no information about any parameters, failing to compensate for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool reads back schematic state after a write, with specific outputs (component-count delta, netlist validation). It distinguishes itself from sibling schematic tools by focusing on verification after agent-authored writes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly indicates when to use: after an agent-authored write, to confirm placement or connection before continuing. However, it does not mention when not to use or list alternatives, leaving room for improvement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the tool as read-only and idempotent. The description adds valuable context: results cite sources and are estimates with caveats. This enhances transparency beyond annotations but does not contradict them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: two sentences that front-load the key action and list covered topics without unnecessary detail. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (14 parameters, conditional requirements) and the presence of detailed schema descriptions and an output schema, the description provides a good overview. It could mention conditional parameter dependencies, but the schema already addresses this, so completeness is adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the parameter semantics are already well-documented in the schema. The description adds minimal additional meaning beyond listing topics; it does not elaborate on parameter relationships or conditional requirements.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: lookup generic engineering reference guidance, listing specific topics like IPC-2221 trace-width, clearance bands, protocol routing, decoupling recipes, bulk capacitance sizing, and DFM checklist. This clearly distinguishes it from sibling tools that manipulate designs or perform other analyses.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description lacks any guidance on when to use this tool versus alternatives. No explicit contexts, preconditions, or exclusions are provided, leaving the agent without direction on appropriate usage scenarios relative to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the description's burden is lower. The phrase 'current' adds minimal behavioral context (snapshot semantics). It does not contradict annotations, but neither does it disclose any additional behavioral traits like caching or side-effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that communicates the core function without unnecessary words. It is front-loaded and every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple, parameterless getter tool with an existing output schema, the description is adequate. It could be improved by briefly noting the domain (e.g., EasyEDA feature flags) but is otherwise sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so schema coverage is 100% by default. With no parameters to describe, the description logically has nothing to add. The baseline for zero-parameter tools is 4, as the schema suffices.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Return current feature flag values' uses a specific verb and resource, clearly indicating it retrieves feature flag values. The name 'get_feature_flags' reinforces this, and the tool is distinct from siblings like 'get_capabilities' or 'get_server_config' which handle different configuration data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description does not mention scenarios, prerequisites, or exclusions. Annotations indicate readOnly and idempotent hints but these are not elaborated in the description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint and idempotentHint. The description adds value by explicitly stating that secrets are never exposed, which is a behavioral guarantee beyond annotations. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences with no wasted words. The core purpose is front-loaded and immediately clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (1 optional param, output schema exists), the description is minimally adequate but lacks detail on what the configuration contains and the effect of the parameter, leaving some ambiguity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not explain the only parameter (include_flags) at all. With 0% schema description coverage, the definition relies entirely on the description to clarify parameter semantics, which it fails to do.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Return' and the resource 'server configuration', and adds the crucial quality that secrets are redacted. This distinguishes it from sibling tools that deal with schematic, BOM, etc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. While it's implied by the tool's purpose, there is no mention of prerequisites or conditions for use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations (readOnlyHint, idempotentHint, destructiveHint) already declare safe read-only behavior. Description adds context about running rules and reporting severity-ranked findings, which is consistent and provides additional behavioral detail (e.g., actionable remediation). No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences: first states action, second describes output. No extraneous information, front-loaded with key purpose. Every sentence is necessary and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Description covers purpose and output format but omits parameter descriptions for a complex tool with a nested boardData object and enum gateMode. Output schema exists, so return values are covered indirectly. Parameter usage guidance is missing, reducing completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Description does not reference any of the three parameters (projectId, gateMode, boardData). With 0% schema description coverage, the description should compensate but fails to explain parameter meaning or usage. The many properties in boardData remain undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the verb 'run', resource 'production review rules', and purpose for PCB handoff. It specifies DFM/DFA/DFT focus and distinguishes from siblings like DRC/ERC runs by mentioning fabrication, assembly, and testability review before Gerber export.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description indicates when to use ('before Gerber export or manufacturing submission'), but does not explicitly exclude other similar checks (e.g., when to use this vs easyeda_drc_run). It provides context for usage but lacks explicit alternatives or when-not conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description discloses that it combines DRC/ERC results and classifies them, which aligns with idempotentHint. It does not contradict annotations. Could mention that rerunning is safe (idempotent) but overall good.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, highly concise and front-loaded with the core purpose. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Description covers the main output format but omits details on required projectId, policy enum options, and use of manual messages. Given the tool's complexity (7 params, nested objects), more context would help.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 57%, but description adds no extra meaning for parameters like 'policy' or 'useNativeChecks'. Critical parameters are not explained, leaving the agent to rely solely on the schema's brief descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the verb ('run and classify'), resource ('post-write schematic QA'), and context ('after generated edits'). It differentiates from sibling tools like easyeda_drc_run by specifying policy-aware classification and output format (pass/fail/inconclusive instead of raw counts).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implied usage as a post-write step, but no explicit guidance on when to use this tool versus alternatives (e.g., raw DRC/ERC runs). No exclusions or scenario examples provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate a write operation (readOnlyHint=false) and non-idempotent behavior (idempotentHint=false). The description adds the fact that deletion is by UUID, but does not disclose other behavioral traits such as error handling, reversibility, or cascading effects. It meets the baseline but adds limited extra value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence of 17 words conveys the action, target, and method without any fluff. It is front-loaded with the verb and resource, making it efficient for an AI agent to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema (not shown) and clear annotations, the description is mostly complete for a delete operation. However, it omits mention of the confirmWrite boolean constraint, which is critical for writing. While the schema documents it, including it in the description would improve completeness for agent decision-making.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50%: confirmWrite is documented in schema, but primitiveIds lacks a schema-level description. The tool description adds that primitiveIds are UUIDs, which is valuable context. This compensates for the schema gap, earning a score above baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it deletes schematic primitives by UUID, specifying the verb (delete), resource (schematic primitives), and method (by UUID). This distinguishes it from sibling tools like easyeda_schematic_modify_primitive, which modifies rather than deletes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives. For example, it does not mention that this tool is for deletion while easyeda_schematic_modify_primitive is for modification, or any prerequisites or constraints.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint as true. The description adds value by detailing result behavior: 'Full results carry complete metadata object per device' and the effect of minimal parameter. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with no redundancy. The first sentence delivers the core purpose, and the second elaborates on result format and an important optimization. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool complexity (7 parameters, optional output schema), the description is minimal. It explains full vs minimal results but omits search details, pagination, and error scenarios. Since an output schema exists, return values need not be detailed, but parameter usage context is lacking.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 29% (only key and minimal have descriptions). The tool description adds info for minimal but fails to cover page, itemsOfPage, symbolType, libraryUuid, and classification. Parameter meaning remains unclear for the majority of parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'Search for schematic symbols/devices in the EasyEDA library by keywords.' This is a specific verb+resource combination that directly conveys the tool's function. It also mentions the minimal flag feature, further clarifying the behavior without ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides usage guidance for the minimal parameter ('pass minimal:true when that is all you need'), but does not contrast with sibling tools or give when-to-use/when-not-to-use advice. No reference to alternatives like other search or inventory tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, covering safety. The description adds no further behavioral details (e.g., data freshness, rate limits). No contradiction exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that efficiently states the tool's function and key constraints, with no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema, the description adequately covers the tool's purpose for a read-only operation. However, it could better differentiate from siblings and add more guidance on supplier selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must add meaning for parameters. It only hints at 'suppliers' usage but does not explain 'projectId' or provide format/constraints for either parameter, leaving gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description specifies the verb 'Retrieve' and the resource 'pricing and availability information for all parts in the project BOM from specified suppliers', clearly distinguishing it from other BOM-related siblings like export or generate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for sourcing data with optional supplier filtering. While no explicit alternatives are mentioned, the context is clear and the name differentiates it from other BOM operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=false. Description adds that it zooms and returns viewport, but doesn't contradict annotations. Transparency is adequate but adds little beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences: first states purpose and return, second provides usage guidance. No wasted words, front-loaded with key action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema and low complexity, the description covers purpose and usage well. However, parameter semantics are lacking, which slightly reduces completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 4 parameters with 0% description coverage. Description mentions 'coordinate/scale' but does not explain each parameter's meaning or format. tabId is not mentioned. This is insufficient for an agent to correctly set the parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool zooms the EasyEDA canvas to a coordinate/scale and returns the viewport rectangle. It distinguishes itself from siblings by mentioning it is useful before calling easyeda_canvas_capture.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description explicitly says when to use: 'before calling easyeda_canvas_capture' or 'standalone to navigate'. No explicit when-not or alternatives, but the sibling list provides context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool as readOnly, idempotent, and non-destructive. The description adds details about the data returned (latency, runtime, cache, storage), which is useful context beyond annotations. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of 20 words, directly listing the report contents. Every word is informative; no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema (context provided) and only one optional parameter, the description covers the report's contents and purpose. However, it omits any mention of the parameter, which is a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and the description does not mention the only parameter 'includeRecentEvents'. The parameter name and default imply its use, but the description does not explain its effect or how it modifies the report. The description should compensate for low schema coverage but fails to do so.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it returns specific performance data (latency budgets, runtime metrics, etc.) for diagnostics. It uses a specific verb ('Return') and resource, and distinguishes from siblings by focusing on observability; no other sibling mentions these metrics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use 'for performance diagnostics' but provides no explicit guidance on when to use this tool over alternatives (e.g., health_check). No when-not-to-use or trade-offs are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true. The description adds value by disclosing that the tool does not expose 'captured primitive snapshots', providing extra behavioral context beyond what annotations offer.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is front-loaded and contains no unnecessary words. It efficiently conveys the tool's purpose and key distinction.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, clear annotations, and an output schema), the description is adequately complete. It covers the core functionality and a notable exclusion (primitive snapshots).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description does not elaborate on the 'transactionId' parameter. Although the parameter name is self-explanatory, the description should have added context such as format or source to aid the agent.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Read' and the resource 'transaction state' including specific fields (validation results, operation hashes, rollback status). It also distinguishes from siblings by noting what is not exposed ('captured primitive snapshots').
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this tool is for checking transaction status but does not explicitly state when to use it versus siblings like project_validate_transaction or project_commit. No guidance on prerequisites or alternatives is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds context beyond annotations: auto-assigns designator, handles duplicate 'R?' by merging, and auto-reconciles on timeout. Annotations only indicate non-read-only and non-idempotent, so the description enriches behavior understanding.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with zero fluff. The first sentence states purpose and core behavior; the second addresses timeout handling. Efficient and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 13 parameters, nested objects, and an output schema, the description omits critical details like parameter effects (e.g., mirror, rotation, addIntoBom), return value structure, and prerequisites. Incomplete for a complex write tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 8% (only confirmWrite has description). Despite 13 parameters and nested objects (deviceItem), the description does not explain any parameters, leaving agents to infer from names like x, y, mirror, rotation, etc.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Place a library component/device on the active schematic sheet' with specific details like auto-assigning designator and merging duplicates. This differentiates it from sibling schematic tools like easyeda_schematic_add_circle or easyeda_schematic_components.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear guidance: check the returned value for duplicate designators, and on timeout error auto-reconcile rather than blindly retrying. Does not explicitly compare to alternatives but gives operational context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true and idempotentHint=true. The description adds beyond that: it uses live sheet info, assumes bottom-left coordinates, reserves default lower-right title-block keep-out, and returns a plan. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no wasted words. The first sentence front-loads the primary purpose, and the second adds key details. Highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (6 params, nested objects, output schema exists), the description is brief but covers core function. It could mention prerequisites (e.g., sheet must be active for live info) but is largely sufficient. Output schema covers return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50%, and the tool description does not add meaning beyond what is in the schema. Parameters like 'margin' and 'projectId' lack schema descriptions and are not explained in the description. The description does not compensate for the coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it computes a safe schematic drawing region before placing components, specifying it uses live sheet info, assumes EasyEDA coordinates, reserves title-block keep-out, and returns a plan avoiding overlap. This specific verb+resource scope distinguishes it from sibling tools like 'easyeda_schematic_place_component' or 'easyeda_schematic_check_collisions'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description says 'before placing components' implying when to use, but it does not explicitly contrast with alternatives or state when not to use. No exclusions or alternative tools are mentioned, relying on context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds value by detailing the output components (plan ID, model hash, operations, validation gates, warnings, blockers) and reaffirming the read-only nature. No contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences, front-loading the key information about the tool's function and output. The first sentence is dense but clear; the second is a crisp safety note. No redundant phrases.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 6 parameters and an output schema exists, the description covers the output well but lacks guidance on input parameters like componentLimit or normalizeNetNames. For a preview tool that may be exploratory, more clarity on how parameters affect the plan would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 17%, and the description does not elaborate on any parameters beyond what the schema provides. With low coverage, the description should compensate, but it offers no param-specific guidance, leaving the agent to rely on the sparse schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool reads the live schematic and produces a normalization plan, with specifics like 'deterministic', 'read-only', and a list of outputs. It distinguishes from siblings by emphasizing previewing normalization without writing, contrasting with write tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool should be used to preview normalization before committing, and explicitly states it never writes, indicating safe usage. However, it lacks explicit guidance on when not to use or comparison to related tools like 'easyeda_schematic_audit_imported_design'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint. The description adds valuable behavioral context: it explains that validation requires both inference and native ERC, and that inference alone can give false positives when pins overlap without a wire. This enhances transparency beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (two sentences), front-loads the core purpose, and avoids unnecessary content. It could be slightly more structured, but it is effective and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (cross-checking two validation methods) and the presence of an output schema, the description provides sufficient context. It explains the key condition for 'valid' and the reason for combining checks, leaving no major gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so both parameters are described in the input schema. The description does not add additional meaning or usage details for the parameters beyond what the schema provides. Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool validates the schematic netlist, listing specific checks (inferred nets, connected refs/pins, floating pins, cross-check with native ERC) and defines what 'valid' means. It provides a specific verb+resource with distinctive scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes useful context about false positives when inference runs alone, implying when this combined check is valuable. However, it does not explicitly state when to use this tool versus siblings like easyeda_erc_run or easyeda_schematic_nets, nor does it provide clear usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true and idempotentHint=true. The description adds that it identifies missing, obsolete, or alternate parts, which is behavioral context beyond the annotations. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, clear sentence that front-loads the action and purpose. No extraneous words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple tool (one parameter, read-only) and presence of an output schema, the description sufficiently covers the tool's function without needing to detail return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain the 'projectId' parameter format or meaning. While the parameter name is somewhat self-explanatory, the description should compensate for the lack of schema details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'validate' and the resource 'project BOM' against LCSC inventory, and specifies the purpose (identify missing, obsolete, or alternate parts). This distinguishes it from siblings like easyeda_bom_export or easyeda_bom_generate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for BOM validation but does not explicitly state when to use it vs. siblings like easyeda_bom_sourcing or easyeda_bom_quality_report. No exclusion criteria or alternative guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint. The description adds value by specifying the exact checks (status, version, capabilities), which is consistent and provides behavioral context beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single, clear sentence that is front-loaded and contains no unnecessary words. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description adequately covers the tool's purpose and outputs for a simple status check. The presence of an output schema reduces the need to detail return values. Some users might benefit from example outputs, but overall it is complete enough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so the description does not need to explain parameter semantics. Baseline of 4 is appropriate given the schema coverage is 100%.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Check') and clearly identifies the resource ('EasyEDA Pro bridge connection status, version, and capabilities'). This distinguishes the tool from its siblings, many of which are feature-specific or perform other actions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like easyeda_health_check or easyeda_get_capabilities. The agent is left without context for selection in an ambiguous scenario.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint true. Description adds no further behavioral details beyond what is stated. Adequate but not enhanced.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, concise, and front-loaded with the action. No wasted words, every word contributes to clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No parameters, output schema present. Description gives sufficient context about what is returned (capabilities, profiles, flags, operations). Could mention that it's a read-only/idempotent operation, but annotations already cover. Complete enough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters; schema coverage is 100%. Description adds no parameter info, which is appropriate. Baseline 4 for zero parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Return server capabilities' with specific examples (profiles, feature flags, supported operations), distinguishing it from siblings like easyeda_get_feature_flags and easyeda_get_tool_profiles.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or alternatives guidance, but context implies this is for a broad overview. Implicit usage from sibling names, but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the tool as read-only and idempotent. The description adds no further behavioral context beyond 'list', which is consistent. No contradiction, but no added value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence that conveys the tool's purpose without any extraneous words. Perfectly concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema and annotations covering safety, the description is sufficient for a simple listing tool. However, the term 'tool profiles' could be more explicitly defined.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With zero parameters, schema coverage is 100% and the description naturally covers the lack of parameters. It adds the note 'and their descriptions' which hints at output content, slightly enhancing meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'list' and the resource 'available tool profiles and their descriptions'. It distinguishes well from sibling tools which are all specific actions, making it unique.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives. However, the simplicity of the tool (no parameters) reduces the need for such guidance, but it would benefit from stating that it helps discover available profiles.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate write and non-idempotent behavior. The description adds valuable context: how connectivity is created (wire stub, net merging) and its effects (visible to ERC, ratsnest, autorouting), exceeding what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no wasted words. The first sentence defines the action, the second explains the behavior. Front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema and 6 parameters, the description covers the core behavior well. It explains the net merging effect and visibility to tooling. Minor omission: no mention of prerequisites (e.g., component must be placed) but overall complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description mentions netName and pinNumber indirectly ('tagged with netName', 'exact coordinate') but adds no new meaning beyond the schema's parameter descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Create real EasyEDA connectivity for a pin' with a specific action (draws wire stub, tags with netName). It clearly differentiates from siblings like 'easyeda_schematic_connect_pins_by_net' by focusing on a single pin connection.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use when connecting a pin to a net, but does not explicitly state when not to use it or compare to alternatives. Usage context is implied but lacks clear guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, so safety is covered. The description adds value by specifying that node connections are included in the output, beyond the parameter schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence of 8 words, perfectly front-loaded with no wasted text. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite the simplicity, the description covers the tool's purpose completely. The presence of an output schema means return values need not be described. For one-parameter list tool, it is fully adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the single parameter (projectId described as 'The project/schematic ID'). The description does not add any additional meaning to the parameter, so baseline score applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List all nets in the schematic with their node connections' uses a specific verb and resource, clearly distinguishing it from sibling tools like easyeda_schematic_net_detail (which focuses on a single net) and easyeda_schematic_validate_netlist (validation).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when or when not to use this tool vs alternatives. While implied as the general listing function, the description lacks criteria for selection over related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint. Description adds valuable context: requires active PCB tab, returns empty list if inactive, and lists returned fields. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, front-loaded with main action. No extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for a list tool with output schema. Describes returned fields, preconditions, and edge case. No gaps identified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 3 parameters with 0% description coverage. Description does not explain any parameter semantics (e.g., projectId, limit, offset). Fails to compensate for missing schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states verb 'list', resource 'components placed on active PCB layout', and lists key returned fields. Distinguishes from schematic components siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides prerequisite (focused PCB tab) and behavior when not satisfied (empty list, not error). Lacks explicit differentiation from other PCB tools like tracks or vias.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations set readOnlyHint=true, idempotentHint=true, destructiveHint=false, consistent with validation. The description adds specific behavioral details (consistency gates) beyond annotations, without contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded with purpose, no wasted words. Efficient and clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given output schema exists and annotations cover safety, the description adequately explains the validation gates and transaction context. Could mention what happens on failure, but overall complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description must compensate. It mentions bridge, expected operation count, and applied writes, corresponding to three parameters, but does not explicitly name them or cover transactionId. Adds some meaning but not fully.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: running transaction consistency gates before commit, listing specific checks (bridge availability, pending/failed operations, optional count, applied writes). It distinguishes from sibling tools like begin/commit/rollback.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description says 'before commit,' indicating usage context. While alternatives are not explicitly mentioned, the sibling list makes the transaction workflow clear. Could be improved by noting when to skip validation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds 'cosmetic only' and reveals top-left corner and fillColor behavior. Annotations indicate a write operation (readOnlyHint=false) and non-idempotent, which the description supports with the confirmWrite parameter. No contradictions or missing critical side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences deliver purpose, use case, and key parameter hints. Front-loaded with the main action. No extraneous text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 12 parameters and a schema output, the description covers the essential behavior for a drawing tool. It could mention that the rectangle is drawn on the current schematic sheet, but overall it is sufficient for an agent to understand the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 42% (5/12 parameters described). The description adds meaning for x, y (top-left corner) and fillColor ('none' for unfilled) but does not explain other parameters like color, lineType, or rotation. It partially compensates for low coverage but not fully.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('draw a rectangle'), the target resource ('schematic sheet'), and the purpose ('section dividers/grouping boxes'). It distinguishes from sibling tools by specifying cosmetic use and pairing with add_text for titles.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context for use (organizing schematic into functional blocks) and hints at pairing with add_text. While it doesn't explicitly exclude alternatives, the cosmetic-only note helps differentiate from functional drawing tools like add_wire.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnlyHint=false), the description warns about silent failure when color/fontName are invalid, adding critical behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no filler: first states purpose with examples, second adds essential behavioral warning. Front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists, return values are covered. The tool has 12 parameters but description only addresses two; however, the core functionality (placing text) is adequately described, and sibling tools are distinct.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With only 8% schema coverage, the description adds meaning to color and fontName parameters (hex string requirement, real font example, and failure warning), but 10 other parameters remain undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool places free-standing text on the schematic sheet and explicitly distinguishes it from net labels, providing specific use cases (section headers, notes, block labels).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It clarifies when to use (cosmetic/organizational) and when not to use (not a net label), but does not explicitly compare to other schematic text tools or provide alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description adds real native connectivity, global net merging, and NET_COLLISION behavior beyond annotations; no contradiction with readOnlyHint or idempotentHint.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two dense sentences with zero waste, efficiently conveying key behaviors and constraints.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers essential connectivity and collision logic, but omits output details and required parameter hints beyond schema; still adequate for the complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only 17% schema description coverage; description adds meaning to netName and points but doesn't detail color, lineType, lineWidth. Partially compensates.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool adds wires, explains net naming and collision detection, and distinguishes from sibling tools like adding components or text.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides context for when to use (connectivity, net merging) but lacks explicit exclusions or alternatives; still clear enough for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds value beyond annotations by detailing the transaction mechanism (snapshots, auto-restore) and the wire-attachment behavior for moves. Annotations only indicate non-read-only and non-idempotent, so the description enriches the behavioral model.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with zero waste. The first sentence introduces the core purpose and key safety feature; the second adds a specific use case. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers transaction safety and wire behavior, but lacks details on what properties can be modified or what a 'primitive' is. The presence of an output schema helps, so it is largely complete for typical use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 60% schema description coverage, the description adds some context (transactionId/projectId for snapshots) but does not explain the 'property' object structure or acceptable values. Baseline of 3 is appropriate as it provides minimal addition over the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'modify a schematic primitive' with a specific verb and resource. It distinguishes from sibling tools like delete or add by emphasizing safe modification and preservation of omitted fields.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains that the tool is for safe modifications with transaction support and auto-restore, and that component moves keep wires attached. It provides clear context but does not explicitly mention when not to use it or suggest alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint annotation, the description discloses that the viewport moves and that the image is delivered once as its own block. This adds significant behavioral context not captured by annotations alone.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with purpose and key limitations. Every word adds value; no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, the description does not need to cover return values. It covers input behavior, side effects, and delivery mechanism completely for a focused tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 80%, and the description adds no meaningful extra semantic detail beyond what the schema already provides (e.g., coordinate ordering acceptance is already in schema). Baseline is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Zoom...and capture as a PNG') and the resource ('rectangular region on canvas'), with the purpose of visual verification. It distinguishes from siblings like easyeda_canvas_capture by specifying region vs full canvas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use (to verify a specific area) and mentions a crucial tradeoff (viewport movement due to no offscreen API). It does not explicitly exclude alternatives like easyeda_canvas_capture, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses that commit 'removes rollback eligibility and releases the document transaction lock', adding behavioral insight beyond the sparse annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences that are direct and front-loaded, with no superfluous text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Provides essential workflow context but could explicitly mention the need for a prior begin_transaction and validation calls.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Description provides no additional meaning for parameters; with 0% schema coverage, it should clarify 'confirmWrite' and 'transactionId', but does not.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the verb 'commit' on a transaction resource, distinguishing it from siblings like begin_transaction and rollback_transaction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly mentions that commit should occur 'after its writes and validation gates succeed', providing clear usage context, though no explicit alternatives or when-not-to-use is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide readOnlyHint, idempotentHint, destructiveHint. Description adds detail about building a canonical model and specific audit checks, reinforcing no modification. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is concise (3 sentences), front-loaded with purpose, and free of redundant text. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of output schema, annotations covering safety, and simple parameters, the description sufficiently covers all necessary context for an agent to understand the tool's functionality.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 100% description coverage for all 3 parameters. Description adds no extra meaning beyond schema (e.g., doesn't explain formats or constraints). Baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses specific verbs ('Read', 'build', 'report') and clearly lists the audit items (net aliases, references, expressions, values, BOM classification). It distinguishes itself from sibling tools by emphasizing read-only and audit nature, unlike modification tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
States 'preview only; it never renames nets or changes components', conveying when to use (read-only audit). Implicitly contrasts with modification siblings, but does not explicitly name alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true. Description adds behavioral detail about scanning real pin coordinates and reporting shared ones, and explains the silent-short risk, adding value beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences that are front-loaded with purpose and efficient. Every sentence provides value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema (not shown but indicated), the description adequately covers the tool's function, usage context, and the specific risk it addresses. No gaps for a read-only check tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a single parameter described as 'The project/schematic ID'. Description does not add further meaning beyond the schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool scans pin coordinates and reports shared (x,y) as a collision risk, distinguishing it from the native NET_COLLISION guard and specifying it targets never-wired pins.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises to run after manual placement and outside easyeda_workflow_* tools, providing clear usage context. Does not explicitly state when not to use, but context is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=false, idempotentHint=true, destructiveHint=false. The description adds critical behavioral context: it opens a confirmation dialog requiring human approval, success only means request sent not components appeared, and recommends verification. This significantly exceeds what annotations alone provide, with no contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, front-loaded with the core purpose, followed by a caution and user guidance. Every sentence adds value; there is no redundancy or irrelevant detail. It is directly actionable for an AI agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists, return value explanation is not needed. The description covers the essential behavioral nuance (human approval, async effect) and post-action verification. It missed parameter guidance but that's partly covered by schema. Overall sufficiently complete for a tool of moderate complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50% (only confirmWrite has a description). The tool description adds no parameter information beyond the schema; it does not mention projectId or confirmWrite. While the schema already describes confirmWrite's constraint, the description should have clarified the role of projectId or the overall parameter usage, making this a gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it requests a schematic-to-PCB sync (SCH_Document.importChanges). The title and description together specify the verb (request sync) and resource (schematic to PCB), distinguishing it from all sibling tools, none of which offer the same sync functionality.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: it requires human approval in a dialog, and advises to verify the result with pcb_components. It implicitly tells when to use (after schematic changes needing PCB sync) but does not explicitly list alternatives or contraindications. Overall useful guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds valuable context that the tool infers electrical types from naming conventions and treats findings as a first-pass signal, which is beyond what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core action, and efficiently conveys the tool's purpose and caveat without unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given a single parameter and the presence of an output schema, the description covers the essential behavioral aspects and usage guidance, though it could slightly benefit from mentioning the output structure (but output schema likely covers that).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description does not explain the sole 'projectId' parameter, leaving its meaning implicit. It relies on the tool name and context, which is insufficient for a low-coverage scenario.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool extracts nets/devices/pins from the live schematic and runs semantic ERC, and distinguishes itself from the sibling tool 'semantic_erc_validate' by noting it is a first-pass signal.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells the agent when to use this tool (for quick auto-extraction and ERC) and when not to use it (not a substitute for semantic_erc_validate), providing clear guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint and idempotentHint. The description adds critical context: pinType is unreliable and should be treated as weak hint, which is beyond the annotations and helps avoid misinterpretation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences: first states the core function, second adds a crucial caveat. Every sentence is value-adding and there is no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given an output schema exists, the description sufficiently states what data is returned (pin numbers, names, coordinates, pinType) and the reliability caveat. No additional context is needed for this simple tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter 'primitiveId' has no schema description (0% coverage). The description minimally says 'by its primitive ID' which adds little beyond the parameter name. For a simple string parameter, the gap is small but not compensated.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves exact pin numbers, names, coordinates, and pinType for a schematic component by primitive ID. It uses specific verbs and resource, and the sibling list shows no other tool covers pins, so it is well-differentiated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description specifies the tool is for getting pin details when you have a primitive ID, and includes a caveat about pinType reliability. It does not explicitly state when not to use, but the clear purpose and warning provide good guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only indicate read-only=false and idempotent=false. The description adds critical behavioral context: writing non-exposed fields once corrupted a title block, and those fields are read-only natively. This goes beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with purpose, no wasted words. The warning is efficient and essential.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values are covered. The description covers the scope, constraints, and prerequisite (confirmWrite), making it complete for a title block update tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds that only these five fields are exposed and mentions the confirmWrite requirement, but it doesn't add significant detail beyond the schema itself.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool updates title block fields and lists the five exposed fields (Company, Version, Drawn, Reviewed, Page Size). This clearly distinguishes it from sibling tools like easyeda_schematic_add_text or easyeda_schematic_modify_primitive, which handle other schematic elements.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly warns against writing Symbol/Border/Device/etc. fields (which are read-only natively) and directs the user to fix such cases via the EasyEDA Pro UI. This provides clear when-to-use and when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint (true) and idempotentHint (false). The description adds that the image is delivered once as its own content block, which is useful behavioral info beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, each serving a purpose: first defines the action and rationale, second provides usage guidance and output format. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose, tab selection, output type (PNG image, content block), and sequencing hint. Given the tool's simplicity and presence of an output schema, the description is fully adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The sole parameter 'tabId' has no schema description (0% coverage). The description explains that it 'captures the given tab (or last-focused)', adding crucial context that the parameter is optional and defaults to the last-focused tab.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it captures the currently visible EasyEDA schematic/PCB canvas as a PNG image for visual verification. Distinguishes itself from sibling 'easyeda_canvas_capture_region' by mentioning that one for framing specific areas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises using 'easyeda_canvas_capture_region' first to frame a specific area. Clarifies that it captures the given tab or the last-focused one. Provides context for use after draw/place/route actions, though does not explicitly state when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true. Description adds value by listing the exact fields returned and the intended usage scenario, providing behavioral context beyond annotations. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence that is concise and front-loaded, listing all returned values without waste. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters, full annotations, and presence of an output schema (not shown but indicated), the description sufficiently explains what the tool returns and when to call it. Complete for its simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has zero parameters, so schema coverage is complete. Description doesn't need to add parameter information; baseline for 0 params is 4. No param descriptions needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool returns server health status with a specific list of fields (runtime version, active profile, bridge state, etc.) and positions it as the single actionable status check after connecting the bridge extension, distinguishing it from siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description explicitly says 'Intended as the single actionable status check after first connecting the bridge extension,' providing clear context for when to use it. However, it doesn't contrast with similar tools like easyeda_bridge_status or mention when not to use it, which slightly lowers the score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate write operation and non-idempotence, which the description corroborates with 'create'. The description adds behavioral context: with identification, it binds to a coincident pin; without, it is cosmetic only. This goes beyond what annotations alone provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two succinct sentences that immediately state the purpose and then explain the two modes. No redundant or unnecessary words; front-loaded with the primary action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists, the description does not need to cover return values. It covers the two modes and connection method. However, it does not address existing net flags or coordinate constraints, but these are minor given the tool's scope.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the description adds meaningful context for the identification parameter by listing the enum values and their purpose. It explains the functional difference between setting and omitting identification, and clarifies that netName should match for stubs, adding value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Create') and identifies the resource ('named net flag/label'). It distinguishes two usage modes (with identification for power flags, without for generic labels) and references a sibling action ('add_wire'), clearly differentiating from tools like 'easyeda_schematic_create_net_port'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance on when to set the identification parameter (for power/ground symbols) versus omitting it (for cosmetic net labels). It also instructs to connect pins using add_wire stubs with the same netName. However, it does not compare directly to sibling tools like create_net_port or connect_pins_by_net.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint. The description adds value by disclosing the 50-wire-per-call cap and pagination behavior. No contradictions with annotations. Additional context about primitiveId usage for delete/modify enhances transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences with no wasted words. Front-loaded with the main action, followed by pagination nuance and cross-reference. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (3 params, output schema exists), the description covers key aspects: output content, pagination cap, and purpose of primitiveId. It references checking total count for pagination. No gaps identified; output schema handles return details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 33% (only projectId described). The description compensates by explaining limit's cap and offset's role in pagination. It also clarifies the output includes primitiveId, which is critical for other tools, thus adding meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists wire segments and enumerates returned fields (primitiveId, coordinates, net name, color, style). It distinguishes from sibling tool easyeda_schematic_nets by noting that schematic_nets alone cannot resolve wire IDs, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear pagination guidance ('page with offset past 50-wire-per-call cap') and explains that primitiveId is needed for delete_primitive/modify_primitive. While not an explicit 'when to use vs alternatives', it effectively contrasts with schematic_nets, implying when to choose this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=false (write operation) and idempotentHint=false. The description adds critical behavioral details: draws real wire stubs, visible to ERC/ratsnest/autorouting, and that failing pins are reported individually. This goes beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three concise sentences, each adding value. First sentence states purpose and relation to sibling, second explains the effect, third covers error handling. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite the tool being complex (bulk write, multiple pins), the description covers what it does, the resulting behavior, and error handling. An output schema exists to provide return value details, so completeness is high.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema coverage is 100%, so the schema already explains parameters. The description adds context about the stub length default (10) and the net merging behavior. This is adequate for an agent to understand parameter usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it is a bulk variant of connect_pin_to_net, drawing real wire stubs and merging pins into one net. It distinguishes from the sibling tool easyeda_schematic_connect_pin_to_net by noting the bulk nature and error handling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Bulk variant of connect_pin_to_net' which guides when to use this tool (multiple pins) vs the singular sibling. It also mentions that failures are reported without aborting, providing usage nuance. However, it could be more explicit about when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![easyeda-mcp-pro MCP server](https://glama.ai/mcp/servers/oaslananka/easyeda-mcp-pro/badges/card.svg)](https://glama.ai/mcp/servers/oaslananka/easyeda-mcp-pro)

Score Badge

Copy to your README.md:

[![easyeda-mcp-pro MCP server](https://glama.ai/mcp/servers/oaslananka/easyeda-mcp-pro/badges/score.svg)](https://glama.ai/mcp/servers/oaslananka/easyeda-mcp-pro)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/oaslananka/easyeda-mcp-pro'

If you have feedback or need assistance with the MCP directory API, please join our Discord server