Skip to main content
Glama

mcg_quote

Price a simulation. FREE: no hardware starts. Returns quote_id, quote_hash, tokens, rate_card_version, wall_s, expires_at, the plan, and record: {traced: true, node, node_uid, map_version (the openmaterials graph version the node is pinned at; the commons map version is published at openmaterials.ai/data/version.json), material (the material the pinned conditions name: what the run computes)} when the completed run's OpenMaterials record is keyed on that public map node (measured instances cite the method that ran), else {traced: false, reason}; read it before you spend. The price is a binding ceiling: never more than this. mcg_run accepts only this quote_id with this quote_hash before expires_at and REJECTS a stale hash (quote_mismatch) or an expired quote (quote_expired). Arms, exactly one: kind from mcg_catalog (spec passed through verbatim, spec.params set the price, engine overrides the default only with a known engine id); external_frontier, an OpenMaterials external-solve envelope from mcg_catalog's graphs (also returns request_id, plan_digest and the compiled plan; an envelope not byte-equal to a supported graph REJECTS with unsupported_graph); draft_id (see the parameter). Also returns app_url, the owner's page in the app (for the human, never fetched by the agent) and, on the kind arm, warnings: the inputs the app cannot render without (material or structure_xyz, study); pass them. accuracy_study needs no hardware_contract up front: the reply's contract_source says whether the run binds this simulation's published contract (published) or the labeled default synthetic one (default_synthetic).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
kindNoSimulation kind from mcg_catalog, e.g. bulk_kappa.
nameYesA human label for the simulation.
specNoThe spec object, e.g. {params: {...}, spec_yaml: '...'}. params drive the price. interface_tbc: params.production_steps and params.equilibration_steps set the NEMD budget (the run total across all interfaces) within the bounds the reply's certification.settable states (a refused run's summary.next names the key to raise); the price follows the budget.
studyNoThe study (project) this simulation belongs to, by exact name; created if absent. Every quote for one investigation should name the same study so the app groups them together.
engineNoOptional engine id override (rejected if unknown).
targetNoRun on one of your connected clusters (see mcg_clusters) instead of the cloud: hardware cost 0, gate fee per the rate card and plan, wall time includes the scheduler's queue-wait estimate. The cluster's status must be connected.
draft_idNoThird arm: price a draft that mcg_stage created and whose inputs have been uploaded (refuses with inputs_missing while any declared input is absent). Also re-prices an already-quoted simulation, after its quote expired or to reproduce a run (pass the run's quote_id, its simulation_id): it clones the spec, the map pin and the staged inputs (not contract files, nor structure files the engine does not read; more than 25 inputs refuse) and returns the clone's fresh quote_id (reply carries requoted_from, and rerun_notes naming skipped inputs and structure overrides). Mutually exclusive with every other argument but name and target.
materialNoKind arm only: the material or formula being simulated (e.g. Si, MoS2). Also selects the reference structure. On a traced run whose engine fixes its own conditions it must match the spec's material.
conditionsNoKind arm only: physical conditions as key/value pairs, e.g. {T: 300}. Values are numbers, strings or lists of up to 16 of them, except on an adapter engine, which runs them: there any value its conditions schema allows (lists, booleans, null) over the keys it declares, judged at quote. On a traced run whose engine fixes its own conditions, a key or value its record does not hold is refused; the error names what to send or omit.
max_tokensNoGraph arm only: quote-time hard ceiling; a quote above it REJECTS (never clamps).
structure_xyzNoKind arm only: the simulated structure as extended-XYZ text; staged as the input structure.xyz so the app renders the exact geometry (takes precedence over the material reference).
external_frontierNoThe OpenMaterials #110 external-solve envelope, verbatim. Mutually exclusive with kind/spec/engine.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.7/5.0
Behavior5/5

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

No annotations provided, so the description carries the full burden. It discloses that the call is FREE, lists returned fields (quote_id, quote_hash, tokens, plan, record tracing, app_url, warnings), states binding ceiling semantics, and names rejection reasons (quote_mismatch, quote_expired, unsupported_graph). Exceptionally thorough.

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?

Dense single paragraph with many clauses and no bullets or clear sections. Every sentence is informative, but the lack of structure makes it hard to parse quickly. Length is justified by complexity but could be better organized.

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?

Given 12 parameters, nested objects, no output schema, and a complex multi-arm workflow, the description covers purpose, usage, return values, error conditions, and workflow constraints (e.g., mcg_run acceptance). It is complete enough for an agent to call correctly.

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 baseline is 3. The description adds key semantics beyond the schema: mutual exclusivity of the three arms, that spec.params drive the price, and draft_id re-pricing and clone behavior. These clarify parameter interactions meaningfully.

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: 'Price a simulation.' It clearly distinguishes from siblings like mcg_run (which runs) and mcg_catalog (which supplies kinds). The purpose is unambiguous and front-loaded.

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?

Explicitly says 'read it before you spend' and details three mutually exclusive arms (kind, external_frontier, draft_id) with their conditions, including when to use each and what happens on rejection. Guides the agent on selection and workflow integration.

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