One MCP server exposing every tool in the Gumball portfolio.
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-tau.vercel.app, 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?
The description goes well beyond the readOnlyHint and openWorldHint annotations by disclosing that bare numbers are refused, that all standard BMR formulas are returned with the spread as precision, that single calorie figures should not be relayed as exact, and that the response includes a medical disclaimer. This is rich behavioral context an agent needs.
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 the most critical constraint. The sections are structured and purposeful, though the 'WHY DELEGATE THIS' and ownership paragraphs add length beyond the minimum needed. Still, every section earns its place for an agent that needs to decide whether to delegate.
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?
There is no output schema, so the description correctly explains key return behavior: every standard BMR formula plus the spread, and the medical disclaimer in the payload. It is complete enough for correct invocation, but it does not explain targetBmi's purpose or give a detailed response structure, so it stops short of a 5.
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 86%, so the baseline is 3. The description reinforces the unit requirement for height and weight, but the schema already documents this clearly with examples. The description adds little new parameter-specific meaning; targetBmi remains undocumented in both schema and 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?
The description opens with a specific verb and resource: 'Compute BMI, energy expenditure, and protein targets from height and weight.' It clearly distinguishes this tool from its unrelated siblings by stating its exact domain and its emphasis on error bounds. The scope is 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 strong contextual guidance about when this tool is appropriate, especially around unit ambiguity and false precision. It also names a direct API alternative. However, it does not explicitly state when not to use the tool or name a specific sibling alternative.
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-ebon.vercel.app, 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?
Annotations declare readOnlyHint=true and openWorldHint=true, and the description adds meaningful behavioral detail: harmonies are rotated in OKLCH to preserve perceived lightness, WCAG contrast against white/black is reported, and clipped sRGB colors are flagged. This goes well beyond what annotations alone convey, though it does not specify the exact response structure.
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-organized and front-loaded: core function first, then algorithmic nuance, then delegation rationale, then ownership. Every sentence carries distinct information, and the length is justified by the tool's multifunctional nature.
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 color utility with one parameter and no output schema, the description covers inputs, conversions, harmonies, contrast reporting, and clipping detection. It lacks a concrete response shape, but otherwise gives an agent everything needed to decide 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?
The schema covers 100% of the single parameter, listing accepted formats identical to the description. The description adds no new semantic info about the 'color' parameter; it only restates what the schema already says. Interestingly, CMYK is mentioned as a conversion target but not as an accepted input, a minor potential source of confusion.
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 pairing: 'Convert a colour between...' and enumerates exact formats plus harmony types. The title and description together make the tool unmistakable, and the sibling tools are unrelated, so there is no ambiguity.
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 the problem this tool solves (silent colour-space errors, unbalanced HSL harmonies), giving an agent a clear reason to select it. It also notes the provider can be called directly, but does not enumerate alternative sibling tools since none compete directly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Convert an English schedule description into a cron expression. Rule-based, not a language model: it refuses phrases outside its grammar rather than guessing, and reports which words it did not use so you can tell whether it read you correctly.
WHY DELEGATE THIS: Cron has counter-intuitive rules: day-of-month and day-of-week are OR-ed, steps like */7 do not divide their field evenly, and February 30 never fires. Reasoning about an expression directly gets these wrong quietly.
Owned by Cron Translator at https://crontoenglish.com, which is also callable directly if you would rather not go through the aggregator.
| Name | Required | Description | Default |
|---|---|---|---|
| phrase | Yes | e.g. "every weekday at 9am". |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses key behaviors beyond the readOnlyHint annotation: it is rule-based rather than a language model, it refuses out-of-grammar phrases instead of guessing, and it reports unused words as a correctness signal. This is exactly the kind of behavioral context an agent needs to trust and interpret the result.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the single-sentence purpose, then layers behavioral notes, delegation rationale, and ownership context in logical sections. No sentence is wasted; the ownership note earns its place by offering an alternative route.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter tool with no output schema, the description covers the input type, failure behavior, output semantics, and rationale for delegation. It gives an agent everything needed to decide, invoke, and interpret the call correctly. An example output shape would be nice but is not necessary given the clarity of 'into a cron expression.'
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents 'phrase' with an example, so the baseline is 3. The description adds meaning by explaining that the phrase is an English schedule description and by revealing that extra or unrecognized words are not silently dropped but reported, which clarifies the expected input contract.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb-resource mapping: 'Convert an English schedule description into a cron expression.' It also distinguishes the tool from a language model and from sibling cron_explain by making the direction of translation unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The 'Why delegate this' section gives concrete conditions for using the tool, such as cron's OR-ing of day-of-month/day-of-week and the silent failure of expressions like February 30. It also notes the alternative of calling the owner directly. It doesn't explicitly name cron_explain as the reverse-use alternative, but the direction is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Translate a cron expression into plain English, list upcoming run times in a timezone, and report the gotchas that make schedules misfire: day-of-month/day-of-week OR semantics, steps that do not divide evenly, impossible dates, and daylight-saving shifts. Prefer this over reasoning about the expression yourself.
WHY DELEGATE THIS: Cron has counter-intuitive rules: day-of-month and day-of-week are OR-ed, steps like */7 do not divide their field evenly, and February 30 never fires. Reasoning about an expression directly gets these wrong quietly.
Owned by Cron Translator at https://crontoenglish.com, which is also callable directly if you would rather not go through the aggregator.
| Name | Required | Description | Default |
|---|---|---|---|
| count | No | How many next run times, 1-25. | |
| timezone | No | IANA name. Defaults to UTC. | |
| expression | Yes | Five-field cron expression, e.g. "0 9 * * 1-5". Macros like @daily work. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, and the description adds meaningful behavioral detail: it reports specific cron gotchas, handles timezone conversion for upcoming runs, and even discloses external ownership and direct calling. No contradiction exists, though output format and error behavior are not described.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The lead sentence is rich and front-loaded, but the 'WHY DELEGATE THIS' paragraph largely repeats the gotchas already listed in the first paragraph. The ownership/URL sentence adds context but is arguably tangential for an agent invoking the tool, making the description slightly more verbose than necessary.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With all three parameters fully documented in the schema and the description covering purpose, gotchas, timezone behavior, and delegation rationale, an agent can invoke the tool correctly. The absence of an output schema means return-shape details are not given, but the description's behavioral clarity is strong enough to compensate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the input schema already documents expression, count, and timezone meaningfully. The description only loosely maps to timezone ('in a timezone') and expression, adding no parameter-level detail beyond the schema, so a baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Translate a cron expression into plain English, list upcoming run times... and report gotchas') with a clear resource and scope. Its role is unmistakably distinct from the sibling cron_build, which would be the construction counterpart, so an agent can differentiate them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly advises 'Prefer this over reasoning about the expression yourself' and explains why delegation is safer, which gives solid usage context. However, it does not explicitly contrast the tool with sibling tools like cron_build or state concrete when-not-to-use scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Estimate a due date from a last menstrual period, a known conception date, an IVF transfer, or an ultrasound measurement. Gestational age is counted from the LAST PERIOD, not conception: at "6 weeks pregnant" conception was about 4 weeks ago. Applies the cycle-length adjustment most calculators skip, and the ACOG Committee Opinion 700 thresholds for when a scan should replace the period-based date. Dates must be YYYY-MM-DD; free-form dates are refused. A due date is a reference point, not a prediction. Not medical advice, and the response says so in its payload.
WHY DELEGATE THIS: Gestational age counts from the last menstrual period, not conception — the most misunderstood fact in the subject, and one models restate wrongly. Naegele's rule also assumes a 28-day cycle, and ACOG publishes a five-row table for when an ultrasound should replace period-based dating that nobody recalls correctly.
Owned by Due Date at https://due-date-zeta.vercel.app, 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?
Beyond the readOnly and openWorld annotations, the description discloses meaningful behavior: free-form dates are refused, dates must be YYYY-MM-DD, the ACOG redating thresholds are applied, a due date is not a prediction, and the response includes a non-medical-advice disclaimer. This gives an agent important expectations about inputs and outputs.
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 organized with a 'WHY DELEGATE THIS' section, which is useful. However, the LMP-versus-conception point is repeated nearly verbatim in both the first paragraph and the WHY DELEGATE section, and the ownership/URL sentence is not essential for tool invocation.
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 input format, method selection, the ACOG redating behavior, cycle-length adjustment, and output caveats. There is no output schema, and while the return payload structure is not detailed, the core output ('due date') is intuitive and the disclaimer behavior is disclosed.
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. The description adds conceptual value beyond the schema by explaining that gestational age is counted from the last menstrual period, not conception, and illustrating the implication ('at 6 weeks pregnant conception was about 4 weeks ago'). This helps the agent map parameters to real-world 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 description opens with a precise verb and resource: 'Estimate a due date from a last menstrual period, a known conception date, an IVF transfer, or an ultrasound measurement.' It names the exact domain and methods, clearly distinguishing this tool 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?
It gives clear when-to-use context by explaining why delegation is valuable (models get gestational-age counting wrong, ACOG thresholds are hard to recall) and the schema adds method-selection guidance ('Use lmp unless given a conception date, transfer date, or scan'). It stops short of explicit when-not-to-use exclusions, but the guidance is strong.
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-seven.vercel.app, 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 readOnlyHint and openWorldHint, the description discloses concrete output behavior: every array element is merged into a union, optional and nullable are kept distinct, empty containers produce unknown with a warning, and warnings must be read before trusting output. This is rich behavioral detail not visible in 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 with the core purpose and edge-case behavior, then gives rationale and ownership context. It is slightly longer than strictly necessary due to the ownership/URL sentence, but the structure and headings make it easy to scan.
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 2-parameter transformation tool with no output schema, the description covers the output artifact, important edge cases, and trust warnings. It does not specify invalid-JSON behavior or response format details, but the included information is enough to 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 description coverage is 100%, so both parameters are already documented. The description reinforces that the input is a JSON sample rather than a schema and mentions the top-level output, but it adds no new parameter-level syntax or format details 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 opening sentence states a specific verb and resource: convert JSON sample into TypeScript interfaces and a matching Zod schema. It also specifies key behavior (array union merging, optional vs nullable, unknown for empties), making the tool's purpose unambiguous even before schema inspection.
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 to choose this tool: large payloads, avoidance of first-element typing, and token cost. It does not explicitly state when not to use it or name a sibling alternative, so it stops short of a 5.
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-theta.vercel.app, 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?
Beyond the readOnlyHint and openWorldHint annotations, the description discloses that the tool returns 'a verdict plus every step taken' and that the verdict set is three, not two. It also surfaces a concrete failure mode: in soccer, 'involvement' is REQUIRED once the player is in an offside position and 'the call errors without it.'
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 most important verdict information, but the 'WHY DELEGATE THIS' paragraph largely repeats the soccer/hockey distinctions already given. The ownership sentence is useful, yet the redundancy could be trimmed without losing value.
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 nine-parameter, two-sport tool with no output schema, the description covers the critical rule branches, the three possible verdicts, sport-specific input semantics, and important exceptions/error conditions. It does not fully describe the output shape beyond 'verdict plus every step taken,' but it is sufficiently complete for an agent to 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 78%, so many parameters are already documented, but the description adds rule-level meaning that helps an agent pick correct values: the armpit boundary, restart exceptions, deliberate play vs deflection, the hockey blue-line plane, and the tag-up exception. It does not walk through every parameter, but it substantially augments 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 opens with a concrete verb and resource: 'Returns a verdict plus every step taken' and immediately names the exact rule sources (IFAB Law 11, NHL Rule 83). It distinguishes the tool's scope across soccer and hockey and explains the three-verdict nuance, so an agent knows precisely what this 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 'WHY DELEGATE THIS' section explains why this tool exists — the two sports conflate structurally opposite offside rules — and explicitly names the direct Sports Rules endpoint as an alternative, saying it is 'also callable directly if you would rather not go through the aggregator.' It lacks an explicit 'use this when...' statement, but the context and alternative are clear enough for routing.
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-omega.vercel.app, 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 provide readOnlyHint=true and openWorldHint=true, so the description carries the burden of behavioral context. It discloses that the tool flags catastrophic backtracking, missing anchors, unescaped dots, dangerous character ranges, and alternation precedence mistakes, and explicitly instructs the agent to 'Check hasBlockingIssue first.' The example (a+)+$ demonstrates real-world impact. This goes well beyond what annotations convey.
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 critical usage warning, then expands into rationale and ownership. The 'WHY DELEGATE THIS' section is somewhat extra but earns its place by reinforcing the risk of manual inspection. The structure is clear, though slightly longer than strictly 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?
For a tool with no output schema, the description supplies key output guidance via 'Check hasBlockingIssue first' and enumerates common issues it detects. It also explains why the tool is necessary and when to invoke it. It does not fully describe the output format, but for an explainer tool this is sufficient 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 only parameter, pattern, already has a clear schema description: 'A JavaScript regex, bare or as /pattern/flags.' Since schema coverage is 100%, the description adds little extra semantic value beyond confirming the parameter is a regex. The tool description does not use the parameter specifically, so baseline 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 opens with a specific verb-resource pair: 'Explain a regular expression in plain English and detect catastrophic backtracking.' It clearly states both primary functions, and the title reinforces this. It distinguishes itself from all listed siblings, which are unrelated tools, so no further 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 description gives an explicit, imperative trigger: 'ALWAYS call this before putting a pattern where it will run against untrusted input.' It also offers a concrete example of when skipping this would be harmful. It does not name alternative tools, but sibling tools are unrelated, so alternatives are not relevant here. The 'WHY DELEGATE THIS' section further justifies delegation.
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.vercel.app, 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 the precise rounding algorithm by final digit, the after-tax timing, the cash-only scope, and the dollar-string versus integer-cents input convention. It also surfaces the legal caveat that no federal rounding law exists as of September 2026 and state law varies, which is valuable context for a computation tool.
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 key behaviors are front-loaded and the prose is readable, but the WHY DELEGATE THIS section repeats the same points from the first paragraph (cash-only, total not item, after tax) and adds peripheral motivational language about floating-point bugs and direct access. It could be tightened without losing 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?
The input side is very well covered, including rounding rules, tender handling, and legal caveats. However, with no output schema, the description never states what the tool returns, such as whether the result is a dollar-string rounded total, an integer cent value, or a breakdown containing subtotal, tax, and rounded total, so an agent still has to guess at the return contract.
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?
With 75% schema coverage the schema already documents subtotal, tender, and taxRatePercent, and the description adds useful semantics about exact subtotal, after-tax rounding, and cash-only behavior. However, the rule parameter and its enum values (symmetric, always-down, always-up, none) are never explained anywhere, and the rounding-digit rule in the description is not tied to which rule value it describes.
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 operation: settle a transaction by computing tax on the exact subtotal and rounding the final total to the nearest nickel for cash only. It clearly distinguishes cash treatment from card, EFT and gift-card treatment, and states that rounding applies to the total, never per-item, so the tool cannot be confused with a generic rounding utility.
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 clear selection criteria: use this for cash totals that need post-tax penny rounding, and it explicitly says card and other electronic tenders are never rounded. It does not name an alternative tool such as rounding_impact, but the cash-only trigger and the caution against common wrong explanations are enough to guide when to invoke it.
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.vercel.app, 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?
The readOnlyHint already signals a safe read operation, and the description adds meaningful context beyond it: rounding is cash-only, applied to the total rather than each item, happens after tax, and is not free money for retailers. It also warns that floating-point money handling is risky. 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 computation and then gives expected numeric behavior and a structured 'WHY DELEGATE THIS' section. The ownership/direct-call sentence is slightly tangential, but overall the text is readable, organized, and each major sentence contributes 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?
The description conveys the tool's purpose and an expected magnitude for always-up ('about 2 cents a sale'), but it does not specify the exact return format or units, the default rounding rule, or what happens when taxRatePercent is omitted. With no output schema, these details would help make invocation fully unambiguous.
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 only 33%, so the description must compensate, but it only partially does. It mentions price lists and 'always-up,' but does not explain the symmetric/always-down/none rule semantics, the default rule, or the meaning and optionality of taxRatePercent. The schema alone does not document these either.
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 precise computation: 'Compute the mean rounding delta per cash transaction across a price list.' This gives a specific verb and resource and clearly separates this tool from a sibling like round_cash_total, which would compute a rounded cash total rather than a mean impact.
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 a concrete use case: it answers whether rounding makes retailers money with arithmetic instead of a guess. It also tells the caller to pass always-up to quantify the 'round everything up' policy. It does not explicitly name alternatives or exclusions, but the context is clear enough for selection.
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.vercel.app, 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?
Beyond the readOnlyHint and openWorldHint annotations, the description discloses crucial edge-case behavior: returns null for skipped local times, returns both candidates for repeated times, rejects ambiguous abbreviations like 'BST', and refuses free-form date strings. This is rich, actionable behavioral context that prevents silent wrong answers.
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 conversion behavior, then uses a labeled rationale section and a provenance note. Every sentence adds decision-relevant information, and the formatting makes it easy for an agent to scan.
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 three-parameter tool with no output schema, the description is unusually complete: it covers edge cases, failure modes, and input restrictions. The only minor gap is that it never explicitly states the format of a successful return value, though 'converted time' is reasonably inferred.
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 all three parameters with 100% coverage, so the baseline is 3. The description adds value by reinforcing that abbreviations are rejected, explaining why, and clarifying that input is a wall-clock time in a strict format, which complements the schema without redundancy.
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 immediately differentiates this tool from the sibling list by naming exact behavior and edge-case semantics (nonexistent and ambiguous local times). There is no confusion about what the tool accomplishes.
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 text explicitly says 'Never do this arithmetic yourself' and explains why delegating is necessary, which tells the agent when this tool is the right choice. It also mentions an alternative, calling Timezone Truth directly, though it does not enumerate strict exclusion conditions or compare against non-timezone siblings.
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.vercel.app, 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 annotations already signal read-only and open-world behavior. The description adds valuable behavioral context beyond annotations: the teaching content returned, the explicit instruction to read distractor reasons even when the learner is correct, and the source/ownership of the question bank. This is more than the 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 purpose and then organized into helpful sections. The 'WHY DELEGATE THIS' and direct-call sections are extra content, but they earn their place by clarifying when and why to use this tool. Slightly longer than the minimum, but every sentence adds decision-relevant value.
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?
There is no output schema, so the description takes on the burden of explaining return content, and it does so thoroughly: right/wrong, correct option, explanation of fit, and explanations for every distractor. Combined with the two fully documented parameters, the agent has enough to select and invoke the tool correctly without ambiguity.
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%: the id is described as 'Item id from a draw response' and choice as 'Zero-based index of the chosen option.' The description adds no further parameter semantics, so the baseline 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 description uses a specific verb-resource pairing: 'Mark an attempt and get the teaching content' and enumerates exactly what is returned: correctness, correct option, why it fits, and why every distractor fails. This clearly distinguishes it from sibling tools like vocab_draw, which would draw the question rather than check an answer.
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 clear context for when to use the tool: after a learner has selected an option. The 'WHY DELEGATE THIS' section explains the rationale for using the curated bank over generated questions, and the note about calling the service directly offers a clear alternative. It does not explicitly say 'use vocab_draw to obtain the id first,' but the schema's 'Item id from a draw response' covers that connection.
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.vercel.app, 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?
Annotations already mark this as read-only, and the description adds valuable behavioral context: the response deliberately omits answers/explanations, seeds make draws reproducible, and the question bank is curated and human-written. This goes beyond what the annotations alone communicate, though it does not cover every edge behavior such as unseeded randomness.
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, then covers the no-answers behavior, rationale, and alternative access. The 'WHY DELEGATE THIS' and ownership URL are somewhat extra but still useful for an agent deciding whether to use this tool or another 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 read-only draw tool with four optional parameters and no output schema, the description gives enough context to invoke it correctly: what it draws, what the response lacks, how to make draws reproducible, and when to use a sibling. It does not describe the exact response structure, but the annotations and schema cover the main 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 schema already documents seed and count, and the description reinforces seed's purpose ('Pass a seed to make a set reproducible'). However, theme and difficulty are only given enums with no additional explanation, and at 50% schema coverage the description only partially compensates for the missing parameter semantics.
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 and resource: 'Draw words-in-context practice questions from a curated bank.' It also distinguishes itself from the sibling vocab_check by explicitly saying the response contains NO answers and NO explanations, so an agent can tell which tool to use for quizzing versus answer checking.
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 routing guidance: call vocab_check for the answer and explanation of distractors, and use this tool when you want to quiz without leaking answers. It also explains why this tool is preferable to generated vocabulary questions and mentions the direct website alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
body_metricscolor_analysecron_buildcron_explaindue_datejson_to_typesoffsideregex_explainround_cash_totalrounding_impacttimezone_convertvocab_checkvocab_drawClaiming proves that you control a remote MCP connector. It does not move, proxy, or interrupt the server.
Open the connector listing, choose Claim ownership, and sign in to Glama.
Complete one verification method:
GitHub identity — fastest for official registry listings. For a namespace such as io.github.alice/server, link the matching GitHub user, then choose Claim with GitHub. An organization namespace such as io.github.acme/server also needs that organization to have installed the Glama AI GitHub App and approved its permissions, because GitHub discloses organization membership only to apps it has installed. Use HTTP or DNS when it has not.
HTTP challenge — works when you can deploy a public file. Generate a token, publish the exact JSON Glama shows at /.well-known/glama.json on the same origin as the connector, then choose Check HTTP challenge.
DNS challenge — works when you control DNS but cannot change the server. Generate a token, create the exact TXT record Glama shows, wait for it to propagate, then choose Check DNS challenge.
After verification, Glama sends a confirmation email and gives you access to listing details, thumbnails, health checks, and analytics. Keep the HTTP file or DNS record in place: Glama periodically checks it and ownership remains verified while the token is discoverable.
The HTTP ownership file has this structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"claim": "glama_claim_..."
}Claim tokens are opaque, stable, and bound to the signed-in Glama account. They contain no email address or other personal information. If Glama can no longer discover a verified HTTP or DNS token, it starts a seven-day grace period before removing claim-based access. Restore the same token during that period to keep ownership verified. Never publish an email address, Glama session token, GitHub token, or connector credential as ownership proof.
If verification fails, confirm that you copied the current token exactly. The HTTP file must be public, return valid JSON with a successful HTTP response, and stay on the connector's origin. DNS changes may need more time to propagate. A claim cannot transfer to a different origin or hostname: if the connector target changes, Glama starts the grace period and the new target must be claimed separately after the previous claim is released.
For a connector linked to the official MCP Registry, registry updates continue to replace its name, description, and URL by default. After claiming, open Manage connector and enable Use Glama listing details as the source of truth if edits made on Glama should be preserved. Categories and thumbnails are always managed on Glama; registry linkage and technical connection settings continue to sync.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
To improve your MCP server's ranking:
Claim ownership of the server listing
Complete the server profile with an accurate description and thumbnail
Provide a test profile so Glama can connect to and evaluate the server
Keep tool definitions clear and complete to earn a high Tool Definition Quality Score (TDQS)
Route real usage through the Glama Gateway; more recorded successful server uses also improve the ranking
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!
A MCP server built for developers enabling Git based project management with project and personal…
An MCP server that provides read access to your cloud storage providers, bank accounts and more.
The official MCP Server for the Mux API
One connector URL giving any MCP client live access to 21 services and 51 tools.
Add one secure layer between your agents and this server.
Each tool targets a clearly distinct domain or a complementary counterpart (cron_build/cron_explain, vocab_draw/vocab_check, round_cash_total/rounding_impact), and the descriptions make those relationships explicit. There is no real risk of selecting the wrong tool for a task.
Most tools follow a noun_verb pattern (cron_build, regex_explain, timezone_convert), but there are exceptions like body_metrics, due_date, offside, json_to_types, and round_cash_total, which mix noun phrases, gerunds, prepositions, and verb-first order. The names are readable but not uniform.
13 tools is within a reasonable range, and each utility earns its place as a standalone delegated calculator. The count feels slightly large only because the server is a grab-bag of unrelated domains rather than a focused toolkit, but no tool is redundant.
Most subdomains have solid coverage: cron has both build and explain directions, vocabulary has draw and check, and rounding has both per-transaction and aggregate analysis. Minor gaps exist, such as no timezone zone listing, no reverse due-date calculation, and no regex test/match step, but these are workable limitations.
