Skip to main content
Glama

Electronics Architect

Solve a design

solve_design
Read-onlyIdempotent

Solve a design and return node voltages, currents, dissipation, junction temperatures, rating checks and warnings. Solved server-side through the signed-in account: unmetered on Pro and Team; on the Free plan each solve counts toward its 10 a month through connected apps (meta.solvesRemaining says how many are left), and a design has 1 sheet. It takes a design document, a template id, OR a saved design's designId (so a design you saved with create_design is solved at every corner without re-sending it), validates before solving, and names the tolerance corner plainly. Every warning carries a stable code, a level (info | caution | warning | critical), a human label, a message and a remedy saying what to change; summary.warningGroups collapses repeats. Read each sheet's converged boolean — never infer success from the absence of an error. An SMPS (pNoLoad, its no-load power in W / effPeak its peak / effMaxLoad at iMax) reports ONE efficiency: its node efficiency equals the stage figure summary.stages[].eff, Pout / Pin, because its whole no-load draw is inside the curve, as on a datasheet (so at light load the efficiency falls away as the no-load power takes over). Quote the STAGE figure for a power budget. The full result also gives each SMPS an efficiencyCurve: the curve the solver used, as [outputCurrent A, efficiency 0..1] pairs from 0 to iMax at the solved input and rail (effVin applied), with the node's efficiency on it; compact leaves it out. PREFER compact: true: the full result echoes every node's properties and repeats each warning three or four times, which is 55–70 KB for a 34-node design; compact keeps every solved number and one grouped warning list per sheet at a quarter to a third of the size. For a range of input voltage (a battery from empty to full, a supply across its tolerance) pass sweep: true rather than guessing charge levels: one call, three solved points, counted as one solve.

Input Schema

NameRequiredDescriptionDefault
sweepNoSolve at three input points in one call: every battery empty (0 %), half (50 %) and full (100 %), every supply at the low end, middle and high end of its voltage tolerance. Use it for "across the battery range" or "at low and high line"; `corner` still applies, so "worst" with a sweep is worst case at low and at high line. Returns `points[]`, each with its inputs (setting, terminal voltage, current), totals, `stages` (with temperature) and grouped warnings; always terse. Counts as one solve. Default false.
cornerNoTolerance corner. "nom" is nominal values; "min"/"max" push every toleranced value the same way, which is how you find a rail that only fails at one end. "worst" moves each one the way that raises the draw and the heat (loads up, efficiencies down, a switcher's output up, an LDO's down) and holds the input at nominal: minimum efficiency at maximum load. Each sheet's `worstCase.held` lists what it held and why. Default "nom".
designNoThe design document. Give this, `templateId` or `designId`.
compactNoReturn the terse result: solved numbers per node without the property echo, `warningGroups` per sheet instead of the repeated warning arrays, the summary totals and `stages`. Default false (the full result).
designIdNoA saved design's id from create_design or list_designs — needs the signed-in account. Give this, `design` or `templateId`.
templateIdNoA shipped template id from list_templates. Give this, `design` or `designId`.
ambientTemperatureNoAmbient in °C for the thermal estimates. Default is the design's own setting, else 25.
includePortVoltagesNoInclude per-port voltages on every node result. Default false.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changed
    • changedInput schema / properties / corner / description
      Previous value: -"Tolerance corner. \"nom\" is nominal values; \"min\"/\"max\" push every toleranced value to its extreme, which is how you find a rail that only fails at one end. Default \"nom\"."New value: +"Tolerance corner. \"nom\" is nominal values; \"min\"/\"max\" push every toleranced value the same way, which is how you find a rail that only fails at one end. \"worst\" moves each one the way that raises the draw and the heat (loads up, efficiencies down, a switcher's output up, an LDO's down) and holds the input at nominal: minimum efficiency at maximum load. Each sheet's `worstCase.held` lists what it held and why. Default \"nom\"."
    • changedInput schema / properties / corner / enum
      Previous value: -[
      -  "nom",
      -  "min",
      -  "max"
      -]New value: +[
      +  "nom",
      +  "min",
      +  "max",
      +  "worst"
      +]
    • addedInput schema / properties / sweep
      Added value: +{
      +  "description": "Solve at three input points in one call: every battery empty (0 %), half (50 %) and full (100 %), every supply at the low end, middle and high end of its voltage tolerance. Use it for \"across the battery range\" or \"at low and high line\"; `corner` still applies, so \"worst\" with a sweep is worst case at low and at high line. Returns `points[]`, each with its inputs (setting, terminal voltage, current), totals, `stages` (with temperature) and grouped warnings; always terse. Counts as one solve. Default false.",
      +  "type": "boolean"
      +}
  2. First observed

TDQS

A4.2/5.0
Behavior5/5

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

Goes far beyond the annotations: billing model (unmetered on Pro/Team, 10/month on Free, meta.solvesRemaining), server-side execution, that sweep counts as one solve, output size (55–70 KB for 34 nodes), and the caveat to read each sheet's `converged` rather than infer success from missing errors. That convergence warning in particular is behavioral knowledge an agent could not get from anywhere else.

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

Conciseness3/5

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

Purpose is front-loaded, but the single dense paragraph runs ~350 words and buries operational guidance. The SMPS efficiency/effVin/efficiencyCurve passage is long and only relevant to one component type, and the compact recommendation plus its size rationale are effectively stated twice.

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

Completeness5/5

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

No output schema exists, so the description carries the full burden and does so: it documents the warning object shape (`code`/`level`/`label`/`message`/`remedy`), `summary.warningGroups`, per-sheet `converged`, `points[]` for sweeps, and how efficiency is reported. An agent can interpret the result without further documentation.

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

Parameters4/5

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

Schema coverage is 100%, so the baseline is 3, but the description adds meaning the schema does not: compact drops the `efficiencyCurve` (not stated in the schema), and it explains why compact is preferred (full result echoes properties and repeats warnings). The designId/templateId/design alternatives are restated from the schema, which limits the score.

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

Purpose4/5

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

Opens with a precise verb+resource and enumerates exactly what comes back (node voltages, currents, dissipation, junction temperatures, rating checks, warnings). It is clearly a simulation/solve tool, but it never explicitly contrasts itself with the close siblings validate_design, review_design or run_derating, so an agent must infer the boundary.

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

Usage Guidelines4/5

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

Strong conditional guidance: pass sweep:true for a battery/supply range rather than guessing charge levels, PREFER compact:true for size reasons, and supply design / templateId / designId as alternatives. It lacks any explicit 'do not use this when…' or sibling routing (e.g. vs validate_design), which keeps it below 5.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources