Skip to main content
Glama

Get one of my recipes

get_recipe
Read-onlyIdempotent

One recipe from your account: its materials and amounts, colorants, notes, its stated firing (firedAt: the cone scale, the low and optional high cone of the claimed range, the cones actually tested, the atmospheres and processes, and for a temperature the rate and hold; each cone exactly as the potter gave it), whether it is for a food surface, the firing logs it went through with a result note each and, where known, the cone and atmosphere each was fired at, the potter’s summary of how it came out at each cone and atmosphere (coneResults; one outside the stated firing is kept), the firing band and target specific gravity saved with it, and its unity formula worked out afresh. It is checked against the limit set chosen in your settings: for the firing given here, or else the band chosen on the recipe, or else the bands its stated firing falls in (a range across two bands is checked at each). A firing from cone 12 up is band 'top', where no limit set has figures: its limits are not checked, and limitsNote says so. coneFit says, for the same firing, whether the chemistry looks like that firing's, as the recipe page's limits panel does: by Katz's boron rule and Hesselberth & Roy's silica and alumina whatever limit set is chosen, a note (verdict 'cooler' or 'hotter') only when boron and silica or alumina agree on another band, 'closer' when a range across bands looks nearer one end, 'fits' when nothing points away (not a pass), 'skipped' where the published figures do not reach (among them firings cooler than cone 06 or hotter than cone 10). Cone 6 against cone 10 is told apart only roughly (strength 'soft'). A guide, not a test.

Input Schema

NameRequiredDescriptionDefault
idYesThe id from a list.
firingNoThe firing, as a cone or a temperature. Leave it out when it is not known. From cone 12 up (about 1320 °C) no published glaze limits reach, so the limits are not checked there; the cone check judges cone 06 to 10 only.
languageNoThe language for any sentences in the answer, as a BCP 47 tag such as "en", "de" or "ja". Languages Glazecalc does not offer are answered in English.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A3.7/5.0
Behavior5/5

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

Annotations already establish a safe read-only, idempotent operation, but the description adds substantial behavior: fresh unity-formula computation, limit-set selection rules, cone-12-and-up skipping with limitsNote, and detailed coneFit verdict semantics and limitations. No contradiction with annotations.

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?

The purpose is front-loaded, but the first sentence is extremely long and heavily nested with parentheticals, making it hard to scan. Most details earn their place because there is no output schema, but the structure could be much clearer.

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 full return-value burden and does so thoroughly: it enumerates recipe fields, firing details, limit-checking behavior, coneFit outcomes, and important caveats such as the cone-12 limit gap and 'guide, not a test' status.

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 coverage is 100%, so id, firing, cone/chart/temperature, and language are already fully documented. The description adds the behavioral effect of the firing parameter on limit checks and coneFit, but does not add parameter syntax or value meaning beyond the schema.

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?

Names a specific retrieval action and resource: one recipe from the user's account. The enumerated contents make clear what kind of data is returned, though it does not explicitly differentiate itself from siblings such as list_recipes or analyze_recipe.

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

Usage Guidelines2/5

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

There is no explicit when-to-use, when-not-to-use, or alternative-tool guidance. The only hint that an id should come from a list appears in the schema, not in the description.

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.