Generate 12V/24V/48V wiring diagrams and size wires, fuses, batteries, solar, and inverters.
Scored across 9 tools
The tools map to distinct calculation steps in system sizing (power budget, solar, battery bank, inverter, charging time, wire gauge) plus two diagram tools. The main potential confusion is calculate_battery_bank vs calculate_battery_config, but the descriptions clearly separate capacity sizing from series/parallel arrangement, and the pipeline ordering (power budget as 'first step') further disambiguates.
Every tool follows a strict snake_case verb_noun pattern: calculate_*, generate_*, list_*. The verbs are meaningful and consistent, and the nouns name the specific quantity or artifact being produced.
Nine tools is well within the ideal 3-15 range, and each one covers a discrete sizing calculation or diagram operation with no filler. The set feels deliberately scoped rather than padded.
The surface covers the full sizing pipeline end to end, from load budget through battery, solar, inverter, charging, and wiring, terminating in diagram generation with an editor link. Minor gaps exist: no dedicated MPPT/charge-controller or DC-DC charger sizing tool, and fuse sizing is only a side output of calculate_wire_gauge rather than a standalone step.
Calculate the recommended battery bank size based on daily energy consumption. Accounts for days of autonomy (how many days without charging) and depth of discharge. Returns required capacity, number of batteries, and wiring configuration.
| Name | Required | Description | Default |
|---|---|---|---|
| systemVoltage | Yes | Target system voltage in volts (e.g. 12, 24, 48) | |
| daysOfAutonomy | No | Days the system should run without any charging (default: 2) | |
| singleBatteryAh | Yes | Capacity of a single battery in amp-hours (e.g. 100, 200) | |
| dailyConsumptionWh | Yes | Daily energy consumption in watt-hours (from calculate_power_budget) | |
| singleBatteryVoltage | Yes | Voltage of a single battery (e.g. 12.8 for LiFePO4, 12 for lead-acid) | |
| depthOfDischargePercent | No | Usable percentage of battery capacity. LiFePO4: 80-90%, AGM: 50%, Gel: 50% (default: 80) |
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 description's job is to add calculation behavior — which it does by naming the factors used (autonomy days, depth of discharge) and the outputs produced. It stops short of stating assumptions or caveats for edge cases, keeping it below 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?
Three tight sentences: purpose first, then the calculation factors, then the return values. No filler, though the middle sentence largely echoes parameter names already documented in the 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?
With full schema coverage and no output schema, the description supplies enough to call the tool correctly and even summarizes the three return values. Missing is any mention of the battery-config sibling or of assumptions when mixing battery types.
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%, with every parameter individually documented including defaults and example values, so the baseline is 3. The description restates days-of-autonomy and depth-of-discharge conceptually but adds no syntax or unit 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?
States a specific verb and resource ('Calculate the recommended battery bank size') and names the inputs it depends on. It does not, however, distinguish itself from the closely-named sibling calculate_battery_config, leaving an agent to guess which sizing tool to pick.
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 the upstream dependency on daily energy consumption (the schema explicitly points to calculate_power_budget), giving some context for when the tool fits a workflow. It offers no explicit when-not guidance and never mentions the alternative sibling calculate_battery_config.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Determine how to arrange batteries in series and/or parallel to achieve a target voltage and capacity. Returns the number of batteries needed, the wiring configuration (e.g. 2S3P), and step-by-step wiring instructions.
| Name | Required | Description | Default |
|---|---|---|---|
| targetVoltage | Yes | Desired system voltage (e.g. 12, 24, 48) | |
| singleBatteryAh | Yes | Capacity of one battery in amp-hours | |
| targetCapacityAh | Yes | Desired total capacity in amp-hours | |
| singleBatteryVoltage | Yes | Nominal voltage of one battery (e.g. 12.8 for LiFePO4, 12 for lead-acid, 3.2 for LiFePO4 cells) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, non-destructive, and closed-world behavior. The description adds useful behavioral context by stating the return values: battery count, wiring configuration notation (e.g. 2S3P), and step-by-step wiring instructions. It does not cover edge cases such as rounding when the target is not exactly achievable, but the output disclosure is substantive.
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, front-loaded with purpose and followed by return values. No redundant or filler content; every sentence contributes to understanding what the tool computes.
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 read-only calculator with four required, fully described parameters and no output schema, the description is nearly complete: it explains purpose and expected outputs. It stops short of clarifying the relationship with calculate_battery_bank or stating assumptions about rounding and infeasible targets.
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 all four parameters are clearly documented with types and examples. The description adds no parameter-level semantics beyond restating target voltage and capacity, so the schema carries the full burden and 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?
States a specific verb and resource: determines series/parallel battery arrangement for a target voltage and capacity, and explicitly names what is returned. However, it does not distinguish itself from the sibling tool calculate_battery_bank, which sounds highly overlapping and could confuse an agent choosing between them.
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 what the tool does but gives no when-to-use guidance, no exclusions, and no reference to alternatives. Given the presence of a similarly named calculate_battery_bank sibling, this omission is a real gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Estimate how long it takes to charge a battery bank from a given state of charge to a target level. Accounts for the bulk charging phase (constant current, up to ~80% SoC) and the slower absorption phase (tapering current, 80-100% SoC). Works for any charging source: solar, shore power, alternator.
| Name | Required | Description | Default |
|---|---|---|---|
| batteryVoltage | Yes | Battery bank voltage (e.g. 12, 24, 48) | |
| chargePowerWatts | Yes | Charger output power in watts | |
| batteryCapacityAh | Yes | Total battery bank capacity in amp-hours | |
| chargeCurrentAmps | No | Maximum charge current in amps (if limited by the charger or battery BMS). If omitted, calculated from power and voltage. | |
| targetStateOfChargePercent | No | Target state of charge in percent (default: 100) | |
| currentStateOfChargePercent | Yes | Current state of charge in percent (e.g. 20 for 20%) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare this is a safe, idempotent, closed-world read/compute operation, so the safety burden is lifted. The description earns credit by disclosing the underlying model that shapes the answer: bulk constant-current phase to ~80% SoC, then tapering absorption phase to 100%, applicable to solar, shore power, or alternator. That context matters for interpreting the result, though it doesn't mention assumptions about efficiency losses or whether the estimate is an upper/lower bound.
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 short sentences: the purpose comes first, then the modeling assumptions that qualify the answer, then applicable charging sources. No filler, though the final sentence is closer to nice-to-have than essential.
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 should convey enough to anticipate the return, and the two-phase discussion does that for a simple numeric estimate. Minor gaps: it doesn't state the unit of the returned duration or note that absorption time is an approximation, which would help an agent present 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 every parameter is already documented in the schema. The description adds no syntax, unit, or edge-case guidance beyond what the schema provides (e.g., no note on how chargeCurrentAmps overrides the power-derived current). 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 a specific verb and resource ('Estimate how long it takes to charge a battery bank') plus the scope (from a given SoC to a target level). It is clearly distinguishable from siblings like calculate_battery_bank or calculate_power_budget by resource, though it never explicitly contrasts itself with them.
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?
Usage is implied by the description — use this when you need a charge-duration estimate for a battery bank. There is no explicit when-not-to-use condition and no alternative tool is named, so the agent must infer boundaries from the sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Calculate the recommended inverter size for running AC loads from a DC battery system. Accounts for continuous power, startup surge power (motors typically surge 2-3x), and includes a 25% headroom for the continuous rating. Returns the recommended inverter wattage and the DC current draw at system voltage.
| Name | Required | Description | Default |
|---|---|---|---|
| loads | Yes | List of AC loads that will run through the inverter | |
| systemVoltage | Yes | DC system voltage (e.g. 12, 24, 48) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the read-only/idempotent/non-destructive profile, and the description adds genuine calculation semantics: 25% headroom on the continuous rating, the 2-3x motor surge assumption, and the two returned values. It stops short of saying how the surge is combined with headroom or whether standard inverter sizes are snapped to.
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 tight sentences: what it computes, what it accounts for, and what it returns. Every sentence carries information and the 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?
With no output schema, the description does name the returned values (recommended wattage, DC current draw) and the safety profile is covered by annotations. Minor residual gaps are the treatment of surge-plus-headroom interaction and whether discrete standard sizes are suggested.
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, but the description adds interpretive domain meaning to the inputs, clarifying that continuous power and startup surge are treated differently and that systemVoltage drives the DC current result. That meaning is not in the schema field descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb (calculate) and resource (recommended inverter size) and scopes it to AC loads fed from a DC battery system. That subject matter alone separates it cleanly from siblings like calculate_battery_bank or calculate_solar_size.
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?
Usage is implied by the AC-load-to-DC-system framing, but the description never states when to choose this over calculate_power_budget or calculate_charging_time, nor any prerequisites. It is adequate context without explicit routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Calculate total daily energy consumption from a list of electrical loads. Each load specifies its power draw, how many hours per day it runs, and quantity. Returns total daily energy (Wh and Ah), peak power draw, and average power. This is typically the first step in sizing a battery bank and solar system.
| Name | Required | Description | Default |
|---|---|---|---|
| loads | Yes | List of electrical loads to include in the budget | |
| systemVoltage | Yes | System voltage in volts (e.g. 12, 24, 48) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already establish that this is a read-only, idempotent, non-destructive, closed-world calculation. The description adds useful behavioral context by naming the returned metrics: daily energy in Wh and Ah, peak power draw, and average power. It does not discuss calculation assumptions such as efficiency losses, but it does not contradict 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?
The description is three tightly written sentences with no wasted language. It front-loads the core action, then summarizes inputs and outputs, then gives the workflow context last.
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, so the description carries the burden of explaining return values, and it does so by listing daily Wh and Ah, peak power, and average power. The main remaining gap is that it does not mention calculation assumptions or system voltage's role explicitly, though the schema covers that parameter.
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 both top-level parameters and the nested load fields. The description reinforces that each load includes power draw, hours per day, and quantity, but adds little syntax or interpretation beyond what the schema provides. The baseline score of 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?
The description states a specific verb and resource: calculating total daily energy consumption from a list of electrical loads. It also positions the tool relative to siblings by calling it the first step in sizing a battery bank and solar system, making its scope distinct from calculate_battery_bank and calculate_solar_size.
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 usage context by saying this is typically the first step in sizing a battery bank and solar system. It does not explicitly list when not to use it or name alternative sibling tools, but the workflow positioning is enough to guide selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Calculate the required solar panel wattage to cover daily energy consumption. Accounts for peak sun hours at the location and system efficiency losses (MPPT conversion, wiring, temperature derating). Returns required wattage and common panel configurations.
| Name | Required | Description | Default |
|---|---|---|---|
| peakSunHours | Yes | Average daily peak sun hours for the location. Examples: Northern Europe winter 1-2h, summer 4-6h. Southern US 5-6h. Equatorial regions 5-7h. | |
| systemEfficiency | No | Overall system efficiency factor (default: 0.85). Accounts for MPPT losses, wiring losses, temperature derating, and panel soiling. | |
| dailyConsumptionWh | Yes | Daily energy consumption in watt-hours (from calculate_power_budget) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, non-destructive and closed-world, so the safety profile needs no restating. The description usefully adds which loss factors are modeled and what is returned ('required wattage and common panel configurations'), but says nothing about assumptions, edge cases, or limits on inputs.
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 sentences, front-loaded with the purpose, then method, then return value. No filler, though the parenthetical loss list partially duplicates the systemEfficiency schema description.
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 two return values. For a simple, fully annotated, single-purpose calculator with fully documented parameters, little an agent needs 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 description coverage is 100% and every parameter is documented with units, defaults and example ranges, so the schema does the heavy lifting. The description only mentions efficiency losses conceptually and adds no syntax or format detail beyond the schema — baseline 3.
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 ('calculate the required solar panel wattage to cover daily energy consumption') and names the inputs it accounts for. The resource is clearly distinct from the battery/inverter/wire siblings, though it never names an alternative explicitly.
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?
Usage is implied by 'to cover daily energy consumption', which ties it to the power-budget workflow, but there is no explicit when-to-use or when-not, and no stated prerequisites (e.g. that consumption should come from calculate_power_budget first).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Calculate the recommended wire gauge / cable cross-section for a DC circuit. Considers both ampacity (current carrying capacity) and voltage drop to recommend the optimal cable size. Also returns total resistance, power loss, and a fuse recommendation. Supports copper conductors from 0.75 mm² (18 AWG) to 240 mm² (300 MCM).
| Name | Required | Description | Default |
|---|---|---|---|
| power | No | Load power in watts. Will be converted to current using the voltage. Provide either current or power. | |
| current | No | Load current in amps. Provide either current or power. | |
| voltage | Yes | System voltage in volts (e.g. 12, 24, 48) | |
| isRoundTrip | No | Account for both positive and negative conductor (default: true). Set to false for chassis-ground returns. | |
| cableLengthM | Yes | One-way cable length in meters | |
| temperatureCelsius | No | Ambient temperature in °C (default: 20°C). Affects copper resistance. | |
| maxVoltageDropPercent | No | Maximum acceptable voltage drop in percent (default: 3%) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish read-only, idempotent, non-destructive, closed-world behavior. The description adds that the calculation considers both ampacity and voltage drop and returns resistance, power loss, and a fuse recommendation; it still does not describe output format or edge-case behavior, but with annotations covering safety 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 uses four compact sentences: purpose, calculation basis, additional returns, and supported conductor range. It is front-loaded and every sentence contributes useful scope without repetition or waste.
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 read-only calculator with full parameter schema coverage and annotations, the description covers purpose, calculation basis, supported conductor range, and several return values. Because there is no output schema, it could be more complete about the exact response shape, such as whether voltage-drop and ampacity values are included, but it is largely 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 description coverage is 100%, so each parameter already has documentation and the description only needs to add meaning beyond the schema. It mentions ampacity and voltage drop conceptually but provides no additional parameter syntax, defaults, or constraints beyond what the schema already states.
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 a specific verb ('Calculate') and resource ('wire gauge / cable cross-section') for DC circuits, and enumerates the criteria and extra outputs, so the core purpose is unambiguous. It does not explicitly contrast itself with sibling calculators, so it stops short of full sibling differentiation.
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 scopes usage to DC circuits and copper conductors from 0.75 mm² to 240 mm², which implies appropriate context. It does not state when to use a sibling tool or when not to use this one, such as for AC or aluminum conductors, so guidance is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate an electrical wiring diagram for campers, boats, or off-grid setups. Returns the schematic as an image (batteries, chargers, protection components, loads) and a link that opens it in the VoltPlan editor to refine, save and turn into a shopping list. Protection components (shunt, main switch, low-voltage cutoff) are auto-generated when both batteries and loads are provided. Show the user the editor link.
| Name | Required | Description | Default |
|---|---|---|---|
| loads | No | Electrical loads / consumers | |
| format | No | png (default): an image the client displays. svg: SVG markup as text, without component icons, for clients that save or post-process files. | png |
| chargers | No | Chargers with their power sources | |
| batteries | No | Batteries in the system | |
| systemName | Yes | Name of the electrical system (e.g. "My Camper Van") |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, non-destructive behavior, so the bar is lower. The description still adds real value beyond that: it discloses the return payload (schematic image plus editor link), the conditional auto-generation of shunt/main switch/low-voltage cutoff, and a required UX action (show the link).
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 sentences, front-loaded with the purpose and output, then the conditional behavior, then the actionable instruction. Each sentence carries information; only the parenthetical component list is mildly redundant with the 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?
With no output schema, the description takes on the burden of explaining return values and does so precisely (image plus editor link, plus the svg-format alternative documented in the schema). Combined with the read-only annotations, an agent has everything needed to call and use this 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 100%, so the parameters are fully documented in structured form. The description mentions the key input categories (batteries, chargers, loads, protection components) but adds no syntax or format guidance beyond the schema, 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?
The description opens with a specific verb and resource ('Generate an electrical wiring diagram') and scopes the domain to campers, boats, and off-grid setups. This clearly separates it from the sibling calculate_* tools, which compute values rather than produce diagrams.
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?
Implicit context for use is clear (vehicle/marine/off-grid system diagrams), and the description states a concrete trigger condition for auto-generating protection components ('when both batteries and loads are provided'). It also gives the agent a follow-up instruction to show the editor link. It stops short of naming when not to use it or pointing at a specific alternative sibling.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all available component types and example configurations for building wiring diagrams. Use this to understand what parameters are needed before calling generate_wiring_diagram.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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 covered. The description adds that the response contains example configurations, which tells the agent what it gets back beyond a bare list.
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 short sentences with no waste. The purpose comes first and the calling guidance second, in the order the agent needs them.
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 should say what comes back. It does so at a high level ('component types and example configurations'). That is enough for the agent to decide whether to call it, though it could note the response shape more precisely.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so the baseline is 4. There is nothing about parameter meaning that the description could or should add.
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 ('List all available component types') and adds what the content includes ('example configurations for building wiring diagrams'). This clearly distinguishes it from the calculate_* siblings and from generate_wiring_diagram.
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 tells the agent when to use it: 'Use this to understand what parameters are needed before calling generate_wiring_diagram.' That gives a clear precondition and names the downstream tool. No explicit exclusions, but none are really needed for a reference-listing tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
generate_wiring_diagram13 fields changedInput schema / properties / batteries / items / properties / capacityAh / descriptionPrevious value: -"Capacity in amp-hours"New value: +"Capacity in amp-hours. Give this or energyWh."Input schema / properties / batteries / items / properties / energyWh / descriptionPrevious value: -"Energy in watt-hours"New value: +"Energy in watt-hours. Calculated from capacityAh × voltage when omitted."Input schema / properties / batteries / items / properties / voltage / descriptionPrevious value: -"Nominal voltage (e.g. 12)"New value: +"Nominal voltage (e.g. 12, or 12.8 for LiFePO4)"Input schema / properties / batteries / items / requiredPrevious value: -[
- "name",
- "voltage",
- "capacityAh",
- "energyWh"
-]New value: +[
+ "name",
+ "voltage"
+]Input schema / properties / chargers / items / properties / outputVoltage / descriptionPrevious value: -"Output voltage"New value: +"Output voltage. Defaults to the first battery's voltage (or 12 V)."Input schema / properties / chargers / items / requiredPrevious value: -[
- "name",
- "inputVoltage",
- "outputVoltage",
- "power"
-]New value: +[
+ "name",
+ "inputVoltage",
+ "power"
+]Input schema / properties / format / defaultPrevious value: -"svg"New value: +"png"Input schema / properties / format / descriptionPrevious value: -"Output format: svg (recommended, renders inline) or png (base64-encoded image, may not display in all clients)"New value: +"png (default): an image the client displays. svg: SVG markup as text, without component icons, for clients that save or post-process files."Input schema / properties / format / enumPrevious value: -[
- "svg",
- "png"
-]New value: +[
+ "png",
+ "svg"
+]Input schema / properties / loads / items / properties / current / descriptionPrevious value: -"Current draw in amps"New value: +"Current draw in amps. Calculated from power / voltage when omitted."Input schema / properties / loads / items / properties / power / descriptionPrevious value: -"Power consumption in watts"New value: +"Power consumption in watts. Give this or current."Input schema / properties / loads / items / properties / voltage / descriptionPrevious value: -"Operating voltage"New value: +"Operating voltage. Defaults to the first battery's voltage (or 12 V)."Input schema / properties / loads / items / requiredPrevious value: -[
- "name",
- "power",
- "voltage",
- "current"
-]New value: +[
+ "name"
+]generate_wiring_diagram1 field changedInput schema / properties / chargers / items / properties / inputVoltage / descriptionPrevious value: -"Input voltage"New value: +"Input voltage. For shore/generator (AC) chargers use the regional mains voltage: 230 V in Europe, UK, Australia, most of Asia and Africa; 120 V in North America and Japan. For solar/wind use the panel or turbine output voltage. For alternator use the vehicle system voltage (typically 14 V)."calculate_battery_bankcalculate_battery_configcalculate_charging_timecalculate_inverter_sizecalculate_power_budgetcalculate_solar_sizecalculate_wire_gaugegenerate_wiring_diagram1 field changedInput schema / properties / chargers / items / properties / sourceType / enumPrevious value: -[
- "shore",
- "solar",
- "wind",
- "generator"
-]New value: +[
+ "shore",
+ "solar",
+ "wind",
+ "generator",
+ "alternator"
+]generate_wiring_diagram2 fields changedInput schema / properties / format / defaultPrevious value: -"png"New value: +"svg"Input schema / properties / format / descriptionPrevious value: -"Output format: svg for text-based SVG, png for base64-encoded image"New value: +"Output format: svg (recommended, renders inline) or png (base64-encoded image, may not display in all clients)"generate_wiring_diagramlist_component_typesPlan DC electrical systems: find components, calculate circuits, check designs and create drafts.
NEC 2023 electrical calculators: wire size, ampacity, voltage drop, conduit fill, box fill, load.
Electrical single-line and multi-line diagrams: build, check (NF C 15-100, IEC 60364), draw, PDF.
Size solar, backup power and LiFePO4 battery systems for Iran; product picks and Persian guides.
Add one secure layer between your agents and this server.
