Skip to main content
Glama

Electronics Architect

by com.electronics-architect
OverviewDiscussionsAdmin

Monte Carlo job (metered)

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 a few seconds (3 s of trials, up to about 5 s a call): 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. Needs a Pro or Team plan: a Free account is refused with PLAN_REQUIRED.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
designNoThe design document (schema v1, SI base units). Give this, `templateId` or `designId`.
optionsNoMonte Carlo settings, the same as simulate_monte_carlo's.
designIdNoA saved design's id from create_design or list_designs. Give this, `design` or `templateId`.
templateIdNoA shipped template id from list_templates. Give this, `design` or `designId`.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Annotations declare readOnlyHint=false and idempotentHint=false, and the description adds substantial behavioral context beyond them: metered quota charged once at creation, two-active-jobs cap with TOO_MANY_JOBS refusal, 24 h result retention, Pro/Team plan requirement with PLAN_REQUIRED, clamping via meta.clamped/clampedBy, and the fact that the job only advances while polled. This is unusually rich disclosure for a mutation tool.

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

Conciseness4/5

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

It is long, but the complexity is real and the key facts (job semantics, alternatives, polling, limits) are front-loaded. A few clauses re-explain what the schema already says, keeping it just short of fully economical.

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?

With no output schema, the description carries the return-value burden and does so: the digest shape (summary, counts, seed, nodeStats, never per-trial arrays), job.status 'done', the next.jobId/next.estimatedPollsRemaining continuation, and meta.clamped semantics. An agent has everything needed to invoke and drive the job correctly.

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

Parameters3/5

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 design/designId/templateId/options and their sub-fields, and the description largely repeats that ('Give a design document, a templateId or a saved design's designId, plus options'). Baseline 3 is appropriate; the description adds no syntax or format detail beyond the schema.

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

Purpose5/5

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

States a specific verb and resource ('Start a Monte Carlo tolerance analysis as a JOB') and immediately scopes it to runs too long for one call. It explicitly names simulate_monte_carlo as the same-engine sibling and distinguishes the job variant from it, so an agent can tell the two apart without opening either schema.

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

Usage Guidelines5/5

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

Gives an explicit decision threshold: use simulate_monte_carlo when nodes × trials is under ~50,000 (one call), use this above that or whenever simulate_monte_carlo timed out. The polling model and the fallback path for continuation are spelled out, leaving nothing to inference.

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

All Electronics Architect toolsInspect
Try in Browser
Shareable, User-Owned Context BackendPeople, applications, and agents read, write, and coordinate together in one context lake. Reach it over MCP, a CLI, a Python SDK, or REST.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources