taiwan-payroll

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.4.1
Disambiguation5/5
Each 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.
Naming Consistency5/5
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.
Tool Count5/5
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.
Completeness4/5
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.
Average 4/5 across 9 of 9 tools scored. Lowest: 2.9/5.
See the Tool Scores section below for per-tool breakdowns.
- 1 of 1 community issues answered or closed in the last 6 months
- 0 commits in the last 12 weeks
- Last stable release on June 8, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
This repository includes a glama.json configuration file.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
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.
Conciseness4/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose4/5
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.
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. 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.
Behavior3/5
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.
Conciseness4/5
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.
Completeness2/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses the calculation formula, rate, and caveat that results are for reference only. However, it does not explicitly state that the tool is read-only or describe any side effects, permissions, or error handling beyond the formula.
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, concise and front-loaded with the key formula and rate. Every word contributes essential information without redundancy.
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?
Given the tool has 4 parameters, no output schema, and moderate complexity, the description is nearly complete. It explains the formula, rate, rounding options, and caveat. It is missing explicit info on the return value format (presumably a number), but the use case makes it obvious.
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 100%, with detailed parameter descriptions. The description adds context like '無上限' and the formula, but the schema already explains the parameters well. The description provides additional value by explaining the rounding strategies and the reference-only nature.
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 title and description explicitly state the tool calculates employer supplementary premium for National Health Insurance with the formula, rate (2.11%), and no cap. It clearly distinguishes from siblings like 'calculate_supplementary_premium' (likely for employees) and other calculation tools.
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 does not explicitly state when to use this tool vs. alternatives like 'calculate_supplementary_premium' or other payroll tools. While the name and formula imply it's for employer premiums, there is no direct guidance on selection criteria or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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.
Conciseness4/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses the rate (2.11%), bonus threshold (4x monthly insured amount), other category thresholds, and the 10 million cap. It also includes a legal disclaimer. However, it does not describe error handling or return format, but the calculation logic is transparent.
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, dense paragraph that front-loads the purpose. Every sentence adds value: rate, rules, thresholds, and disclaimer. No wasted words. Appropriate length for the complexity.
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?
Given 6 parameters and no output schema, the description covers the core logic and disclaims accuracy. It explains input constraints (e.g., bonus-specific fields) but does not specify output format (likely a number). For a pure calculation tool, this is adequate but could mention return value type.
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 value by explaining the calculation context (e.g., bonus requires monthly insured salary and YTD bonus) and the rounding strategies. This helps the agent understand why certain parameters are needed beyond schema descriptions.
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 calculates the supplementary premium at 2.11% rate, specifying the resource (二代健保補充保費) and distinguishing it from siblings like employer premium or tax withholding. The verb '計算' (calculate) and detailed rule mentions make 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.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly state when to use this tool versus alternatives like calculate_employer_supplementary_premium or calculate_income_tax_withholding. However, the context of supplementary premium and the sibling list imply its specific use case. No clear when-to-use or when-not-to-use guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.
Behavior5/5
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.
Conciseness4/5
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.
Completeness5/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![taiwan-payroll MCP server](https://glama.ai/mcp/servers/supra126/taiwan-payroll/badges/card.svg)](https://glama.ai/mcp/servers/supra126/taiwan-payroll)

Score Badge

Copy to your README.md:

[![taiwan-payroll MCP server](https://glama.ai/mcp/servers/supra126/taiwan-payroll/badges/score.svg)](https://glama.ai/mcp/servers/supra126/taiwan-payroll)

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/supra126/taiwan-payroll'

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