MakerPortal compute

Solve the on-axis magnetic field of an air-core solenoid.

solenoidField

Solve the on-axis magnetic field of an air-core solenoid.

The identical function that renders /lab/solenoid/{diameter}x{length}mm. Returns the centre field per amp-turn and at the requested turns and current, the on-axis profile out to three half-lengths, the span over which the field holds to within 1% and 5% of its centre value, the field at the coil mouth as a fraction of the centre, how far the infinite-solenoid shortcut mu0nI overstates the answer, and the turn count below which the closed form should not be used on this geometry. Dimensions are in millimetres. The field is exactly linear in turns x current, so only that product changes the answer.

Every result carries provenance.canonicalUrl — the published page for these exact inputs, or the lane hub when they are off the published grid.

Input Schema

TableJSON Schema

Name	Required	Description
`turns`	No	Number of turns. Defaults to 1, which is what the published pages state (their figures are per amp-turn). The field is exactly linear in turns x current.
`length`	Yes	Winding length along the axis, in millimetres.
`current`	No	Winding current in amperes. Defaults to 1. Only the product of turns and current changes the answer.
`diameter`	Yes	Mean winding diameter in millimetres.

Output Schema

TableJSON Schema

Name	Required	Description
`inputs`	Yes	The parsed inputs, echoed back with defaults filled in.
`result`	Yes	The solved analysis. Shape is per-tool.
`license`	Yes
`provenance`	Yes

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

First observedSep 6, 2026

TDQS

A4.5/5.0

Behavior4/5

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

With no annotations provided, the description carries the full burden and does so well: it discloses the returned quantities, the linear dependence on turns x current, millimeter units, and the provenance URL behavior. It does not explicitly state that the operation is side-effect free, but the solver nature makes this sufficiently clear.

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 compact yet information-dense: three paragraphs move from operation to outputs to provenance conventions, with every sentence earning its place. There is no verbose repetition of schema fields or annotations.

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 the output schema exists and the sibling tools are unrelated, the description is complete for correct invocation. It covers units, input semantics, result contents, the linear scaling behavior, and the provenance URL, leaving no critical gap for an agent deciding to call the tool.

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?

The input schema already documents all four parameters fully, so the baseline is 3. The description adds valuable cross-parameter semantics by explaining that only the product of turns and current changes the answer and that published figures are per amp-turn, helping the agent choose meaningful inputs.

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?

The description opens with a specific verb-resource pair, 'Solve the on-axis magnetic field of an air-core solenoid,' and then enumerates the concrete outputs. This makes the tool's purpose unambiguous and clearly distinguishes it from the unrelated sibling tools.

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?

It provides clear context by stating that this is the identical function behind a published lab page, which helps an agent know when this tool is the right match. It does not explicitly list exclusions or alternatives, but none of the sibling tools is a plausible candidate for the same calculation.

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

All MakerPortal compute tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.3/5.0

Disambiguation5/5

Each tool targets a clearly distinct computational domain: biquad filter design, LLM VRAM fitting, room eigenmodes, room shape selection, and solenoid fields. Even the two room-related tools are cleanly separated—one analyzes existing dimensions while the other synthesizes proportions—so an agent is unlikely to misselect.

Naming Consistency5/5

All five tool names follow the same camelCase, domain-plus-result pattern: biquadDesign, llmVramFit, roomModes, roomShapeBand, solenoidField. There are no underscores, hyphens, or mixed casing conventions, so the naming is internally consistent.

Tool Count5/5

Five tools is a well-scoped count for a specialized compute server. Each tool is substantial and standalone, and there is no sense of padding or missing middle ground between too granular and too broad.

Completeness5/5

Each tool is a self-contained calculation with rich output and explicit bounds, and no CRUD lifecycle is expected for a compute server. The coverage across the exposed domains is thorough, with no obvious dead-end workflow or missing companion operation.

Resources

Need Help?