One MCP server exposing every tool in the Gumball portfolio.
Returns the full row-by-row schedule: per-period interest, scheduled principal, any extra principal, PMI, payment and running balance. Handles monthly or daily accrual (daily needs a start date, so leap years follow from the calendar rather than an assumption), biweekly payments, one-off or recurring extra principal, and PMI termination under the Homeowners Protection Act at 78% or 80% of the ORIGINAL value — plus the midpoint trigger that ends PMI regardless of balance. The final payment differs from every other one and is reported as such. Refuses a payment that cannot amortize the balance rather than producing a schedule that never ends. Not financial advice.
WHY DELEGATE THIS: A model gets the payment formula roughly right and then drifts: over 360 rows the principal/interest split accumulates rounding error, and the final payment — the one row people actually check against a statement — is almost always wrong. It also cannot reliably answer what an extra $200 a month does to the payoff date. Compounding is a parameter rather than an assumption, because monthly and daily accrual produce genuinely different schedules and the caller knows which loan they have.
Owned by Amortization Schedule at https://amortize.gumballtools.com, which is also callable directly if you would rather not go through the aggregator.
| Name | Required | Description | Default |
|---|---|---|---|
| principal | Yes | Loan amount in dollars. | |
| startDate | No | ISO YYYY-MM-DD. Required for daily accrual unless dayCountBasis is given. | |
| termMonths | Yes | Term in months, e.g. 360 for thirty years. | |
| compounding | No | Monthly (rate/12) is the US fixed-mortgage norm. Daily is simple daily accrual. | |
| dayCountBasis | No | ||
| paymentFrequency | No | ||
| annualRatePercent | Yes | Annual rate as a percentage, e.g. 6.5 — not 0.065. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations only indicate readOnly and openWorld hints, so the description carries the behavioral burden. It discloses important behavior such as the final payment differing from others, refusing non-amortizing payments, PMI termination rules, daily accrual requiring a start date, and the 'not financial advice' caveat. Nothing here contradicts the readOnlyHint.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is longer than average but well-structured with a lead summary, capability list, delegation rationale, and ownership note. Each section earns its place, though the ownership/URL paragraph is somewhat supplementary and could be trimmed without losing invocation guidance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description does a good job listing return fields and explaining complex behaviors like PMI termination and failing gracefully on non-amortizing payments. It is slightly incomplete regarding how to specify extra principal and PMI inputs, since those capabilities are mentioned but not mapped to schema parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 71%, and the schema already documents most parameters such as annualRatePercent format and compounding options. The description adds some rationale for compounding being a parameter and notes the daily accrual start-date requirement, but it does not deeply document the remaining parameters. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Returns the full row-by-row schedule' and lists the exact output fields. It clearly identifies this as a loan amortization schedule builder, and the detailed capabilities make it distinguishable 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The 'WHY DELEGATE THIS' section gives strong context for when to use the tool: when model drift on long schedules, final-payment accuracy, or extra-principal impact matter. It also offers a direct alternative URL, but does not explicitly state when not to use this tool versus a sibling.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compute BMI, energy expenditure, and protein targets from height and weight. Height and weight MUST carry units — a bare number is REFUSED rather than guessed, because a unit mix-up produces a plausible-looking answer that is badly wrong. Returns every standard BMR formula plus the spread between them, because the spread IS the precision of the estimate. Do not relay a single calorie figure as though it were exact. Not medical advice, and the response says so in its payload.
WHY DELEGATE THIS: Two failure modes at once. A bare number is ambiguous — "170" is a height in centimetres or a weight in pounds — and a wrong unit yields a plausible BMI that is off by a factor of two. And the standard energy formulas disagree by hundreds of calories, so any single figure is false precision.
Owned by Body Metrics at https://body-metrics.gumballtools.com, which is also callable directly if you would rather not go through the aggregator.
| Name | Required | Description | Default |
|---|---|---|---|
| age | Yes | Years, 15-100. | |
| sex | Yes | The BMR equations are fitted separately. | |
| height | Yes | WITH a unit: 178cm, 1.78m, 5'10", 70in. Bare numbers refused. | |
| weight | Yes | WITH a unit: 75kg, 165lb, 11st 8lb. Bare numbers refused. | |
| activity | No | The largest source of error. Most people overestimate; take the lower band. | |
| targetBmi | No | ||
| bodyFatPercent | No | Adds the Katch-McArdle estimate. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint/openWorldHint annotations, the description discloses critical behaviors: bare numbers are refused rather than guessed, all standard BMR formulas are returned along with the spread, and the response includes a medical disclaimer. It also instructs the agent not to relay a single calorie figure as exact.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The essential information is front-loaded: what is computed and the mandatory-unit rule come first. The 'WHY DELEGATE THIS' section is somewhat redundant with the opening paragraph, but it earns some value by reinforcing the failure modes. Overall it is focused and well organized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no output schema, the description does a good job explaining the output philosophy: multiple formulas, spread as precision, and an embedded disclaimer. It could specify the exact return payload more concretely, but an agent has enough context to invoke the tool correctly and interpret results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 86%, which sets a solid baseline. The description adds meaning to height and weight by emphasizing that units are mandatory and explaining why unit mix-ups are dangerous. It does not need to repeat the schema's parameter details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Compute BMI, energy expenditure, and protein targets from height and weight.' It also clarifies the unique output shape — every standard BMR formula plus the spread — which distinguishes it from generic calculator siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The 'WHY DELEGATE THIS' section explicitly explains when the tool is the right choice: unit ambiguity and false precision. It also mentions the direct alternative (calling Body Metrics directly). It does not explicitly name sibling tools or state when not to use, but the guidance is otherwise clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Checks the check digit on an IBAN (ISO 7064 MOD 97-10), ISBN-10, ISBN-13, EAN-13, UPC-A, or a Luhn-checked card number. When the checksum fails it searches for the single substitution or adjacent transposition that would repair it, so the answer is which character to fix rather than merely that something is wrong. Reports the ambiguity when more than one fix would work. Refuses an IBAN whose country code is not in the length registry rather than assuming a length, and requires the format to be named because a bare digit string can parse as more than one. A passing checksum is arithmetic only: it does not mean the account, book or card exists.
WHY DELEGATE THIS: Mod-97 over a rearranged thirty-character IBAN, or a weighted sum mod 10/11 over thirteen digits, is arithmetic a model fumbles silently and asserts confidently. Worse, asked WHICH digit is wrong it pattern-matches a plausible answer instead of solving the modular equation — and when more than one single-digit fix would satisfy the checksum, it names one instead of reporting the ambiguity.
Owned by Check Digit Validator at https://check-digit.gumballtools.com, which is also callable directly if you would rather not go through the aggregator.
| Name | Required | Description | Default |
|---|---|---|---|
| input | Yes | The number to check. Spaces and hyphens are ignored. | |
| format | Yes | Which checksum to apply. Required — a digit string is not auto-detected. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With readOnlyHint/openWorldHint already provided, the description adds substantial non-obvious behavior: it searches for a single substitution or transposition, reports ambiguous fixes, refuses IBANs with unknown country-code lengths, and clarifies that a passing checksum is not proof of existence. None of this contradicts the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The core behavior is front-loaded, and the detailed error-handling and ambiguity reporting are essential given the tool's complexity. The 'WHY DELEGATE THIS' and ownership sentences are purposeful but the ownership/URL line is the closest thing to non-essential, preventing a 5.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite lacking an output schema, the description conveys what the agent should expect back ('which character to fix', ambiguity reports) and covers refusal behavior and format-selection constraints. For a tool with six formats and modular arithmetic, this is enough for correct selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents both parameters at 100% coverage, so the baseline is 3. The description adds meaningful extra semantics for 'format' by explaining that a bare digit string is ambiguous, that the format must be named, and that IBAN length handling is registry-based. It does not add much beyond the schema for 'input', hence 4 rather than 5.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific action ('Checks the check digit') and names the exact resource and formats (IBAN, ISBN-10/13, EAN-13, UPC-A, Luhn). It also distinguishes the tool by stating it localises a fixable error rather than only reporting failure, so an agent can tell it apart from any generic validator.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The 'WHY DELEGATE THIS' section makes the intended use case explicit: offload checksum arithmetic and error-localisation when a model would otherwise 'fumble silently' or pattern-match a plausible answer. It does not name sibling alternatives, and the sibling list contains no overlapping tools, but it stops short of enumerating when-not-to-use conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Convert a colour between hex, RGB, HSL, OKLCH, CMYK, and CSS names, and derive complementary, analogous, triadic, split-complementary and monochromatic harmonies. Harmonies are rotated in OKLCH, not HSL, so they keep their perceived lightness instead of one looking washed out. Reports WCAG contrast against white and black, and flags colours clipped to fit sRGB.
WHY DELEGATE THIS: Colour-space arithmetic has no feedback signal — a wrong hex-to-OKLCH looks exactly like a right one until someone sees the colour. Harmonies rotated in HSL also come out perceptually unbalanced, which is the usual mistake.
Owned by Color Companion at https://color-companion.gumballtools.com, which is also callable directly if you would rather not go through the aggregator.
| Name | Required | Description | Default |
|---|---|---|---|
| color | Yes | hex, rgb(), hsl(), oklch(), a CSS colour name, or "transparent". |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnly/openWorld annotations, the description discloses meaningful behavioral details: harmonies are rotated in OKLCH to preserve perceived lightness, WCAG contrast is reported against white and black, and out-of-sRGB colors are flagged. This gives the agent useful expectations about the tool's decisions and limitations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the main capability and then adds a concise 'WHY DELEGATE THIS' rationale. The ownership line is mildly extra but not wasteful. It is longer than minimal, yet every sentence carries useful context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter, no-output-schema tool, the description covers the core invocation needs: supported input formats, generated harmonies, contrast reporting, clipping behavior, and the OKLCH rationale. It stops short of describing the exact return shape, which would be a small additional benefit.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already fully documents accepted color formats, so the baseline is 3. The description adds value by clarifying that the single color parameter drives multiple kinds of output, including conversions, harmony generation, contrast checks, and clipping flags, and by mentioning CMYK as an additional conversion target.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: converting colors between named formats and deriving specific harmony types. It also names concrete outputs like WCAG contrast and sRGB clipping, which 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The 'WHY DELEGATE THIS' section gives a clear rationale for when this tool is valuable, especially the lack of feedback in color-space arithmetic and the perceptual balance issue with HSL harmonies. It does not list sibling alternatives, but no sibling tool appears color-related, so exclusions are unnecessary.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Convert an English schedule description into a cron expression. Rule-based, not a language model: it refuses phrases outside its grammar rather than guessing, and reports which words it did not use so you can tell whether it read you correctly.
WHY DELEGATE THIS: Cron has counter-intuitive rules: day-of-month and day-of-week are OR-ed, steps like */7 do not divide their field evenly, and February 30 never fires. Reasoning about an expression directly gets these wrong quietly.
Owned by Cron Translator at https://crontoenglish.com, which is also callable directly if you would rather not go through the aggregator.
| Name | Required | Description | Default |
|---|---|---|---|
| phrase | Yes | e.g. "every weekday at 9am". |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses key behaviors beyond the readOnlyHint annotation: it is rule-based rather than a language model, it refuses out-of-grammar phrases instead of guessing, and it reports unused words as a correctness signal. This is exactly the kind of behavioral context an agent needs to trust and interpret the result.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the single-sentence purpose, then layers behavioral notes, delegation rationale, and ownership context in logical sections. No sentence is wasted; the ownership note earns its place by offering an alternative route.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter tool with no output schema, the description covers the input type, failure behavior, output semantics, and rationale for delegation. It gives an agent everything needed to decide, invoke, and interpret the call correctly. An example output shape would be nice but is not necessary given the clarity of 'into a cron expression.'
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents 'phrase' with an example, so the baseline is 3. The description adds meaning by explaining that the phrase is an English schedule description and by revealing that extra or unrecognized words are not silently dropped but reported, which clarifies the expected input contract.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb-resource mapping: 'Convert an English schedule description into a cron expression.' It also distinguishes the tool from a language model and from sibling cron_explain by making the direction of translation unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The 'Why delegate this' section gives concrete conditions for using the tool, such as cron's OR-ing of day-of-month/day-of-week and the silent failure of expressions like February 30. It also notes the alternative of calling the owner directly. It doesn't explicitly name cron_explain as the reverse-use alternative, but the direction is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Translate a cron expression into plain English, list upcoming run times in a timezone, and report the gotchas that make schedules misfire: day-of-month/day-of-week OR semantics, steps that do not divide evenly, impossible dates, and daylight-saving shifts. Prefer this over reasoning about the expression yourself.
WHY DELEGATE THIS: Cron has counter-intuitive rules: day-of-month and day-of-week are OR-ed, steps like */7 do not divide their field evenly, and February 30 never fires. Reasoning about an expression directly gets these wrong quietly.
Owned by Cron Translator at https://crontoenglish.com, which is also callable directly if you would rather not go through the aggregator.
| Name | Required | Description | Default |
|---|---|---|---|
| count | No | How many next run times, 1-25. | |
| timezone | No | IANA name. Defaults to UTC. | |
| expression | Yes | Five-field cron expression, e.g. "0 9 * * 1-5". Macros like @daily work. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, and the description adds meaningful behavioral detail: it reports specific cron gotchas, handles timezone conversion for upcoming runs, and even discloses external ownership and direct calling. No contradiction exists, though output format and error behavior are not described.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The lead sentence is rich and front-loaded, but the 'WHY DELEGATE THIS' paragraph largely repeats the gotchas already listed in the first paragraph. The ownership/URL sentence adds context but is arguably tangential for an agent invoking the tool, making the description slightly more verbose than necessary.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With all three parameters fully documented in the schema and the description covering purpose, gotchas, timezone behavior, and delegation rationale, an agent can invoke the tool correctly. The absence of an output schema means return-shape details are not given, but the description's behavioral clarity is strong enough to compensate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the input schema already documents expression, count, and timezone meaningfully. The description only loosely maps to timezone ('in a timezone') and expression, adding no parameter-level detail beyond the schema, so a baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Translate a cron expression into plain English, list upcoming run times... and report gotchas') with a clear resource and scope. Its role is unmistakably distinct from the sibling cron_build, which would be the construction counterpart, so an agent can differentiate them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly advises 'Prefer this over reasoning about the expression yourself' and explains why delegation is safer, which gives solid usage context. However, it does not explicitly contrast the tool with sibling tools like cron_build or state concrete when-not-to-use scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Estimate a due date from a last menstrual period, a known conception date, an IVF transfer, or an ultrasound measurement. Gestational age is counted from the LAST PERIOD, not conception: at "6 weeks pregnant" conception was about 4 weeks ago. Applies the cycle-length adjustment most calculators skip, and the ACOG Committee Opinion 700 thresholds for when a scan should replace the period-based date. Dates must be YYYY-MM-DD; free-form dates are refused. A due date is a reference point, not a prediction. Not medical advice, and the response says so in its payload.
WHY DELEGATE THIS: Gestational age counts from the last menstrual period, not conception — the most misunderstood fact in the subject, and one models restate wrongly. Naegele's rule also assumes a 28-day cycle, and ACOG publishes a five-row table for when an ultrasound should replace period-based dating that nobody recalls correctly.
Owned by Due Date at https://due-date.gumballtools.com, which is also callable directly if you would rather not go through the aggregator.
| Name | Required | Description | Default |
|---|---|---|---|
| lmp | No | With ultrasound, enables the ACOG redating check. | |
| asOf | No | Reference date for "how far along". Default today. | |
| date | Yes | YYYY-MM-DD. The FIRST DAY of the last period, or the conception, transfer, or scan date. | |
| method | Yes | Use lmp unless given a conception date, transfer date, or scan. | |
| scanDays | No | For ultrasound: days part, 0-6. | |
| scanWeeks | No | For ultrasound: weeks part of the measured gestational age. | |
| cycleLength | No | 20-45, default 28. Affects lmp only; a 35-day cycle moves it a week. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes well beyond the readOnlyHint/openWorldHint annotations. It discloses that gestational age is counted from the last period rather than conception, that ACOG Committee Opinion 700 thresholds are applied, that dates must be YYYY-MM-DD and free-form dates are refused, and that a due date is a reference point, not a prediction. This gives the agent a clear behavioral model for the computation and its output.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is longer than average but well-organized, with the core function and critical caveats front-loaded. The 'WHY DELEGATE THIS' section justifies the existence of the tool and is useful for agent selection. The final ownership/URL sentence is slightly tangential to invocation, but it does provide an actionable alternative and does not seriously hurt clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 7 parameters, 5 method enums, and no output schema, the description covers the essential domain logic, input constraints, and the tool's non-answer nature. It does not describe the exact response payload fields beyond the disclaimer, but the title and opening sentence make the primary outputs (due date and gestational age) reasonably clear. The main gap is the absence of an explicit return-structure description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds useful context by explaining the LMP-vs-conception distinction and noting that cycle-length adjustments affect the period-based calculation. This helps the agent understand relationships between method, date, and cycleLength beyond the raw schema field descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Estimate a due date from a last menstrual period, a known conception date, an IVF transfer, or an ultrasound measurement.' It also clarifies the core concept of gestational age counted from LMP, distinguishing this tool from simpler calculators. No sibling tool overlaps with this domain, so no additional differentiation is needed.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The 'WHY DELEGATE THIS' section gives strong context for when to use the tool, highlighting that gestational age is commonly misunderstood and that ACOG redating thresholds are hard to recall. The schema further instructs 'Use lmp unless given a conception date, transfer date, or scan.' However, the description itself does not explicitly state when not to use the tool or name alternatives, though no relevant siblings exist.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Solves a linear or quadratic equation in one variable and returns every step: expanding parentheses, combining like terms, moving terms across the equals sign, and applying the quadratic formula with the discriminant stated. Reports identities and contradictions as such rather than as "no answer", gives roots as exact fractions with a decimal alongside, and labels complex roots explicitly instead of claiming no solution. Refuses rather than guesses on a missing or duplicated "=", a second variable, a function name, an unsupported exponent, or an inequality — every refusal says what to change. Covers only one-variable linear and quadratic equations: not systems, not inequalities, not degree three or higher.
WHY DELEGATE THIS: Three places this algebra goes quietly wrong when reasoned about directly: the sign when distributing a negative across parentheses, which direction a term moves as it crosses the equals sign, and dropping one of the two ± roots of a quadratic or rounding a complex pair into a false "no solution". Exact fraction arithmetic gets all three right every time, and showing the work is the point — a student checking their own scratch paper needs the steps, not the answer.
Owned by Equation Steps at https://equation-steps.gumballtools.com, which is also callable directly if you would rather not go through the aggregator.
| Name | Required | Description | Default |
|---|---|---|---|
| input | Yes | One equation with exactly one "=", using x as the only variable, e.g. "3(x-2) = 5x + 4". |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only provide readOnlyHint and openWorldHint, so the description carries the behavioral burden. It discloses rich runtime behavior: identities and contradictions are reported distinctly, roots are returned as exact fractions with decimals, complex roots are explicitly labeled, and refusals include what to change.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is longer than average but remains well-structured and front-loaded with core behavior. The 'WHY DELEGATE THIS' section is somewhat redundant for pure invocation purposes, but the operational details are organized clearly and earn their place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description fully explains what the tool returns: every step, including expanding parentheses, combining terms, moving terms, and the quadratic formula with discriminant. It also covers edge cases like identities, contradictions, and complex roots, leaving no major operational gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already documents the single 'input' parameter at 100% coverage with an example. The description adds operational meaning: supported equation types, refusal conditions, and the transformations that will be applied to the input, going well beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Solves a linear or quadratic equation in one variable and returns every step.' It also enumerates the exact step types and explicitly excludes systems, inequalities, and higher-degree equations, making it easy to distinguish from sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit when-to-use guidance and exclusion criteria: 'Covers only one-variable linear and quadratic equations: not systems, not inequalities, not degree three or higher.' It also details refusal conditions such as missing or duplicated '=', second variables, function names, unsupported exponents, and inequalities.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Convert a JSON sample into TypeScript interfaces and a matching Zod schema. Merges EVERY array element into a union rather than typing from the first, keeps optional and nullable distinct, and emits unknown with a warning for empty containers instead of inventing a shape. Read the warnings before trusting the output.
WHY DELEGATE THIS: Typing from the first array element produces types that reject the rest of the data, and null is routinely conflated with absent. Also far cheaper in output tokens than writing the types inline for a large payload.
Owned by JSON to Types at https://json-to-types.gumballtools.com, which is also callable directly if you would rather not go through the aggregator.
| Name | Required | Description | Default |
|---|---|---|---|
| json | Yes | Raw JSON sample text, not a JSON Schema. | |
| rootName | No | Name for the top-level interface. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnly and openWorld hints, the description discloses important inference behaviors: every array element is merged into a union, optional and nullable are kept distinct, and empty containers emit unknown with a warning. The explicit warning to read warnings before trusting output adds valuable transparency about output reliability. No contradiction with annotations exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core action and behavioral differentiators, followed by a compact rationale and ownership note. It is somewhat longer than strictly necessary, but every section serves a purpose: behavior, delegation value, and direct-call alternative. Structure is clear with labeled sections.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a conversion tool with no output schema, the description reasonably explains the output type (TypeScript interfaces plus Zod schema) and key edge-case behavior (empty containers, optional/nullable, array unions). It could add details like output formatting or default rootName behavior, but the essential details an agent needs to invoke and trust it are present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already has 100% description coverage for both parameters: 'json' is described as raw JSON sample text, and 'rootName' as the top-level interface name. The description adds general context about JSON samples and output but does not provide additional parameter-level detail beyond the schema. A baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Convert a JSON sample into TypeScript interfaces and a matching Zod schema.' It further clarifies behavior by specifying union merging for arrays, distinct optional/nullable handling, and unknown-with-warning for empty containers. Sibling tools are unrelated domains, so there is no ambiguity about which tool this is.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The 'WHY DELEGATE THIS' section gives clear context for when this tool is useful: avoiding types that reject valid data due to first-element typing, and saving output tokens for large payloads. It does not explicitly name alternative tools or provide when-not-to-use conditions, but the rationale is clear enough to guide selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns a verdict plus every step taken. THREE verdicts, not two: offside, onside, and no-offside-offence — the last is real and common, because in soccer an offside POSITION is not an offence without involvement in active play. Soccer: hands and arms never count (boundary at the bottom of the armpit), there is no offence direct from a throw-in, goal kick or corner, and a DELIBERATE play by an opponent resets it while a deflection does not. Hockey: skates decide it, not the stick, and since 2021 a skate in the air above the blue line is onside — but NOT when tagging up on a delayed offside. Not an official ruling.
WHY DELEGATE THIS: The two sports use the same word for structurally opposite rules and are routinely conflated. Soccer excludes hands and arms and treats an offside position as no offence without involvement; hockey judges skates against the blue-line plane, where since 2021 a skate in the air is onside — except when tagging up.
Owned by Sports Rules at https://sports-rules.gumballtools.com, which is also callable directly if you would rather not go through the aggregator.
| Name | Required | Description | Default |
|---|---|---|---|
| ball | No | SOCCER. Same scale. | |
| sport | Yes | ||
| restart | No | SOCCER. No offence direct from throw-in, goal-kick, or corner-kick. | |
| attacker | No | SOCCER. Position along the attacking axis; larger is nearer the opponents' goal. | |
| rearSkate | No | HOCKEY. Trailing skate in cm from the blue line leading edge; negative is behind. | |
| situation | No | ||
| skateOnIce | No | HOCKEY. Irrelevant on a zone entry since 2021; decisive when tagging up. | |
| involvement | No | SOCCER. REQUIRED once the player is in an offside position; the call errors without it. | |
| secondLastDefender | No | SOCCER. The SECOND-last opponent. Level is onside. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint and openWorldHint, and the description adds meaningful behavioral detail: three possible verdicts, return of every step, the no-offside-offence outcome, sport-specific edge cases, and the 'not an official ruling' disclaimer. It does not contradict the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded, readable, and uses bolded terms and clear sections. However, the 'WHY DELEGATE THIS' paragraph largely repeats the soccer/hockey distinctions already presented, and the ownership/direct-call sentence could be shorter. It is structured but somewhat redundant.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex two-sport tool with nine parameters and no output schema, the description covers the main edge cases, the three verdicts, key sport-specific rules, and an important caveat. It does not fully describe the output structure beyond 'verdict plus every step taken,' but it is sufficient for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is high, so the baseline is 3, but the description adds substantial legal context beyond the schema: hands and arms never count, deliberate play resets while deflection does not, and skates rather than the stick decide hockey offside. This helps an agent reason about parameters like involvement, restart, rearSkate, skateOnIce, and situation without restating every field.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool computes an offside verdict under IFAB Law 11 or NHL Rule 83 and returns a verdict plus every step taken. It explicitly names three distinct verdicts and differentiates soccer from hockey, making its purpose unmistakable and distinguishing it from unrelated siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The 'WHY DELEGATE THIS' section gives a strong positive rationale for using the tool, noting that the two sports use the same word for structurally opposite rules. It also names an alternative—calling Sports Rules directly—but does not provide explicit when-not-to-use conditions beyond the caveat that it is not an official ruling.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Explain a regular expression in plain English and detect catastrophic backtracking. ALWAYS call this before putting a pattern where it will run against untrusted input: (a+)+$ looks harmless and takes minutes of CPU on a failing 30-character input. Also flags missing anchors, unescaped dots, ranges like [A-z] that span punctuation, and alternation precedence mistakes. Check hasBlockingIssue first.
WHY DELEGATE THIS: Whether a pattern backtracks catastrophically depends on nested quantifier structure that is unreliable to eyeball — and getting it wrong ships a denial-of-service vector in a validator.
Owned by Regex Explainer at https://regex-explainer.gumballtools.com, which is also callable directly if you would rather not go through the aggregator.
| Name | Required | Description | Default |
|---|---|---|---|
| pattern | Yes | A JavaScript regex, bare or as /pattern/flags. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only declare readOnlyHint and openWorldHint. The description adds meaningful behavioral context beyond that: it flags catastrophic backtracking, missing anchors, unescaped dots, [A-z] ranges, alternation precedence mistakes, and instructs the agent to check hasBlockingIssue first. 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Core purpose and critical warning are front-loaded. The 'WHY DELEGATE THIS' and ownership lines add useful context but go slightly beyond the minimum needed for invocation, so it is not perfectly concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter tool with no output schema, the description provides enough guidance: input format, when to use it, and a hint about the result ('Check hasBlockingIssue first'). It does not fully specify the return shape, which is a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the parameter is already documented as a JavaScript regex, bare or as /pattern/flags. The description reinforces this with examples but does not add meaningful parameter semantics beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('explain') and resource ('regular expression') and adds a second distinct capability ('detect catastrophic backtracking'). It is clearly distinguishable 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives an explicit trigger: 'ALWAYS call this before putting a pattern where it will run against untrusted input', with a concrete ReDoS example. It does not give an explicit when-not-to-use or name an alternative tool, but the condition is precise and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Settle a transaction: exact subtotal, tax computed on that exact subtotal, then round the final total to the nearest nickel — and ONLY for cash. Card, EFT and gift-card payments stay priced to the cent, so the same basket legitimately comes to two amounts. Rounding applies to the TOTAL, never per item. A final digit of 1, 2, 6 or 7 rounds down; 3, 4, 8 or 9 rounds up. A string amount is read as dollars, a number as integer cents. Not legal or tax advice — there was no federal rounding law as of September 2026 and state law varies.
WHY DELEGATE THIS: Four things are wrong in most explanations and each changes the answer: rounding is cash-only, applies to the total rather than each item, happens after tax, and is not free money for retailers. Money in floating point is also a bug waiting to happen.
Owned by Penny Rounding at https://penny-rounding.gumballtools.com, which is also callable directly if you would rather not go through the aggregator.
| Name | Required | Description | Default |
|---|---|---|---|
| rule | No | ||
| tender | No | Default cash. Card is NEVER rounded. | |
| subtotal | Yes | Pre-tax subtotal as a dollar string, e.g. "19.99". | |
| taxRatePercent | No | Percentage, e.g. 8.25 — not 0.0825. Rounding happens after tax. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint and openWorldHint annotations, the description discloses cash-only behavior, total-vs-item rounding, post-tax order, exact digit rounding rules, string-as-dollars vs number-as-cents coercion, and a legal caveat. 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Core operational details are front-loaded and well organized. The 'WHY DELEGATE THIS' section is slightly redundant, but it adds misconception context and a technical warning, so it earns most of its length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The common cash-rounding path is thoroughly documented, including input formats and exclusions. Yet there is no output schema and no statement of the return value, and the rule parameter's effect on the result is left unexplained, so non-default invocations are under-specified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds useful semantics for subtotal input types and reinforces tender/tax behavior. However, the 'rule' parameter is not described; the stated digit-rounding behavior is only the default and does not explain symmetric, always-down, always-up, or none.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a precise verb+resource: settle a transaction by computing tax on the exact subtotal and rounding the final total to the nearest nickel, cash only. This unambiguous scope is clearly distinct from generic rounding tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly states when to use (cash, after tax, on the total) and when not to (card, EFT, gift-card stay priced to the cent). It does not name a sibling tool as the alternative, so the routing guidance stops just short of being fully explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compute the mean rounding delta per cash transaction across a price list. Answers "does rounding make retailers money" with arithmetic rather than a guess: symmetric rounding nets to essentially zero by construction. Pass always-up to quantify the "just round everything up" idea, which is worth about 2 cents a sale and which no jurisdiction has adopted for retail.
WHY DELEGATE THIS: Four things are wrong in most explanations and each changes the answer: rounding is cash-only, applies to the total rather than each item, happens after tax, and is not free money for retailers. Money in floating point is also a bug waiting to happen.
Owned by Penny Rounding at https://penny-rounding.gumballtools.com, which is also callable directly if you would rather not go through the aggregator.
| Name | Required | Description | Default |
|---|---|---|---|
| rule | No | ||
| prices | Yes | Comma-separated prices, e.g. 0.99,4.99,19.99. | |
| taxRatePercent | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnly/openWorld annotations, it reveals substantive behavior: symmetric rounding nets to zero by construction, always-up is worth about 2 cents/sale, rounding applies post-tax to totals in cash, and floating-point money is risky. It stops short of describing the output shape, but adds real context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The main purpose is front-loaded and the WHY DELEGATE section is organized around the four key misconceptions. The ownership URL and aggregator note are slightly extraneous, but they do not obscure the core guidance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the return value is never specified, and parameters like taxRatePercent lack precise semantics. The conceptual model is strong, but an agent would still have to guess at some invocation details and how to interpret the result.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 33%, so the description must compensate. It gives meaning to rule (symmetric vs always-up) and connects taxRatePercent to the 'after tax' behavior, but it leaves taxRatePercent units and the always-down/none cases undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Compute the mean rounding delta per cash transaction across a price list.' It also frames the business question it answers, but it does not explicitly differentiate itself from the sibling round_cash_total.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives a clear use case—quantifying whether rounding makes retailers money, with the always-up option as an example. However, it never states when to use this tool versus alternatives like round_cash_total, or any exclusion conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Convert a wall-clock time between IANA zones. Returns null when the local time DOES NOT EXIST because a daylight-saving jump skipped it, and both candidates when it happens twice. Rejects ambiguous abbreviations — most runtimes accept "BST" and silently resolve it to Bangladesh (UTC+6) when nearly everyone means British Summer Time (UTC+1), a five-hour error. Never do this arithmetic yourself.
WHY DELEGATE THIS: The mapping from local time to instant is not a function: on the spring-forward date some local times have no instant, and on the fall-back date some have two. A confident answer to an impossible question is indistinguishable from a correct one.
Owned by Timezone Truth at https://timezone-truth.gumballtools.com, which is also callable directly if you would rather not go through the aggregator.
| Name | Required | Description | Default |
|---|---|---|---|
| to | Yes | Target IANA zone, e.g. "Asia/Tokyo". | |
| from | Yes | Source IANA zone, e.g. "America/New_York". Abbreviations rejected. | |
| time | Yes | Wall-clock time as YYYY-MM-DD HH:MM. Free-form dates are refused. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes well beyond the readOnlyHint annotation by exactly describing edge-case behavior: null for nonexistent local times and both candidates for ambiguous times. It also explains the abbreviation rejection and the five-hour error risk, giving the agent essential behavioral expectations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and front-loaded: it states the core action first, then important edge cases, then the delegation rationale, then ownership and direct access. Every sentence earns its place and no content is redundant enough to cut.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given there is no output schema, the description explains the unusual return cases (null, both candidates) but does not specify the exact shape of a normal successful result, such as whether it returns a string with the converted wall-clock time and offset. This is a minor gap, but the overall definition is still very usable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already documents all three parameters with examples and constraints, so the description does not need to add much. It reinforces the abbreviation and free-form date rejections, but those are already in the schema, so the value added beyond the schema is minimal.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Convert a wall-clock time between IANA zones.' It also distinguishes this from doing arithmetic manually and from the direct Timezone Truth endpoint, making the tool's role unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives strong when-not guidance ('Never do this arithmetic yourself') and explains why delegation matters. It also mentions the direct Timezone Truth URL as an alternative to the aggregator, but it does not explicitly state when to prefer this tool over other sibling tools, though the siblings are largely unrelated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Mark an attempt and get the teaching content: whether it was right, which option was correct, why it fits, and why EVERY distractor fails. Read the distractor reasons out even when the learner was right — knowing why the tempting option was tempting is the part that transfers.
WHY DELEGATE THIS: A curated, human-written question bank. Generated vocabulary questions frequently have two defensible answers, which is worse practice than none.
Owned by Words in Context at https://words-in-context.gumballtools.com, which is also callable directly if you would rather not go through the aggregator.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Item id from a draw response. | |
| choice | Yes | Zero-based index of the chosen option. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes beyond the readOnlyHint annotation by disclosing the non-obvious requirement to read distractor reasons even after a correct answer. It also reveals the pedagogical rationale that knowing why the tempting option was tempting is the part that transfers. This gives an agent useful behavioral expectations beyond the structured annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose and output, followed by a behavioral instruction and a concise delegation rationale. Every sentence earns its place, and there is no redundant restating of the title or schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity, fully documented parameters, and annotations, the description is complete. It explains what the tool returns, how the result should be used pedagogically, and where the underlying content comes from, so an agent has enough context to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already fully documents both parameters: 'id' as an item id from a draw response and 'choice' as a zero-based option index. The description adds no additional parameter-level meaning, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the verb (mark/check) and resource (a vocabulary answer), and specifies exactly what the tool returns: correctness, the correct option, why it fits, and why every distractor fails. It also distinguishes itself from siblings by emphasizing the curated human-written Words in Context question bank and the direct-call option.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context: it is for checking a vocabulary attempt and delivering teaching content, including reading distractor reasons even when the answer is right. It also explains why delegation is appropriate, citing the curated question bank and the danger of generated questions with two defensible answers. It does not explicitly contrast with vocab_draw, but the sibling relationship and 'id from a draw response' make the intended flow clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Draw words-in-context practice questions from a curated bank. The response deliberately contains NO answers and NO explanations, so you can quiz someone without leaking them — call vocab_check for the answer and the reason each distractor fails. Pass a seed to make a set reproducible.
WHY DELEGATE THIS: A curated, human-written question bank. Generated vocabulary questions frequently have two defensible answers, which is worse practice than none.
Owned by Words in Context at https://words-in-context.gumballtools.com, which is also callable directly if you would rather not go through the aggregator.
| Name | Required | Description | Default |
|---|---|---|---|
| seed | No | Makes the draw reproducible. | |
| count | No | 1-20, default 5. Refused if out of range. | |
| theme | No | ||
| difficulty | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnly/openWorld annotations, the description discloses a critical output behavior: it deliberately omits answers and explanations to avoid leaking them, and a seed makes draws reproducible. It also identifies the external source with a URL. A small gap is that the exact return shape or format is not described.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The core behavior is front-loaded in the first sentence and the 'WHY DELEGATE THIS' section earns its place by helping tool choice. It is slightly redundant ('curated bank' then 'curated, human-written question bank') and the direct-URL note could be trimmed, but overall it is tight.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only tool with no required parameters and no output schema, the description covers the important context: no answers/explanations, reproducibility, delegation rationale, and direct alternative. It does not spell out the exact question format, but the phrase 'practice questions' plus the answer-routing to vocab_check covers the essential selection and invocation needs.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description only restates the seed's reproducibility, which the schema already documents, and leaves theme and difficulty meanings to their enum names. Schema coverage is 50%, so it is not under the low-coverage threshold that would force the description to compensate, but the description adds little parameter-level meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The first sentence names a specific action and resource: 'Draw words-in-context practice questions from a curated bank.' It further distinguishes itself by stating the response contains no answers or explanations and pointing to vocab_check, which separates it from the relevant sibling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives an explicit delegation rationale ('curated, human-written question bank' vs generated questions that 'frequently have two defensible answers') and names alternatives: vocab_check for answers and the direct Words in Context service. This is enough for an agent to decide when to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
amortize_schedulecheck_digit_runequation_steps_runbody_metricscolor_analysecron_buildcron_explaindue_datejson_to_typesoffsideregex_explainround_cash_totalrounding_impacttimezone_convertvocab_checkvocab_drawClaiming proves that you control a remote MCP connector. It does not move, proxy, or interrupt the server.
Open the connector listing, choose Claim ownership, and sign in to Glama.
Complete one verification method:
GitHub identity — fastest for official registry listings. For a namespace such as io.github.alice/server, link the matching GitHub user, then choose Claim with GitHub. An organization namespace such as io.github.acme/server also needs that organization to have installed the Glama AI GitHub App and approved its permissions, because GitHub discloses organization membership only to apps it has installed. Use HTTP or DNS when it has not.
HTTP challenge — works when you can deploy a public file. Generate a token, publish the exact JSON Glama shows at /.well-known/glama.json on the same origin as the connector, then choose Check HTTP challenge.
DNS challenge — works when you control DNS but cannot change the server. Generate a token, create the exact TXT record Glama shows, wait for it to propagate, then choose Check DNS challenge.
After verification, Glama sends a confirmation email and gives you access to listing details, thumbnails, health checks, and analytics. Keep the HTTP file or DNS record in place: Glama periodically checks it and ownership remains verified while the token is discoverable.
The HTTP ownership file has this structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"claim": "glama_claim_..."
}Claim tokens are opaque, stable, and bound to the signed-in Glama account. They contain no email address or other personal information. If Glama can no longer discover a verified HTTP or DNS token, it starts a seven-day grace period before removing claim-based access. Restore the same token during that period to keep ownership verified. Never publish an email address, Glama session token, GitHub token, or connector credential as ownership proof.
If verification fails, confirm that you copied the current token exactly. The HTTP file must be public, return valid JSON with a successful HTTP response, and stay on the connector's origin. DNS changes may need more time to propagate. A claim cannot transfer to a different origin or hostname: if the connector target changes, Glama starts the grace period and the new target must be claimed separately after the previous claim is released.
For a connector linked to the official MCP Registry, registry updates continue to replace its name, description, and URL by default. After claiming, open Manage connector and enable Use Glama listing details as the source of truth if edits made on Glama should be preserved. Categories and thumbnails are always managed on Glama; registry linkage and technical connection settings continue to sync.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
To improve your MCP server's ranking:
Claim ownership of the server listing
Complete the server profile with an accurate description and thumbnail
Provide a test profile so Glama can connect to and evaluate the server
Keep tool definitions clear and complete to earn a high Tool Definition Quality Score (TDQS)
Route real usage through the Glama Gateway; more recorded successful server uses also improve the ranking
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!
A MCP server built for developers enabling Git based project management with project and personal…
An MCP server that provides read access to your cloud storage providers, bank accounts and more.
Add one secure layer between your agents and this server.
Every tool targets a distinct domain and operation, with detailed descriptions that make overlap unlikely. The closest pairs, like cron_build/cron_explain and vocab_check/vocab_draw, are complementary rather than ambiguous.
All names are snake_case, but the grammatical pattern is mixed: some are noun_verb, some verb_noun, some noun_noun, and two end in the unusual suffix '_run'. The names are readable, but they do not follow one predictable convention.
At 16 tools this is just above the typical 3-15 range, but the server is explicitly an aggregator of standalone specialized tools, so the broader count is defensible. Each tool earns its place and there is no redundant duplication.
The server is not a single-domain CRUD surface, so completeness is more about whether each tool feels self-contained. It does: paired tools like build/explain and draw/check form complete workflows, and no obvious essential counterpart appears missing.
