Skip to main content
Glama
Sign In

Glazecalc

by com.glazecalcapp
OverviewDiscussionsAdmin

Make a recipe for a target formula

solve_target
Read-onlyIdempotent

Makes a glaze recipe, in percent, from the materials given whose unity formula comes as near a target as they allow (Solve for a target in the Glazecalc app). The target is a unity formula (moles; the fluxes are scaled to add up to 1) or an oxide analysis (percent by weight of the fired glaze), with potash and soda apart. Give the materials by their library names, or onHand for the materials on the person’s shelf (with a token or connected app that may read it). closeness says how near each oxide comes: close (within 0.02, or 5% of a large amount such as silica’s), off, or far (more than three times that), with a verdict (close, fair or poor) and a summary; unreachable names the target’s oxides nothing given supplies. Raw clay is held to 20% of the batch where that costs the match little (capped and allowMore say more). Test any recipe before using it.

Input Schema

NameRequiredDescriptionDefault
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.
onHandNoMake it from the materials on the person’s shelf, as well as any named: needs a token or connected app that may read it.
targetYesThe unity formula or oxide analysis to aim for.
mustUseNoMaterials given that must be in the recipe.
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.
allowMoreNoMaterials whose suggested cap to lift, as report.capped names them: raw clay is held to 20% of the batch (or the recipe's own share) where that costs the match little.
materialsNoThe library names of the materials to make it from. Use search_materials to find the names.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.3/5.0
Behavior5/5

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

Annotations already declare readOnly/idempotent/non-destructive, and the description adds substantial context beyond them: the closeness tolerance model (0.02 or 5% of large amounts, off/far thresholds), the verdict/summary/unreachable outputs, and the raw-clay 20% cap. This is rich behavioral disclosure that helps an agent predict results.

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?

Content is front-loaded with the core action and nearly every sentence earns its place, packing tolerance, cap, and validation guidance efficiently. It is a dense run-on paragraph, however, making the output-field and cap details harder to scan than a structured layout would be.

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?

For a 7-parameter solver with no output schema, the description fills the gap by describing the result fields (closeness, verdict, summary, unreachable, capped) and the clay-cap logic. An agent has enough to call it correctly and interpret the answer.

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; the description goes further by explaining the unity vs analysis distinction for target.kind and tying allowMore to report.capped. It reinforces schema meaning rather than merely repeating it, though it doesn't detail firing/language options already documented.

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?

The description opens with a specific verb+resource ('Makes a glaze recipe, in percent') and states the governing objective ('whose unity formula comes as near a target as they allow'), which an agent can map to the solve_target name. It doesn't explicitly differentiate from close siblings like match_with_what_i_have or match_from_materials, so it falls short of 5.

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 supplies concrete calling conditions — give materials by library name or use onHand (with a token or connected app), and 'Test any recipe before using it' nudges toward validation siblings. It lacks an explicit 'use this instead of match_with_what_i_have when...' exclusion, so it stops at 4.

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

All Glazecalc 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