gnomon-mcp

Name: gnomon-mcp
Author: lihtness

by lihtness

Overview Schema Related Servers Score Discussions

Python

Hybrid

gnomon-mcp

PyPI Python License: MIT MCP Registry

The pointer on a sundial that turns shadow into time.

A small MCP server for the boring-but-essential utilities every model needs: dates, calendars, arithmetic, unit conversion. Use it so your assistant stops "next-token guessing" math and date math.

Why

LLMs are bad at arithmetic and date math by default. They produce plausible answers that are often wrong by a small amount — exactly the kind of mistake that's hard to notice in a long response. gnomon-mcp exposes deterministic Python implementations through MCP so your model can compute instead of guess.

When an agent should reach for gnomon

Anywhere the next plausible token is not the right answer. Concretely:

Math that matters — anything beyond trivial mental arithmetic, anything with a decimal point, anything that compounds. Call calc.
"What day is it" / "how long until" / "how long since" — the model's training cutoff is not today. Call now for a snapshot; calendar with until/since/diff for elapsed time; parse for natural-language dates ("next thursday").
Date arithmetic across month/year boundaries — adding 30 days, finding a quarter-end, counting business days. Models routinely off-by-one these. Call calendar with add / business_days.
Unit conversion — call calc_convert. Never eyeball "kg → lb" or "°C → °F".
Table-row workloads — when the same kind of computation needs to run on every row of a table, both batch tools (calendar, calc) take a list and return a list in order. One call, N results.

The rule of thumb: if you'd ask a colleague to "just double-check that number," call gnomon instead.

How this compares to other MCP servers

Time and math already have several MCP servers — the official Time reference (timezone-only), mcp-time and mcp-datetime (date formatting / timezone), calculator-server (math + units, no dates), and bundles like agent-utils-mcp (regex / hashing / JWT). gnomon's lane is narrower:

Batch-first. calendar(ops) and calc(expressions) take lists; one tool call covers a whole table column instead of N calls.
A real now(). One call returns 18 fields — ISO week, quarter, fiscal year, day-of-year, is_weekend, … — instead of just {iso, tz}.
Dates and math and units in one wiring. No need to compose three separate servers.
Natural-language dates baked in ("next thursday", "in 3 hours") without a separate NLP server.

If you only need timezone conversion, the official Time server is enough. If you want a broad utility bundle (regex, hashing, encoding, JWT), agent-utils-mcp is a better fit. gnomon is for the boring date-arithmetic-and-arithmetic core, batched.

Related MCP server: chuk-mcp-time

Tools

Calendar

Two tools:

now(tz?) — standalone. Returns a rich dict snapshot of the current moment. One call gets you everything about "right now".
calendar(ops) — batch dispatcher. Each item picks its own op. Designed for table-row workloads (e.g. one call computes time-elapsed for every row).

now(tz?) returns:

{
  "iso": "2026-05-25T14:30:45+00:00",
  "date": "2026-05-25",
  "time": "14:30:45",
  "unix": 1779345045,
  "tz": "UTC",
  "year": 2026, "month": 5, "month_name": "May", "day": 25,
  "weekday": "Monday", "weekday_num": 0,          # 0=Monday
  "day_of_year": 145, "week_of_year": 22,         # ISO week
  "quarter": 2, "fiscal_year_us_gov": 2026,       # FY starts Oct 1
  "hour": 14, "minute": 30, "second": 45,
  "is_weekend": False,
}

calendar(ops) operations:

Op	Params	Returns
`diff`	`start, end, unit`	`end - start` — time elapsed between two known dates
`until`	`target, unit, tz?`	`target - now` — time left to a future point (negative if past)
`since`	`source, unit, tz?`	`now - source` — time elapsed since a past point (negative if future)
`add`	`date, n, unit`	ISO of `date + n units` (`seconds\|...\|weeks`, plus `months\|years` calendar-aware)
`weekday`	`date`	`"Monday"`..`"Sunday"`
`business_days`	`start, end`	count of Mon-Fri days (start inclusive, end exclusive)
`parse`	`natural, tz?`	ISO from natural language ("next thursday", "in 3 hours")
`format`	`date, fmt`	strftime-formatted string

Units for diff/until/since: seconds, minutes, hours, days, weeks.

Example — compute several things in one call:

calendar([
  {"op": "until", "target": "2026-12-31", "unit": "days"},          # days left in year
  {"op": "since", "source": "2026-01-01", "unit": "days"},          # days elapsed in year
  {"op": "diff", "start": "2026-01-01", "end": "2026-12-31", "unit": "days"},
  {"op": "weekday", "date": "2026-05-25"},                           # "Monday"
  {"op": "add", "date": "2026-05-25", "n": 1, "unit": "months"},
  {"op": "parse", "natural": "next thursday", "tz": "America/Los_Angeles"},
])

Calculator

Tool	Purpose
`calc(expressions)`	Evaluate a list of Python expressions and return a list of results. Math (`sqrt`, `sin`, `log`, `pi`, `e`, ...), stats (`mean`, `median`, `stdev`, `variance`), and useful builtins (`abs`, `round`, `min`, `max`, `sum`, `range`, `sorted`, ...) are pre-loaded. Batch in / batch out, order preserved.
`calc_convert(value, from_unit, to_unit)`	Unit conversion via Pint (`meter` → `foot`, `kg` → `lb`, `degC` → `degF`, etc.).

Examples:

calc(["2 + 3 * 4"])                  # [14]
calc(["sqrt(16)", "sin(pi/2)"])      # [4.0, 1.0]
calc(["mean([1, 2, 3, 4])"])         # [2.5]
calc(["sum(range(101))"])            # [5050]
calc(["(25 / 100) * 100"])           # [25.0]

Future tools (sketches)

The same logic — if the model is likely to bluff it, expose a deterministic version — points at several more primitives worth building. None of these are implemented yet; they are candidates, listed roughly in order of bang-for-buck:

Text measurement — count(text, unit) for chars / words / lines / sentences / LLM tokens. Agents constantly miscount "how long is this" and "will this fit in the context window."
Regex match / replace — regex_find(pattern, text) and regex_sub(pattern, repl, text). Models hallucinate which substrings match a regex; a real engine ends the argument.
Structured-data extraction — jq(path, json) / jsonpath(path, json). Reading values out of a nested blob by path, without typos.
Hashing & encoding — hash(text, algo) (sha256, md5, blake2), encode(text, scheme) / decode(text, scheme) (base64, hex, url, jwt-payload). All things models confidently invent wrong.
Decimal money math — money(expr) evaluated under Python's Decimal with explicit rounding. calc is float-based and quietly unsafe for currency.
Holiday-aware business days — extend calendar.business_days with a country (or calendar) parameter so US/UK/IN holidays are excluded. The current implementation only knows weekends.
Cron describe / next-fire — cron_describe("0 9 * * 1-5") → human English; cron_next(expr, n) → next N firing times. Models routinely misread cron fields.
Token counting for a target model — count_tokens(text, model) via tiktoken / Anthropic tokenizer. Lets an agent budget its own prompts and outputs instead of guessing.

If you want one of these, open an issue (or a PR — each is a small self-contained module that fits the existing tools/ layout).

Install

Recommended: no install — run on demand via uv:

uvx gnomon-mcp           # serves stdio MCP, ready for any client
uvx gnomon-mcp --demo    # call every tool once and print the results (no MCP client needed)

Or install globally:

pip install gnomon-mcp

Wire it into your agent

All recipes assume uvx gnomon-mcp. If you prefer a pinned install, swap the command for gnomon-mcp (with no uvx).

Claude Code

claude mcp add gnomon -- uvx gnomon-mcp

Or edit ~/.claude.json / a project .mcp.json:

{
  "mcpServers": {
    "gnomon": { "command": "uvx", "args": ["gnomon-mcp"] }
  }
}

Claude Desktop

claude_desktop_config.json:

{
  "mcpServers": {
    "gnomon": { "command": "uvx", "args": ["gnomon-mcp"] }
  }
}

Cursor

~/.cursor/mcp.json (or .cursor/mcp.json in a project):

{
  "mcpServers": {
    "gnomon": { "command": "uvx", "args": ["gnomon-mcp"] }
  }
}

Continue

~/.continue/config.yaml:

mcpServers:
  - name: gnomon
    command: uvx
    args: ["gnomon-mcp"]

Any other client (generic stdio)

Spawn uvx gnomon-mcp as a subprocess and speak MCP over stdin/stdout. That is the entire integration.

Hosted / remote (HTTP transport)

For team-shared instances or agents that can't spawn a local subprocess:

uvx gnomon-mcp --transport streamable-http --host 0.0.0.0 --port 8000
# also supported: --transport sse

Then point your MCP client at http://<host>:8000/mcp (or /sse for the SSE transport).

Tell your agent to actually use it

The MCP tool descriptions are intentionally terse to keep persistent context cost minimal (~150 tokens for all four tools). The richer "when to reach for gnomon" guidance lives in a Claude Code skill that loads on demand.

Option A — Claude Code plugin (one command, recommended)

The plugin wires both the MCP server and the skill in one shot. Inside Claude Code:

/plugin marketplace add lihtness/gnomon-mcp
/plugin install gnomon@gnomon-mcp

That registers gnomon as an MCP server (auto-starts via uvx) and installs the on-demand skill. Skill body loads only when the task triggers it — persistent context stays ~150 tokens for the four tool descriptions plus ~40 tokens for the skill's name + summary.

Option B — manual skill install (no plugin)

If you've already wired the MCP server with claude mcp add gnomon -- uvx gnomon-mcp and only want the skill:

mkdir -p ~/.claude/skills/gnomon
curl -fsSL https://raw.githubusercontent.com/lihtness/gnomon-mcp/main/skills/gnomon/SKILL.md \
  -o ~/.claude/skills/gnomon/SKILL.md

Option C — paste into your system prompt (non-Claude-Code agents)

For agents without skill support, paste this short version into your system prompt or CLAUDE.md:

You have gnomon: deterministic tools for dates and math. Use them instead
of guessing.

- `now` — current moment (your training cutoff isn't today).
- `calendar(ops)` — batch date math: diff/until/since/add/weekday/
  business_days/parse (natural language)/format.
- `calc(expressions)` — batch Python eval; math + statistics + common
  builtins pre-loaded.
- `calc_convert(value, from, to)` — unit conversion via Pint.

Both batch tools take a list and return a list. Prefer one batched call
over many small ones.

Development

git clone https://github.com/lihtness/gnomon-mcp
cd gnomon-mcp
pip install -e ".[dev]"
pytest

License

MIT

Available Tools

4 tools

calcB

Eval Python expressions -> list. Pre-loaded: math, statistics (mean/median/stdev/variance), abs/round/min/max/sum/range/sorted.

ParametersJSON Schema

Name	Required	Description	Default
`expressions`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

B3.4/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description must fully disclose behavior. It lists pre-loaded functions but omits critical safety concerns (e.g., eval executing arbitrary code, sandboxing), side effects, error handling, or the exact return format beyond 'list'.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise with two sentences, front-loading the core action and then listing capabilities. It is efficient but could be better structured with bullet points for readability.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's nature (evaluating expressions) and the presence of an output schema, the description covers basic functionality but lacks details on error handling, security notes, and return schema specifics. It is adequate but not thorough.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

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

Schema description coverage is 0%, so the description must compensate. It adds meaning by stating that the parameter 'expressions' is an array of Python expressions and lists available functions. However, it does not specify per-expression evaluation or expected format, leaving gaps.

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 clearly states the tool evaluates Python expressions and returns a list, listing pre-loaded functions like math and statistics. This distinguishes it from sibling tools like calc_convert (conversions) and calendar/now (time).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for mathematical computations but does not explicitly state when to use this tool versus siblings like calc_convert. It lacks explicit when-to-use and when-not-to-use guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

calc_convertC

Convert value between units (Pint). E.g. ('meter','foot'), ('kg','lb'), ('degC','degF').

ParametersJSON Schema

Name	Required	Description	Default
`value`	Yes
`from_unit`	Yes
`to_unit`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

C2.7/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so description must convey behavioral traits. It only states 'Convert value between units' without detailing accepted unit formats, error behavior, or output structure.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is very short and front-loaded with a clear action and examples. It is concise but could benefit from more structure.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 0% schema coverage and no annotations, the description is insufficient. It lacks details on supported unit conversions, case sensitivity, and error handling, making it incomplete for an AI agent.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

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

Schema description coverage is 0%, but the description adds example unit pairs. However, it does not clarify parameter semantics for 'value' or specify the exact unit strings required.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it converts values between units, with examples like ('meter','foot'), ('kg','lb'). It distinguishes from sibling tool 'calc' which is a general calculator, though not explicitly stated.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool versus alternatives like 'calc'. The description does not mention any prerequisites or exclusions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

calendarA

Batch date ops: [{"op": NAME, ...args}, ...] -> [result, ...]

diff(start, end, unit) until(target, unit, tz?) since(source, unit, tz?) -> float add(date, n, unit) -> ISO weekday(date) -> name business_days(start, end) -> int (Mon-Fri, end exclusive) parse(natural, tz?) -> ISO format(date, fmt) -> str

ParametersJSON Schema

Name	Required	Description	Default
`ops`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.5/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations, so description carries burden. It discloses return format (array of results), mentions that business_days excludes end date, and shows unit options. However, it lacks detail on error handling, timezone effects for non-tz ops, and potential pitfalls of permissive input schema.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Very concise, using compact DSL notation, no redundant sentences. However, the dense format may be hard to parse; slight improvement in structure (e.g., bulleted list) would help.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity and low schema richness, the description covers all major operations but lacks details on return types for each op, error conditions, and full parameter semantics (e.g., format patterns). The presence of an output schema reduces burden, but the description still has gaps.

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 0%, but description compensates by detailing the ops structure, valid operation names, and their arguments (e.g., diff(start,end,unit)). This adds significant meaning beyond the raw schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states 'Batch date ops' and lists specific calculus (diff, add, etc.), clearly indicating it performs multiple date operations in a batch. It distinguishes from siblings like 'calc' (arithmetic) and 'now' (current time).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No explicit when-to-use or alternatives guidance. The DSL listing implies usage for date arithmetic, but no exclusions or comparisons to sibling tools are provided.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

nowA

Current moment as dict (iso, date, weekday, week_of_year, quarter, fiscal_year_us_gov, is_weekend, ...). Optional IANA tz.

ParametersJSON Schema

Name	Required	Description	Default
`tz`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4.2/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description bears the burden of disclosing behavior. It specifies the output format (dict with time-related fields) and the optional parameter (IANA timezone). It does not mention any side effects or latency, but for a simple time retrieval tool, this is adequate.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence that immediately states the purpose ('Current moment as dict') and follows with examples of output fields and the optional parameter. Every part is essential, and the structure is front-loaded.

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?

For a simple tool with one optional parameter and an output schema (likely detailed), the description covers the key aspects: what it returns, the optional timezone input. It lacks specification of default behavior when tz is null, but overall it is sufficiently complete for the tool's complexity.

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?

The only parameter 'tz' has a schema type of string or null. The description adds the key context that it expects an IANA timezone string, which is not present in the schema. Given zero schema description coverage, this compensation is valuable and clear.

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 clearly states that the tool returns the current moment as a dict with specific fields (iso, date, weekday, ...). It distinguishes itself from sibling tools like calc, calc_convert, and calendar, which are for calculations, conversions, and calendar functions respectively.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for obtaining current time information, but provides no explicit guidance on when to use this tool over alternatives. Sibling tools are sufficiently different, but the description lacks direct 'when-to-use' advice.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.7/5.0

Disambiguation5/5

Each tool has a clearly distinct purpose: calc for Python expressions, calc_convert for unit conversion, calendar for date operations, and now for current time. There is no overlap or ambiguity.

Naming Consistency4/5

Names are mostly lowercase and readable, but there is a slight inconsistency: calc and calc_convert share a prefix, while calendar and now are single words of different parts of speech. Still, the pattern is clear and predictable.

Tool Count5/5

With 4 tools, the server is well-scoped for a general utility toolkit. Each tool fulfills a core need without excess or deficiency.

Completeness5/5

The tool set covers arithmetic, unit conversion, comprehensive date operations (difference, business days, parsing, formatting), and current time with timezone support. No obvious gaps for the intended domain.

Maintenance

ActivityInactive

ResponsivenessSyncing

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

mcp A
tools.clean
Read-only developer, date, finance, and text utilities. Authless remote MCP server by Clean.tools.
Developer Tools Finance
422
mcp-server
com.niftypm
Nifty's MCP server — exposes tasks, projects, messages, and files as tools for AI agents.
Project Management Communication File Systems
2
strata
ai.klavis
MCP server for progressive tool usage at any scale (see https://klavis.ai)
Agent Orchestration Autonomous Agents Developer Tools
25,748
Unit & Currency Converter A
io.github.guptaprakhariitr
60+ units, live FX, timezones, and date arithmetic for AI agents.
Finance Location Services
621

Related MCP Servers

Math & Calculator MCP Server
Developer Tools
Ankluna72
A
license
A
quality
D
maintenance
Provides advanced mathematical utilities including basic arithmetic, statistical analysis, unit conversions, quadratic equation solving, percentage calculations, and trigonometric functions for AI assistants.
Updated 9 months ago (2025-12-04 14:56 UTC)
6
MIT
chuk-mcp-time
Search
IBM
A
license
A
quality
C
maintenance
Provides high-accuracy time information by querying multiple NTP servers for consensus time, and comprehensive timezone support using IANA tzdata for conversions, DST handling, and clock drift detection independent of system time.
Updated 21 days ago (2026-08-15 01:34 UTC)
7
3
Apache 2.0
aleostudio MCP Server
Developer Tools App Automation
aleostudio
F
license
A
quality
D
maintenance
A lightweight MCP server providing utility tools for math, text processing, data conversion, and URL fetching. It supports both STDIO and SSE communication modes for seamless integration with Claude Desktop and remote AI agents.
Updated 6 months ago (2026-02-25 09:52 UTC)
5
1
mcp-tools-server
Developer Tools
RenanMiqueloti
A
license
Not graded
quality
C
maintenance
A general-purpose MCP server with utility tools including datetime information, safe math calculations, text statistics, JSON extraction, knowledge base search, and HTTP GET requests. It demonstrates server-side MCP implementation and can be connected to Claude Desktop or LangGraph agents.
Updated 5 days ago (2026-08-31 06:12 UTC)
MIT

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/lihtness/gnomon-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server