electronics-architect
Design, analyze and solve power architectures deterministically, with diagrams and reports engineers can inspect, sign off and present.
Что умеет
- List Templates: List the power-tree designs that ship with Electronics Architect — the same templates the editor offers on first run. Returns each template's id, its sheet names, a component census by
- Get Template: Read one shipped template as a complete design document — the same JSON the ea://templates/{id} resource serves, as a tool for clients that do not expose resources (the Claude Code accep
- Get Design Schema: The design contract: what a valid Electronics Architect design document looks like. Call with no arguments for the units policy, the top-level shape and the list of every node type.
Какие данные видит
Нужен ли аккаунт
Не нужен: сервер работает без входа
Design, analyze and solve power architectures deterministically, with diagrams and reports engineers can inspect, sign off and present.
Through this server, your AI assistant can:
- Build the power tree: sources, switching regulators, LDOs, batteries and BMS, and loads, in cascades of any depth.
- Solve it: a server-side circuit solver returns every rail's current, efficiency, dissipation and temperature, plus warnings that state the fix. Same design in, same numbers out.
- Check the worst case: tolerance corners, Monte Carlo with a per-rail spread, and derating of every part against NASA GSFC or IPC-9592.
- Use real parts: a growing, community-verified part library, each value traced to its datasheet.
- Save, compare, share and export: designs live in your account, with revision history, design-to-design comparison, share links and BOM export.
In the Electronics Architect web editor, the same design is an editable diagram, with PDF reports, PNG export, DigiKey part search ranked against your operating conditions, and a verify link on every report that re-solves it.
Templates and the design format are free to browse. Solving and saving need a Pro ($10/month) or Team account, with a 7-day free trial.
Как подключить
Как подключить electronics-architect к Claude
Адрес сервера, который нужно вставить в настройках Claude:
https://electronics-architect--electronics-architect.run.tools
- Откройте Claude (сайт claude.ai или приложение для компьютера).
- Перейдите в Настройки → Коннекторы (в английском интерфейсе: Settings → Connectors).
- Нажмите Добавить пользовательский коннектор (Add custom connector).
- Вставьте адрес сервера, скопированный ниже, в поле URL удалённого MCP-сервера и нажмите Добавить.
- В чате нажмите + → Коннекторы и включите новый коннектор.
Пользовательские коннекторы доступны на тарифах Free, Pro, Max, Team и Enterprise. На Free можно добавить только один. В Team и Enterprise коннектор сначала добавляет владелец организации в Настройки организации → Коннекторы.
Авторизация
После нажатия Добавить откроется окно входа в сервис. Войдите под своим аккаунтом и подтвердите доступ. Пароль Claude не видит.
Как подключить electronics-architect к ChatGPT
Адрес сервера, который нужно вставить в настройках ChatGPT:
https://electronics-architect--electronics-architect.run.tools
- Откройте ChatGPT в браузере (chatgpt.com). Нужен тариф Plus, Pro, Business, Enterprise или Edu.
- Один раз включите режим разработчика: Настройки → Приложения → Дополнительные настройки → Режим разработчика (Settings → Apps → Advanced settings → Developer mode).
- Откройте Настройки → Коннекторы и нажмите Создать (Create).
- Заполните форму: Название (любое), Описание (одна фраза, что делает сервис), URL MCP-сервера (скопируйте ниже).
- В поле Аутентификация выберите OAuth, если сервис требует вход, иначе Нет. Нажмите Создать.
- В новом чате откройте + → Приложения/Коннекторы и включите коннектор.
Название раздела у OpenAI менялось (Connectors → Apps/Plugins). Если пункт называется иначе, ищите «режим разработчика» в настройках. В рабочих пространствах Business/Enterprise администратор должен разрешить пользовательские коннекторы.
Авторизация
При первом использовании ChatGPT откроет окно входа в сервис. Войдите и подтвердите доступ.
Как подключить electronics-architect к Cursor
Адрес сервера, который нужно вставить в настройках Cursor:
https://electronics-architect--electronics-architect.run.tools
Быстрый способ: нажмите кнопку Открыть в Cursor ниже, Cursor сам предложит добавить сервер.
Вручную:
- В Cursor откройте Settings → Cursor Settings → MCP и нажмите Add new global MCP server.
- Вставьте JSON, скопированный ниже, в открывшийся файл
~/.cursor/mcp.json(для одного проекта:.cursor/mcp.jsonв корне проекта). - Сохраните файл. Сервер появится в списке MCP; при необходимости пройдите авторизацию по кнопке рядом с ним.
Авторизация
Если сервис требует вход, рядом с сервером в списке MCP появится кнопка авторизации.
Список инструментов сервера (21)
Технические названия из tools/list. Нужны только разработчикам.
| list_templates | List the power-tree designs that ship with Electronics Architect — the same templates the editor offers on first run. Returns each template's id, its sheet names, a component census by node type, and the explanatory notes the template carries on canvas. Read the full design with get_template (or the ea://templates/{id} resource where your client supports resources), or pass an id to solve_design. Start here when the user describes a design that probably already exists (an FPGA rail set, a USB-C PD supply, a motor driver) rather than building from nothing. |
| get_template | Read one shipped template as a complete design document — the same JSON the ea://templates/{id} resource serves, as a tool for clients that do not expose resources (the Claude Code acceptance run, 2026-09-11, had to solve two templates just to read their wiring). Every template is schema-valid and solves as-is; it is also the fastest way to see the port conventions in use (which side a Capacitor shunts on, where a Ground attaches, that an RFAmplifier's right port is the RF output rather than a pass-through). Copy it, edit it, then validate_design. |
| get_design_schema | The design contract: what a valid Electronics Architect design document looks like. Call with no arguments for the units policy, the top-level shape and the list of every node type. Call with a `type` for that type's full property set — key, unit, default, allowed range and what it means. ALWAYS read this before writing a design by hand: numbers are SI base units with no prefix (0.0006 for 600 µA, 47e-6 for 47 µF) and are JSON numbers, never strings, and unknown property keys are rejected rather than ignored. |
| validate_design | Check a design against schema v1 WITHOUT solving it: property keys, types, units and structure (every connection must name a node that exists on its sheet; node ids must be unique). Cheap, and returns every problem at once with a JSON path for each. Run this after writing or editing a design and before solve_design — a design that fails here is refused by the solver anyway, and the messages here are more specific. |
| solve_design | Solve a design and return node voltages, currents, dissipation, junction temperatures, rating checks and warnings. Solved server-side through the signed-in account — no quota is consumed. 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. A converter reports TWO efficiencies and they are meant to differ: a node's `efficiency` is the conversion efficiency read off its own curve at this load point, while `summary.stages[].eff` is the whole stage, Pout / Pin, which also pays the quiescent current. A 12 V to 5 V buck at 1 A reads 0.920 on the node and 0.910 on the stage, because the 0.060 W its `iq` draws is real dissipation the curve does not describe. Quote the STAGE figure for a power budget and the node figure when you are describing the part. 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. |
| simulate_monte_carlo | Run a multi-trial Monte Carlo tolerance analysis entirely server-side. Randomizes component tolerances (supporting Uniform, Gaussian, or Bimodal distributions; draws are clamped to each property's registry min/max bounds) and simulates circuit yield, statistical distributions of voltages/currents/powers/temperatures, and worst-case thermal violation rates. Result carries `seed` (replay it for a byte-identical run), `failedTrials` (thrown trials — counted and excluded from `trials` and every statistic), `unconvergedTrials` (informational). Percentiles (median/p99/p1) use the nearest-rank method. A design containing a node type this build does not recognize is refused with an error rather than simulated as zeros. Each run counts against the account's monthly Monte Carlo quota, like a run from the editor; get_account_usage shows what is left. BY DEFAULT THE RESULT IS A DIGEST, not the trials: the run counts, `summary` (system power and efficiency percentiles, thermal violation rate, protection trips) and `nodeStats` — for every node, min / mean / max / p1 / p99 of voltage, current, power and temperature across the trials, and how many trials broke that node's thermal limit. The per-trial array is omitted because it is about 3 KB per trial for a fifteen-node design — a default 1000-trial run is 3.5 MB, more than a client can read. Pass `includeTrials: true` only when you need the per-trial `inputs` (keyed "<nodeName>:<propName>:<nodeId>") for sensitivity analysis, and keep `options.trials` at 50 or fewer when you do. |
| run_monte_carlo_job | Start a Monte Carlo tolerance analysis as a JOB, for a run too long for one call — thousands of trials on a large design. The same engine, seed stream and statistics as simulate_monte_carlo (the same seed gives the same numbers), but the run is cut into slices of about ten seconds: the first runs inside this call, and every get_job call runs one more, so THE JOB ADVANCES ONLY WHILE YOU POLL IT. Give a design document, a `templateId` or a saved design's `designId`, plus `options` (trials, seed, ambientTemperature). If the run fits in the first slice the result comes back at once (`job.status` "done" with `result`); otherwise `next` says what to do — call get_job with `next.jobId`, and `next.estimatedPollsRemaining` is measured from the slice that just ran, so tell the engineer that figure before a long poll loop. Use simulate_monte_carlo when nodes × trials is under about 50,000 — it answers in one call; use this above that, or whenever simulate_monte_carlo timed out. Charges ONE Monte Carlo run against the account's monthly quota at creation, whatever the length; two active jobs per account (a third is refused TOO_MANY_JOBS — poll or cancel one first); the result is kept 24 h. Trials are clamped to the plan's cap and to the job's size budget; `meta.clamped` and `meta.clampedBy` say when. The result is the digest simulate_monte_carlo returns — summary, counts, seed and per-node nodeStats — never a per-trial array. |
| get_job | Poll a Monte Carlo job by the `jobId` run_monte_carlo_job returned. Each call first runs about ten more seconds of the job's trials — the job progresses only while it is polled — then answers with `job` (status, `trials.done` of `trials.total`, `progress`) and `next`, which says whether to call again and how many calls are likely left. Keep calling until `job.status` is done, failed or cancelled; do not wait between calls unless `job.sliceInProgress` is true (another request is running a slice — wait about ten seconds). When done, `result` is the digest simulate_monte_carlo returns (summary, counts, seed, nodeStats). Polling uses no quota. A job is readable for 24 h after it finishes or last progressed; a job that belongs to another key is NOT_FOUND. To cancel one, DELETE /v1/jobs/{id} over REST (no refund). |
| compare_designs | Compare two designs: what changed between them, and what the change did. Give each side as a design document, a saved design's `designId`, or a shipped `templateId` — mix them freely (a saved baseline against an edited document is the usual case). Returns `changes` (nodes added, removed and changed with every property's before/after, and wires added or removed), `delta` (source power, load power, total dissipation, efficiency and warning counts, each as { a, b, delta }), `stages` (the converters whose loss or efficiency moved), `nodes` (every node present in both whose voltage, current, power or junction temperature moved) and `warnings.resolved` / `warnings.introduced`. Solving both sides is unmetered. Pass `monteCarlo: { trials, seed }` to add `yield` — thermal-violation and protection-trip rates, efficiency and power statistics on both sides with the same seed, so the movement is attributable to the change; that is two metered Monte Carlo runs against the account's quota. USE THIS after every edit instead of reading two full solve results side by side; it is the cheap way to see whether a part swap helped. |
| run_derating | Grade every rated part of a design against a derating standard — NASA GSFC (EEE-INST-002 factors, 105 °C junction cap) or IPC-9592 (115 °C cap) — after one nominal solve. Solved server-side through the signed-in account — no quota is consumed. The same evaluator the editor's Derating panel runs, so the person sees exactly this report. Give a design document, a `templateId` or a saved design's `designId`, and the `standard` (required: which table a part is held to is the engineer's call). Returns, per graded component, its stress checks — parameter, actual, rated, the derated `limit`, `stressPct` (actual over RATED) and `status` — its worst status and mitigation text; `summary` counts compliant / warning / overstressed; `thresholds` is the factor table used. Status: GREEN inside the limit, ORANGE within the last 20 % under it, RED over it. A rating left at 0 or blank is UNSTATED, not a 0 limit: the parameter is skipped and named in the component's `unrated` list — tell the engineer what to enter rather than reporting a pass. Sources, loads and the BMS have no abs-max ratings and are not graded. Read `solve.converged` first: a report on a solve that did not converge grades numbers that mean nothing. Unmetered: no quota is used. |
| get_component_model | Retrieve parametric simulation models from the Electronics Architect curated part library — real regulators with their physics filled in: Vin range, Vout, Imax, dropout, Iq, the efficiency handles, thermal resistance, package, and absolute-maximum ratings (pdMax, vinMax). NOT pricing or stock. Each model carries a `properties` block: the node's complete property set with the datasheet values applied by the same routine the editor's part picker uses, so copy `properties` straight into a node of that `type` (confirm the type with get_design_schema first); the other keys are descriptive. Each model also carries `provenance` per supplied key and `filledFromDefaults`, the property keys the library did NOT supply — registry defaults, not datasheet figures; check it before trusting a number the datasheet should have given. Filter by `type` (the list comes back as `types`) or look up an exact `mpn`. The library holds curated and community-verified parts and grows as datasheet contributions are merged; a miss means "enter the datasheet values by hand", not "the part does not exist". Pricing, stock and distributor search are not available through this server. |
| open_in_editor | Return the URL that puts a design in front of a person on the canvas. This is the hand-back, and it belongs at the end of every workflow: an agent produces, a human reviews and approves. With a `designId` the URL opens THAT design directly for the account (or team) that owns it — they sign in if they are not already, the design loads, and a banner names the key that made or last changed it with one click to the previous state. create_design and update_design return the same link as `editorUrl`, so you rarely need this tool for a design you just saved. With no arguments it returns a blank editor. For someone WITHOUT an account on this design — a colleague, a customer — use create_share_link instead; that is the no-account path and this is not. |
| get_account_usage | Who this server is acting as, and what is left this month. Returns the API key's label and scopes, the account tier, and each metered feature's used / limit / reset date, plus `pack` (a prepaid top-up balance that never expires and is drawn only after the monthly allowance) and `remaining` (allowance plus pack). Check this before a run that will use several AI calls or Monte Carlo runs, so you can tell the user up front rather than stopping half way. At the limit a call fails with QUOTA_EXHAUSTED and a `pack_offer` naming the $5 top-up the account owner can add from Account in the editor; you cannot buy it from a key. Solving is unmetered and is not listed as a quota. |
| list_designs | List the cloud designs this key can see — a personal key sees the account's own designs, a team key sees the team's. These are the same designs the editor shows under My Designs / Team Designs. |
| create_design | Save a design to the cloud so a person can open it in the editor. The design must validate against schema v1. Returns the new design id and `editorUrl`, a link that opens this exact design on the canvas for the account that owns it, flagged as created by this key. This is how agent work reaches a human: create it, then hand back `editorUrl` (the same link open_in_editor gives), or create_share_link for someone without an account. |
| get_design | Read one cloud design by id, with its revision count. Use list_designs to find ids. |
| update_design | Replace a cloud design with a new version. The state being replaced is kept in the design's revision history, attributed to this API key by its label, so a person can see exactly what the agent changed and roll it back. Send the whole document — there is no partial update — and include a short `message` saying what changed, because that is what the history shows. Returns `editorUrl`: hand it back, and the person lands on the changed design with the change flagged as this key's and the previous state one click away. |
| create_share_link | Create (or update) the public link for a cloud design — the same link the editor's Share dialog makes. Anyone with the URL can open the design; no account needed. Use this for a person who does NOT own the design or sit on its team; for the owner, `editorUrl` / open_in_editor is the link. One public link exists per design and this updates it in place. |
| export_design | Export a cloud design. "bom_json" and "bom_csv" give the bill of materials — designator, type, nameplate value, MPN, manufacturer, package, DigiKey part number — "design_json" gives the document itself, "solve_json" the solved result at one corner, and "report_json" the machine-readable report: the summary and the grouped warnings with their fixes at all three corners plus the BOM. Every export carries `attribution` — the solver release, the design fingerprint, the date and a verify URL — and the CSV ends with that line; quote it when you hand the export to a person. The document is returned inline, not as a link. PDF exports (the schematic, Monte Carlo and derating reports, the engineering dossier) are drawn by the editor and are not available here; hand the user an open_in_editor URL for those. The derating CHECKS as data are run_derating. |
| review_design | Ask Electronics Architect's own reviewer for an AI design review (AIDR) of a design or a solve result. First what the numbers mean in plain English — efficiency losses, thermal margin, dropout headroom, reliability risk — then concrete improvements: topology changes (a linear regulator that should be a buck, a missing pre-regulator), sequencing, derating and thermal fixes, with component designators, numbers and estimated gains. One call on the account's monthly AI quota. Pass the solve result rather than the bare design when you have one — the review is much better with real numbers. |
| synthesize_from_text | Generate a complete power tree from a plain-English brief ("12 V in, rails at 5 V 2 A, 3.3 V 1 A and 1.8 V 500 mA, efficiency matters more than cost") and return it already solved. Draws on the account's monthly synthesis quota, which is smaller than the AI quota — check get_account_usage first. Always review the result with solve_design and validate_design before presenting it as finished: generated designs can carry wrong part parameters. |