This server is a Taiwan payroll and labor/health insurance calculation engine with the following capabilities:
Calculate full payroll breakdown: Computes monthly labor insurance (including employment insurance), health insurance, labor pension, and occupational accident insurance contributions split among employee, employer, and government — supporting different worker identities (local, general migrant, domestic migrant), dependents, voluntary pension contributions, and part-time workers.
Calculate supplementary second-generation health insurance premium: Computes the supplementary NHI premium for six income types: bonuses, part-time wages, professional fees, dividends, interest, and rent.
Calculate employer supplementary health insurance premium: Computes the employer-side supplementary NHI premium based on the difference between total monthly paid salaries and total insured salary amounts.
Calculate income tax withholding: Computes salary withholding tax for residents (formula method), resident non-monthly bonuses, and non-residents.
Calculate old-age pension (monthly): Estimates monthly labor insurance old-age pension using the official best-of-two-formula approach, with support for early/deferred claim adjustments.
Calculate old-age lump sum: Estimates the lump-sum old-age benefit based on insured years and post-age-60 service.
Calculate one-time old-age payment (old system): Estimates the legacy one-time old-age payment using the base-unit system, applicable to those with pre-2009 insured years.
Calculate prorated mid-month premiums: Handles mid-month onboarding or resignation — labor/occupational/pension contributions are prorated by day (30-day basis), while health insurance follows the official end-of-month attribution rule.
List available years: Returns supported year parameters, data versions, and minimum wage (monthly/hourly) to confirm valid year values before calculating.
開源的台灣勞健保勞退法定費用計算引擎。輸入薪資與身份，算出勞保（含就保）、健保、勞退、職災與二代健保補充保費的各方負擔——並涵蓋薪資所得扣繳、月中到職／離職破月、健保補充保費申報媒體檔，以及勞保老年給付試算。
🧮 線上試算：https://taiwan-payroll.vercel.app（免安裝，瀏覽器直接算）
🔌 三種介面：TypeScript（npm）、Python（PyPI，純 stdlib）、MCP server（給 AI 助理呼叫）
📑 官方對證：級距表與費率逐級取自主管機關公告，計算結果對官方範例黃金向量逐位元驗證
🔁 跨語言一致：TS 與 Python 讀同一份 data/、跑同一套 testdata/，結果逐位元相同
📦 零執行期依賴：core 不帶任何 runtime 套件
定位是「計算引擎」而非「法遵保證」。 內建民國 113–115（2024–2026）年度官方參數。
npm install taiwan-payroll # TypeScript / Node
pip install taiwan-payroll # PythonRelated MCP server: OpenAccountants
import { createPayrollEngine } from 'taiwan-payroll';
const engine = createPayrollEngine({ year: 2026 });
const r = engine.calculate({
monthlySalary: 42000,
identity: 'category1',
dependents: 1,
employmentInsurance: true,
pensionSelfContribution: 0.06,
});
console.log(r.employee); // { labor: 1050, health: 1302, pensionSelf: 2520, total: 4872 }
console.log(r.employer.occupational); // 職災雇主負擔// 補充保費（六類所得：bonus/parttime/professional/dividend/interest/rent）
engine.calculateSupplementary({ type: 'bonus', amount: 200000, monthlyInsuredSalary: 42000 });
// → { type: 'bonus', chargeable: 32000, rate: '0.0211', premium: 675 }
// 月中到職／離職（勞保/職保/勞退按日；健保採官方「月底歸屬」原則）
engine.calculateProrated({ monthlySalary: 29500, startDate: '2026-03-08' });
// → { ..., days: { insured: 23 }, healthCharged: true }健保破月採「月底歸屬原則」：以月底所屬投保單位計收整月——到職當月計整月、離職當月不計。此為健保署實務規則（非按日、與 15 日分水嶺無關）。
由申報資料產生健保署「補充保險費明細申報檔」（CSV／Big5），涵蓋 6 類所得：獎金(62)、兼職薪資(63)、執行業務(65)、股利(66)、利息(67)、租金(68)。每個產生器皆以健保署官方範例逐位元驗證，TS 與 Python 結果一致。
import { generateSupplementaryBonusFiling } from 'taiwan-payroll';
const { filename, content } = generateSupplementaryBonusFiling({
year: 2026,
filingDate: '20260901', // 用於檔名
unit: { taxId: '11111111', name: '甲公司', phone: '0227065866', email: 'a@b.tw', contactName: '王小明' },
records: [
{ action: 'I', payDate: '20260615', payeeId: 'A123456789', payeeName: '李四',
bonusAmount: 50000, insuredSalary: 31800, ytdBonusCumulative: 150000, unitCode: '123456789' },
],
});
// filename: 'DPR111111111150901001.csv'
// content : Unicode 字串；檔案實際為 Big5，存檔時請以 Big5 編碼寫出。獎金/兼職/執行業務/利息/租金：逐列補充保費由引擎計算。股利(generateSupplementaryDividendFiling)因含股票股利／雇主扣除等情形，逐列保費由呼叫端提供（另附便利函式 calcDividendPremium）。
輸出為「資料檔」供以官方入口上傳。Big5 編碼：TS 由呼叫端編碼，Python 提供 to_big5_bytes()（core 維持零依賴）。
API 詳見文件站 /docs/api。
依勞保局官方公式試算三種老年給付（皆對官方數值/公式驗證、TS≡Python）：
import { calcOldAgePension, calcOldAgeLumpSum, calcOldAgeSinglePayment, getYearData } from 'taiwan-payroll';
const d = getYearData(2026);
calcOldAgePension(d, { avgInsuredSalary: 32000, years: 35, months: 6 }); // 月領年金（擇優兩式，可提前/延後）
calcOldAgeLumpSum(d, { avgInsuredSalary: 30000, years: 10 }); // 老年一次金
calcOldAgeSinglePayment(d, { avgInsuredSalary: 30000, preSixtyYears: 20 }); // 一次請領（舊制基數）老年年金：擇優兩式（平均×年資×0.775%+3000 vs ×1.55%），提前/延後 claimOffsetMonths（±4%/年、上限 ±5 年（±20%））；附 averageHighestInsuredSalary、statutoryClaimAge。
老年一次金：年資每滿 1 年發 1 個月，逾 60 歲後年資最多 5 年。
一次請領：基數制（前 15 年每年 1 基數、超過部分每年 2 基數、前 60 上限 45、合併上限 50），平均採退保前 36 個月。
試算僅供參考，實際以勞保局核定為準。
data/{year}.json — 單一事實來源，年度法規參數（級距表、費率），以 JSON Schema 驗證。
testdata/ — 語言無關的黃金測試向量（官方案例，含 source 出處），是跨語言行為一致性的根基。
packages/core — 零執行期依賴的 TypeScript 引擎。
Python：pip install taiwan-payroll，純 stdlib、API 對應 TS 版（PyPI）。
MCP server：讓 Claude 等 AI 助理直接呼叫試算。遠端免安裝端點 https://taiwan-payroll.simoko.workers.dev/mcp（Streamable HTTP），或本地 npx taiwan-payroll-mcp（stdio，npm）。
線上計算機與完整 API：https://taiwan-payroll.vercel.app
項目 | 主管機關 | 文號 |
勞保投保薪資分級表（11級，上限45,800） | 勞動部勞保局 | 勞動保2字第1140091863號令 |
勞退月提繳分級表（62級，上限150,000） | 勞動部勞保局 | 勞動福3字第1140153598號令 |
職災投保薪資分級表（21級，上限72,800） | 勞動部勞保局 | 職災保險法§17 |
健保投保金額分級表（58級，上限313,000） | 衛福部健保署 | 衛部保字第1140153424號令 |
費率：勞保 12.5%（含就保 1%）、健保 5.17%、勞退雇主 6%、職災平均 0.21%、二代健保補充保費 2.11%。
目前內建民國 113／114／115（2024／2025／2026） 三個年度，各年度的分級表與文號見 data/{year}.json 的 sources；以 createPayrollEngine({ year }) 指定，可用年度由 getAvailableYears() 取得。
pnpm install
pnpm validate:data # 驗證 data schema、級距連續性、向量格式
pnpm -r test # 跑全部黃金測試向量
pnpm typecheck本套件依公開法規與主管機關公告實作，計算結果僅供參考，實際應繳金額以勞保局、健保署核發之繳款單為準。本套件不構成法律或會計建議。
MIT
計算薪資所得扣繳稅額：居住者固定月薪(公式法)、非每月給付獎金(5%，未達起扣標準免扣)、非居住者(18%；月薪≤1.5倍基本工資為6%)。結果僅供參考，以勞保局、健保署核發之繳款單為準，不構成法律或會計建議。
| Name | Required | Description | Default |
|---|---|---|---|
| year | No | 年度（西元，如 2026）。省略則使用最新可用年度；可先用 list_years 查可用年度。 | |
| type | Yes | 扣繳類型：resident=居住者固定月薪(公式法)、residentBonus=居住者非每月給付(獎金)5%、nonResident=非居住者18%/6%。 | |
| monthlySalary | No | 月薪資，新臺幣元（resident／nonResident 用）。 | |
| dependents | No | 配偶及受扶養親屬人數（僅 resident），預設 0。 | |
| amount | No | 該筆給付金額，新臺幣元（僅 residentBonus）。 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Absent annotations, the description carries the full burden. It discloses the non-authoritative nature ('僅供參考', not official advice), the rate rules, and the '未達起扣標準免扣' condition for bonus. This provides useful behavioral context beyond raw computation.
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 a compact two sentences: the first covers the core functionality and rates, the second adds the legal disclaimer. Every clause adds meaningful information with no redundancy or filler. Ideal front-loading.
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?
Given the tool's complexity (3 types, 5 parameters, no output schema), the description covers the key usage scenarios and rate rules. The schema handles individual parameter descriptions. The lack of output schema means return format is not detailed, but that is acceptable per guidelines. Minor gaps: no mention of year range or dependents' effect, but those are in schema.
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% (baseline 3). The description adds value by explaining the rate formulas (e.g., 5% for bonus, 18%/6% for non-resident based on wage threshold) and the withholding threshold, which are not present in the schema's parameter descriptions. This enrichment justifies a score above baseline.
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 clearly states it calculates income tax withholding for salary, listing three distinct types (resident formula, resident bonus at 5%, non-resident at 18% or 6%). This specificity and differentiation from sibling tools (e.g., payroll, premium calculations) makes the purpose 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 description implicitly guides usage by enumerating the three scenarios (resident, resident bonus, non-resident), but does not explicitly contrast with sibling tools or state when not to use it. No alternatives or prerequisites are mentioned, leaving the agent to infer from the type parameter.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
依勞保老年一次金法定公式（平均月投保薪資 × 給付月數；年資每滿 1 年給 1 個月、逾 60 歲後之年資最多計入 5 年）試算給付金額。結果僅供參考，以勞保局、健保署核發之繳款單為準，不構成法律或會計建議。
| Name | Required | Description | Default |
|---|---|---|---|
| year | No | 年度（西元，如 2026）。省略則使用最新可用年度；可先用 list_years 查可用年度。 | |
| avgInsuredSalary | Yes | 平均月投保薪資（最高 60 個月平均），新臺幣元。 | |
| years | Yes | 保險年資：年。 | |
| months | No | 保險年資：月（0–11），預設 0。 | |
| postSixtyMonths | No | 逾 60 歲以後之保險年資（月），最多計入 5 年（60 個月），超過部分不計。不得超過總保險月數。預設 0。 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description only includes a disclaimer about reference and no legal advice. Does not disclose side effects, authentication needs, or data fetching behavior.
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?
One concise paragraph with formula upfront. No unnecessary words.
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?
Covers the calculation logic but lacks output format description and error conditions. For a 5-parameter calculation tool, this is adequate but not fully comprehensive.
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 baseline is 3. Description adds minimal context beyond the formula (e.g., postSixtyMonths limit) but doesn't significantly enhance parameter understanding.
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 clearly specifies it calculates the old-age lump sum benefit using the legal formula. However, it does not explicitly differentiate from sibling tools like calculate_old_age_pension or calculate_old_age_single_payment.
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?
No guidance on when to use this tool versus alternatives. No prerequisites or exclusions provided. Only a disclaimer that results are for reference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
依勞保老年年金法定公式（擇優兩式、提前/延後增減給每年 ±4%，上限 ±5 年（±20%））試算月領金額；年資未滿 15 年不符年金請領資格。結果僅供參考，以勞保局、健保署核發之繳款單為準，不構成法律或會計建議。
| Name | Required | Description | Default |
|---|---|---|---|
| year | No | 年度（西元，如 2026）。省略則使用最新可用年度；可先用 list_years 查可用年度。 | |
| avgInsuredSalary | Yes | 平均月投保薪資（最高 60 個月平均），新臺幣元。 | |
| years | Yes | 保險年資：年。 | |
| months | No | 保險年資：月（0–11），預設 0。 | |
| claimOffsetMonths | No | 提前(負)/延後(正)請領月數，相對法定請領年齡；每年 ±4%，上限 ±5 年（±20%）。預設 0。 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes the calculation formula, eligibility check, and reference-only nature. No annotations provided, so description carries burden. Adds value beyond schema with formula details, but could elaborate on algorithm or assumptions.
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?
Two sentences that efficiently convey purpose, formula, eligibility, and disclaimer. No wasted words, though slightly more structure (e.g., bullet points) could improve readability.
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?
Covers key aspects: formula, adjustment, eligibility, disclaimer. But lacks output format (currency, value type) and details on the two formulas. No output schema, so description should compensate more.
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% with descriptions for all 5 parameters. The description does not add significant extra meaning beyond what the schema provides, only contextualizing the 15-year requirement. 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 clearly states it calculates the monthly old-age pension using the legal formula, specifying the two formulas and adjustment rates. The title includes '月領' (monthly), distinguishing it from lump sum or single payment 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?
The description mentions eligibility (years < 15 not eligible) and disclaimer, but does not explicitly say when to use this tool vs alternatives like lump sum or single payment. No explicit when-not or sibling differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
依勞保一次請領老年給付法定公式（基數制：前 15 年每年 1 個基數、第 16 年起每年 2 個基數、60 歲前最高 45 個基數、逾 60 歲後年資每年 2 個基數最多計 5 年、合併最高 50 個基數）試算給付金額。適用 98 年前已有保險年資者。結果僅供參考，以勞保局、健保署核發之繳款單為準，不構成法律或會計建議。
| Name | Required | Description | Default |
|---|---|---|---|
| year | No | 年度（西元，如 2026）。省略則使用最新可用年度；可先用 list_years 查可用年度。 | |
| avgInsuredSalary | Yes | 平均月投保薪資（採退保前 3 年內最高 36 個月平均），新臺幣元。 | |
| preSixtyYears | Yes | 60 歲（含）以前之保險年資：年。 | |
| preSixtyMonths | No | 60 歲（含）以前之保險年資：月（0–11），預設 0。 | |
| postSixtyYears | No | 逾 60 歲以後之保險年資：年。逾 60 歲後最多計入 5 年，超過部分不計。預設 0。 | |
| postSixtyMonths | No | 逾 60 歲以後之保險年資：月（0–11），預設 0。 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavioral traits: the formula details (base system, limits), the condition for pre-98 years, and the disclaimer that results are for reference only and subject to official confirmation. It also notes that omitting year uses latest available.
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 a single paragraph that front-loads the main purpose, but it is dense and could be broken into shorter sentences or bullet points for better readability. It is not overly verbose.
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?
Given the tool's complexity (6 parameters, legal formula, applicability conditions), the description covers all essential aspects: formula, parameter usage, applicability, disclaimer. It is complete for an AI agent to understand 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 input schema already provides 100% coverage with clear parameter descriptions. The description adds value by explaining the overall formula and the logic behind the parameters (e.g., the 45 vs 50 base limits), which enhances understanding beyond individual parameter descriptions.
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 clearly states the tool calculates the old-age lump sum payment for labor insurance using the legal formula, and distinguishes itself from sibling tools like calculate_old_age_pension by specifying the lump sum nature and applicability to those with insurance years before 98.
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 mentions applicability for those with insurance years before 98, which helps decide when to use this tool. However, it does not mention when not to use or explicitly contrast with alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
計算台灣某月薪資的勞保（含就保）、健保、勞退、職災各方（員工/雇主/政府）負擔。支援不同身份別、眷屬、自提、部分工時。結果僅供參考，以勞保局、健保署核發之繳款單為準，不構成法律或會計建議。
| Name | Required | Description | Default |
|---|---|---|---|
| year | No | 年度（西元，如 2026）。省略則使用最新可用年度；可先用 list_years 查可用年度。 | |
| monthlySalary | Yes | 月薪資總額（經常性薪資），新臺幣元／月。 | |
| identity | No | 身份別（預設 category1）：category1=本國勞工或外籍配偶；migrantGeneral=一般移工（勞保僅普通事故 11.5%、無就保/勞退）；migrantDomestic=家事移工（僅健保＋職災，職災費率請以 occupationalRate 傳 0.0018）。不適用的險種回傳 0。 | |
| dependents | No | 健保眷屬人數（計費上限 3 口），預設 0。 | |
| employmentInsurance | No | 是否參加就業保險（勞保費率 12.5% 或 11.5%），預設 true。一般移工/家事移工一律視為不參加。 | |
| pensionSelfContribution | No | 勞工自願提繳率，小數（0~0.06，如 0.06 表 6%），預設 0。 | |
| occupationalRate | No | 職災行業別費率，小數比例（如 0.0021 表 0.21%；家事移工 0.0018），範圍 [0, 0.02)。省略則用該年度平均費率。 | |
| partTime | No | 是否為部分工時：true 時未達基本工資者勞保/健保對到官方低級距（職保仍歸第 1 級）。預設 false。 | |
| rounding | No | 進位策略：round=四捨五入（預設）、ceil=無條件進位、aggregate-then-round=合計後分配（政府方吸收進位差）。 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description includes a disclaimer that results are for reference and subject to official documents, which is valuable. However, it does not describe output format, rate updates, or any limitations beyond the disclaimer.
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 a single concise paragraph that front-loads the main purpose and lists supported features. It is appropriately sized but could benefit from structured bullet points for better readability.
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?
Given 9 parameters and no output schema, the description lacks information about return structure (e.g., breakdown by party), error handling, or frequency of rate updates. This is a significant gap for a complex tool.
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% with detailed descriptions for each parameter. The tool description adds no additional parameter context beyond the schema, so it meets the baseline.
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 clearly states the tool calculates Taiwan's payroll deductions (labor insurance, health insurance, pension, occupational accident) for all parties. It specifies supported variations (identity, dependents, etc.) and distinguishes itself from sibling tools like calculate_old_age_pension by its comprehensive scope.
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 implies usage for full payroll calculation but does not explicitly state when to use this tool versus siblings like calculate_income_tax_withholding or calculate_old_age_pension. No when-not-to-use or alternative recommendations are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
計算月中到職或離職當月的破月保費。勞保/職保/勞退按日（30 日基準）；健保採官方「月底歸屬」——到職當月計整月、離職當月不計。結果僅供參考，以勞保局、健保署核發之繳款單為準，不構成法律或會計建議。
| Name | Required | Description | Default |
|---|---|---|---|
| year | No | 年度（西元，如 2026）。省略則使用最新可用年度；可先用 list_years 查可用年度。 | |
| monthlySalary | Yes | 月薪資總額（經常性薪資），新臺幣元／月。 | |
| identity | No | 身份別（預設 category1）：category1=本國勞工或外籍配偶；migrantGeneral=一般移工（勞保僅普通事故 11.5%、無就保/勞退）；migrantDomestic=家事移工（僅健保＋職災，職災費率請以 occupationalRate 傳 0.0018）。不適用的險種回傳 0。 | |
| dependents | No | 健保眷屬人數（計費上限 3 口），預設 0。 | |
| employmentInsurance | No | 是否參加就業保險（勞保費率 12.5% 或 11.5%），預設 true。一般移工/家事移工一律視為不參加。 | |
| pensionSelfContribution | No | 勞工自願提繳率，小數（0~0.06，如 0.06 表 6%），預設 0。 | |
| occupationalRate | No | 職災行業別費率，小數比例（如 0.0021 表 0.21%；家事移工 0.0018），範圍 [0, 0.02)。省略則用該年度平均費率。 | |
| partTime | No | 是否為部分工時：true 時未達基本工資者勞保/健保對到官方低級距（職保仍歸第 1 級）。預設 false。 | |
| rounding | No | 進位策略：round=四捨五入（預設）、ceil=無條件進位、aggregate-then-round=合計後分配（政府方吸收進位差）。 | |
| startDate | No | 到職日（YYYY-MM-DD）。startDate 與 endDate 至少擇一，且兩者須為同一月份。 | |
| endDate | No | 離職日（YYYY-MM-DD）。 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses calculation rules (30-day basis, end-of-month attribution) and states results are for reference only, not legal/accounting advice. With no annotations, this provides good behavioral context beyond basic calculate action.
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?
Very concise: two sentences followed by disclaimer, all essential information included with no filler. Front-loaded with purpose.
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?
Given complexity (11 parameters, multiple insurance types) and no output schema, description covers key rules and limitations. Slightly lacking in specifying exact return structure, but adequate for a calculator tool.
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 covers all 11 parameters with descriptions, so baseline is 3. Description adds overall context but does not elaborate on individual parameter details beyond what schema already provides.
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?
Description clearly states it calculates prorated insurance premiums for mid-month onboarding or resignation, with specific verb and resource. Distinguishes from sibling tools (e.g., calculate_payroll, calculate_income_tax_withholding) by focusing on prorated scenarios.
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?
Implies usage for mid-month entries via the description, and sibling names show different purposes, but no explicit when-not or alternatives are provided. Still clear enough for an agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
列出目前支援的年度、資料版本與基本工資（月薪/時薪）。計算前可先用本工具確認有效的 year 值。
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It describes the tool's output but does not explicitly state that it is read-only or has no side effects. For a listing tool, this is adequate but could be improved by explicitly noting non-destructive behavior.
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 a single concise sentence that front-loads the main purpose and includes the key usage guidance. Every part is necessary and earns its place.
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?
Given the tool has no parameters, no output schema, and serves as a prerequisite for sibling calculation tools, the description adequately explains its role and output. It could be slightly improved by noting data freshness or static nature, but it is complete enough for a simple listing tool.
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 has no parameters, so schema_description_coverage is 100%. The description adds value by explaining the output contents (years, versions, wages) and their purpose, meeting the baseline for zero-parameter tools.
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 clearly states the tool lists supported years, data versions, and basic wages, and distinguishes it from sibling calculation tools by noting it is used to confirm valid year values before calculations.
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 says 'before calculation, you can first use this tool to confirm valid year values', providing clear guidance on when to use it and implying it should not be used for the calculations themselves.
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.
v1.4.1calculate_employer_supplementary_premiumcalculate_income_tax_withholdingcalculate_old_age_lump_sumcalculate_old_age_pensioncalculate_old_age_single_paymentcalculate_payrollcalculate_proratedcalculate_supplementary_premiumlist_yearsEach tool targets a distinct calculation or information need (e.g., employer vs general supplementary premium, different types of old-age benefits, prorated scenarios). Descriptions clearly differentiate them, so an agent can reliably select the correct tool.
All tools follow a consistent 'calculate_' prefix except 'list_years', which appropriately uses 'list_'. The verb_noun pattern is uniform and predictable, making it easy for an agent to infer tool purposes.
With 9 tools covering major payroll components (general payroll, tax, supplementary premiums, old-age benefits, prorated, and year listing), the count is well-scoped for the domain. No tool feels superfluous or missing.
The set covers core Taiwan payroll operations including labor/health insurance, pension, supplementary premiums, and mid-month adjustments. Minor gaps exist (e.g., no dedicated severance or deduction tool), but these are edge cases not critical for the primary purpose.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Deterministic Mexican payroll & tax math: finiquito, ISR, aguinaldo, IMSS (2026 tables).
Verified 2026 Canadian payroll math: employer total cost, employee take-home, net-to-gross. Free.
Taiwan payments (ECPay 綠界 + NewebPay 藍新) & e-invoices for AI agents. Stateless, never holds funds.
Source-backed Sri Lanka payslip tools for APIT/PAYE, EPF, ETF, stamp duty, and net pay.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/supra126/taiwan-payroll'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
