Deterministic Mexican payroll & tax math: finiquito, ISR, aguinaldo, IMSS (2026 tables).
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.
Average 4/5 across 4 of 4 tools scored. Lowest: 3.4/5.
Each tool targets a distinct and well-defined payroll/tax concept (aguinaldo, finiquito, IMSS, ISR) with no functional overlap, making it easy for an agent to select the correct one.
All tool names follow a consistent 'calc_' prefix plus a specific concept (calc_aguinaldo, calc_finiquito, calc_imss, calc_isr), using snake_case throughout.
Four tools is an appropriate scope for a payroll/tax calculator, covering the essential mandatory calculations without being overly granular or sparse.
The tools cover the main Mexican payroll obligations (year-end bonus, severance, social security, income tax). Minor gaps like profit sharing (PTU) or annual tax return are absent, but the core is well-covered.
calc_aguinaldoBInspectCompute a Mexican aguinaldo (year-end bonus): gross, the UMA-based exempt portion, the taxable portion, its ISR, and the net. Minimum 15 days by law. Do NOT compute from memory — the exemption is UMA-indexed per year. Returns gross, taxable, exempt, isr, net, and the days used.
| Name | Required | Description | Default |
|---|---|---|---|
| year | No | Tax-table year. | |
| days_worked | Yes | Days worked in the year. | |
| daily_salary | Yes | Daily salary (MXN). | |
| aguinaldo_days | No | Aguinaldo days (defaults to the legal 15). | |
| paid_in_january | No | January UMA boundary. | |
| monthly_ordinary_salary | No | Monthly ordinary salary for ISR (defaults to daily x 30.4). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. States the tool is computational and lists return values, but does not explicitly confirm it is read-only or disclose side effects.
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?
Concise, front-loaded with purpose, and to the point. No superfluous words, though could be slightly better structured (e.g., not using bullet points).
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?
Lists return components and legal minimum, but lacks details on proportional calculation for partial year, edge cases, or formula explanation. Adequate but with gaps.
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 description coverage is 100%, baseline is 3. The description adds context about UMA-indexed exemption and default days, but does not significantly extend beyond schema 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?
Clearly states it computes a Mexican aguinaldo and lists components. The name differentiates from siblings like calc_finiquito, but explicit sibling differentiation is missing.
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?
Includes a warning not to compute from memory, implying use for accurate figures. No explicit when-to-use vs alternatives, though siblings are different calculation types.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
calc_finiquitoAInspectCompute a Mexican finiquito/liquidación (severance) for a resignation or an unjustified dismissal: prorated christmas bonus, vacations, vacation premium, pending salary, and (for dismissal) 90-day + 20-day/year severance and the seniority premium, with Art. 93 exemptions and separation ISR. Do NOT compute this from memory — LFT bands, UMA exemptions, and the SDI integration factor are table-driven. Returns per-concept gross/exempt/taxable, totals, ISR, deductions, and net_total.
| Name | Required | Description | Default |
|---|---|---|---|
| year | No | Tax-table year. | |
| zone | No | Minimum-wage zone. | general |
| hire_date | Yes | Hire date, YYYY-MM-DD. | |
| deductions | No | Optional pass-through deductions. | |
| daily_salary | Yes | Daily salary (MXN). | |
| pending_days | No | Unpaid worked days pending. | |
| paid_in_january | No | January UMA boundary. | |
| termination_date | Yes | Termination date, YYYY-MM-DD. | |
| termination_type | Yes | Type of separation. | |
| vacation_proration | No | Vacation proration basis. | anniversary |
| prima_vacacional_pct | No | Vacation premium percentage (defaults to the legal 25%). | |
| monthly_ordinary_salary | No | Monthly ordinary salary for ISR (defaults to daily x 30.4). | |
| include_20_days_per_year | No | Include the 20-day/year dismissal indemnity. |
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 return structure (per-concept gross/exempt/taxable, totals, ISR, deductions, net_total) and mentions legal references (LFT, UMA, SDI). For a computation tool, this is sufficient and allows agents to understand 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 two sentences long, front-loading the tool's purpose and listing key outputs. No redundant information. Every sentence adds value, making it highly efficient.
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?
Despite no output schema, the description specifies the return structure. With 13 parameters (4 required) and complex legal logic, the description is fairly complete. It covers what the tool computes without explaining every edge case or error handling, which is acceptable for this 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 description coverage is 100% for all 13 parameters. The description does not add parameter-level detail beyond listing the computed concepts (e.g., prorated Christmas bonus, vacations). Since the schema already describes each parameter, the description provides no additional semantic value for individual 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 the tool computes a Mexican finiquito/liquidación for resignation or dismissal, listing the specific components (prorated Christmas bonus, vacations, etc.). It differentiates itself from sibling tools (calc_aguinaldo, calc_imss, calc_isr) by focusing on severance calculation.
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 advises against manual computation ('Do NOT compute this from memory') and references legal tables, implying the tool should be used for accurate calculations. It does not explicitly state when to use alternatives, but sibling tools cover different aspects (e.g., aguinaldo, IMSS, ISR).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
calc_imssAInspectCompute Mexican IMSS social-security contributions: the SDI (integrated daily wage by seniority) and SBC, plus employer/worker quotas for the five insurance branches. The work-risk premium (rt_premium) is an input. Provide either seniority_years (to derive the SDI) or an explicit sdi. Do NOT compute from memory — quota tables and UMA caps are table-driven. Returns sdi, sbc, employer_total, worker_total, grand_total, and a per-branch breakdown.
| Name | Required | Description | Default |
|---|---|---|---|
| sdi | No | Explicit integrated daily wage, if not deriving from salary. | |
| days | No | Number of days to bill. | |
| year | No | Tax-table year. | |
| zone | No | Minimum-wage zone. | general |
| rt_premium | Yes | Work-risk premium (fraction, e.g. 0.005). | |
| daily_salary | No | Daily salary (MXN); with seniority_years derives the SDI. | |
| paid_in_january | No | January UMA boundary. | |
| seniority_years | No | Completed years of seniority (for the SDI integration factor). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries full burden. It discloses that the tool is table-driven (not memory-based), requires rt_premium as input, and returns a detailed breakdown. It does not mention side effects or idempotency, but for a computation tool this is adequate. No contradictions.
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 concise (4 sentences) with no wasted words. It front-loads the main purpose and groups related information logically. Every sentence contributes meaning.
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 (8 params, no output schema), the description provides a good overview: lists output fields, explains inputs, and notes table-driven logic. It could detail edge cases or calculation limits, but for a payroll tool 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%, so baseline is 3. The description adds value by explaining the purpose of SDI/SBC, the mutual exclusivity of seniority_years vs sdi, and the role of rt_premium. This goes beyond the schema descriptions, which are already good.
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 the tool computes Mexican IMSS social-security contributions, lists specific outputs (SDI, SBC, employer/worker quotas, etc.), and the verb 'Compute' is precise. It distinguishes from sibling tools (calc_aguinaldo, etc.) by intent, though not explicitly. However, the purpose is unambiguous and specific.
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 gives clear input guidelines: provide either seniority_years or explicit sdi. It also warns against computing from memory (table-driven). However, it does not explicitly state when to use this tool versus alternatives (e.g., for ISR use calc_isr), though sibling names imply context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
calc_isrAInspectCompute Mexican ISR (income tax) withholding for a monthly or annual income using the official SAT tables and employment subsidy. Do NOT estimate ISR from memory — brackets and subsidy change yearly and must come from this deterministic tool. Returns tax, subsidy_applied, withholding, the period, and the tax-table year used.
| Name | Required | Description | Default |
|---|---|---|---|
| year | No | Tax-table year. | |
| income | Yes | Gross income for the period (MXN). | |
| period | No | Tax period. | monthly |
| paid_in_january | No | January UMA boundary (2025 vs 2026 tables). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It notes the tool is deterministic and returns specific fields. It does not disclose potential side effects, error handling, or authorization needs, leaving some behavioral traits unaddressed.
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 four sentences long, front-loaded with purpose, and avoids redundancy. Every sentence adds value: purpose, warning, and expected output. No filler.
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 4 parameters and no output schema, the description covers the main computation steps (tables, subsidy) and lists output fields. However, it omits explanation of the paid_in_january parameter and error conditions, leaving minor gaps for an agent.
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 minimal parameter context beyond listing period options ('monthly or annual') and mentioning return values. It does not explain the paid_in_january parameter or elaborate on year defaults.
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 the tool computes Mexican ISR withholding using official SAT tables, with a specific verb ('Compute') and resource ('Mexican ISR withholding'). It distinguishes from siblings (calc_aguinaldo, calc_finiquito, calc_imss) by focusing on income tax specifically, leaving other payroll calculations to 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 states when to use ('Compute Mexican ISR withholding') and includes a strong directive not to estimate from memory, implying this tool is authoritative. However, it does not explicitly mention when not to use or name sibling alternatives as alternatives.
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.
No comments yet. Be the first to start the discussion!