台灣勞健保勞退試算
Server Details
台灣勞保、健保、勞退、職災與二代健保補充保費試算，含薪資扣繳、破月與勞保老年給付。資料取自主管機關公告，對官方範例逐位元驗證。
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 4.2/5 across 9 of 9 tools scored. Lowest: 3.6/5.
Each tool targets a distinct calculation scenario (e.g., payroll, pension types, supplementary premiums, income tax) with no functional overlap. The descriptions clearly differentiate their purposes.
All tools follow a consistent 'calculate_' prefix for computational tools and 'list_years' for enumeration, using snake_case throughout. The verb_noun pattern is uniform.
9 tools cover the core aspects of Taiwan's labor insurance, health insurance, pension, and tax calculations without redundancy. The count is well-matched to the domain's complexity.
The set includes all major calculations required for payroll and benefits: employer/employee burdens, multiple pension options, supplementary premiums, tax withholding, prorated scenarios, and a year reference tool. No obvious gaps.
Available Tools
9 toolscalculate_income_tax_withholding薪資所得扣繳稅額ARead-onlyIdempotentInspect
計算薪資所得扣繳稅額：居住者固定月薪(公式法)、非每月給付獎金(5%，未達起扣標準免扣)、非居住者(18%；月薪≤1.5倍基本工資為6%)。結果僅供參考，以勞保局、健保署核發之繳款單為準，不構成法律或會計建議。
| Name | Required | Description | Default |
|---|---|---|---|
| type | Yes | 扣繳類型：resident=居住者固定月薪(公式法)、residentBonus=居住者非每月給付(獎金)5%、nonResident=非居住者18%/6%。 | |
| year | No | 年度（西元，如 2026）。省略則使用最新可用年度；可先用 list_years 查可用年度。 | |
| amount | No | 該筆給付金額，新臺幣元（僅 residentBonus）。 | |
| dependents | No | 配偶及受扶養親屬人數（僅 resident），預設 0。 | |
| monthlySalary | No | 月薪資，新臺幣元（resident／nonResident 用）。 |
Output Schema
| Name | Required | Description |
|---|---|---|
| rate | Yes | |
| withholding | Yes | |
| taxableAnnual | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations show readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds context: results are estimates, not legal advice, and details rate logic. No contradiction.
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 dense paragraph, which is concise but could be more structured. It effectively front-loads the purpose. Still good for its length.
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 (5 params, 1 required, output schema exists), the description covers all major scenarios and caveats. It references list_years for available years, showing completeness.
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 each param. The description adds context (e.g., '未達起扣標準免扣' for bonus) but mostly reinforces schema. A 4 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 income tax withholding, distinguishing three scenarios with specific rates. It differentiates from sibling tools like calculate_employer_supplementary_premium by focusing on withholding tax.
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 explains when to use each type (resident, residentBonus, nonResident) with rates and conditions. It doesn't explicitly exclude cases, but the specificity guides correct usage. Also notes results are for reference only.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
calculate_old_age_lump_sum計算勞保老年一次金ARead-onlyIdempotentInspect
依勞保老年一次金法定公式（平均月投保薪資 × 給付月數；年資每滿 1 年給 1 個月、逾 60 歲後之年資最多計入 5 年）試算給付金額。結果僅供參考，以勞保局、健保署核發之繳款單為準，不構成法律或會計建議。
| Name | Required | Description | Default |
|---|---|---|---|
| year | No | 年度（西元，如 2026）。省略則使用最新可用年度；可先用 list_years 查可用年度。 | |
| years | Yes | 保險年資：年。 | |
| months | No | 保險年資：月（0–11），預設 0。 | |
| postSixtyMonths | No | 逾 60 歲以後之保險年資（月），最多計入 5 年（60 個月），超過部分不計。不得超過總保險月數。預設 0。 | |
| avgInsuredSalary | Yes | 平均月投保薪資（最高 60 個月平均），新臺幣元。 |
Output Schema
| Name | Required | Description |
|---|---|---|
| payment | Yes | |
| insuredMonthsCounted | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly and idempotent. The description adds context that the result is for reference only and not binding, which is important for agent decision-making, but doesn't reveal additional behavioral traits beyond what annotations imply.
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?
A single paragraph that efficiently conveys formula, scope, and disclaimer. No superfluous content.
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 complexity of the legal formula and the availability of an output schema (which likely explains the result structure), the description provides sufficient contextual completeness for the agent to understand the tool's purpose and limitations.
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?
All five parameters have schema descriptions (100% coverage). The description adds value by explaining the formula in natural language, particularly the rule for post-60 years (max 5 years), which reinforces the parameter semantics.
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 benefit using the legal formula, specifying key variables (average insured salary, years). It distinguishes itself from siblings like calculate_old_age_pension (likely monthly) and others by naming the specific benefit type.
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 includes a disclaimer about reference only and not legal advice, but does not explicitly state when to use this tool over siblings like calculate_old_age_single_payment or calculate_old_age_pension. No alternative tools are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
calculate_old_age_pension計算勞保老年年金（月領）ARead-onlyIdempotentInspect
依勞保老年年金法定公式（擇優兩式、提前/延後增減給每年 ±4%，上限 ±5 年（±20%））試算月領金額；年資未滿 15 年不符年金請領資格。結果僅供參考，以勞保局、健保署核發之繳款單為準，不構成法律或會計建議。
| Name | Required | Description | Default |
|---|---|---|---|
| year | No | 年度（西元，如 2026）。省略則使用最新可用年度；可先用 list_years 查可用年度。 | |
| years | Yes | 保險年資：年。 | |
| months | No | 保險年資：月（0–11），預設 0。 | |
| avgInsuredSalary | Yes | 平均月投保薪資（最高 60 個月平均），新臺幣元。 | |
| claimOffsetMonths | No | 提前(負)/延後(正)請領月數，相對法定請領年齡；每年 ±4%，上限 ±5 年（±20%）。預設 0。 |
Output Schema
| Name | Required | Description |
|---|---|---|
| monthly | Yes | |
| eligible | Yes | |
| formulaA | Yes | |
| formulaB | Yes | |
| adjustmentMonths | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnlyHint, idempotentHint, destructiveHint), the description details the formula behavior (annual ±4%, max ±20%), eligibility condition (minimum 15 years), and the non-binding disclaimer about official sources. No contradiction with annotations.
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 sentence that packs all key information: formula, eligibility, disclaimer. It is slightly long but well-structured with front-loaded purpose. Could be more structured with bullet points, but still effective.
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?
With 5 parameters (2 required), 100% schema coverage, and an output schema present, the description adequately covers the tool's behavior, eligibility, disclaimer, and formula details. No missing critical context given the tool complexity.
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. The description adds value by explaining the claimOffsetMonths parameter's effect (early/late adjustment) and highlighting the 15-year minimum requirement. It provides formula context that aids understanding of parameters.
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, including early/late adjustment rates and eligibility criteria. The title specifies '月領' (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 using list_years to check available years for the year parameter, providing usage guidance. However, it does not explicitly contrast with sibling tools like calculate_old_age_lump_sum or explain when not to use this tool (e.g., for lump sum).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
calculate_old_age_single_payment計算勞保一次請領老年給付ARead-onlyIdempotentInspect
依勞保一次請領老年給付法定公式（基數制：前 15 年每年 1 個基數、第 16 年起每年 2 個基數、60 歲前最高 45 個基數、逾 60 歲後年資每年 2 個基數最多計 5 年、合併最高 50 個基數）試算給付金額。適用 98 年前已有保險年資者。結果僅供參考，以勞保局、健保署核發之繳款單為準，不構成法律或會計建議。
| Name | Required | Description | Default |
|---|---|---|---|
| year | No | 年度（西元，如 2026）。省略則使用最新可用年度；可先用 list_years 查可用年度。 | |
| preSixtyYears | Yes | 60 歲（含）以前之保險年資：年。 | |
| postSixtyYears | No | 逾 60 歲以後之保險年資：年。逾 60 歲後最多計入 5 年，超過部分不計。預設 0。 | |
| preSixtyMonths | No | 60 歲（含）以前之保險年資：月（0–11），預設 0。 | |
| postSixtyMonths | No | 逾 60 歲以後之保險年資：月（0–11），預設 0。 | |
| avgInsuredSalary | Yes | 平均月投保薪資（採退保前 3 年內最高 36 個月平均），新臺幣元。 |
Output Schema
| Name | Required | Description |
|---|---|---|
| payment | Yes | |
| basisTwelfths | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, and non-destructive, so safety is clear. The description adds value by detailing the formula, stating results are for reference only, and including a disclaimer that they are not legal advice. This provides behavioral context beyond annotations.
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 comprehensive with multiple sentences, but all sentences are relevant: formula, applicability, disclaimer. It is well-structured, starting with the formula and ending with limitations. Slightly lengthy but appropriate for a complex calculation.
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, presence of output schema, and thorough schema descriptions, the description covers the formula, applicability, and limitations. It could mention error handling or examples, but is fairly complete for an agent to understand usage.
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 each parameter described in the schema. The description adds extra meaning by explaining the formula (e.g., how years translate to benefit units), which helps understand parameter interplay. This goes beyond the schema definitions.
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 lump-sum old-age benefit using a specific formula. It is specific about the verb ('試算') and the resource ('一次請領老年給付'). However, it does not explicitly differentiate from sibling tools like calculate_old_age_lump_sum or calculate_old_age_pension, which may cause confusion.
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 applicability ('適用98年前已有保險年資者'), providing a condition for use. However, it does not guide when to avoid this tool or mention alternatives (e.g., for monthly pensions). No explicit exclusions or 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.
calculate_payroll計算台灣勞健保勞退ARead-onlyIdempotentInspect
計算台灣某月薪資的勞保（含就保）、健保、勞退、職災各方（員工/雇主/政府）負擔。支援不同身份別、眷屬、自提、部分工時。結果僅供參考，以勞保局、健保署核發之繳款單為準，不構成法律或會計建議。
| Name | Required | Description | Default |
|---|---|---|---|
| year | No | 年度（西元，如 2026）。省略則使用最新可用年度；可先用 list_years 查可用年度。 | |
| identity | No | 身份別（預設 category1）：category1=本國勞工或外籍配偶；migrantGeneral=一般移工（勞保僅普通事故 11.5%、無就保/勞退）；migrantDomestic=家事移工（僅健保＋職災，職災費率請以 occupationalRate 傳 0.0018）。不適用的險種回傳 0。 | |
| partTime | No | 是否為部分工時：true 時未達基本工資者勞保/健保對到官方低級距（職保仍歸第 1 級）。預設 false。 | |
| rounding | No | 進位策略：round=四捨五入（預設）、ceil=無條件進位、aggregate-then-round=合計後分配（政府方吸收進位差）。 | |
| dependents | No | 健保眷屬人數（計費上限 3 口），預設 0。 | |
| monthlySalary | Yes | 月薪資總額（經常性薪資），新臺幣元／月。 | |
| occupationalRate | No | 職災行業別費率，小數比例（如 0.0021 表 0.21%；家事移工 0.0018），範圍 [0, 0.02)。省略則用該年度平均費率。 | |
| employmentInsurance | No | 是否參加就業保險（勞保費率 12.5% 或 11.5%），預設 true。一般移工/家事移工一律視為不參加。 | |
| pensionSelfContribution | No | 勞工自願提繳率，小數（0~0.06，如 0.06 表 6%），預設 0。 |
Output Schema
| Name | Required | Description |
|---|---|---|
| meta | Yes | |
| brackets | Yes | |
| employee | Yes | |
| employer | Yes | |
| government | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, indicating it's a safe, non-destructive calculation. The description adds the disclaimer that results are for reference only, which aligns with annotations. No contradictions, but the description adds little beyond what annotations provide.
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 purpose and supported features. It is relatively concise, though 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.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (9 parameters, 1 required) and the existence of output schema, the description covers key aspects: what is calculated, supported identity types, dependents, self-contribution, and part-time. It also includes a disclaimer. It could mention constraints or edge cases, but overall it is fairly complete.
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 parameter descriptions. The description adds meaningful context, such as explaining identity categories and when certain insurances apply, and the occupationalRate range. This adds value beyond the schema alone.
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 insurance burdens for labor, health, pension, and occupational accident for each party. It mentions supported features like different identities and part-time. However, it does not explicitly differentiate from sibling tools like calculate_income_tax_withholding, which reduces clarity slightly.
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 the tool supports various identities and scenarios, and provides a disclaimer that results are for reference only. It hints at using list_years for available years, but does not explicitly state when to use this tool versus alternatives like calculate_old_age_pension.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
calculate_prorated月中到職／離職破月計算ARead-onlyIdempotentInspect
計算月中到職或離職當月的破月保費。勞保/職保/勞退按日（30 日基準）；健保採官方「月底歸屬」——到職當月計整月、離職當月不計。結果僅供參考，以勞保局、健保署核發之繳款單為準，不構成法律或會計建議。
| Name | Required | Description | Default |
|---|---|---|---|
| year | No | 年度（西元，如 2026）。省略則使用最新可用年度；可先用 list_years 查可用年度。 | |
| endDate | No | 離職日（YYYY-MM-DD）。 | |
| identity | No | 身份別（預設 category1）：category1=本國勞工或外籍配偶；migrantGeneral=一般移工（勞保僅普通事故 11.5%、無就保/勞退）；migrantDomestic=家事移工（僅健保＋職災，職災費率請以 occupationalRate 傳 0.0018）。不適用的險種回傳 0。 | |
| partTime | No | 是否為部分工時：true 時未達基本工資者勞保/健保對到官方低級距（職保仍歸第 1 級）。預設 false。 | |
| rounding | No | 進位策略：round=四捨五入（預設）、ceil=無條件進位、aggregate-then-round=合計後分配（政府方吸收進位差）。 | |
| startDate | No | 到職日（YYYY-MM-DD）。startDate 與 endDate 至少擇一，且兩者須為同一月份。 | |
| dependents | No | 健保眷屬人數（計費上限 3 口），預設 0。 | |
| monthlySalary | Yes | 月薪資總額（經常性薪資），新臺幣元／月。 | |
| occupationalRate | No | 職災行業別費率，小數比例（如 0.0021 表 0.21%；家事移工 0.0018），範圍 [0, 0.02)。省略則用該年度平均費率。 | |
| employmentInsurance | No | 是否參加就業保險（勞保費率 12.5% 或 11.5%），預設 true。一般移工/家事移工一律視為不參加。 | |
| pensionSelfContribution | No | 勞工自願提繳率，小數（0~0.06，如 0.06 表 6%），預設 0。 |
Output Schema
| Name | Required | Description |
|---|---|---|
| days | Yes | |
| meta | Yes | |
| brackets | Yes | |
| employee | Yes | |
| employer | Yes | |
| government | Yes | |
| healthCharged | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, idempotentHint=true, destructiveHint=false; description adds detailed calculation rules (per-day for labor, month-end rule for health) and a disclaimer. No contradictions, adds value.
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?
Description is moderately long but well-structured, front-loading purpose and key rules. Every sentence adds value; could be slightly shorter but not 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 complexity (multiple insurance types, proration rules), description covers essential behaviors, constraints (same month for start/end), and identity-specific rules. Output schema exists, so return format need not be described. Complete and self-sufficient.
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 good per-parameter descriptions. Description adds no additional parameter details beyond schema, so 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?
Description clearly states it calculates prorated premiums for mid-month entry/exit, with specific breakdown of labor and health insurance rules. Distinct from sibling tools like calculate_payroll or calculate_income_tax_withholding.
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?
Context makes it obvious this is for prorated calculations when to date or start date is mid-month. No explicit 'when not to use' but sibling tool list provides alternatives. Disclaimer about reference only adds guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_years列出可用年度ARead-onlyIdempotentInspect
列出目前支援的年度、資料版本與基本工資（月薪/時薪）。計算前可先用本工具確認有效的 year 值。
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
| years | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark it as read-only, idempotent, and non-destructive. Description adds that it returns data versions and basic wages, complementing the structured information well.
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 concise Chinese sentences, front-loaded with the main action, no superfluous words. Every sentence adds value.
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?
For a parameterless, read-only listing tool with an output schema, the description fully covers the tool's purpose and returned data. No gaps remain.
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?
No parameters exist, so the description cannot add parameter-level value. Baseline 4 is appropriate given zero parameters.
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?
Name, title, and description clearly state it lists supported years, data versions, and basic wages. The verb 'list' and specific resource items 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises using this tool before calculations to confirm valid year values. Context helps distinguish from sibling calculation tools, though no explicit 'when not to use' is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!