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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so safety is covered. The description adds useful behavioral context: it lists the full output set and explains that a Touchstone file without a frequency triggers a full-file K/μ sweep and stable-range extraction.

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?

Three tightly structured sentences: the first front-loads the computed outputs, the second covers the Touchstone-sweep behavior, and the third gives the design-stage usage cue. Every sentence earns its place with 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?

With no output schema, the description successfully explains the return contents (K/μ table, stable frequency ranges, stability circles and their stable side). The nested input schema is fully described and the description supplies the design-workflow context, leaving nothing material missing for 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?

Schema description coverage is 100%, so the schema already documents parameters thoroughly. The description's note about omitting frequency with a Touchstone file to sweep the whole file largely restates what the schema's frequency field already says, adding little new semantics.

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 exact computed quantities—Rollett K, |Δ|, Edwards-Sinsky μ and μ', unconditional-stability verdict, and source/load stability circles with stable side. This is a specific verb+resource statement that clearly separates the tool from siblings like gain_circles and noise_circles.

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

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

It gives a clear when-to-use instruction: 'Use before designing any amplifier matching network to know which source/load impedances are safe.' No explicit when-not or named alternatives are provided, but the context is unambiguous.

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 cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the bar is lower. The description still adds real behavioral context beyond them: it discloses the full analysis result set, that the sweep is optional, that bandwidth is computed only for a VSWR limit, and that tolerance analysis is deterministic corner-based ('Monte-Carlo-free'), which is a meaningful behavioral distinction. It does not discuss failure modes or how it handles malformed element chains.

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?

Front-loaded with what the tool returns before the supported-element list, and both sentences carry substantive content. The long element enumeration ('inductor, capacitor, resistor... coupled inductors') largely duplicates the schema's oneOf branches and could be trimmed without information loss.

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 exists, so the description must describe returns itself, and it does so thoroughly: per-node impedance/Γ/VSWR, input impedance with return and mismatch loss, optional S11/VSWR sweep, matched bandwidth, and tolerance corners. Combined with 100% schema coverage for the 7 inputs, an agent has everything needed to call and interpret it.

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 description coverage is 100% with 7 params, so the schema already documents every parameter including tolerance_pct, load forms, and element types. The description adds only marginal meaning (it re-lists the supported element families and notes ±tolerance_pct semantics), which the oneOf branches already convey. Baseline 3 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?

States a specific verb (analyze) and resource (cascaded RF circuit, load → components → source) and enumerates the concrete outputs: node impedances, Γ, VSWR, input impedance, return/mismatch loss, optional sweep, bandwidth, and tolerance corners. It is clearly distinguishable from the design_* siblings (which synthesize networks) because this tool only evaluates a given circuit.

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?

Gives explicit scenarios: 'verify a matching network, check an antenna tuner, or answer what impedance does the source see?'. That is clear when-to-use guidance, but it never names a sibling alternative (e.g. design_l_match or tline_input_impedance) or states when a different tool is preferable, so it stops short of the top score.

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 readOnly/idempotent/non-destructive, so safety is covered; the description adds real behavioral context beyond that: the K>1 and |Δ|<1 preconditions, and that design_networks triggers L-network synthesis that is self-verified by recomputing ΓS/ΓL. It does not describe return format or failure behavior, but it meaningfully enriches the annotation baseline.

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?

Two sentences, tightly written and front-loaded with the primary purpose and outputs before the conditional design_networks behavior. The heavy parenthetical nesting in the first sentence makes it dense, but every clause carries technical information rather than 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 nested-object, no-output-schema tool, the description covers purpose, the exact computed quantities (effectively describing the return), validity preconditions, and the optional network-design branch. It omits any mention of error/edge-case behavior when the K/|Δ| conditions fail, leaving a small gap.

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 description coverage is 100%, so the parameters are already documented and the baseline is 3. The description adds incremental meaning for design_networks beyond the schema text ('synthesize L-section input/output networks from the system Z0, verified by recomputing ΓS/ΓL'), clarifying the role of Z0 and frequency, which justifies a bump to 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 names the specific operation (simultaneous conjugate match of a two-port for maximum transducer gain) and enumerates the exact deliverables (ΓS, ΓL, ZS, ZL, GT,max/MAG, MSG, U, gain error bounds), so the agent knows precisely what the tool returns. It does not name a sibling it differs from (e.g., gain_circles or design_l_match), which keeps it short of a 5.

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 states clear applicability conditions: 'Requires K > 1 and |Δ| < 1' tells the agent when the tool is valid, and conditionally that design_networks=true adds L-section synthesis. It does not route the agent to alternative tools or state explicit when-not cases beyond the stability constraint.

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 declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the agent knows it's a safe, deterministic read. Description adds substantive context beyond annotations: returns 2-4 solutions with exact values, classifications, verified input impedance, matched bandwidth, and optional E-series rounding. It doesn't mention whether results are cached or whether the tool is computationally expensive, but the information given is rich.

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?

Front-loads the core purpose in the first sentence. Subsequent sentences add useful detail on returns, element ordering, and usage. Slightly dense but every sentence contributes; no obvious 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 synthesis tool with no output schema, the description comprehensively covers what the tool does, what it returns (2-4 solutions with component values, classifications, VSWR, bandwidth, optional rounding), element ordering, and integration with sibling tools. Nothing essential is missing for 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?

Schema description coverage is 100% (>80%), so the schema already documents all 8 parameters thoroughly. The description mentions handling complex loads/sources and optional rounding but adds no syntax or meaning beyond what the schema 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?

Specific verb 'Synthesize' + resource 'two-element lumped L-network' + explicit constraint 'matches a load to a source at one frequency.' Differentiates from siblings design_pi_t_match and design_stub_match by naming the network topology and element count.

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 an example use case ('match 25-j15 Ω to 50 Ω at 2.4 GHz') and mentions that elements can be passed to analyze_circuit or render_smith_chart. However, no explicit guidance on when to prefer L-section over pi/T or stub matching, and no stated 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 cover the safety profile (readOnly, idempotent, non-destructive), so the lower bar applies. The description adds real value beyond them: it discloses the mathematical validity constraint on Q and enumerates what is returned (all low-pass/high-pass/mixed variants with component values, virtual resistance, verification, bandwidth). No output schema exists, so this return-value disclosure matters.

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

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

Four tight sentences, front-loaded with the verb and resource, then the constraint, the return content, and finally use cases. Every sentence adds distinct information; nothing is redundant with the title or schema.

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 10-parameter tool with nested load objects and no output schema, the description covers purpose, validity constraint, return contents, and use cases adequately. It does not describe failure/error behavior beyond the Q constraint or the effect of ordering options like preference, but nothing essential for a correct call is missing.

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 coverage is 100%, so the baseline is 3. The description goes beyond the schema by explaining that Q sets the loaded bandwidth (≈ f0/Q) and that the required minimum Q derives from the impedance ratio, which gives the agent a semantic grasp of the key parameter's role.

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

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

States a specific verb ('Synthesize') and resource (three-element Pi/T lumped matching networks) and even spells out the topology element order. It explicitly contrasts itself with the L-network sibling (design_l_match), so an agent can route between them without opening either schema.

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?

Gives concrete use cases (PA output networks, harmonic filtering, 'match 10 Ω to 50 Ω with Q = 5') and a hard precondition (Q must exceed √(Rhigh/Rlow − 1)). It implies the L-network as the alternative when that constraint fails, but never names the sibling or states explicitly when NOT to use this tool, so it stops short of 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 carry the safety profile (readOnly, idempotent, non-destructive), and the description adds genuine behavioral context: the offset-line step for complex loads, the VSWR-based real-axis targets, and the conditional physical-length output tied to frequency. It also discloses return content and element ordering, which matters since 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?

Front-loaded with the formula and purpose, followed by conditional behavior and the return-content sentence. Four sentences, each informative, though the algorithm detail is dense relative to the routing guidance an agent most needs.

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

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

With no output schema, the description correctly enumerates what is returned (offset length, transformer impedance, physical lengths, verification, matched bandwidth) and notes the load→source ordering. Given the nested load object and eight parameters, this is nearly complete, missing only error/edge-case behavior.

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 description coverage is 100%, so the schema already documents all eight parameters, including the complex vs real load handling and defaults. The description adds conceptual context (the rotation step, conjugate source matching) but no per-parameter syntax or format details beyond what the schema 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?

States a specific verb and resource (design a λ/4 impedance transformer) and even gives the governing formula Z1 = √(Z0·R). An agent can distinguish this immediately from siblings like design_l_match, design_pi_t_match, and design_stub_match.

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 explains the internal approach (real loads matched directly, complex loads get a rotating Z0 section) but never states when to choose this topology over the sibling matching tools. Usage is implied by the matching context rather than compared against alternatives.

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 readOnly/idempotent/non-destructive, and the description adds real substance on top: returns ALL solutions in wavelengths, degrees and physical length (with eps_eff/velocity_factor), plus verification and matched bandwidth, and states component ordering (load → source) for downstream tools. With no output schema, this carries the return-value burden well.

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?

Three dense sentences, front-loaded with purpose and the computed quantities before the return/chaining detail. Nearly every clause carries information, though the parenthetical citations and return enumeration make it slightly heavier than needed.

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 an 11-parameter, nested-object tool with no output schema, the description covers what the tool computes, what it returns, and how the result plugs into sibling tools. It does not explain defaults/fallbacks for the many optional impedance and line parameters, but those are fully covered by the 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?

Schema coverage is 100%, so all 11 parameters are already documented, which sets the baseline at 3. The description only loosely links parameters ('open- or short-circuited stub (shunt or series)', 'when frequency is given') without adding format or constraint detail beyond the schema.

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?

Names a specific verb+resource ('single-stub tuner design'), specifies exactly what is computed (distance d from load, stub length ℓ, open/short, shunt/series), and cites Pozar §5.2. It is clearly distinguishable from design_l_match, design_pi_t_match and design_quarter_wave.

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?

Gives a positive usage context ('microstrip/coax stub tuners and textbook Smith chart stub problems') and notes the output feeds analyze_circuit / render_smith_chart, which is genuinely useful chaining guidance. It stops short of naming when to prefer a sibling topology (L-match, Pi-T, quarter-wave) instead, so no explicit 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 readOnly/idempotent/non-destructive, so the safety profile is covered. The description adds real behavioral value by disclosing the return contents (centre in Γ and Z, radius, achievability flag, reference maximum MAG/MSG or G_S,max/G_L,max) and the ladder behavior when gains_db is omitted.

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

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

A single dense paragraph that is front-loaded with purpose, then type semantics, then return values, then the plotting hand-off. Every sentence carries information, though it is information-heavy enough that it borders on terse for a physics-domain 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 exists, and the description compensates by naming the returned quantities (centre, radius, achievability, max gain reference). Combined with 80% schema coverage and the plotting hand-off, it is nearly complete; minor gaps remain around error/precondition behavior for the Touchstone path.

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 coverage is 80%, so the schema carries most parameter detail. The description still enriches semantics by explaining what each 'type' enum value computes and the special meaning of gains_db for unilateral types plus its omission behavior, going beyond the schema's short field notes.

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

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

States a specific verb+resource ('Constant-gain circles for amplifier design') and enumerates the four circle types ('available', 'operating', 'unilateral_source', 'unilateral_load') with their defining formulas, distinguishing it clearly from siblings like noise_circles and amplifier_stability.

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?

Gives explicit routing for the 'unilateral_source'/'unilateral_load' types (S12≈0 designs) and the omit-gains_db case, and names the follow-up sibling ('Pass the circles to render_smith_chart'). It lacks explicit when-not guidance versus other matching tools, so a 4 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, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds real behavioral context beyond structured data: the 'exactly ONE of' input constraint, that vswr/return_loss_db require an optional gamma_angle_deg, and that supplying a frequency additionally returns series/parallel R+L/C element values.

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?

Front-loads what the tool converts, then immediately states the input constraint, then the frequency-dependent output, then three illustrative queries. No filler sentences; every clause adds selection or invocation value.

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 10-parameter, no-output-schema converter, the description adequately covers inputs, the one-of rule, and the shape of what is returned (VSWR, return loss, mismatch loss, delivered power, Q, and L/C elements with frequency). Minor gap: it does not clarify units/format for the returned summary or how the language parameter affects output.

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 description coverage is 100%, so the baseline is 3. The description goes beyond the schema by explaining the mutual-exclusivity rule across the five input quantities and how vswr and return_loss_db combine with gamma_angle_deg, which the per-parameter schema descriptions only hint at.

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

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

States a specific verb (convert) and resource (RF impedance/admittance/reflection-coefficient quantities), and enumerates exactly which quantities are produced. An agent can distinguish this from siblings like design_l_match or parse_touchstone purely from the description.

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?

Gives clear context ('Convert one RF quantity into all the others') plus concrete invocation examples such as 'what is the VSWR of 75 Ω on 50 Ω?'. It states the one-of input rule, which effectively tells the agent when the tool applies, but it never names an alternative tool or a when-not-to-use condition.

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 non-destructive, so the safety profile is fully covered. The description adds useful behavioral context — interpolation at frequency, fallback from .s2p noise block to explicit parameters, and the conditional gain evaluation — but does not mention output format or edge cases like NF below NFmin. With annotations doing the heavy lifting, a 3 is appropriate.

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?

Two information-dense sentences that front-load the core computation and then the optional evaluation. Near-optimal, though the parenthetical interpolation/defaults make it slightly dense for a 10-parameter 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?

Given 10 parameters, full schema coverage, and strong annotations, the description covers the main computational path, the dual input modes (Touchstone vs explicit), and the optional downstream analyses. It lacks return-value guidance, but no output schema exists, so a small gap remains.

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 description coverage is 100%, so every parameter (rn units in Ω not normalized, z0 default, nf_db defaults, device/touchstone options, gamma_opt, source_gamma vs source_impedance) is already documented in the schema. The description does not add syntax or format detail beyond noting the .s2p noise block origin, so the baseline 3 applies.

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 specific verb (draw/compute constant noise-figure circles), specific domain object (source ΓS plane), and the exact inputs (NFmin, Γopt, Rn). Distinguishes from sibling gain_circles by scope and names the LNA input-matching use case.

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 final sentence 'Use for low-noise amplifier (LNA) input matching' gives clear context, and the description notes the optional evaluation path for a proposed source impedance. It does not, however, explicitly name alternatives like gain_circles or state when not to use this 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?

Annotations already declare readOnly=true, idempotent=true, destructive=false and openWorld=false, so the safety profile is covered. The description adds genuine behavioral context beyond that: the accepted format dialects (MA/DB/RI) and frequency-unit agnosticism, plus what the returned summary synthesizes. It omits auth/permission or error behavior, which keeps it short of a 5.

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?

Effectively one long sentence, but it is front-loaded with the core verb+resource before enumerating outputs, and every clause (formats, port-specific metrics, noise parameters) carries information. Dense yet economical; a slightly lighter enumeration would read better but nothing is wasted.

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

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

With no output schema, the description correctly assumes the burden of describing returns and does so comprehensively, covering both 1-port and 2-port outputs plus noise parameters. It leaves minor gaps on invalid-input/error handling and on how path and content interact, so not a full 5, but it is complete enough for 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?

Schema description coverage is 100%, so the schema already documents language, max_rows, touchstone_path and touchstone_content including their defaults and path-vs-content tradeoff. The description adds no parameter-level detail beyond the 1-port/2-port scope implied by the summary contents, so the baseline 3 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?

Specific verb+resource: reads a Touchstone v1 S-parameter file and summarizes it. It explicitly enumerates what the summary contains (port count, reference impedance, frequency range, per-frequency table, stability, noise parameters), making it trivially distinguishable from the design/analysis siblings without opening any schema.

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?

Clear context is given: it is for files from a VNA, simulator or datasheet, and the description notes it handles MA/DB/RI formats and any frequency unit. No explicit when-not or alternative routing is offered, but no sibling competes for this job, so the context is sufficient without an exclusion.

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=false, idempotentHint=true and destructiveHint=false, and the description is consistent with them by disclosing the write behavior: optional output_path writes the file, with format 'both' writing two files. It adds useful context (rendering engine, file output) but does not discuss failure modes or overwrite semantics.

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

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

A single dense paragraph, but it is front-loaded with purpose and format before enumerating layers, and every sentence conveys a distinct capability. It is longer than ideal and slightly run-on, though nothing is clearly redundant.

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 16-parameter, deeply nested tool with no output schema, the description covers the full set of renderable layers and states the return format, so an agent can compose a call without opening the schema. It omits only peripheral details like error conditions or file-overwrite behavior.

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 coverage is 94%, so the schema carries most parameter meaning (baseline 3). The description still adds value by explaining layer intent — VSWR circles, constant-Q contours, Γ-plane circle centres, amplifier overlays with shaded unstable side — and that components run load → source, which the schema alone states less plainly.

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?

Specific verb+resource ("Draw a publication-quality Smith chart") with output format stated immediately (PNG via resvg and/or SVG). It enumerates the exact layer types it can render, which cleanly separates it from siblings like analyze_circuit, gain_circles, and noise_circles that compute rather than draw.

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?

Gives clear workflow context: circles can come from gain_circles / noise_circles / amplifier_stability and circuit format is 'same format as analyze_circuit', which routes the agent to the right producers. It lacks an explicit when-not or a stated call ordering, so it stops short of full when/alternatives 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?

Annotations already declare readOnly/idempotent/non-destructive, so the safety profile is covered. The description goes further by disclosing the full return set (Γ at load and input, electrical/physical length, guided wavelength, distances to first voltage max/min) and noting it handles lossy or lossless lines — genuine 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.

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

Front-loads the operation and its formula, then returns, then use cases — a sensible ordering. Three dense sentences with no filler, though the inline formula is somewhat heavy and the return list could be trimmed.

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 an 11-parameter tool with no output schema, the description usefully enumerates what comes back and clarifies the length/loss/unit model. Combined with 100% schema coverage, an agent has what it needs; only the absence of explicit prerequisites (e.g. frequency required for physical lengths is left to the schema) keeps it from a 5.

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 description coverage is 100% and every parameter (z0, load, length, eps_eff, velocity_factor, etc.) is already documented in the schema, including unit formats and defaults. The description restates the formula and unit conventions but adds little semantic detail the schema lacks, so the baseline of 3 applies.

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

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

States a precise verb+resource — input impedance of a transmission line terminated in a load — and even supplies the governing equation. This is unmistakably distinct from siblings like impedance_convert (a pure impedance transform) or the design_* matching tools, which an agent can tell apart without opening schemas.

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?

Gives concrete usage context: 'Use for coax/microstrip/λ/4/λ/2 line questions and where-is-the-voltage-minimum problems.' That's clear routing, but it names no alternative tool and states no when-not-to-use condition, so it stops short of 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 readOnly, idempotent, non-destructive, and closed-world, so the safety profile is covered. The description still adds genuine context beyond them by disclosing that responses also include runtime capabilities (PNG rendering, filesystem access), which an agent would not learn from the schema.

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

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

Front-loaded with purpose, then a compact mode-by-mode breakdown. Efficient and scannable, though the parenthetical example for 'since' slightly duplicates the schema's own example.

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?

There is no output schema, but the description compensates by describing what each mode returns (version, release date, release notes, per-release history, full history, runtime capabilities). An agent has everything needed to call it correctly 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?

Schema description coverage is 100%, so all four parameters are self-documenting. The description reinforces the semantics of all/since/version by mapping each to an outcome, but adds no syntax or constraint detail beyond the schema, and never mentions the 'language' enum parameter.

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

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

States a specific verb and resource ('Report which version of smith-charts-mcp is running and what changed between versions') and clearly distinguishes itself from the design/chart-rendering siblings. An agent knows immediately this is a metadata/introspection tool.

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?

Enumerates every mode of invocation with the exact selection condition: no arguments for current release, 'version:' for one release's notes, 'since:' for changes after a version (with a natural-language example), and 'all:' for full history. Nothing about argument choice is left to inference.

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