Skip to main content
Glama
wudongjie

hourledger-mcp

by wudongjie
OverviewSchemaRelated ServersScoreDiscussions
TypeScript
Remote

hourledger-mcp

An MCP server that calculates work hours, overtime, and gross pay — wrapping the same tested rules engine that powers HourLedger, a suite of free, no-sign-up work-hours calculators.

Tools

calculate_work_hours

Takes clock in/out entries (with unpaid breaks), an hourly rate, and a ruleset; returns the per-day and total regular / overtime / double-time split plus gross pay.

Supported rulesets, each covered by the automated test suite:

Ruleset

Rule

federal

1.5× past 40 h/week (FLSA)

california

1.5× past 8 h/day, 2× past 12 h/day, 7th-day rule, no pyramiding (Labor Code §510)

alaska

1.5× past 8 h/day or 40 h/week (AS 23.10.060)

colorado

1.5× past 12 h/day or 40 h/week (COMPS Order)

nevada

daily 8 h rule only below 1.5× minimum wage — applied automatically from the rate (NRS 608.018)

Handles overnight shifts, per-entry rounding policies (exact / 5 min / 15 min / 0.1 h), and configurable workweek start day.

time_and_a_half

Quick 1.5× rate and overtime-pay calculation from a rate and OT hours.

Related MCP server: TimePRO MCP Server

Setup

Claude Desktop / Claude Code

{
  "mcpServers": {
    "hourledger": {
      "command": "npx",
      "args": ["-y", "hourledger-mcp"]
    }
  }
}

Or with Claude Code: claude mcp add hourledger -- npx -y hourledger-mcp

Example

"How much do I make this week? I worked Monday to Thursday 7am–5pm at $19/hour in Nevada."

The model calls calculate_work_hours with the four 10-hour entries and gets back the correct Nevada answer ($19 ≥ $18 cutoff → weekly rule only → 40 regular hours, no OT), with day-by-day detail.

Interactive calculators

Prefer a UI? Every ruleset has a free, no-sign-up calculator at hourledger.com:

Disclaimer

General information, not legal or payroll advice. Exemptions and local rules vary — verify disputed pay with your state labor agency or a qualified professional.

Development

The pay-rules engine (src/engine.ts + its 27 tests) is mirrored from the HourLedger site project, where rule changes land first. npm test runs the full suite; prepublishOnly enforces tests + build before any publish.

License

MIT

Available Tools

2 tools
calculate_work_hoursA

Calculate regular/overtime/double-time hours and gross pay from clock in/out entries. Rulesets: federal (40h/week), california (8h/day 1.5x, 12h/day 2x, 7th-day rule), alaska (8h/day or 40h/week), colorado (12h/day or 40h/week), nevada (8h/day below $18/h, else weekly). Full calculators at https://hourledger.com

ParametersJSON Schema
NameRequiredDescriptionDefault
entriesYes
rulesetNofederal
roundingNonone
nvDailyOtNoNevada only: override the rate-based daily-OT eligibility check
hourlyRateYes
workweekStartNo0=Sunday … 6=Saturday

TDQS

A3.9/5.0
Behavior3/5

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

No annotations exist, so the description carries the burden of behavioral disclosure. It mentions calculation of regular/overtime/double-time hours and gross pay, and lists ruleset details. However, it omits behavioral nuances like rounding options, unpaid break subtraction, overnight shift handling, and workweek-start configuration, which are relevant to the calculation.

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 two sentences: the first states the purpose, the second lists rulesets and a link. It is compact, front-loaded, and contains no redundant content.

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 6 parameters, no annotations, and no output schema, the description provides minimal viable context: it states what it calculates and which rulesets are supported. But it leaves parameter semantics and behavioral edge cases unexplained, making it incomplete for a complex tool.

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 only 33%, so the description must compensate. It adds meaning to the 'ruleset' parameter by explaining each state's rule and implies 'hourlyRate' and 'entries' through 'gross pay' and 'clock in/out entries'. It does not explain 'rounding', 'unpaidBreakMins', or 'workweekStart', leaving those to the sparse schema.

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: 'Calculate regular/overtime/double-time hours and gross pay from clock in/out entries.' It clearly states the tool's scope and distinguishes it from sibling time_and_a_half by covering multiple jurisdiction-specific rulesets.

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?

The description provides clear context by enumerating available rulesets (federal, california, alaska, colorado, nevada), implying this tool is for jurisdiction-aware payroll calculations. However, it does not explicitly mention the sibling time_and_a_half or state when to prefer one over the other, so explicit exclusions are missing.

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

time_and_a_halfA

Calculate a time-and-a-half (1.5x) overtime rate and total overtime pay from an hourly rate and overtime hours. Interactive version: https://hourledger.com/time-and-a-half-calculator

ParametersJSON Schema
NameRequiredDescriptionDefault
hourlyRateYes
overtimeHoursYes

TDQS

A3.5/5.0
Behavior3/5

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

With no annotations provided, the description carries the burden of behavioral disclosure. It states that the tool 'calculates' something, implying a non-mutating, read-only operation. However, it does not describe the return format (e.g., whether a single value or two values are returned) or any edge-case behavior, leaving some ambiguity.

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 and front-loaded with the main purpose. The second sentence includes a link to an interactive calculator, which is useful but not essential for an API agent. No wasted words, though the link could be seen as extraneous.

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 two-parameter calculator with no output schema, the description adequately states the inputs and the outputs (rate and total pay). It lacks details about output structure or edge cases, but given the tool's low complexity, it is reasonably complete.

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?

The description mentions 'hourly rate' and 'overtime hours,' which map directly to the schema's `hourlyRate` and `overtimeHours`. Since the schema has 0% description coverage, this naming helps clarify the parameters' roles, but the description adds little beyond the parameter names themselves, such as units or calculation details.

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 explicitly states 'Calculate a time-and-a-half (1.5x) overtime rate and total overtime pay from an hourly rate and overtime hours,' providing a specific verb and resource. It clearly distinguishes this tool from the sibling 'calculate_work_hours' by focusing on overtime calculation rather than general work hours.

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?

The description offers no explicit guidance on when to use this tool versus the sibling 'calculate_work_hours'. It does not mention alternatives, exclusions, or prerequisites. The intended use is only implied by the tool's name and the description of its calculation.

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.6/5.0
Disambiguation4/5

The two tools have distinct purposes: one computes full work-hour calculations with various rulesets, while the other is a simple time-and-a-half overtime rate calculator. Though time_and_a_half overlaps conceptually with calculate_work_hours, the descriptions clearly indicate their different use cases, and an agent would likely select the right tool without confusion.

Naming Consistency3/5

The naming pattern is inconsistent: 'calculate_work_hours' follows a verb_noun structure, while 'time_and_a_half' is a noun phrase. Both are descriptive and readable, but the lack of a uniform convention makes the set slightly less predictable.

Tool Count3/5

With only two tools, the server feels thin, but the scope is narrowly focused on hourly pay calculations. The tools cover the core functionality well, though a user might expect additional calculator types (e.g., double-time or salary-based) to round out the set.

Completeness4/5

The calculate_work_hours tool comprehensively handles regular, overtime, and double-time pay across multiple jurisdictions, while time_and_a_half covers a specific standalone use case. No obvious gaps exist within the server's stated purpose, though one could imagine additional pay-related calculators.

Maintenance

ActivityStale
ResponsivenessNo issues

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

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

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

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/wudongjie/hourledger-mcp'

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