Fiscal y nomina MX: recargos, ISR, CFDI, RESICO, calendario, IMSS, aguinaldo, finiquito.
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.2/5 across 10 of 10 tools scored. Lowest: 3.6/5.
Each tool targets a distinct fiscal or labor calculation (aguinaldo, CFDI validation, IMSS, ISR estimation, etc.) with no overlap. The descriptions clearly differentiate their purposes.
All tools follow a consistent 'fiscal_<noun>' pattern, using snake_case and clear, domain-specific nouns (e.g., fiscal_aguinaldo, fiscal_isr_retencion). No deviation.
10 tools cover the essential calculations for Mexican fiscal and payroll management (aguinaldo, finiquito, IMSS, ISR, CFDI, etc.) without being excessive or insufficient.
The set covers major tax and labor calculations but lacks a few common tools like PTU (profit sharing) or IVA (VAT) handling. However, it is fairly comprehensive for its stated scope.
fiscal_aguinaldoACalcula el aguinaldo (LFT Art. 87): bruto (proporcional si aplica), parte exenta (30 UMA), parte gravada e ISR estimado. Determinista. Informativo, no asesoria fiscal.
| Name | Required | Description | Default |
|---|---|---|---|
| dias_aguinaldo | No | Opcional. Dias de aguinaldo (default 15, minimo de ley). | |
| salario_diario | Yes | Salario diario. | |
| dias_trabajados | No | Opcional. Dias trabajados en el anio (default 365). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations (readOnlyHint=true, openWorldHint=false) are complemented by description stating 'Determinista' (deterministic) and 'Informativo, no asesoria fiscal' (informational, not tax advice). This adds value beyond annotations without 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?
Single sentence in Spanish that is front-loaded with key outputs. It is concise without wasted words, though it could be slightly more structured with line breaks.
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 moderate complexity of a tax calculator and no output schema, the description lists main outputs but omits details like UMA value dependency or rounding behavior. It partially compensates for missing output schema but is not fully 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 description coverage is 100% for all 3 parameters, so the baseline is 3. The tool description does not add new meaning beyond what the schema already provides for 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 calculates aguinaldo under LFT Art. 87, listing specific outputs (bruto, exenta, gravada, ISR estimado). It is distinct from sibling tools like fiscal_finiquito (severance) and fiscal_isr_retencion (withholding) by focusing on this specific statutory bonus.
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 explicit guidance on when to use this tool versus siblings. While the description implies it's for aguinaldo calculations, it does not provide usage context, prerequisites, or mention alternatives like fiscal_finiquito for severance calculations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
fiscal_calendarioAObligaciones fiscales y fechas limite de un regimen fiscal mexicano. Con mes (1-12) calcula la fecha limite del pago mensual de ese periodo (dia 17 del mes siguiente, ajustado al siguiente dia habil por fin de semana). Con rfc6 (6o digito del RFC) estima la extension del decreto de facilidades. Informativo, no asesoria fiscal.
| Name | Required | Description | Default |
|---|---|---|---|
| mes | No | Opcional. Periodo mensual a declarar (1=enero). | |
| rfc6 | No | Opcional. 6o digito numerico del RFC, para la extension de dias. | |
| regimen | Yes | Regimen fiscal. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint annotation, the description reveals key behavioral traits: the deadline calculation rule (17th of next month, adjusted to next business day) and the extension logic based on RFC digit. It also warns 'Informativo, no asesoria fiscal', adding important context.
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 three sentences, concise, and front-loaded with the purpose. Every sentence adds value without repetition.
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 no output schema, the description explains what the tool calculates and the logic. However, it does not specify the exact output format or behavior when parameters are omitted, leaving minor 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 coverage is 100%, but the description adds meaning by explaining how `mes` and `rfc6` affect the output (deadline calculation and extension estimation), going beyond parameter names.
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 provides 'Obligaciones fiscales y fechas limite' for Mexican tax regimes. It distinguishes itself from sibling tools like fiscal_aguinaldo or fiscal_cfdi_validar by focusing on deadlines and extensions.
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 the tool: to calculate payment deadlines with `mes` and estimate extensions with `rfc6`. It does not explicitly exclude alternatives but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
fiscal_cfdi_validarAValida la coherencia de un CFDI 4.0 antes de emitirlo: relacion entre tipo de comprobante, uso, metodo/forma de pago y tipo de receptor, contra los catalogos del SAT. Determinista. NO timbra ni sustituye al PAC. Informativo, no asesoria fiscal.
| Name | Required | Description | Default |
|---|---|---|---|
| uso | Yes | Clave de Uso del CFDI (c_UsoCFDI), ej. G03, D01, CP01. | |
| tipo | Yes | Tipo de comprobante (I,E,T,N,P). | |
| metodo | No | Opcional. Metodo de pago (PUE/PPD). | |
| receptor | No | Opcional. Tipo de persona del receptor. | |
| forma_pago | No | Opcional. Clave de forma de pago (ej. 03, 99). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already signal readOnlyHint=true; the description adds key behavioral traits: determinism, non-stamping, non-substitution of PAC, and informative nature. 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 two sentences, front-loaded with the core action and scope, followed by important caveats. Every sentence provides value without redundancy.
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?
The description covers purpose, usage, and behavioral traits well, but lacks information about the return value or output format. Since no output schema exists, the agent would benefit from knowing whether the tool returns a boolean, error messages, or details. This omission reduces 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 description coverage is 100%, so baseline is 3. The description summarizes the parameter relationship ('relacion entre tipo...') but does not add significant detail beyond the schema descriptions. The term 'coherencia' provides context but not per-parameter clarification.
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 verb 'Valida' and the resource 'CFDI 4.0', and specifies the validation scope: 'relacion entre tipo de comprobante, uso, metodo/forma de pago y tipo de receptor, contra los catalogos del SAT'. It distinguishes from siblings by mentioning determinism and what it does not do (timbra, sustituye PAC).
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 states when to use ('antes de emitirlo') and what not to do ('NO timbra ni sustituye al PAC', 'Informativo, no asesoria fiscal'). It does not explicitly name alternative tools but provides enough context for appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
fiscal_finiquitoACalcula finiquito (renuncia/termino) o liquidacion (despido injustificado), LFT: aguinaldo proporcional, vacaciones + prima, y para liquidacion 3 meses + 20 dias/anio + prima de antiguedad. Devuelve montos BRUTOS. La procedencia legal y el ISR se confirman con abogado/contador. No asesoria.
| Name | Required | Description | Default |
|---|---|---|---|
| tipo | No | finiquito (renuncia) o liquidacion (despido injustificado). | |
| dias_aguinaldo | No | Opcional. Default 15. | |
| salario_diario | Yes | Salario diario. | |
| antiguedad_anios | No | Anios de antiguedad (para indemnizacion/prima). | |
| salarios_pendientes | No | Opcional. Salarios devengados no pagados (bruto). | |
| dias_trabajados_anio | No | Dias trabajados del anio en curso (aguinaldo proporcional). | |
| prima_vacacional_pct | No | Opcional. Default 0.25. | |
| dias_vacaciones_pendientes | No | Dias de vacaciones no gozadas. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=true, consistent with a calculation tool. Description explicitly states it returns BRUTO amounts and does not provide legal advice. No contradictions. It adds context about what the tool does not cover (legal procedure, ISR), which is helpful.
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 one dense paragraph but includes essential information: purpose, components, disclaimer. It is front-loaded with the main action. Could be slightly more structured, but no unnecessary words. Efficient given the complexity.
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 complex legal calculation tool, the description covers the key components and limitations. It mentions returning BRUTO amounts, which is critical. However, without an output schema, the description could detail what specific fields are returned. Still, it is sufficiently 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 description coverage is 100% with each parameter documented. The tool description groups parameters into calculation components (aguinaldo proporcional, vacaciones, etc.) but does not add significant per-parameter detail beyond the schema. Baseline 3 is appropriate given full schema coverage.
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 finiquito (resignation) or liquidacion (unjustified dismissal) and lists the LFT components (aguinaldo, vacation, etc.). It distinguishes between two scenarios and specifies the jurisdiction (LFT). This is specific and unique among sibling fiscal tools.
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 (finiquito for renuncia, liquidacion for despido injustificado). It advises that legal procedure and ISR should be confirmed with a professional, indicating the tool's scope is limited to calculation. No explicit when-not-to-use, but context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
fiscal_imssACalcula las cuotas IMSS obrero-patronales del periodo sobre el SBC diario (topado a 25 UMA): Enfermedades y Maternidad, Invalidez y Vida, Retiro, Cesantia y Vejez (curva patronal 2026 por veces UMA), Guarderias, Riesgos de Trabajo e INFONAVIT. Determinista. Da sbc_diario o salario_diario. Estimacion (la prima RT es por empresa; los dias reales dependen del mes). Informativo, no asesoria.
| Name | Required | Description | Default |
|---|---|---|---|
| dias | No | Opcional. Dias del periodo (default 30.4). | |
| prima_rt | No | Opcional. Prima de Riesgos de Trabajo (default Clase I minima). | |
| sbc_diario | No | SBC diario. Si se da, se usa directo. | |
| salario_diario | No | Alterno a sbc_diario: salario diario que se integra con el factor. | |
| es_salario_minimo | No | Opcional. Fuerza el piso de CyV (3.150%). | |
| factor_integracion | No | Opcional. Factor de integracion (default del anio). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true, so the tool is safe. The description adds behavioral context: it is 'Determinista' (deterministic) and an 'Estimacion' (estimation) due to variable factors like prima RT and days, which goes beyond annotations and helps the agent understand the tool's nature.
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 that packs a lot of information without repetition. It is efficient but could benefit from clearer sentence breaks or bullet points for easier scanning. Still, it is appropriately sized for the complexity.
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 lacking an output schema, the description lists the computed quota types and notes the estimation nature. For a read-only, deterministic tool, this provides sufficient context for the agent to understand what it returns. However, the precise output structure is not specified.
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?
100% schema description coverage means parameters are already documented in the schema. The description adds minor context (e.g., 'topado a 25 UMA') but does not elaborate on individual parameters. Baseline 3 is appropriate as the description does not significantly enhance parameter understanding beyond the schema.
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 opens with a specific verb ('Calcula') and resource ('cuotas IMSS obrero-patronales'), detailing the types of quotas. It also distinguishes itself from sibling tools (other fiscal calculations) by focusing exclusively on IMSS, making its purpose unmistakable.
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 use for IMSS quota calculations and includes a disclaimer ('Informativo, no asesoria'). However, it does not explicitly state when to use this tool over siblings or provide exclusions. The guidance is implicit rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
fiscal_isr_estimadoAESTIMA el ISR anual segun regimen, ingresos y deducciones, con la tarifa progresiva Art. 152 (Anexo 8 RMF 2026) o la tasa aplicable (RESICO/PM). Es una ESTIMACION: el ISR real depende de deducciones exactas, acreditamientos y pagos provisionales. Informativo, no asesoria fiscal.
| Name | Required | Description | Default |
|---|---|---|---|
| regimen | Yes | Regimen fiscal. | |
| ingresos | Yes | Ingresos anuales, en pesos. | |
| deducciones | No | Opcional. Deducciones anuales (no aplica a RESICO PF). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so no destructive actions. The description adds valuable context: it is an estimate dependent on exact deductions and payments, and is informative only. This goes beyond the annotations to clarify limitations and legal basis.
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, front-loaded with the primary function, followed by a clarifying limitation. Every word adds value, no redundancy. It is appropriately sized for the tool's simplicity.
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 no output schema, the description could mention what is returned (estimated amount). However, the tool is a simple estimator and the description implies a numeric result. With full schema coverage and annotations, it is largely complete, lacking only explicit output description.
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 meaning by noting that deductions do not apply for RESICO PF, and it mentions 'ingresos y deducciones' aligning with schema. This extra detail about parameter applicability enhances 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 estimates annual ISR based on regime, income, and deductions, using specific legal references (Art. 152, Anexo 8 RMF 2026). The verb 'ESTIMA' and resource 'ISR anual' are specific, and the description implicitly distinguishes from siblings like fiscal_isr_retencion which deals with 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?
The description explains the tool is an estimate and not tax advice, implying it should not be used for final calculations. However, it does not explicitly state when to use this tool versus alternatives (e.g., fiscal_isr_retencion for withholding), nor does it mention prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
fiscal_isr_retencionACalcula la retencion MENSUAL de ISR de salarios (Art. 96 LISR) menos el subsidio al empleo vigente (DOF 2025). Determinista. Devuelve ISR de tarifa, subsidio aplicado y retencion final. Informativo, no asesoria fiscal.
| Name | Required | Description | Default |
|---|---|---|---|
| ingreso_gravado | Yes | Ingreso gravado del mes (base de retencion), en pesos. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false. The description adds value by stating the tool is deterministic, listing the returned values (ISR tariff, subsidy, final withholding), and including a disclaimer ('Informativo, no asesoria fiscal'). 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 concise, front-loaded with the main action, and every sentence adds value: calculation type, legal basis, determinism, output, and disclaimer. No wasted 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?
The tool has a simple input (one number) and no output schema. The description adequately explains the output (three values) and provides legal context and a disclaimer, making it complete for an AI agent to use 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?
Schema description coverage is 100%, providing complete parameter semantics. The description does not add additional meaning beyond what the schema already provides, so the baseline score of 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 that the tool calculates the monthly ISR withholding on salaries (Art. 96 LISR) minus the current employment subsidy, and returns three specific values. It distinguishes from siblings like fiscal_isr_estimado by specifying 'MENSUAL' and 'salarios'.
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 specifying monthly salary withholding, but does not explicitly list when not to use or provide alternatives among siblings. The context is clear but lacks explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
fiscal_recargosACalcula recargos por mora + actualizacion por pago tardio de una contribucion en Mexico (CFF Art. 17-A y 21). Determinista y auditable. Los meses se cuentan dia-a-dia desde el vencimiento (cada fraccion = mes completo). Si no se dan los INPC, el total NO incluye actualizacion y sera mayor. Informativo, no asesoria fiscal.
| Name | Required | Description | Default |
|---|---|---|---|
| monto | Yes | Monto original del adeudo, en pesos. | |
| inpc_den | No | Opcional. INPC del mes anterior al de vencimiento (denominador). | |
| inpc_num | No | Opcional. INPC del mes anterior al de pago (numerador, CFF 17-A). | |
| fecha_pago | Yes | Fecha en que se paga, YYYY-MM-DD. | |
| fecha_venc | Yes | Fecha limite de pago, YYYY-MM-DD. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds significant behavioral context beyond the annotations (readOnlyHint=true): it explicitly states the tool is deterministic and auditable, explains the day-by-day month counting, and clarifies the effect of missing INPC parameters. 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 concise, consisting of three sentences that are front-loaded with the main purpose. Each sentence adds value: purpose first, then behavioral details, then a disclaimer. No redundant or extraneous text.
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?
The tool has 5 parameters with thorough schema descriptions and the description adds operational context. However, since there is no output schema, the description could have mentioned the return format (e.g., total amount, breakdown). Despite this minor gap, the description is fairly complete for a calculation tool with clear inputs.
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 100% coverage with descriptions, but the tool description adds additional meaning: it explains the month-counting rule (cada fraccion = mes completo), specifies the optionality and impact of INPC parameters, and clarifies that the amount is in pesos. This enriches the semantic understanding 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 identifies the tool as calculating late payment surcharges for Mexican contributions, referencing specific legal articles (CFF Art. 17-A y 21). This specific verb+resource combination distinguishes it from sibling tools like fiscal_imss or fiscal_isr_retencion, which handle different fiscal 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 provides clear context: it's deterministic, auditable, and explains the month-counting method. It also states the condition about INPC parameters. However, it lacks explicit guidance on when to prefer this tool over siblings or when not to use it (e.g., if not in Mexico).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
fiscal_regimen_factoresADevuelve los FACTORES para elegir regimen fiscal en Mexico (topes de ingreso, base gravable, tasas, exclusiones) segun tipo de persona, ingresos anuales y actividad. INFORMA, NO DECIDE: nunca recomienda un regimen; la eleccion es del contribuyente con su contador. Informativo, no asesoria fiscal.
| Name | Required | Description | Default |
|---|---|---|---|
| actividad | No | Opcional. Actividad principal (PF). | |
| tipo_persona | Yes | Tipo de contribuyente. | |
| ingresos_anuales | Yes | Ingresos anuales estimados, en pesos. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool as read-only. The description goes further by emphasizing it never recommends a regime and is purely informative, which reinforces the read-only nature and adds context about the tool's limitations. 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, with two clear sentences front-loaded with the main purpose. It avoids repetition or extraneous details, making it efficient for an AI agent to parse.
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 3 parameters and no output schema, the description adequately explains what it returns (factors) and its non-decision-making nature. It provides sufficient context for the agent to understand the tool's role, though a brief mention of the response structure could enhance 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 description coverage is 100%, so baseline is 3. The description does not add new meaning beyond the schema; it merely restates the parameters (tipo_persona, ingresos_anuales, actividad). It aligns with schema content without enhancing 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 states the tool returns factors for choosing a fiscal regime in Mexico, listing specific types of factors (income limits, taxable base, rates, exclusions). It distinguishes itself from sibling tools like fiscal_isr_estimado or fiscal_calendario by focusing on regime selection rather than specific 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 implies the tool is for informational purposes and not for decision-making, but it does not explicitly guide when to use this tool over alternatives. Given sibling tools like fiscal_isr_retencion and fiscal_recargos, explicit usage guidance could improve differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
fiscal_valores_vigentesADevuelve los valores fiscales vigentes verificados de Mexico para un anio (UMA, salario minimo, tasas de recargo y parcialidades), cada uno con su fuente oficial. Es el 'moat': datos mantenidos y verificados contra DOF/LIF/CFF. Informativo, no asesoria fiscal.
| Name | Required | Description | Default |
|---|---|---|---|
| anio | No | Anio fiscal. Default: el mas reciente cargado. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true. The description adds value by explaining the data is 'mantenidos y verificados contra DOF/LIF/CFF' and that it is non-advisory ('Informativo, no asesoria fiscal'). 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?
Two sentences with the main action front-loaded. The 'moat' metaphor adds character but is not excessive. Generally concise and to the point.
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?
Without an output schema, the description lists the returned values (UMA, salario minimo, tasas) and notes their official sources. This is sufficient for a simple read tool with one optional parameter.
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 a clear description for the single parameter 'anio' (default: most recent). The description does not add further parameter details, 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?
The description clearly states the verb 'Devuelve' (returns) and the specific resource 'valores fiscales vigentes verificados de Mexico'. It lists the exact items returned (UMA, salario minimo, tasas) and distinguishes from siblings by positioning itself as the 'moat' of verified data.
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 the tool is for informational reference ('Informativo, no asesoria fiscal') but does not explicitly state when to use it versus alternatives. No exclusions or comparisons to sibling tools are provided.
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!