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

With no annotations to provide safety or behavior hints, the description carries the burden. It discloses the internal process: runs DC operating point via a short transient at t=0, reads voltages from labelled Grid Text nodes, and overlays them. This is valuable behavioral context, though it could mention failure modes or side effects more explicitly.

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 concise and front-loaded with the main output. The two paragraphs are efficient and each sentence contributes meaning, though the second paragraph could be tightened without losing important detail.

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 only one parameter, no annotations, and no output schema, the description covers the essential behavior, output format (SVG), and applicable use cases. It lacks explicit parameter meaning and error details, but is reasonably complete for a tool of this simplicity.

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 0%, so the description must compensate for the undocumented 'cir' parameter. However, the description never explicitly defines 'cir' or explains what value to pass. The tool context implies it is the circuit/schematic, but this is not stated, making the parameter semantics under-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?

The description clearly states the specific action: 'Render the schematic as SVG with each labelled node's DC operating-point voltage written beside it.' This distinguishes it from sibling tools like draw_schematic and plot_schematic by adding the DC annotation value.

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 context on when to use the tool: 'Best on the generated stages and other circuits that hold a stable operating point.' It does not explicitly name alternatives or exclusions, but the guidance is clear enough.

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?

With no annotations, the description carries the full burden. It discloses that the tool does not run the circuit, states what it returns (analyses and expressions), and provides sequencing advice relative to another tool. This is rich behavioral context beyond a bare 'describe'.

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, zero filler. The first sentence front-loads the core purpose; the second adds return-value detail and a usage note. Every clause earns its place.

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 tool with an output schema, the description covers purpose, behavior, and usage guidance well. The only gap is the lack of explicit parameter definition, but the output schema handles return details and sibling tool names provide context, making this nearly 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 input schema has one parameter 'name' with 0% coverage—no description in the schema. The tool description never explicitly states that 'name' refers to the reference circuit or example name, only implying it via the word 'reference circuit.' This leaves the parameter meaning ambiguous for an agent.

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 'report' with the resource 'reference circuit', and explicitly contrasts with simulate_example by adding 'without running it.' This clearly distinguishes the tool from its siblings and states what it does.

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 says 'Read this before simulate_example so you ask for an analysis that exists,' giving concrete when-to-use guidance and naming the alternative. This is clear, actionable direction for an agent.

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?

With no annotations, the description carries the full burden. It discloses that it bypasses Micro-Cap's broken batch command, draws directly from the .CIR, and returns self-contained SVG. It also notes no simulation runs, which is a behavioral constraint. It does not mention edge cases (e.g., unsupported components) but covers the essential behavior 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 appropriately sized, front-loaded with the core action, and every sentence earns its place: it explains the need (batch incompatibility), the input, the output, and a use case. It avoids fluff and is well-structured, making it easy for an agent to grasp quickly.

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 a simple 1-parameter tool with no output schema and no annotations, this description is remarkably complete. It covers what the tool does, why it exists, the input, the output type (SVG), how to use the output ('save it as .svg or embed it'), and disclaims simulation. There are no significant gaps for selecting and invoking 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?

Schema coverage is 0%, so the description must compensate. The only parameter 'cir' is implied consistently throughout: the description repeatedly references the '.CIR' source. It does not explicitly state whether it expects a file path or raw content, but the meaning is clear enough. This exceeds the schema's bare 'string' type, though explicit parameter syntax would be even better.

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 what the tool does: 'Render a .CIR schematic as an SVG picture.' It uniquely distinguishes itself from plotting with 'the *drawing*, not a plot' and explicitly positions itself relative to Micro-Cap's batch limitation. The verb 'render' and resource '.CIR schematic' are specific, and the contrast with plotting and simulation differentiates 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.

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

It provides clear context for when to use: 'Use it to *see* a circuit' without opening Micro-Cap, and explicitly excludes simulation ('No simulation runs'). However, it does not name specific sibling alternatives (e.g., 'use simulate_schematic for simulation'), instead implying them via 'not a plot' and 'no simulation runs.' This is clear but not as explicit as directly naming 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?

With no annotations, the description carries full burden. It discloses that it 'produces a drawn schematic' and returns the .CIR text, and explains how feedback resistor is sized. This gives a solid understanding of tool behavior and output format, though it omits explicit side effects or error conditions.

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?

Description is front-loaded with a clear action statement, includes concise formulas, and has a structured Args list. Every sentence adds value, and the explanation of rin's dual roles is efficient.

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 moderate complexity (6 params, 1 required) and the output schema indicating return value, the description fully specifies parameter semantics, output, and intended usage. It even covers the feedback resistor calculation and downstream use with simulate_schematic.

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 Args section explains every parameter with additional semantic detail beyond schema defaults: gain's constraints, kind's two options, rin's role depending on kind, source's Micro-Cap syntax, analysis options, and output_node label. This fully compensates for 0% schema description coverage.

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 'Draw a .CIR op-amp amplifier with a near-ideal op-amp', specifying the exact resource and distinguishing it from sibling tools like generate_transistor_amplifier. It also explains inverting/non-inverting configurations with formulas.

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 clear context for when to use (generating op-amp amplifier .CIR) and mentions 'feed it to simulate_schematic or hand the .CIR to the user' for downstream usage. However, it does not explicitly contrast with alternative generator tools, making it a 4 rather than 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?

With no annotations, the description carries the full burden. It discloses several behavioral traits: bias points computed for mid-supply output, bases driven directly by sources, no coupling caps/dividers, and the constraint 'Rc must exceed Re.' It also states the return is .CIR text. It does not mention error handling for invalid inputs, but coverage is good overall.

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 moderately long but well structured: a clear purpose statement, a short explanatory paragraph on the cascode's benefit, an Args list, and a return note. Each sentence provides relevant context, though the theory paragraph could be trimmed for a developer-focused AI without losing essential guidance.

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 moderate complexity (6 parameters, no annotations), the description covers the tool's purpose, parameter roles, key constraints, and return value. An output schema exists, so detailed return formatting is unnecessary. The description is sufficiently complete for an agent to select and 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?

Schema description coverage is 0%, yet the description compensates with an explicit Args section. It gives meaningful semantic details for all six parameters: rc/re ratio sets gain, vcc is supply voltage, source is AC drive added to bias, analysis is one of three modes, and output_node is the output label. This adds clear value 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?

The description opens with a clear verb+resource statement: 'Draw a .CIR cascode amplifier (common-emitter under common-base).' This precisely distinguishes the tool from sibling generator tools such as generate_emitter_follower and generate_differential_pair by naming the specific topology.

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 advantage of a cascode over a plain common-emitter ('Miller capacitance nearly vanishes and both output impedance and bandwidth rise'), giving clear context for when to select this tool. It does not explicitly list alternatives or when-not-to-use, but the reasoning is strong.

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?

With no annotations, the description carries the full burden. It discloses that the output is .CIR text, that the current mirror has an Early effect causing a few % deviation, and how to read the output node. This goes beyond a basic restatement.

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 a clear opening, a brief circuit explanation, and a bullet-like Args list. Every sentence adds value, including the formula for computing Iref and the note about Early effect, without being verbose.

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 no annotations, no schema descriptions, but an output schema (returns .CIR text), the description covers the key aspects: what it does, how to use it, what the parameters mean, and what output to expect. It ties into the simulation workflow by suggesting transient/DC analysis.

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 0%, so the description must explain parameters, and it does. Each of the five parameters is listed with its role (e.g., rref sets Iref) and analysis type is specified as transient or dc, providing meaning beyond the bare 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?

The description clearly states it draws a .CIR BJT current mirror, which is a specific verb and resource. It distinguishes itself from sibling tools by specifying it's a current mirror generator, not an amplifier or other 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?

It provides usage context by explaining the circuit is a DC bias block and should be run with transient/DC analysis, not AC. It doesn't explicitly name alternative tools, but this context helps an agent decide when to use it.

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?

With no annotations provided, the description carries the full behavioral burden. It clearly discloses that the tool auto-sizes bias for mid-supply, that both collectors are labelled, and that the default trace plots OUTP (with instruction to edit for OUTN). It also explains the gain relationship and that it returns .CIR text, which is transparent about output and side-effect-free generation. It could add error conditions or limitations, but for a generator it is quite thorough.

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: a concise summary paragraph, a paragraph on circuit behavior and gain, and a clear Args list. Every sentence adds value—no filler or repetition. It front-loads the core purpose and provides crucial context (gain formula, auto-sizing) without becoming bloated.

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 complexity (7 params, no annotations), the description covers the main aspects: purpose, topology, parameter semantics, and return value. It lacks an explanation of what 'analysis' values (AC, Transient, DC) actually do or how to choose among them, but the output schema likely covers return structure. The description is complete enough for a knowledgeable user to invoke correctly, with minor gaps around analysis type semantics.

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 0%, so the description fully compensates by listing all 7 parameters with semantic meaning. Each parameter's purpose is explained (e.g., 'rc: collector load on each side', 'rt: emitter tail resistor; leave unset to auto-size', 'output_node: which collector the default trace plots'). This goes far beyond the schema's parameter titles and defaults.

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: 'Draw a .CIR BJT long-tailed (differential) pair.' It explicitly names the circuit type and differentiates it from sibling generator tools by detailing the topology (matched NPN pair, tail resistor, collector loads) and the unique auto-biasing behavior.

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 implies usage for generating a differential pair circuit but does not explicitly state when to prefer this tool over alternatives like generate_amplifier or generate_cascode. It provides guidance for parameter usage (e.g., 'leave unset to auto-size') but no exclusions or comparison to siblings.

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?

With no annotations, the description carries the full burden. It discloses the circuit topology, voltage gain behavior, auto-biasing, and the return type ('.CIR text'). This goes beyond a basic statement and gives the agent meaningful insight into the tool's 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: an overview sentence, a concise circuit explanation, and a clear Args list. Each sentence adds value; there is no redundancy 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?

The description covers what it produces, how it works, parameter semantics, and how to use the output. The output schema handles return details, so no additional explanation is needed. It is complete for the tool's complexity.

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, so the description fully compensates by providing an Args section that explains every parameter: re sets bias current, r1/r2 form a divider with auto-bias behavior, and source uses Micro-Cap syntax. This is far above bare schema information.

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 begins with 'Draw a .CIR emitter follower (common-collector BJT buffer)', clearly specifying the verb, resource, and circuit type. It distinguishes from sibling generator tools by explaining the circuit's function and characteristics.

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 clear context: it explains the buffer's purpose ('drives a heavy load without loading the source') and directs the user to feed the result to simulate_schematic. However, it does not explicitly mention alternatives or 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It explains the gain formula, the auto-bias behavior based on VTO/KP, the consequence of mis-biasing (saturation drop and gain collapse), and the output being .CIR text. This is rich, non-obvious behavior that goes far beyond what the schema reveals.

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: a one-line summary, a compact paragraph of circuit behavior and key formulas, a bulleted Args list, and a return statement. Every sentence contributes substantive information, and the most important identifying information is front-loaded. No filler is present.

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

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

The description is self-sufficient for a generator tool with 9 parameters and an output schema. It covers circuit topology, biasing strategy, gain expression, parameter semantics, and the return type. It even warns about a common failure mode (mis-biasing). Given the absence of annotations, this is a complete and robust description.

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, forcing the description to compensate. The dedicated Args section defines every one of the 9 parameters, including domain-specific syntax (e.g., source as Micro-Cap value) and nuanced behavior (e.g., r1/r2 auto-bias when unset). This fully compensates for the sparse 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?

The description opens with a specific and informative statement: 'Draw a .CIR common-source MOSFET gain stage (NMOS primitive).' It names the exact circuit type and technology, distinguishing it clearly from sibling tools like generate_emitter_follower or generate_differential_pair.

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 context by specifying the circuit topology and bias scheme, and it suggests a downstream action ('Feed the result to simulate_schematic'). However, it does not explicitly state when to choose this tool over alternatives or when not to use it. No alternative tools are named, so guidance is mostly implicit.

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?

Since no annotations are provided, the description must fully disclose behavioral traits, and it does. It clarifies that the tool produces a drawn schematic rather than a netlist ('produces a drawn schematic you can open in Micro-Cap'), ensures electrical fidelity ('Every pin position is taken from Micro-Cap's own component library, so the drawn circuit is electrically what you asked for'), and states the return value ('Returns the .CIR text and the ordered part references'). No contradictions exist.

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 and front-loaded, starting with the core purpose, then context, scope, and parameter details. While moderately long, every sentence adds value: the 'Bounded on purpose' paragraph sets expectations, examples clarify usage, and the Args section is organized. No filler or repetition significant enough to reduce the score.

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

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

The description is complete given the tool's complexity. It explains the circuit topology, parameter syntax, return values, and relationship to sibling tools. An output schema exists to cover the return structure, and the description still mentions the return value. It even includes examples for common use cases and limitations, making it fully self-contained.

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 0%, so the description must fully explain parameters. It does this exceptionally: each argument (parts, source, analysis, output_node, shunt) is described with format, examples, and default behavior. For instance, parts are 'ordered "KIND=VALUE" strings in series, KIND in R/C/L, e.g. ["R=1K", "C=159.155N"]' and shunt is 'extra "KIND=VALUE" strings hung in parallel from the output node to ground.'

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: 'Draw a .CIR schematic: a voltage source driving parts in series to ground, optionally with parallel branches from the output node to ground.' It uses a specific verb ('Draw'), resource ('.CIR schematic'), and scope, and explicitly distinguishes from siblings: 'For an op-amp gain stage use generate_amplifier; for a common-emitter BJT stage use generate_transistor_amplifier.'

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 excellent usage guidance: it explains the tool's bounded purpose ('Bounded on purpose — a source, a series chain of two-terminal passives (R, C, L), and optional parallel shunt branches'), mentions what it covers ('RC/RL/RLC, dividers, and resonant tanks'), suggests a workflow ('Feed the result to simulate_schematic to run it'), and explicitly names alternatives for other circuit types ('For an op-amp gain stage use generate_amplifier...').

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?

With no annotations, the description carries the full burden and delivers: it discloses the auto-bias behavior (computed to bias collector at mid-supply, preventing saturation), the constraint Rc > Re, the return type (.CIR text), and the gain formula. No destructive aspects are hidden, and the description adds significant 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.

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

The description is well-structured with a purpose sentence, a design rationale paragraph, and a clean Args list. Every sentence earns its place, providing essential technical details without 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 tool with 9 parameters, no annotations, and no schema descriptions, this description is remarkably complete. It covers all parameters, key constraints, output format, and integration with simulate_schematic. The output schema exists, and the description explicitly states 'Returns the .CIR text', making it fully self-sufficient.

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 0%, but the description compensates fully by explaining every parameter: rc/re (gain), r1/r2 (bias divider, auto vs override), vcc, cin, source (with syntax example), analysis (AC/Transient/DC), and output_node. It adds meaning far beyond the raw schema, including defaults and constraints.

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 'Draw a .CIR common-emitter BJT gain stage (NPN primitive)' with specific verb 'draw', resource 'common-emitter BJT gain stage', and output format '.CIR'. It clearly distinguishes itself from sibling tools like generate_emitter_follower and generate_mosfet_amplifier by specifying the topology.

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 provides clear context: this is a common-emitter stage with divider bias, unbypassed emitter degeneration, and AC coupling. It also instructs to feed the result to simulate_schematic. However, it lacks explicit when-not-to-use guidance or direct comparison with sibling amplifier generators, so no 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?

With no annotations, the description carries the behavioral burden. It usefully discloses that .CKT files are plain SPICE while .CIR files contain extra schematic data (coordinates, analysis settings), which is meaningful behavioral context. It doesn't cover errors or permissions, but for a simple fetch operation this is solid.

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 exceptionally concise: two short sentences plus a focused note on file types. Every sentence earns its place, and the key purpose is front-loaded.

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 (one parameter, output schema exists), the description covers the important nuances: file format differences and how the output relates to simulate. It could mention naming conventions or examples, but it is adequately complete for an MCP tool of this scope.

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 0% description coverage, so the description must compensate, but it never explicitly explains the 'name' parameter. It implies name selects a reference circuit but provides no details about valid values or where to obtain names (e.g., via search_examples).

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 a specific verb ('Fetch') and resource ('one reference circuit's source text'), clearly identifying the tool's core function. It is distinguished from siblings like simulate_example and describe_example by emphasizing raw source text retrieval, especially the .CKT vs .CIR distinction.

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 gives clear context on when to use this tool: to obtain source text that can be fed to simulate (for .CKT) or to inspect Micro-Cap schematic data (for .CIR). It implies a workflow but does not explicitly name alternatives or state when not to use it, so it falls 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?

With no annotations provided, the description bears the full burden of behavioral disclosure. It reveals the return format (domain name -> circuit count) and the data source (Micro-Cap shipped reference circuits), implying a read-only listing operation. This is sufficient for a simple list tool, though it does not explicitly state the absence of 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.

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

The description is two sentences and front-loads the purpose, then gives the return format, and ends with practical advice. Every sentence contributes essential 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?

Given that the tool has no parameters and an output schema exists, the description adequately covers purpose, usage, and return format. It is fully sufficient for an agent to understand what does this tool do and when to invoke 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?

The tool has zero parameters, so there is no parameter schema to clarify. The description adds value by explaining what the returned data represents (domain name -> circuit count), which complements the empty input schema meaningfully.

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 clearly that the tool lists circuit-design domains for which Micro-Cap provides reference circuits. The verb 'list' and the resource 'domains' are specific, and the tool is differentiated from sibling tools that generate, simulate, or plot circuits.

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 instruction 'Start here before designing from scratch' provides clear guidance on when to use this tool, positioning it as a preliminary step before using generator or simulation tools. Although it does not mention sibling tools by name, it gives strong contextual cues for appropriate use.

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?

With no annotations provided, the description carries the full burden. It discloses that the output is a JPEG image and warns that reading values off the picture is guesswork, which is a meaningful behavioral caveat. It does not mention side effects or error handling, but for a plotting tool this is adequate.

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: the first states the core action and output, the second provides usage guidance and a contrast with simulate. Every sentence earns its place, with no fluff.

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 the main purpose, output format, and usage constraints, which is sufficient for a simple plotting tool. However, it omits parameter-level details and does not explain how the 'analysis' parameter affects the plot. Given the tool's simplicity, it is still fairly 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?

Schema coverage is 0%. The description only mentions 'netlist' implicitly and gives no information about the 'defines' or 'analysis' parameters. It does not compensate for the lack of schema descriptions, leaving agents without guidance on optional parameters.

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 that the tool runs a netlist and returns a Micro-Cap rendered plot as a JPEG image. It distinguishes itself from the sibling 'simulate' tool by specifying that it is for visual inspection only, making its purpose unambiguous.

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 says 'Use this to *look* at a waveform' and 'For numbers to reason about, use simulate', providing both a when-to-use and a when-not-to-use with a named alternative. This gives an agent clear decision-making 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?

No annotations are provided, so the description carries the transparency burden. It states the tool runs a simulation and returns a JPEG, but doesn't disclose potential side effects, prerequisites, or error behavior. It offers enough for basic understanding but lacks depth.

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 concise sentences that front-load the core function, followed by usage guidance. Every word contributes value, no 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 3-parameter tool with no output schema and no annotations, the description covers purpose and usage well but fails to document parameter semantics or output details beyond JPEG. Somewhat incomplete for an agent to invoke with confidence.

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 0%, so the description must explain parameters. It implicitly covers 'cir' by referring to .CIR schematics, but says nothing about 'points' or 'analysis' (which has a default 'ac'). This leaves the majority of parameters unexplained.

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 action: running a .CIR schematic and returning a JPEG plot. Clearly distinguishes from simulate_schematic by labeling it the 'picture companion' for visual inspection vs. numerical analysis.

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 says when to use it: to look at a schematic response, including reference or generated circuits. Also directs users to simulate_schematic when they need numbers, providing a clear 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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It adds the detail '~470 reference circuits' and clarifies search criteria ('by name or domain'), but it does not disclose limit behavior, sorting, pagination, or whether the operation is read-only. For a search tool, these are notable gaps.

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 sentence that is front-loaded with the core action and scope. No filler words. Every term ('search', '~470 reference circuits', 'by name or domain') contributes meaningful information. It is appropriately concise for a search tool with a simple interface.

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 tool has an output schema, so return values are presumably defined, but the description lacks contextual integration. It does not mention related tools like list_domains (which could provide valid domain values) or describe_example/get_example (which might be the next step after searching). The description is too isolated to fully orient the agent, especially given the many sibling tools.

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 0%, so the description must compensate. It explains that 'query' is a name or domain, adding meaning beyond the schema's bare 'Query' label. However, the 'limit' parameter is not mentioned at all; the schema only shows its type and default, leaving its purpose implicit. Partial compensation is achieved.

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 'Search the ~470 reference circuits by name or domain' clearly states the verb (search), resource (reference circuits), and scope (~470 circuits, by name or domain). This distinguishes it from siblings like get_example, describe_example, and generate_* tools.

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 no guidance on when to use this tool versus alternatives such as get_example, describe_example, or list_domains. It does not mention use cases, prerequisites, or exclusions, leaving the agent without clear direction on tool selection.

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?

With no annotations, the description carries full burden. It discloses several behavioral traits: mandatory .PRINT line, need for DC path to ground, potential convergence failures, and the need for active parts to have wired supplies. It also describes what is returned, including solver statistics and warnings.

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: a one-sentence summary, then bulleted rules that are concise and actionable, followed by parameter definitions and return info. Every section earns its place without fluff.

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 no annotations and 0% schema parameter coverage, the description covers purpose, usage guidelines, parameter semantics, and return values. It is comprehensive for a complex simulator 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?

Schema description coverage is 0%, so the description fully compensates with an Args section that explains each parameter: netlist format, analysis options, defines dictionary, and max_points cap. This adds meaning far beyond the bare 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?

The description starts with a specific verb and resource: 'Run a SPICE netlist through Micro-Cap and return the waveform data.' This clearly distinguishes it from sibling tools like simulate_schematic, which would simulate a schematic rather than a netlist.

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 explicit rules for when to use different analysis types ('ac for frequency response', 'transient for time-domain'), and advises setting time spans based on circuit constants. It implicitly differentiates from siblings by emphasizing that this tool takes plain SPICE netlists, which is a 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?

No annotations exist, so the description must carry the burden. It discloses that numeric export is enabled automatically while shipped circuits have it off, and explains the points parameter behavior (display setting often 0 producing a single useless row). These are non-obvious behavioral traits beyond 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?

The description is front-loaded with a clear purpose statement, followed by brief contextual notes and parameter explanations. Each sentence contributes value, though the section is slightly long. The Args block is parsable and well-organized.

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 an output schema exists, the description doesn't need to explain return values. It covers the tool's role, prerequisite usage (describe_example), analysis limitations, and the important points caveat. Minor gaps like the relationship between max_points and points are not explained, but overall it is sufficiently complete for practical use.

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 zero property descriptions, but the description explains all four parameters in the Args section. Particularly for 'points' it adds crucial context about the circuits' display settings and how overriding makes results usable. This significantly exceeds schema information.

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 'Run one of Micro-Cap's own reference circuits and return its data.' It specifies a specific verb (run) and resource (Micro-Cap reference circuits), and the reference to using describe_example first distinguishes it from simulation of custom circuits and other generation tools.

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 provides explicit guidance: reference circuits are the 'cheapest way to get a trustworthy baseline before modifying anything' and instructs to use describe_example first to check supported analyses. It also warns that asking for an unsupported analysis 'returns nothing useful.' It does not explicitly compare to alternatives like simulate or sweep, 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.

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

With no annotations, the description fully carries the transparency burden. It discloses significant internal behavior: numeric export is forced on, NPts is overridden to `points`, and TMIN is repaired for batch mode. It also explains why these changes are necessary (stock schematics often yield no data), which helps the agent anticipate the tool's actions.

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 structured with a summary first, then usage guidance, then behavioral notes, then parameter explanations. Every sentence adds value, including the references to get_example and simulate_example. It is longer than minimal, but the length is justified by the tool's complexity and the need for precise usage.

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 5-parameter tool with no annotations, the description covers purpose, usage, behavioral quirks, and parameters. It also references related tools for fetching examples and understanding `points`. Since an output schema exists, the description does not need to detail return values. The description is fully adequate for an agent to select and invoke this 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?

Schema description coverage is 0%, so the description must compensate. It provides an Args section that gives meaningful semantics to all parameters: schematic (full .CIR text), analysis (which analyses to run), defines (values for .DEFINE symbols), points (resolution), max_points (cap). While `analysis` remains somewhat vague, the descriptions are sufficient for basic invocation.

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: "Run a Micro-Cap .CIR schematic and return its data." It clearly distinguishes this from sibling `simulate` by stating that `simulate` is for plain SPICE netlists while this tool is for the coordinate-carrying .CIR format.

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 explicitly explains when to use it: "Use this to adapt a reference: fetch one with get_example... change a component value or two... and run the modified schematic here." It also names the alternative (`simulate`) and the exact condition for choosing this tool over it, providing a clear workflow.

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?

With no annotations, the description carries the full transparency burden. It discloses the key behavioral traits: repeated execution, the .DEFINE dependency, separate runs per value, and the max_points cap on returned samples. It also references 'Micro-Cap run' to indicate the external simulator context. It does not mention potential resource costs or confirm that files are not modified, but for a simulation/read-like tool this is a strong disclosure.

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 concise and well-structured. The first sentence states the purpose, followed by prerequisite context, then a compact Args list. It uses code-style formatting for .DEFINE and examples, making it scannable. Every sentence contributes information without redundancy or fluff.

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 complexity (5 parameters, 3 required, no annotations) and the presence of an output schema, the description is complete. It explains the prerequisite, the analysis parameter's default, and the max_points limit. It does not need to explain return values because an output schema exists, and the description covers usage and behavioral aspects sufficiently.

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 0% description coverage, but the description includes an Args section that explains each parameter: netlist, parameter, values, analysis, and max_points. Each explanation is meaningful and includes an example for values. This fully compensates for the lack of schema-level descriptions and gives the AI agent all needed semantic information.

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 combination: 'Run one netlist repeatedly, varying a .DEFINE parameter.' This clearly distinguishes sweep from the sibling simulate tool, which is for a single run, and the generate_* tools. The description also states the mechanism (varying a .DEFINE parameter) and the required deck declaration, making the tool's purpose unambiguous.

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 clear context for when to use this tool: when you need to run a netlist across multiple .DEFINE values. It also states prerequisites ('The deck must declare the symbol') and describes the per-value run behavior. However, it does not explicitly name alternatives or state when not to use it, so it falls 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.