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

Annotations already declare readOnly, idempotent, and non-destructive. The description adds valuable context beyond these: 'Altium may be started by the bridge' and error types (AD_NOT_FOUND, TIMEOUT, lock timeout). This helps the agent anticipate side effects and failure modes, though the error list is generic (referenced as 'same as other live tools').

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with labeled sections (Purpose, When to use, Parameters, Returns, Prerequisites, Errors). It is front-loaded with the purpose and immediately gives usage context. Every sentence contributes essential information, and there is no redundant repetition of schema or annotations.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (no parameters), the description fully covers the necessary context: purpose, usage timing, prerequisites, return format, and error behavior. There is no output schema, so the description appropriately explains the return value. The description leaves no critical questions unanswered for an agent.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has zero parameters, so the schema fully covers this aspect. The description explicitly states 'Parameters: None,' which removes any ambiguity. While it adds no extra meaning beyond the schema, the explicit confirmation is helpful and aligns with the baseline for zero-parameter tools.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's specific purpose: 'Verify the DelphiScript bridge responds inside Altium.' This is a concrete verb+resource combination that distinguishes it from sibling tools, and it further reinforces the distinction by explaining where it fits in the workflow relative to get_server_status and expensive reads.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides explicit guidance on when to use: 'After get_server_status looks good; before expensive PCB/schematic reads.' This gives a clear temporal and conditional usage context. It also mentions prerequisites (AD must be installed) and alludes to alternatives by positioning this tool against get_server_status.

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

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

The description goes beyond annotations by revealing the persistence side-effect: 'Writes %USERPROFILE%\.altium-mcp\config.json (or equivalent).' It also explains error behavior when the file is missing and that the env var overrides at runtime without persisting. No contradiction with idempotent=true or destructive=false.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with labeled sections (Purpose, When to use, Parameters, Returns, Prerequisites, Notes). It is concise enough while covering all relevant aspects, front-loading the primary purpose and usage trigger. No wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple one-parameter configuration tool, the description covers purpose, trigger condition, parameter semantics, return value, error case, prerequisites, and important runtime override behavior. With good annotations and full schema coverage, this is complete and leaves no gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema already provides 100% coverage with a clear description and example for 'path'. The description adds little beyond restating 'file must exist' and 'absolute path', which are already in the schema. Baseline 3 is appropriate since schema carries the full semantic load.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb and resource: 'Persist the absolute path to Altium X2.EXE for bridge launches.' It clearly distinguishes this tool from sibling get/edit tools by focusing on persistent configuration of the executable path.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It explicitly states when to use the tool: 'get_server_status shows altiumExeFound false or wrong AD version path.' It also notes an alternative (env var override) and clarifies that this method is persistent while the env var is not, giving clear decision guidance.

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

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

The description goes far beyond the minimal annotations (readOnlyHint=false, destructiveHint=true) by disclosing that it does not auto-save, that errors may start with 'ERROR:', that breakpoints in Altium can cause TIMEOUT and require lock file deletion, and that some actions create empty component shells without a library path. This gives the agent a rich understanding of side effects and failure modes.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is long but well-structured with clear headings (Purpose, When to use, Sheet targeting, Actions, Returns, Prerequisites, Notes, Debugging). Every section contributes necessary detail for the tool's 17 parameters and 13 actions; however, the length itself is a slight burden for an agent to parse, so it is not maximally concise.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has 17 parameters, no output schema, and complex action-specific behavior, the description is remarkably complete. It covers return format ('Bridge JSON result object with action, sheet, details'), prerequisites, error prefixes, Delphi-side error codes, and debugging/lock handling, leaving minimal ambiguity for an agent.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema has 0% description coverage, but the description fully compensates. It explains coordinate units (mils), rotation snapping (0/90/180/270), the exact CSV format for wires and buses (e.g., '0,0,1000,0,1000,500'), required vs optional parameters per action, and power_port_style enum values with default net names.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with 'Edit one schematic sheet (.SchDoc) via a single tool with multiple modes (action)', clearly stating the verb, resource, and scope. It enumerates concrete actions (move, rotate, set parameters, place components, add text/net labels/wires/buses) that distinguish it from read-only siblings like get_schematic_data.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The 'When to use' section explicitly lists the editing scenarios and instructs to 'call get_schematic_data on the same sheet to verify' after editing, providing a clear workflow and an alternative read tool. It also states prerequisites (target .SchDoc must belong to an open project), though it does not explicitly state when NOT to use the tool.

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

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

Beyond the annotations (readOnly, idempotent, non-destructive), the description adds valuable behavioral context: it runs in Node only (not Altium) and indicates the JSON capability flags returned. This gives the agent a clear understanding of the tool's runtime environment and output format.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise and well-structured, with clear labeled sections: Purpose, When to use, Parameters, Returns, Prerequisites. Each sentence serves a distinct function with no fluff or repetition.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a zero-parameter tool with no output schema, the description covers all essential aspects: what it does, when to use it, what it returns, and prerequisites. It is complete for the agent to decide whether to call it and interpret the result.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With zero parameters, the baseline is 4. The description correctly states 'Parameters: None' and adds no unnecessary detail. No additional parameter semantics are needed.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: 'Report offline / file-mode features.' The verb 'Report' and resource 'offline/file-mode features' are specific, and the example (Rust sidecar for .PcbLib) adds clarity. It distinguishes itself from siblings that focus on live schematic/PCB data.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides explicit when-to-use guidance: 'Check if non-live file tools exist in this build.' It also notes 'Prerequisites: None.' However, it does not explicitly mention when not to use it or name alternatives, so it falls slightly short of a full 5.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, covering the safety profile. The description adds beyond annotations by explaining the return format (String array parsed in Node), the prerequisite for an active PCB, and the lighter-response nature compared to full component data. This is useful context but not exhaustive (e.g., no pagination or error behavior).

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with labeled sections (Purpose, When to use, Parameters, Returns, Prerequisites, Notes). Each sentence delivers distinct value without redundancy, and the most critical info is front-loaded. It is appropriately concise for the tool's simplicity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple read-only tool with no parameters and no output schema, the description is complete. It covers purpose, usage guidance, return format, prerequisites, and implementation details. There are no significant gaps that would hinder an agent's correct invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has zero parameters, and the schema correctly reflects that. The description explicitly notes 'Parameters: None,' which is redundant with the schema but harmless. With no parameters, the description's job is minimal, and it fulfills the baseline for a 0-param tool.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: returning all component reference designators on the active PCB. It uses a specific verb-resource combination and distinguishes itself from siblings like get_component_pins by positioning it as a quick inventory.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly states when to use ('Quick inventory before get_component_pins') and contrasts with the heavier alternative ('Same underlying command... but lighter response'). Also mentions prerequisite of an active/focused PCB, providing clear usage context.

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

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 extra context by specifying the prerequisite of an active/focused PCB and the exact return format (JSON array of net name strings), which is especially useful given no output schema exists.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is compact and well-structured with labeled sections (Purpose, When to use, Parameters, Returns, Prerequisites). Every sentence contributes meaningful information without repetition or filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple no-parameter read-only tool, the description covers purpose, usage context, parameter absence, return type, and prerequisites. With good annotations and no output schema, this level of detail is fully adequate for an agent to invoke the tool correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has no parameters, and the description confirms 'Parameters: None'. With zero parameters, the baseline is 4, and there is nothing further to add beyond what the schema already communicates.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states 'Unique net names on the active PCB', using a specific verb-resource pair that clearly identifies the function. It distinguishes from sibling tools by focusing on net names, as opposed to layers, rules, or designators.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides explicit use cases ('Netlist-style checks, signal naming audit') but does not mention when not to use it or name any alternative tools. This gives clear context but lacks exclusions.

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

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

Annotations already declare readOnlyHint and idempotentHint as true. The description adds valuable behavioral context beyond this: error conditions ('Bridge may fail if designator missing or command errors'), prerequisites (active/focused PCB, designators must exist), and return format ('Bridge JSON with pin information'). This enriches the agent's understanding without contradicting annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with labeled sections (Purpose, When to use, Parameters, Returns, Prerequisites, Errors), each contributing unique information. It is appropriately sized, front-loaded with purpose, and free of unnecessary filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a single-parameter, read-only tool with no output schema, the description covers purpose, usage, prerequisites, errors, and a return format. However, the return description 'Bridge JSON with pin information' is somewhat vague and does not detail the exact fields returned, leaving minor ambiguity about the output structure.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema fully covers the only parameter (designators) with a description and example, so the baseline is 3. The description's 'Parameters' section repeats the same information with a different example but adds no new semantic detail beyond what the schema already provides.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's function: 'Pin-level data for selected components on the active PCB.' This specific verb+resource combination distinguishes it from siblings like get_all_nets and get_all_designators by focusing on per-component pin information.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The 'When to use' section explicitly states 'After designators are known; net names per pin, etc.,' providing clear context for when to invoke this tool. It lacks explicit exclusions or alternative recommendations, but the prerequisite of known designators is clearly conveyed.

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

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

Annotations already establish read-only/idempotent behavior, so the description adds value by disclosing prerequisites (correct .PcbDoc opened and focused) and error behavior (empty or partial data if no board focused). This goes beyond the structured data.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well organized into labeled sections (Purpose, When to use, Parameters, Returns, Prerequisites, Errors). Every sentence provides useful information without unnecessary fluff, making it highly concise and scannable.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description covers purpose, usage, parameters, return format, prerequisites, and error conditions. The return format is somewhat vague ('Bridge-specific JSON'), but for a simple listing tool this is adequate. It could mention the existence of get_pcb_layer_stackup to avoid ambiguity but otherwise is complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has zero parameters and schema coverage is 100%, so the baseline is 4. The description explicitly states 'Parameters: None,' which is redundant but consistent. No additional parameter semantics are needed.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states the tool's specific verb and resource: 'List electrical and mechanical layer metadata for the active PCB.' It clearly distinguishes its scope (active PCB) and mentions concrete use cases like 'export layer names/ids,' which helps differentiate it from sibling tools like get_pcb_layer_stackup.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is an explicit 'When to use' section with clear scenarios ('Layer stack review, export layer names/ids'). While it does not explicitly name alternatives or exclusions, the context provided is sufficient for an agent to determine when 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.

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds useful context beyond annotations by specifying the return format ('JSON stackup structure from the bridge') and the prerequisite 'Active/focused PCB.'

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with clear labels (Purpose, When to use, Parameters, Returns, Prerequisites), extremely concise, and front-loaded. Every sentence provides necessary information without redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description covers all necessary context: purpose, usage conditions, return type, and prerequisites. Combined with rich annotations, it is fully sufficient for an agent to understand and invoke the tool correctly despite the absence of an output schema.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has zero parameters, and the input schema is empty. The description explicitly states 'Parameters: None,' which is consistent and provides baseline clarity. Per the scoring guide, 0 params earns a baseline of 4.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool retrieves the physical stackup (dielectrics, thicknesses) for the active PCB, using a specific verb and resource. It distinguishes from sibling tools like get_pcb_layers and get_pcb_rules by focusing on the stackup details.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides a clear 'When to use' section specifying impedance/SI questions tied to stackup. While it doesn't explicitly mention when not to use it or alternative tools, the context is sufficient for most agents to select it appropriately.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, covering safety. Description adds return format (JSON with short descriptors) and prerequisite that an active/focused PCB must exist in Altium, both useful 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

Five labeled segments (Purpose, When to use, Parameters, Returns, Prerequisites) each one line. Highly structured, front-loaded, no filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a zero-parameter read-only tool with strong annotations, the description covers purpose, usage context, return type, and prerequisite. The only missing detail is the exact JSON shape of rule descriptors, but that is not critical for correct invocation given no parameters.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema has no parameters (100% coverage with zero fields). Description explicitly states 'Parameters: None' and clarifies that the tool operates on the active board, removing ambiguity about how the target board is specified.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States 'List PCB design rules from the active board' with a specific verb and resource. Clearly distinguishes from sibling tools like get_pcb_layers and get_all_nets.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly states 'When to use: DRC-related questions, clearance/copper rules review.' Provides clear context but does not mention when not to use or name alternative tools, so not a 5.

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

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 significant behavioral details beyond these: error code names, fallback to legacy mode on invalid include_queries, the placeholder behavior of 'harness', the limitation of not flattening pins/sheet entries, and the resolution order. There is 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is long but appropriately structured with labeled sections (Purpose, When to use, Parameters, Resolution order, Primitive shape, Prerequisites, Errors, Notes). It is front-loaded with the most important usage guidance, and every sentence provides operational value—e.g., the 'harness' placeholder, error codes, and non-flattening note prevent confusion. No filler or redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with 4 optional parameters, no output schema, and moderate complexity, the description covers all necessary aspects: what it returns (legacy vs. filtered shapes, primitive structure), how to disambiguate multiple projects, error codes, and prerequisites (open project, no active PCB needed). This is sufficient for an agent to correctly invoke the tool and interpret results.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Although schema description coverage is 100%, the description adds crucial semantics: the legacy vs. filtered mode distinction based on including include_queries, the exact effect of 'all', the resolution order hierarchy (schematic_full_path wins, then project_full_path + sheet file name, then focused project), and the relationship between sheet file name and project path. These go far beyond the schema's per-parameter descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb+resource: 'Export schematic sheet content with optional filtering'. It clearly states the purpose of avoiding context flooding, and differentiates from sibling tools by mentioning 'verify edit_schematic results' and by focusing on schematic sheet data, unlike get_pcb_layers or get_pcb_rules.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It explicitly provides a 'When to use' section: 'BOM/placement review, wiring checks, sheet size for placement, or verify edit_schematic results.' It also advises to 'Prefer include_queries with a small subset on busy designs', giving clear guidance on when and how to use the filtering. The resolution order and prerequisites offer additional unambiguous usage context.

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

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

Annotations already declare readOnlyHint=true and idempotentHint=true, but the description adds valuable behavioral detail: it 'Triggers script bundle sync into workspace/AltiumScript,' and it explains that failed bridge runs write bridge_last_error.txt and live tools append that file to the error field when success is false. This goes beyond the annotations and informs the agent of side effects and error handling.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-organized with labeled sections (Purpose, When to use, Parameters, Returns, Prerequisites, How to interpret). It front-loads purpose and usage, and every sentence provides essential information without unnecessary fluff. It is appropriately sized for a diagnostic tool.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema is present, so the description compensates by enumerating all return fields (e.g., altiumExeFound, bridgeLastError, env) and explaining how to interpret diagnostics. It also covers prerequisites, side effects, and error workflows, making it fully complete for a zero-parameter tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has zero parameters and the schema is empty, so schema coverage is 100%. The description explicitly says 'Parameters: None,' which is sufficient. With no parameters to document, the baseline of 4 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses the specific verb 'Inspect' and identifies the resource as 'MCP + Altium bridge setup.' The phrase 'before other tools' establishes its role as a diagnostic first-call function, clearly distinguishing it from siblings like altium_ping or configure_altium_exe.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It explicitly states 'When to use: First call in a session, or after MCP/Altium install or path errors.' This provides clear timing and conditions, and implicitly tells when not to use it. It also points to configure_altium_exe or env for fixing path issues, giving an alternative.

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

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 safety profile is covered. The description adds valuable behavioral context: prerequisites ('Altium running'), inclusion of non-design entries (Free Documents, AltiumScript MCP project), and a clarification about logical documents not being every editor tab. These details go beyond annotations and help the agent anticipate the tool's output and edge cases.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with labeled sections (Purpose, When to use, Parameters, Returns, Prerequisites, Notes) and is appropriately sized. Each sentence serves a purpose: the return format is described efficiently, and the notes clarify potential pitfalls without unnecessary verbosity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite lacking an output schema, the description fully specifies the return JSON structure (projectCount, focusedProjectFullPath, projects[], documents[]), making the tool's behavior predictable. It also covers prerequisites and edge cases (non-design entries, logical documents), so the agent has all necessary context to invoke and interpret results.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has no parameters (coverage 100%), and the description explicitly states 'Parameters: None,' which is clear. With zero parameters, the baseline is 4, and the description neither adds nor detracts; it simply confirms there are no arguments to worry about.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a clear, specific verb+resource: 'List every open workspace entry (projects + logical documents).' This distinguishes itself from sibling tools like get_schematic_data and get_pcb_layers, which focus on specific design data rather than the workspace project hierarchy. The purpose is unambiguous and matches the tool name.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The 'When to use' section explicitly states use cases: discover project_full_path, schematic_full_path, or confirm which .PrjPcb is focused. This provides clear context and helps an agent decide when to invoke this tool. However, it does not explicitly mention alternatives or exclusions, though the distinct domain makes confusion unlikely.

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