Project Gumball
REMOTE · GUMBALLTOOLS.COM · SCANNED SEP 25
One MCP server exposing every tool in the Gumball portfolio.
Available components
How this component scores in each security and reliability category. Every signal is checked automatically against the live server, and we only credit what we can confirm. How we score → Why this is hard to score →
Endpoint Security63
- The endpoint's TLS certificate is valid, in date, and uses a strong key. View diagnostics → Pass
- Authorisation not fully verified: no authorisation is required to call this server, and 25 tool(s) never declared a destructiveHint. The MCP spec treats an absent hint as destructive by default, so we cannot call this surface safe. See how to fix → View diagnostics → Unverified
- HTTPS is enforced; there's no plaintext access path. View diagnostics → Pass
- The HSTS (Strict-Transport-Security) header is present. View diagnostics → Pass
- DNSSEC check failed: this domain isn't protected by DNSSEC. See how to fix → View diagnostics → Fail
Transport & Reachability100
- Verified streamable-http transport via a live MCP handshake. View diagnostics → Pass
Schema Quality & AI Usability61
- AI-judged instruction clarity (excellent).Pass
- Context-footprint check failed: tool/resource definitions use about 7480 tokens (~299/item across 25 items; 25 tools + 0 resources), over budget; trim descriptions and params. See how to fix → Fail
- Usage-examples check failed: none of the tools include examples. See how to fix → Fail
Stability & Change Management67
- Stability observed for 20 of 30 days with no destabilising changes; credit accrues until the full window elapses.Partial
Tool Coverage95
- 100% of tools have a non-trivial description (not blank, and not just the tool's name).Pass
- 86% of tool parameters carry a description.Partial
Tool Safety100
- No prompt-injection markers were found in the server instructions, tool names or descriptions we captured.Pass
- We read all 25 captured tool definition(s), and no name or description among them implies an irreversible operation.Pass
- An AI judge read all 25 captured unit(s) of tool text and found none that tries to manipulate the model reading it.Pass
Capabilities100
- Implements a current MCP spec version (2026-07-28).Pass
How do I install the Project Gumball MCP server?
Project Gumball is a hosted endpoint at https://gumballtools.com/api/mcp, so there is nothing to install locally. Ready-made configuration for Claude, Cursor, VS Code, Codex and 5 more is on this page, copied from each client's own documentation.
remote · gumballtools.com
claude mcp add --transport http com-gumballtools-platform 'https://gumballtools.com/api/mcp'
{
"mcpServers": {
"com-gumballtools-platform": {
"url": "https://gumballtools.com/api/mcp"
}
}
} {
"servers": {
"com-gumballtools-platform": {
"type": "http",
"url": "https://gumballtools.com/api/mcp"
}
}
} [mcp_servers.com-gumballtools-platform] url = "https://gumballtools.com/api/mcp"
{
"$schema": "https://opencode.ai/config.json",
"mcp": {
"com-gumballtools-platform": {
"type": "remote",
"url": "https://gumballtools.com/api/mcp",
"enabled": true
}
}
} openclaw mcp add com-gumballtools-platform --url 'https://gumballtools.com/api/mcp' --transport streamable-http
mcp_servers:
com-gumballtools-platform:
url: "https://gumballtools.com/api/mcp" {
"McpServers": {
"com-gumballtools-platform": {
"Transport": "http",
"Url": "https://gumballtools.com/api/mcp"
}
}
} assistant mcp add com-gumballtools-platform -t streamable-http -u 'https://gumballtools.com/api/mcp'
{
"mcpServers": {
"com-gumballtools-platform": {
"type": "http",
"url": "https://gumballtools.com/api/mcp"
}
}
} The mcpServers block is a cross-client convention. Remote transports vary, so check your client's docs.
Every change we have recorded for this component, newest first. Security-relevant changes are always shown. ▲ marks a change for the better, ▼ a change for the worse; unmarked changes are neutral.
- 25 Sept 26 0
- We updated how we score, so this day's move reflects our rubric, not a change to the server See what changed → functional
- 24 Sept 26 +1
No change was recorded against any check on this day. Stability & Change Management went from 60 to 63. That category is still filling its 30-day observation window: 18 days of observed history at the previous scan, 19 at this one. The score rises as the window fills, whether or not the server changes.
- 22 Sept 26 +1
No change was recorded against any check on this day. Stability & Change Management went from 53 to 57. That category is still filling its 30-day observation window: 16 days of observed history at the previous scan, 17 at this one. The score rises as the window fills, whether or not the server changes.
- 20 Sept 26 +1
No change was recorded against any check on this day. Stability & Change Management went from 47 to 50. That category is still filling its 30-day observation window: 14 days of observed history at the previous scan, 15 at this one. The score rises as the window fills, whether or not the server changes.
- 18 Sept 26 +1
No change was recorded against any check on this day. Stability & Change Management went from 40 to 43. That category is still filling its 30-day observation window: 12 days of observed history at the previous scan, 13 at this one. The score rises as the window fills, whether or not the server changes.
- 16 Sept 26 +1
No change was recorded against any check on this day. Stability & Change Management went from 33 to 37. That category is still filling its 30-day observation window: 10 days of observed history at the previous scan, 11 at this one. The score rises as the window fills, whether or not the server changes.
- 13 Sept 26 +1
No change was recorded against any check on this day. Stability & Change Management went from 23 to 27. That category is still filling its 30-day observation window: 7 days of observed history at the previous scan, 8 at this one. The score rises as the window fills, whether or not the server changes.
- 11 Sept 26 +1
No change was recorded against any check on this day. Stability & Change Management went from 17 to 20. That category is still filling its 30-day observation window: 5 days of observed history at the previous scan, 6 at this one. The score rises as the window fills, whether or not the server changes.
Diagnostic detail from the automated scan of this channel: what the scanner observed at each step, so you can see exactly where a check passed or failed. It is informational only and never changes the trust score.
Captured 25 Sept 2026 · Probed https://gumballtools.com/api/mcp
TLS valid
Negotiated TLS 1.3 with TLS_AES_128_GCM_SHA256 .
| Subject | Issuer | Valid from | Valid until | Key | Signature | Serial |
|---|---|---|---|---|---|---|
| CN=*.gumballtools.com | CN=YR2,O=Let's Encrypt,C=US | 6 Sept 2026 | 5 Dec 2026 | RSA 2048 | SHA256-RSA | 60927985e79d22e7a1106139f609d74b0e4 |
| SANs: *.gumballtools.com, gumballtools.com | ||||||
| CN=YR2,O=Let's Encrypt,C=US (CA) | CN=Root YR,O=ISRG,C=US | 3 Sept 2025 | 2 Sept 2028 | RSA 2048 | SHA256-RSA | 4ebd24947e24d394802d84a52fd5b319 |
| CN=Root YR,O=ISRG,C=US (CA) | CN=ISRG Root X1,O=Internet Security Research Group,C=US | 13 May 2026 | 2 Sept 2032 | RSA 4096 | SHA256-RSA | f24b6d17f9d9ad7cb1c9fea78782699f |
Background: What to check on a remote MCP endpoint →
DNSSEC insecure
Validation of gumballtools.com. — Not signed
| Zone | DS | Keys | Algorithms | Outcome |
|---|---|---|---|---|
| . | trust_anchor | 20326, 38696 | 8, 8 | Verified |
| com. | present | 19718 | 13 | Verified |
| gumballtools.com. | absent | Unsigned (proven) parent-signed NSEC/NSEC3 proves an unsigned delegation |
Authentication No authorisation required
The endpoint answered without asking for a token. Anyone who knows the URL can reach it.
| Result | No authorisation required |
|---|---|
| HTTP status | 200 |
| Header | Value |
|---|---|
| strict-transport-security | max-age=63072000 |
Background: How OAuth 2.1 works in the 2026 MCP spec →
Transports 2 probes
| Transport | URL | Outcome | Status | Location |
|---|---|---|---|---|
| streamable-http | https://gumballtools.com/api/mcp | Verified | 200 | |
| http (plaintext) | http://gumballtools.com/api/mcp | HTTPS enforced | 308 | https://gumballtools.com/api/mcp |
The tools this component advertises to a client, with an estimated token cost for each. Expand a tool to see its parameters and schema. The per-tool counts are indicative and are not scored directly; the schema's total context footprint is one signal in Schema Quality & AI Usability. A tool's description is untrusted text the model reads on every call, which is what makes this list a security surface and not just an inventory: how tool poisoning works →
amortize_schedule Build a loan amortization schedule (Amortization Schedule) ~403
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 | Type | Req | Description |
|---|---|---|---|
| annualRatePercent | number | yes | Annual rate as a percentage, e.g. 6.5 — not 0.065. |
| compounding | string | – | Monthly (rate/12) is the US fixed-mortgage norm. Daily is simple daily accrual. |
| dayCountBasis | string | – | – |
| paymentFrequency | string | – | – |
| principal | number | yes | Loan amount in dollars. |
| startDate | string | – | ISO YYYY-MM-DD. Required for daily accrual unless dayCountBasis is given. |
| termMonths | number | yes | Term in months, e.g. 360 for thirty years. |
No output schema declared.
No examples provided.
body_metrics BMI, calories, and protein with error bounds (Body Metrics) ~341
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 | Type | Req | Description |
|---|---|---|---|
| activity | string | – | The largest source of error. Most people overestimate; take the lower band. |
| age | number | yes | Years, 15-100. |
| bodyFatPercent | number | – | Adds the Katch-McArdle estimate. |
| height | string | yes | WITH a unit: 178cm, 1.78m, 5'10", 70in. Bare numbers refused. |
| sex | string | yes | The BMR equations are fitted separately. |
| targetBmi | number | – | – |
| weight | string | yes | WITH a unit: 75kg, 165lb, 11st 8lb. Bare numbers refused. |
No output schema declared.
No examples provided.
check_digit_run Validate a check digit and localise a single-digit error (Check Digit Validator) ~314
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 | Type | Req | Description |
|---|---|---|---|
| format | string | yes | Which checksum to apply. Required — a digit string is not auto-detected. |
| input | string | yes | The number to check. Spaces and hyphens are ignored. |
No output schema declared.
No examples provided.
color_analyse Convert a colour and find its harmonies (Color Companion) ~206
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 | Type | Req | Description |
|---|---|---|---|
| color | string | yes | hex, rgb(), hsl(), oklch(), a CSS colour name, or "transparent". |
No output schema declared.
No examples provided.
cron_build Build a cron expression from English (Cron Translator) ~151
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 | Type | Req | Description |
|---|---|---|---|
| phrase | string | yes | e.g. "every weekday at 9am". |
No output schema declared.
No examples provided.
cron_explain Explain a cron expression (Cron Translator) ~212
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 | Type | Req | Description |
|---|---|---|---|
| count | integer | – | How many next run times, 1-25. |
| expression | string | yes | Five-field cron expression, e.g. "0 9 * * 1-5". Macros like @daily work. |
| timezone | string | – | IANA name. Defaults to UTC. |
No output schema declared.
No examples provided.
cron_next_runs List the next run times for a cron expression (Cron Translator) ~293
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 | Type | Req | Description |
|---|---|---|---|
| count | integer | – | How many runs to return. Defaults to 5. |
| expression | string | yes | A five-field cron expression, e.g. "0 9 * * 1-5". |
| timezone | string | – | IANA zone for the local rendering, e.g. "America/New_York". Defaults to UTC. |
No output schema declared.
No examples provided.
due_date Due date and gestational age, with ACOG redating applied (Due Date) ~382
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 | Type | Req | Description |
|---|---|---|---|
| asOf | string | – | Reference date for "how far along". Default today. |
| cycleLength | number | – | 20-45, default 28. Affects lmp only; a 35-day cycle moves it a week. |
| date | string | yes | YYYY-MM-DD. The FIRST DAY of the last period, or the conception, transfer, or scan date. |
| lmp | string | – | With ultrasound, enables the ACOG redating check. |
| method | string | yes | Use lmp unless given a conception date, transfer date, or scan. |
| scanDays | number | – | For ultrasound: days part, 0-6. |
| scanWeeks | number | – | For ultrasound: weeks part of the measured gestational age. |
No output schema declared.
No examples provided.
equation_steps_run Solve an equation and show every step (Equation Steps) ~304
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 | Type | Req | Description |
|---|---|---|---|
| input | string | yes | One equation with exactly one "=", using x as the only variable, e.g. "3(x-2) = 5x + 4". |
No output schema declared.
No examples provided.
iso_week_run Convert between dates and ISO week numbers (ISO Week Number) ~565
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 looki…
| Name | Type | Req | Description |
|---|---|---|---|
| input | string | 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. |
No output schema declared.
No examples provided.
json_to_types JSON to TypeScript and Zod (JSON to Types) ~179
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 | Type | Req | Description |
|---|---|---|---|
| json | string | yes | Raw JSON sample text, not a JSON Schema. |
| rootName | string | – | Name for the top-level interface. |
No output schema declared.
No examples provided.
offside Work an offside call through IFAB Law 11 or NHL Rule 83 (Sports Rules) ~442
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 | Type | Req | Description |
|---|---|---|---|
| attacker | number | – | SOCCER. Position along the attacking axis; larger is nearer the opponents' goal. |
| ball | number | – | SOCCER. Same scale. |
| involvement | string | – | SOCCER. REQUIRED once the player is in an offside position; the call errors without it. |
| rearSkate | number | – | HOCKEY. Trailing skate in cm from the blue line leading edge; negative is behind. |
| restart | string | – | SOCCER. No offence direct from throw-in, goal-kick, or corner-kick. |
| secondLastDefender | number | – | SOCCER. The SECOND-last opponent. Level is onside. |
| situation | string | – | – |
| skateOnIce | boolean | – | HOCKEY. Irrelevant on a zone entry since 2021; decisive when tagging up. |
| sport | string | yes | – |
No output schema declared.
No examples provided.
offside_rule_contrast Contrast soccer and hockey offside, dimension by dimension (Sports Rules) ~238
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.
Input schema present but exposes no named parameters.
No output schema declared.
No examples provided.
price_band Find every list price that settles to the same cash total (Penny Rounding) ~400
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 | Type | Req | Description |
|---|---|---|---|
| listPrice | string | yes | The list price as a dollar string, e.g. "19.98". |
| spreadCents | integer | – | How far either side of the price to look, 1-50. Defaults to 5. |
| taxRatePercent | number | – | Tax rate as a percentage, e.g. 8.25. Defaults to 0. |
No output schema declared.
No examples provided.
regex_explain Explain a regex and check it for ReDoS (Regex Explainer) ~181
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 | Type | Req | Description |
|---|---|---|---|
| pattern | string | yes | A JavaScript regex, bare or as /pattern/flags. |
No output schema declared.
No examples provided.
round_cash_total Round a cash total the way the post-penny rules work (Penny Rounding) ~306
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 | Type | Req | Description |
|---|---|---|---|
| rule | string | – | – |
| subtotal | string | yes | Pre-tax subtotal as a dollar string, e.g. "19.99". |
| taxRatePercent | number | – | Percentage, e.g. 8.25 — not 0.0825. Rounding happens after tax. |
| tender | string | – | Default cash. Card is NEVER rounded. |
No output schema declared.
No examples provided.
rounding_impact What cash rounding is actually worth (Penny Rounding) ~211
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 | Type | Req | Description |
|---|---|---|---|
| prices | string | yes | Comma-separated prices, e.g. 0.99,4.99,19.99. |
| rule | string | – | – |
| taxRatePercent | number | – | – |
No output schema declared.
No examples provided.
timezone_convert Convert a time between timezones (Timezone Truth) ~246
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 | Type | Req | Description |
|---|---|---|---|
| from | string | yes | Source IANA zone, e.g. "America/New_York". Abbreviations rejected. |
| time | string | yes | Wall-clock time as YYYY-MM-DD HH:MM. Free-form dates are refused. |
| to | string | yes | Target IANA zone, e.g. "Asia/Tokyo". |
No output schema declared.
No examples provided.
validate_auto Detect the format and validate (Payload Validator) ~355
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 | Type | Req | Description |
|---|---|---|---|
| input | string | yes | The raw document text. Up to 1,000,000 bytes. |
No output schema declared.
No examples provided.
validate_csv Validate CSV (Payload Validator) ~392
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 | Type | Req | Description |
|---|---|---|---|
| delimiter | string | – | Field delimiter, one character. Omit to sniff it from the header. |
| hasHeader | boolean | – | Whether the first row names the columns. Default true. False compares rows against the first row and skips header checks. |
| input | string | yes | The raw CSV text. Up to 1,000,000 bytes. |
No output schema declared.
No examples provided.
validate_json Validate JSON (Payload Validator) ~346
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 | Type | Req | Description |
|---|---|---|---|
| input | string | yes | The raw JSON text, not a parsed object. Up to 1,000,000 bytes. |
No output schema declared.
No examples provided.
validate_xml Validate XML (Payload Validator) ~334
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 | Type | Req | Description |
|---|---|---|---|
| input | string | yes | The raw XML text. Up to 1,000,000 bytes. |
No output schema declared.
No examples provided.
validate_yaml Validate YAML (Payload Validator) ~352
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 | Type | Req | Description |
|---|---|---|---|
| input | string | yes | The raw YAML text. Up to 1,000,000 bytes. |
No output schema declared.
No examples provided.
vocab_check Check a vocabulary answer (Words in Context) ~154
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 | Type | Req | Description |
|---|---|---|---|
| choice | integer | yes | Zero-based index of the chosen option. |
| id | string | yes | Item id from a draw response. |
No output schema declared.
No examples provided.
vocab_draw Draw vocabulary practice questions (Words in Context) ~173
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 | Type | Req | Description |
|---|---|---|---|
| count | integer | – | 1-20, default 5. Refused if out of range. |
| difficulty | string | – | – |
| seed | integer | – | Makes the draw reproducible. |
| theme | string | – | – |
No output schema declared.
No examples provided.
What is the Project Gumball MCP server?
Project Gumball is an MCP server listed in the public MCP registry as com.gumballtools/platform. One MCP server exposing every tool in the Gumball portfolio. This page covers its hosted endpoint (https://gumballtools.com/api/mcp).
Is the Project Gumball MCP server safe to use?
Project Gumball scores 73 out of 100 on VerifyMCP. That is a record of what we were able to check automatically, not an endorsement. The category breakdown on this page shows every signal behind the number, including the ones we could not confirm.
What tools does the Project Gumball MCP server expose?
Project Gumball exposes 25 tools: cron_explain, cron_build, cron_next_runs, json_to_types, regex_explain, and 20 more. Their descriptions and schemas cost roughly 7,480 tokens of context every time the server is loaded.
Does the Project Gumball MCP server require authentication?
No. We connected to Project Gumball without credentials and it answered, so anything it exposes is reachable by anyone who knows the address.
Is the Project Gumball MCP server still maintained?
Project Gumball is still listed as active in the MCP registry. We last reached this channel on 25 September 2026. Those dates come from our own scans of the registry and the channel itself, not from anything the publisher announced.