Skip to main content
Glama
Sign In
tw-mcp

tw-mcp

by Larryveryhandsome
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

勞基法加班費

labor_overtime
Read-onlyIdempotent

Calculates Taiwan Labor Standards Act overtime pay for weekdays, rest days, holidays, and regular leave, returning statutory minimums, 1.34/1.67 comparisons, breakdowns, formulas, and citations.

Instructions

依勞動基準法試算加班費（平日延長工時、休息日、國定假日、例假日），回傳法定最低金額（條文分數 4/3、5/3、8/3 精確計算）、 業界常用 1.34／1.67 倍率的對照金額、分段明細、公式、法條與警告。例：月薪 36,000、平日加班 2 小時 ＝ 法定最低 400 元（業界 1.34 算法 402 元）。

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "wage": "<wage>",
      "hours": "<hours>"
    },
    "name": "labor_overtime"
  }
}

Input Schema

NameRequiredDescriptionDefault
dateNo出勤日期 YYYY-MM-DD（選填；有內建資料的年份會自動辨識國定假日、檢查基本工資）
wageYes月薪（wage_type=monthly）或時薪（wage_type=hourly），新台幣
hoursYes平日：超過 8 小時的延長工時；休息日／國定假日／例假日：當天出勤總時數
day_typeNoweekday 平日、rest_day 休息日、holiday 國定假日、regular_leave 例假日weekday
wage_typeNomonthly 月薪制、hourly 時薪制monthly

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A3.9/5.0
Behavior4/5

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

Annotations already declare the operation read-only, idempotent and non-destructive, so safety needs no explanation. The description adds genuine beyond-schema behavior: it returns the legal minimum computed with exact article fractions (4/3, 5/3, 8/3), a 1.34/1.67 industry comparison, segment breakdown, formula, cited articles and warnings. It also states that providing a date triggers automatic national-holiday detection and minimum-wage checks — none of which is visible in the schema or annotations.

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 front-loaded with the core action and scope, then lists the return payload, then closes with a concrete example that anchors the numbers. It is dense but every clause (day types, comparison amounts, warnings, example) carries information an agent would otherwise have to guess. Minor density could be reduced, but nothing is wasteful.

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?

There is no output schema, so the description carries the burden of describing returns — and it does, naming the legal minimum, industry comparison, breakdown, formula, articles and warnings. Combined with 100% schema coverage on inputs and a safe read-only annotation profile, an agent has enough to call this correctly; only explicit sibling routing is missing.

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 coverage is 100%, so every parameter including both enums is already documented in structured form. The description reinforces the wage/hours meaning through the 36,000 / 2-hour example but does not add per-parameter format or edge-case detail beyond the schema. Baseline 3 is correct where the schema does the heavy lifting.

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 specific verb+resource (試算加班費 under 勞動基準法) and enumerates exactly which four day types it handles. It also names the output currency (法定最低金額 vs 業界 1.34／1.67) so an agent distinguishes this calculator from a date/workday helper like tw_workdays at a glance.

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?

Usage is implied through the day-type list and the worked example, giving the agent a clear sense of the inputs this tool is meant for. However, there is no explicit statement of when to use this versus a sibling, nor any exclusions or prerequisite conditions. Sibling tools only differ strongly in name (tw_workdays for workday lookup), so that implicit boundary could be made explicit.

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

Deploy Server

Other Tools