Skip to main content
Glama

Electronics Architect

Monte Carlo (metered)

simulate_monte_carlo
Idempotent

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 "::") for sensitivity analysis, and keep options.trials at 50 or fewer when you do.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
optionsNoOptional Monte Carlo settings.
designIdNoA saved design's id from create_design or list_designs — needs the signed-in account. Give this or `designJson`.
designJsonNoFull circuit design JSON (Sheet.serialize() format; design schema v1 at https://electronics-architect.com/schema/design-v1.json — SI base units, numbers not strings). Give this or `designId`.
includeTrialsNoAlso return the raw per-trial array (nodes, inputs, violations per trial). Default false — it is large, so keep options.trials small when you set this.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A3.6/5.0
Behavior1/5

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

The description contradicts the idempotentHint=true annotation by stating 'Each run counts against the account's monthly Monte Carlo quota,' which is an additional side effect on repeated identical calls. Although the description otherwise discloses many behavioral traits (seed replay, clamping, failed/unconverged trials, percentile method, size defaults), this direct contradiction with the annotation forces a score of 1.

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

Conciseness5/5

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

The description is front-loaded with the core action, then proceeds through result format, quota behavior, default digest versus raw trials, and parameter guidance. Despite its length, every sentence carries operational information relevant to calling the tool correctly.

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?

For a complex, nested-parameter simulation tool with no output schema, the description thoroughly explains the default digest result, the omitted per-trial array and its size rationale, quota consumption, and failure modes. An agent has enough context to call it correctly without needing return-value 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 description coverage is 100%, so the baseline is 3, but the description adds useful parameter implications: seed enables byte-identical replay, includeTrials should be used only for per-trial sensitivity analysis, and options.trials should be kept at 50 or fewer when includeTrials is true. It does not add format or constraint details beyond what the schema already documents, so it falls short of 5.

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?

States a specific verb and resource: run a multi-trial Monte Carlo tolerance analysis server-side, including distributions, clamping, and what is simulated. It does not distinguish itself from the sibling run_monte_carlo_job, leaving potential ambiguity about which Monte Carlo entry point to choose.

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?

Provides clear conditions for using includeTrials=true and points to get_account_usage for quota, plus guidance to keep trials small when requesting raw data. It does not compare against the sibling run_monte_carlo_job or explain when to prefer this tool over that alternative.

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