Skip to main content
Glama
Sign In

MaterialsCodeGraph

by com.materialscodegraph
OverviewDiscussionsAdmin

mcg_stage

Create a DRAFT simulation whose input files are uploaded before pricing. FREE. Takes the same kind, spec, study, material and conditions as mcg_quote plus inputs: one entry per file the run needs, each with a name and, for small text files, the text inline (staged immediately). Entries without text come back in uploads as presigned PUT URLs (valid 15 minutes, 4 GiB per file): upload each with a plain HTTP PUT of the file bytes, no key or header. Then call mcg_quote with draft_id to price; it REJECTS with inputs_missing until every declared input has arrived.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "kind": "<kind>",
      "name": "<name>",
      "spec": "<spec>",
      "inputs": "<inputs>"
    },
    "name": "mcg_stage"
  }
}

Input Schema

NameRequiredDescriptionDefault
kindYesSimulation kind from mcg_catalog.
nameYesA human label for the simulation.
specYesThe spec object; params drive the eventual price.
studyNoThe study (project) this simulation joins: the id of a study you own (std_ plus 20 hex), or an exact name, created if absent. A value shaped like a study id never creates a study: one that is not yours is refused.
engineNoOptional engine id override.
inputsYesThe input files the run needs.
materialNoThe material or formula simulated.
conditionsNoPhysical conditions: numbers, strings or lists of up to 16 of them (on an adapter engine, any value its conditions schema allows). 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.
potential_from_runNoA done nep_train or nep_campaign run id whose trained NEP model this draft runs; staged as its potential (with its license notice) beside the inputs.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / study / description
      Previous value: -"The study (project) this simulation joins, by exact name; created if absent."New value: +"The study (project) this simulation joins: the id of a study you own (std_ plus 20 hex), or an exact name, created if absent. A value shaped like a study id never creates a study: one that is not yours is refused."
  2. Changed1 schema field changed
    • addedInput schema / properties / potential_from_run
      Added value: +{
+  "description": "A done nep_train or nep_campaign run id whose trained NEP model this draft runs; staged as its potential (with its license notice) beside the inputs.",
+  "type": "string"
+}
  3. First observed

TDQS

A4.5/5.0
Behavior4/5

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

With no annotations, the description carries the burden and does well: it discloses that the tool is FREE, that URLs expire in 15 minutes, the 4 GiB per-file cap, the plain-HTTP-PUT-without-headers contract, and the exact failure mode (inputs_missing). It does not state authentication requirements or what happens when a URL expires or a draft goes stale.

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?

Front-loaded with the core action and tightly packed, with no filler. The sentences are long and run-on (upload mechanics, expiry, and rejection all crammed into one clause chain), which slightly hurts scanability.

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

Completeness4/5

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

For a 9-parameter, nested-object, output-schema-less tool, the description covers the workflow, return artifacts (upload URLs, draft_id) and the follow-up call. Remaining gaps — auth, draft lifetime, error names beyond inputs_missing — are minor but real.

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 beyond the schema: it explains the text-vs-URL branch of `inputs` ('staged immediately' vs presigned PUT), clarifies that `kind/spec/study/material/conditions` are the same as mcg_quote, and reveals that draft_id/upload URLs are returned. That return-shape hint matters since no output schema exists.

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 — 'Create a DRAFT simulation' — and immediately names the distinguishing characteristic: input files are uploaded before pricing. It also references the sibling mcg_quote by name, so an agent can tell this apart from quote/run without opening a 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?

Lays out the full sequence: stage inputs via mcg_stage, upload bytes to the returned presigned URLs, then call mcg_quote with draft_id. It names the alternative tool and the precondition ('REJECTS with inputs_missing until every declared input has arrived'), leaving little to inference.

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

All MaterialsCodeGraph toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources