Skip to main content
Glama

Project Gumball

by com.gumballtools

Due date and gestational age, with ACOG redating applied (Due Date)

due_date
Read-only

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.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
lmpNoWith ultrasound, enables the ACOG redating check.
asOfNoReference date for "how far along". Default today.
dateYesYYYY-MM-DD. The FIRST DAY of the last period, or the conception, transfer, or scan date.
methodYesUse lmp unless given a conception date, transfer date, or scan.
scanDaysNoFor ultrasound: days part, 0-6.
scanWeeksNoFor ultrasound: weeks part of the measured gestational age.
cycleLengthNo20-45, default 28. Affects lmp only; a 35-day cycle moves it a week.

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. First observed

TDQS

A4.4/5.0
Behavior5/5

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.

Conciseness3/5

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.

Completeness4/5

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.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3. The description 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.

Purpose5/5

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.

Usage Guidelines4/5

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.

All Project Gumball toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.1/5.0
Disambiguation5/5

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.

Naming Consistency3/5

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.

Tool Count4/5

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.

Completeness4/5

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.

Resources