Skip to main content
Glama

Run the field-theory lab

pull_lab

Runs the pull engine's field-theory lab on a theory document (its fields, Lagrangian, which quantity is the mass, what fixes the sector and the value expected; pull_schema lists the keys): the equations derived, a static solution found and weighed, a check that the solver finds no lump where there is none, its small oscillations and a collision, in a fixed layout with an honesty box saying what is exact and what is remembered rather than sourced. reference (true, or a reference theory's name) runs the reference suite instead, each known number naming its source. reference true (the one-dimensional suite) answers within 30 seconds for 1 unit. A one-dimensional theory is counted first, by the engine, in its sites and its relaxation and collision steps: one that comes to 1 unit (a second or so, on the lattice the lab picks for most theories) answers at once for that unit, and a larger one is queued and priced like a theory with a model, at least 1 unit. The lab picks a spacing of 0.05 over the heavier meson and a box of 16 over the lighter, so a theory whose vacua differ a hundredfold in mass counts 64,001 sites and some 3,200 CPU-seconds, and a lattice the theory sets itself (lattice.dx as fine as 1e-4, lattice.half_length as wide as 1000) grows as the square of one over the spacing. A theory with a model (the Skyrme model's baryon, the Faddeev-Skyrme model's knot), and reference skyrme or hopfion, relaxes a lattice in three dimensions, which takes minutes of CPU: it is queued, on 4 threads, and priced by the engine's count of its lattice and steps, a unit for each 5 CPU-seconds of one thread it estimates, at least 1 and at most 300 (the reference Skyrmion costs 38; a hopfion relaxes four times, and the reference one, on 128 sites a side, comes to far over the most a job may cost and is refused with its price, while one relaxed on 64 sites a side, 217 units, is accepted; pull_cost says the price first). The steps priced are the steps asked for or, for each site of the relaxed lattice's side less one, 60 (a Skyrmion) or 75 (a hopfion), whichever is fewer, which is more than a relaxation took in a box that holds the soliton (a Skyrmion's 25 to 43 for each side less one at 25 to 161 sites a side, a hopfion's 28 to 56 at 32 to 128); a box narrower than the soliton (a Skyrmion's lattice.half_length must be 2 or more, a hopfion's relax.half_length 4 or more), where a relaxation took several times as long or never settled, is refused, and a relaxation that has not settled by then is stopped at three times its estimate and costs its price. A call priced at more than 2 units is queued: the answer is 202 with a job id and its price, GET /api/agents/jobs/ (or the MCP tool job) says when it is done, and the whole report comes back as report.json beside a short verdict. A queued call is refused on the free plan with 402: its units buy only calls that answer at once, and queued jobs need a paid plan (a pass or the card plan).

Input Schema

NameRequiredDescriptionDefault
theoryNoThe theory document written inline: its fields, Lagrangian and the quantity to match.
referenceNoTrue, or a reference name, to compare against a reference run.

Output Schema

NameRequiredDescriptionDefault
msNoMilliseconds the run took.
jobYesThe job id; the job tool reads it.
verbNoThe tool that made it.
filesNoFiles made, each with a name, type, size and a signed URL.
unitsNoUnits this call cost.
resultNoThe engine's own answer, a JSON document.
statusNoqueued when the job runs in the background.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changed
    • addedInput schema / properties / reference / description
      Added value: +"True, or a reference name, to compare against a reference run."
    • addedInput schema / properties / theory / description
      Added value: +"The theory document written inline: its fields, Lagrangian and the quantity to match."
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
      +  "$schema": "http://json-schema.org/draft-07/schema#",
      +  "additionalProperties": true,
      +  "properties": {
      +    "files": {
      +      "description": "Files made, each with a name, type, size and a signed URL.",
      +      "items": {
      +        "additionalProperties": {},
      +        "type": "object"
      +      },
      +      "type": "array"
      +    },
      +    "job": {
      +      "description": "The job id; the job tool reads it.",
      +      "type": "string"
      +    },
      +    "ms": {
      +      "description": "Milliseconds the run took.",
      +      "type": "number"
      +    },
      +    "result": {
      +      "description": "The engine's own answer, a JSON document."
      +    },
      +    "status": {
      +      "description": "queued when the job runs in the background.",
      +      "type": "string"
      +    },
      +    "units": {
      +      "description": "Units this call cost.",
      +      "type": "number"
      +    },
      +    "verb": {
      +      "description": "The tool that made it.",
      +      "type": "string"
      +    }
      +  },
      +  "required": [
      +    "job"
      +  ],
      +  "type": "object"
      +}
  2. First observed

TDQS

A3.8/5.0
Behavior5/5

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

Annotations only assert readOnlyHint=false, idempotentHint=false, openWorldHint=false, destructiveHint=false; the description adds substantial disclosure beyond that: async 202 responses with a job id, the GET /api/agents/jobs/<job> (or 'job' tool) completion path, 402 refusal on the free plan, paid-plan requirement for queued jobs, thread counts, CPU-time estimation rules, and explicit refusal conditions (lattice narrower than the soliton, unsettled relaxations stopped at 3x estimate). This is exactly the operational context an agent needs before invoking.

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

Conciseness2/5

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

The body is a single enormous run-on paragraph that buries the selection-relevant facts under extreme numeric minutiae (64,001 sites, ~3,200 CPU-seconds, 0.05 spacing, 16 box, 25-to-43 step counts). Only the first clause is front-loaded; the rest is unordered and hard to scan, and much of the cost arithmetic is not actionable at call time.

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 complex, nested-parameter tool with an output schema present, the description covers the essentials an agent needs: queuing threshold, plan gating, refusal modes, timeouts, and the failure/pricing contract. Return-value detail is legitimately offloaded to the output schema, though the density makes it hard to confirm coverage at a glance.

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% and both parameters are documented in-schema, so the baseline is 3. The description goes further by characterizing the inline theory document (fields, Lagrangian, which quantity is the mass, what fixes the sector and the expected value) and by spelling out reference semantics (true = the one-dimensional suite; reference skyrme/hopfion select model-based runs), which the schema's const/pattern does not convey.

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 concrete verb+resource: "Runs the pull engine's field-theory lab on a theory document", and the opening clause enumerates what the lab produces (equations derived, static solution weighed, oscillation and collision). That is well beyond a tautology of the title. It does not, however, explicitly distinguish itself from close siblings such as pull_call, pull_analyse or pull_practice, so an agent must infer the boundary.

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

Usage Guidelines3/5

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

The description gives conditional routing details (reference=true runs the reference suite, >2-unit calls are queued, free-plan queued calls return 402) and defers key discovery to pull_schema and pricing to pull_cost. But it never says when to reach for pull_lab rather than pull_call/pull_analyse; usage is implied by the cost/queue mechanics rather than stated as a selection rule.

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