One MCP server exposing every tool in the Gumball portfolio.
Scored across 25 tools
Tools are mostly distinct by domain and action; the validate_* family and vocab_* family are especially clear. Some confusion is possible between cron_explain and cron_next_runs (both list upcoming runs) and between price_band and round_cash_total (both involve tax and rounding), but the descriptions do enough to separate them.
Snake_case is consistent and family prefixes like validate_, cron_, and vocab_ help, but the overall convention mixes verb_noun (amortize_schedule, round_cash_total), noun_verb (check_digit_run, regex_explain, timezone_convert), and bare nouns (body_metrics, offside, price_band). There is no single predictable pattern across the full set.
25 tools is at the heavy end of the scale, and while every tool is a distinct self-contained utility, the breadth makes selection harder than a well-scoped 3-15 tool server. For an aggregator this count is defensible, but it feels more like a grab bag than a focused toolset.
Each mini-domain is reasonably complete: cron has build/explain/next_runs, rounding has settle/optimize/impact, validation has auto plus format-specific validators, and vocab has draw/check. As a whole the set lacks a unifying workflow, and minor gaps exist (e.g., no regex builder or reverse due-date calculation), but no core tool chain has an obvious dead end.
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.
Lists the next run times for a cron expression in a specific timezone, with no prose. Use it when the only question is "when does this next fire" — whether a job runs before a deadline, or what a user's upcoming schedule looks like. Do not compute these dates unaided: weekday arithmetic, month lengths and daylight-saving shifts make manual calculation unreliable, and a schedule that is wrong by an hour twice a year is the hardest kind of wrong to notice. Returns each run as a UTC ISO 8601 instant plus a local wall-clock rendering in the requested timezone. Refuses Quartz-only syntax (L, W, #, ?) rather than guessing at it.
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 runs to return. Defaults to 5. | |
| timezone | No | IANA zone for the local rendering, e.g. "America/New_York". Defaults to UTC. | |
| expression | Yes | A five-field cron expression, e.g. "0 9 * * 1-5". |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint, and the description adds meaningful behavior beyond that: returns UTC ISO 8601 plus local wall-clock rendering, refuses Quartz-only syntax rather than guessing, and produces no prose. This is rich, accurate behavioral context with no contradiction.
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 and well-organized with a clear purpose sentence, but it is longer than necessary. The "WHY DELEGATE THIS" section repeats some of the earlier warning about manual calculation, and the "Owned by Cron Translator... callable directly" sentence adds little for an agent selecting the tool.
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 adequately explains the return format, timezone behavior, and syntax limitations, while the schema covers parameter defaults. It is slightly incomplete on error behavior for invalid expressions, but the core information needed to call and interpret the tool is 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?
Schema coverage is 100%, so the baseline is 3 even without extra parameter detail. The description does add some value by clarifying timezone semantics (UTC instant plus local rendering) and expression limitations, but it does not add much about count or expression beyond what the schema already states.
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: "Lists the next run times for a cron expression in a specific timezone." It also clarifies that the output is "with no prose," which distinguishes it from explanation-style sibling tools like cron_explain.
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 says to use the tool when the only question is "when does this next fire" and gives concrete scenarios: job deadlines and upcoming schedules. It also warns against manual computation. However, it does not explicitly name sibling alternatives or state when not to use it, only implying the boundary through the question phrasing.
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.
Converts calendar dates to ISO 8601 week-numbering dates and back, in either direction, and reports how many weeks an ISO year has.
Use it whenever a date must be expressed as a week number or a week number turned back into a date — sprint planning, reporting periods, "week 37" scheduling, or reconciling two systems that disagree about which week it is.
Do not compute this by dividing day-of-year by seven. Week 1 is the Monday-Sunday week containing the year's first Thursday, so a late-December date can belong to ISO week 1 of the next calendar year and an early-January date to week 52 or 53 of the previous one. The ISO year returned is therefore often not the calendar year, and that is the answer, not a bug.
Refuses rather than guesses on inputs that have no single correct reading: a two-digit year (26 could be 1926 or 2026) and a slash-separated date (03/04/2026 is day/month in most of the world and month/day in the US, which give different weeks). Every refusal says what to send instead.
Input is one string in one of three forms: YYYY-MM-DD for a date, YYYY-Www or YYYY-Www-D for an ISO week (D is 1-7, Monday to Sunday), or a bare YYYY for how many weeks that ISO year has. Calendar dates only — no time of day, no timezone.
Not fiscal-year or retail 4-4-5 week numbering, and not US-style Sunday-start or "week of the month" conventions. Those are different systems that also call themselves week numbers.
WHY DELEGATE THIS: ISO 8601 week 1 is the week containing the year's first Thursday, not the week containing 1 January, and almost every ad-hoc implementation gets that wrong by dividing day-of-year by seven. Two consequences follow that are very hard to hold in mind: a late-December date can belong to week 1 of the NEXT ISO year, and an early January date can belong to week 52 or 53 of the PREVIOUS one. A year has 53 weeks rather than 52 under a specific rule, not a pattern. Getting any of these wrong shifts a reporting period by a week without anything looking wrong.
Owned by ISO Week Number at https://iso-week.gumballtools.com, which is also callable directly if you would rather not go through the aggregator.
| Name | Required | Description | Default |
|---|---|---|---|
| input | Yes | A date (2027-01-01), an ISO week (2026-W53 or 2026-W53-5), or a bare year (2026). Two-digit years and slash-separated dates are refused as ambiguous. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool read-only, and the description adds substantial behavioral context beyond that: it refuses ambiguous inputs rather than guessing, explains what refusals say, handles boundary cases like December dates belonging to next ISO year, and clarifies that a returned ISO year differing from the calendar year is intended, not a bug.
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?
Well structured with front-loaded purpose, clear use guidance, and explicit input/refusal rules. The 'WHY DELEGATE THIS' section repeats some earlier content about week-1 rules and dividing by seven, so it is slightly longer than strictly necessary, but it is organized and readable.
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 with subtle date arithmetic, the description is complete: it covers accepted input forms, boundary behavior, ambiguous-input handling, exclusions, and even ownership. An agent has everything needed to invoke it correctly and interpret the domain 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 100%, but the description greatly expands parameter meaning by spelling out the exact accepted string forms (YYYY-MM-DD, YYYY-Www, YYYY-Www-D, bare YYYY) and the ambiguity rules for two-digit years and slash-separated dates. This is valuable beyond the schema's brief parameter description.
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?
States a precise verb and resource: converts calendar dates to ISO 8601 week-numbering dates and back, in either direction, and reports weeks in an ISO year. It also distinguishes itself from other week-numbering systems (fiscal, 4-4-5, Sunday-start), so an agent can tell it apart from siblings without opening schemas.
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?
Explicitly says 'Use it whenever a date must be expressed as a week number...' and gives concrete scenarios like sprint planning and reporting periods. It also tells the agent what not to do (divide by seven) and what systems it is not for (fiscal-year, retail 4-4-5, US Sunday-start), making selection unambiguous.
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.
Returns the structural differences between soccer offside and hockey offside, one dimension at a time. Use it when someone asks how the two compare, and — more usefully — before reasoning about one sport using an intuition from the other, which is the commonest way to get either wrong.
They differ on what part of the player is measured, when the picture freezes, whether position alone is an offence, what happens at exactly level, what resets the situation, and which restarts are exempt. Six dimensions, and borrowing the answer from the wrong sport is wrong on most of them.
Takes no arguments. Returns the comparison.
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 |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, so the description is not responsible for safety disclosure. It adds meaningful behavioral context by enumerating the six comparison dimensions (body part measured, freeze frame, position alone as offence, level situations, resets, exempt restarts) and clarifying 2021 hockey offside nuances. It does not describe output format, but the comparison content is well specified.
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 and structured with headings, but it is longer than needed for a no-argument tool. Points such as 'commonest way to get either wrong', 'routinely conflated', and 'borrowing the answer from the wrong sport is wrong on most of them' repeat similar ideas. The ownership URL and detailed delegate rationale add context but could be trimmed.
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 parameters, read-only annotations, and no output schema, the description covers purpose, usage, dimensions, and argument expectations. The only notable omission is the exact output format, but 'Returns the comparison' plus the listed dimensions is likely sufficient for an agent to invoke and 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?
The tool takes zero parameters, and the description explicitly states 'Takes no arguments.' This removes any risk of an agent inventing inputs. With no parameters to document, the description fully covers the parameter surface beyond the empty 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 opens with a specific action and resource: 'Returns the structural differences between soccer offside and hockey offside, one dimension at a time.' It also states when to use it, asking 'how the two compare', which clearly distinguishes it from the sibling tool 'offside' that likely handles a single sport. No ambiguity about what the tool does.
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 use cases: use it when someone asks how the two sports compare, and before reasoning about one sport using intuition from the other. It does not explicitly name alternatives or say when not to use it, but the context is clear enough for an agent to route correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
For a list price and a tax rate, finds every nearby list price that settles to the SAME cash total, and the highest one. Use it for "what should I charge" and "can I price to gain from rounding" questions.
There is exactly one free move here and it is easy to get backwards, which is why this is worth a call rather than a calculation. Rounding collapses a band of five consecutive list prices onto one nickel: at 0% tax, $19.98 through $20.02 all settle to $20.00 in cash. Within that band the cash collected is identical, so the highest price in it is strictly better — the same from cash customers and up to 4 cents more from every card customer.
The move that looks clever and is not: pricing BELOW a nickel so rounding "adds" a couple of cents. You collect the same cash and less on card. The rounding delta is not revenue, and this tool will not recommend it.
Returns the whole band, the highest price in it, and the free gain in cents — never more than 4.
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 |
|---|---|---|---|
| listPrice | Yes | The list price as a dollar string, e.g. "19.98". | |
| spreadCents | No | How far either side of the price to look, 1-50. Defaults to 5. | |
| taxRatePercent | No | Tax rate as a percentage, e.g. 8.25. Defaults to 0. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint, and the description goes well beyond that. It discloses that rounding is cash-only, applies after tax, is not free money, and that floating point money is a bug risk. It also clearly states what the tool returns and that the gain is never more than 4 cents. 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 longer than average but is front-loaded with the core purpose and use cases. The warning and 'WHY DELEGATE THIS' sections are genuinely informative, though the ownership/URL sentence at the end is somewhat extraneous. Overall, most sentences earn their place, but a little trimming would make it tighter.
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 clearly states what is returned: 'the whole band, the highest price in it, and the free gain in cents.' It also covers domain traps, parameter context, and the rationale for delegating. The agent has enough to decide when to call it and what to expect in response.
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 schema already documents all three parameters. The description adds useful conceptual context around listPrice and taxRatePercent, especially the 'after tax' and 'cash only' behavior, but it does not add significant per-parameter semantics beyond the schema. 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: 'finds every nearby list price that settles to the SAME cash total, and the highest one.' It also frames concrete use cases ('what should I charge' and 'can I price to gain from rounding'), making the tool's identity and value unmistakable. The title reinforces the same behavior without conflicting with the description.
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 states when to use the tool and what kinds of questions it answers. It also warns against a common misuse ('The move that looks clever and is not') and says the tool 'will not recommend it.' It does not explicitly name sibling alternatives like round_cash_total or rounding_impact, so the routing guidance is strong but not fully exhaustive.
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.
Detects whether a payload is JSON, YAML, XML or CSV, then validates it. Use it for a file with no extension, a clipboard paste, or a response body with an unhelpful content type. Detection is structural and the reason is always returned, so the assumption is visible: a leading "<" is XML, "{" or "[" is JSON, a %YAML directive or key: value lines are YAML, a consistent delimiter count across lines is CSV. JSON is checked before YAML deliberately, since JSON is a strict subset of YAML 1.2. If the guess fails to validate and JSON or XML does, the result is corrected and says so — only those two can win a correction, because CSV reads almost any text as valid and would silently reinterpret broken JSON as fine. Prefer the format-specific tool when you know the format.
WHY DELEGATE THIS: Syntax errors are the easy half. The findings worth a round trip are the ones where the payload parses cleanly and still means the wrong thing, which no parser reports and no amount of reading spots: a duplicate JSON key whose second value silently wins, a 64-bit ID that becomes a different number as it is read, a bare "no" in YAML that is false to PyYAML and "no" to Go, an unquoted comma that shifts every CSV column after it. Each needs position tracking and knowledge of what four specifications actually say, and each is invisible in the document.
Owned by Payload Validator at https://payload-validator.gumballtools.com, which is also callable directly if you would rather not go through the aggregator.
| Name | Required | Description | Default |
|---|---|---|---|
| input | Yes | The raw document text. Up to 1,000,000 bytes. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint and openWorldHint annotations, the description discloses significant behavioral detail: detection is structural, the assumed format is always returned, JSON is deliberately checked before YAML because JSON is a strict YAML subset, corrections only happen for JSON/XML, and CSV validation can silently reinterpret broken JSON. It also names concrete semantic traps like duplicate JSON keys, 64-bit ID precision loss, and YAML 'no' ambiguity, which a parser would not surface.
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 first paragraph is tightly written and front-loads purpose, usage, and routing. The 'WHY DELEGATE THIS' paragraph is long and somewhat promotional, but it earns its place by explaining subtle validation failure modes and the tool's unique value. The ownership line is minor overhead but not pure filler.
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 description is unusually complete for a complex tool: it covers input ambiguity, detection logic, correction behavior, limitations, and failure modes. The main gap is that there is no output schema and the description does not spell out the exact response shape beyond 'the reason is always returned' and correction messaging. Still, an agent has enough to select and invoke the tool correctly in most cases.
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 the single parameter as raw document text up to 1,000,000 bytes, so the baseline is 3. The description adds real-world meaning by framing the parameter as a 'payload' from a file, clipboard, or response body, and explains how that payload will be interpreted structurally. That extra framing is useful but not strictly necessary given the schema coverage.
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-object: 'Detects whether a payload is JSON, YAML, XML or CSV, then validates it.' It also clearly distinguishes this aggregator from the format-specific siblings by explicitly saying 'Prefer the format-specific tool when you know the format.' An agent can tell exactly what this tool does and how it differs from validate_json, validate_yaml, validate_xml, and validate_csv.
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 concrete when-to-use cases: a file with no extension, a clipboard paste, or a response body with an unhelpful content type. It also provides a clear exclusion rule: 'Prefer the format-specific tool when you know the format.' This gives the agent actionable routing guidance without needing to inspect sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Validates CSV against RFC 4180 and reports ragged rows individually with both field counts, because "row 4813 has 6 fields, the header has 5" is the entire answer. A ragged row loads without complaint almost everywhere — pandas pads or throws by engine, Excel shifts the columns, split(",") mis-assigns every field after the extra one — so nobody notices until a figure is wrong. Sniffs the delimiter from the header ignoring quoted regions, and always reports it, because a semicolon-separated European export read as comma-separated yields one column and no error. Also unterminated quotes, duplicate and unnamed and space-padded column names, mixed line endings, and a byte order mark that makes the first column impossible to look up by name.
WHY DELEGATE THIS: Syntax errors are the easy half. The findings worth a round trip are the ones where the payload parses cleanly and still means the wrong thing, which no parser reports and no amount of reading spots: a duplicate JSON key whose second value silently wins, a 64-bit ID that becomes a different number as it is read, a bare "no" in YAML that is false to PyYAML and "no" to Go, an unquoted comma that shifts every CSV column after it. Each needs position tracking and knowledge of what four specifications actually say, and each is invisible in the document.
Owned by Payload Validator at https://payload-validator.gumballtools.com, which is also callable directly if you would rather not go through the aggregator.
| Name | Required | Description | Default |
|---|---|---|---|
| input | Yes | The raw CSV text. Up to 1,000,000 bytes. | |
| delimiter | No | Field delimiter, one character. Omit to sniff it from the header. | |
| hasHeader | No | Whether the first row names the columns. Default true. False compares rows against the first row and skips header checks. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With readOnlyHint=true, the description still earns its keep by detailing behaviors not in annotations: it sniffs the delimiter from the header while ignoring quoted regions, always reports the delimiter, reports ragged rows with both field counts, and checks multiple edge cases. This goes well beyond the structured safety hints.
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 and well organized, but it is long and includes off-topic examples (JSON duplicate keys, YAML 'no') and meta details about the owning service and aggregator. These sentences add color but not invocation-critical information.
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 validator with full parameter documentation and rich check-list coverage, the description tells an agent what to expect in terms of findings (ragged rows, delimiter report, edge cases). It does not specify the exact output/error schema, and with no output schema available that is a small but real 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 coverage is 100%, so the schema already documents input, delimiter, and hasHeader. The description adds useful behavioral nuance—especially that the sniffer ignores quoted regions and that the delimiter is always reported, which informs what the tool returns. This is above the baseline 3.
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-plus-resource statement—"Validates CSV against RFC 4180"—and enumerates concrete checks (ragged rows, delimiter sniffing, unterminated quotes, BOM, etc.). This clearly distinguishes it from sibling validators like validate_json, validate_xml, and validate_yaml.
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 tool's scope is obvious from name and first sentence, and the 'WHY DELEGATE THIS' section gives strong context for when to prefer this service over manual parsing. However, it never explicitly states when not to use validate_csv or how it compares to validate_auto/other validator siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Validates a JSON document and reports every problem in one pass with a 1-based line and column, a stable rule code and a fix hint. Reports the three things JSON.parse cannot: duplicate keys (accepted by every parser, which then disagree about which value wins), integer precision loss past 2^53-1 proved with exact BigInt arithmetic (any 64-bit ID is in the lossy range), and unpaired surrogates that parse here and fail on re-serialisation. Also trailing commas, comments, single quotes, unquoted keys, Python literals, leading zeros, hex numbers, raw control characters, byte order marks, and NDJSON being read as one document. Returns valid and parseable separately, because a duplicate key is parseable and still ambiguous.
WHY DELEGATE THIS: Syntax errors are the easy half. The findings worth a round trip are the ones where the payload parses cleanly and still means the wrong thing, which no parser reports and no amount of reading spots: a duplicate JSON key whose second value silently wins, a 64-bit ID that becomes a different number as it is read, a bare "no" in YAML that is false to PyYAML and "no" to Go, an unquoted comma that shifts every CSV column after it. Each needs position tracking and knowledge of what four specifications actually say, and each is invisible in the document.
Owned by Payload Validator at https://payload-validator.gumballtools.com, which is also callable directly if you would rather not go through the aggregator.
| Name | Required | Description | Default |
|---|---|---|---|
| input | Yes | The raw JSON text, not a parsed object. Up to 1,000,000 bytes. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With readOnlyHint=true, the description adds substantial behavioral detail beyond the annotation: it reports line/column positions, stable rule codes, fix hints, separates valid from parseable, and lists specific error classes. The description also discloses caveats like NDJSON being read as one document, giving an agent a realistic model of behavior. 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?
The description is front-loaded with the core validation behavior and is organized with a separate rationale section. However, the 'WHY DELEGATE THIS' paragraph is verbose and partly repeats the value proposition, so not every sentence earns its place. It is still structured enough to be navigable.
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 only one simple input parameter, the description provides strong coverage of expected behavior, edge cases, and the distinction between valid and parseable. It does not specify the exact response schema or field names, which would be useful given the absence of an output schema, but it gives enough detail for an agent to invoke the tool and understand its 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?
The schema already covers the single parameter with 100% coverage, describing it as raw JSON text up to 1,000,000 bytes. The description reinforces that the input is a text document rather than a parsed object, but does not add substantial new parameter-level semantics beyond what the schema states. 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: 'Validates a JSON document and reports every problem in one pass'. It distinguishes this from sibling validators by enumerating JSON-specific issues like duplicate keys, integer precision loss, and unpaired surrogates, so an agent knows exactly what domain it covers.
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' paragraph gives clear context for when this tool is valuable: when a payload parses cleanly but still means the wrong thing. It does not explicitly name sibling validators such as validate_yaml or validate_csv, nor state when *not* to use this tool, but the JSON scope and the contrast with ordinary parsers make the intended use clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Validates XML for well-formedness, namespace correctness and entity-based attacks. Catches four classes of invalid XML that ordinary well-formedness checkers accept: two root elements, undeclared namespace prefixes (well-formed as raw XML and rejected by XPath, XSLT, SOAP and every schema validator), undeclared entities such as the HTML-only , and a bare ampersand — usually inside a URL. Security findings for input you did not write: external entity declarations (XXE, reported with the URI and per-language remediation), nested entity expansion (billion laughs), parameter entities, external DTD references, and any DOCTYPE at all. Nothing is ever resolved or fetched — that is the vulnerability, not a gap.
WHY DELEGATE THIS: Syntax errors are the easy half. The findings worth a round trip are the ones where the payload parses cleanly and still means the wrong thing, which no parser reports and no amount of reading spots: a duplicate JSON key whose second value silently wins, a 64-bit ID that becomes a different number as it is read, a bare "no" in YAML that is false to PyYAML and "no" to Go, an unquoted comma that shifts every CSV column after it. Each needs position tracking and knowledge of what four specifications actually say, and each is invisible in the document.
Owned by Payload Validator at https://payload-validator.gumballtools.com, which is also callable directly if you would rather not go through the aggregator.
| Name | Required | Description | Default |
|---|---|---|---|
| input | Yes | The raw XML text. Up to 1,000,000 bytes. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide readOnlyHint and openWorldHint, and the description adds meaningful behavioral context beyond that: 'Nothing is ever resolved or fetched — that is the vulnerability, not a gap.' It also discloses specific security findings like XXE, billion laughs, and DOCTYPEs. This is valuable side-effect transparency. 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 core behavior is front-loaded, but the long 'WHY DELEGATE THIS' paragraph is largely irrelevant to validate_xml, discussing duplicate JSON keys, 64-bit IDs, YAML booleans, and CSV commas. This bloats the description and dilutes the tool-specific message, making it less concise and focused than it should be.
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 description covers detection categories, security findings, and non-resolving behavior in detail, but it does not describe the output/return format, error behavior, or result structure. Since there is no output schema, this is a notable gap. The included generic aggregator pitch also consumes space that could have been used for tool-relevant completion.
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 covers 100% of the single parameter with 'The raw XML text. Up to 1,000,000 bytes.' The description adds no extra parameter-level semantics beyond what the schema provides, so the baseline score of 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 first sentence states a clear verb-resource-scope combination: 'Validates XML for well-formedness, namespace correctness and entity-based attacks.' This differentiates from sibling validators like validate_json and validate_csv. However, the 'WHY DELEGATE THIS' paragraph drifts into JSON, YAML, and CSV examples, which slightly muddies the XML-specific focus.
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?
No explicit when-to-use or when-not-to-use guidance is provided. The description never tells the agent to choose validate_xml over validate_json, validate_csv, or validate_auto. The only usage-related note is about calling Payload Validator directly, which is an access alternative rather than a tool-selection criterion, and the off-topic paragraph could actually mislead an agent into thinking this tool handles non-XML formats.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Validates a YAML document, including the values that mean different things to different loaders — found by resolving each unquoted scalar under both spec versions and comparing, not by matching a list of words. In YAML 1.1 (PyYAML) the bare words no/yes/on/off/y/n are booleans, so a country list loses Norway and the "on:" key of every GitHub Actions workflow is really the key true; 0755 is 493 under 1.1 and 755 under 1.2, both numbers so nothing looks wrong; 1:30 is the base-60 integer 90. Also duplicate keys, tabs used as indentation, non-breaking spaces mistaken for indentation, aliases with no anchor, merge keys, multi-document streams, and alias bombs. Quoted values are never flagged.
WHY DELEGATE THIS: Syntax errors are the easy half. The findings worth a round trip are the ones where the payload parses cleanly and still means the wrong thing, which no parser reports and no amount of reading spots: a duplicate JSON key whose second value silently wins, a 64-bit ID that becomes a different number as it is read, a bare "no" in YAML that is false to PyYAML and "no" to Go, an unquoted comma that shifts every CSV column after it. Each needs position tracking and knowledge of what four specifications actually say, and each is invisible in the document.
Owned by Payload Validator at https://payload-validator.gumballtools.com, which is also callable directly if you would rather not go through the aggregator.
| Name | Required | Description | Default |
|---|---|---|---|
| input | Yes | The raw YAML text. Up to 1,000,000 bytes. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description is exceptionally transparent about what the validator does: it resolves unquoted scalars under both YAML spec versions, reports duplicate keys, detects tabs/NBSP indentation issues, aliases without anchors, merge keys, multi-document streams, and alias bombs, and never flags quoted values. This adds far more behavioral context than the readOnlyHint/openWorldHint annotations alone provide.
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 behavior and contains valuable technical detail, but the 'WHY DELEGATE THIS' section repeats earlier examples, such as the bare 'no' scalar, and includes rhetorical flourishes like 'which no parser reports and no amount of reading spots'. It is informative but longer and more redundant 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?
Given the tool's complexity and the absence of an output schema, the description covers the validation scope thoroughly: spec version differences, dangerous YAML constructs, and what will not be flagged. It does not describe the exact output/return format or error reporting structure, which would make it fully complete for an agent, but it gives enough context 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 input schema already fully documents the single parameter 'input' as raw YAML text up to 1,000,000 bytes, giving 100% schema description coverage. The description adds useful behavioral context about how the YAML will be interpreted, but it does not substantially expand the semantic meaning of the parameter itself beyond what the schema already states.
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: it validates a YAML document and goes beyond syntax to flag semantic issues across YAML 1.1/1.2 loader differences. It clearly separates itself from sibling validators like validate_json, validate_csv, and validate_xml by focusing on YAML-specific behavior.
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 makes clear that this tool is for validating YAML text, including subtle loader-version discrepancies, duplicate keys, aliases, and multi-document streams. It does not explicitly name sibling validators as alternatives or say 'use validate_json for JSON', but the YAML-focused framing gives an agent clear context for when to select it.
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.
cron_next_runsoffside_rule_contrastprice_bandiso_week_runvalidate_autovalidate_csvvalidate_jsonvalidate_xmlvalidate_yamlamortize_schedulecheck_digit_runequation_steps_runbody_metricscolor_analysecron_buildcron_explaindue_datejson_to_typesoffsideregex_explainround_cash_totalrounding_impacttimezone_convertvocab_checkvocab_drawA 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.
