Calculo laboral mexicano (LFT) con desglose, fundamento y deslinde: concepto 'aguinaldo', 'prima_vacacional' o 'finiquito'. Cuesta LABORAL. Es resultado matematico, no resolucion oficial; cada respuesta declara con que tabla/version se calculo.
| Name | Required | Description | Default |
|---|---|---|---|
| concepto | Yes | ||
| fecha_baja | No | ||
| fecha_ingreso | No | ||
| dias_aguinaldo | No | ||
| salario_diario | No | ||
| dias_trabajados | No | ||
| anios_antiguedad | No | ||
| incluir_indemnizacion | No | ||
| dias_pendientes_salario | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No hay anotaciones, por lo que la descripción carga toda la responsabilidad. Revela que la operación tiene un costo ('Cuesta LABORAL'), que el resultado es matemático y no una resolución oficial, y que cada respuesta declara la tabla/versión usada. Son datos conductuales importantes para que el agente gestione expectativas y no presente el resultado como oficial.
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?
La descripción es una sola oración densa que pone al inicio el propósito y los conceptos válidos, luego agrega costo, deslinde y transparencia de versión. Es compacta y cada segmento aporta información, pero el encadenamiento con punto y coma la hace ligeramente difícil de parsear. Podría estructurarse mejor en frases separadas.
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?
No hay esquema de salida, y la descripción menciona que la respuesta incluye desglose, fundamento y deslinde, lo cual ayuda. Pero con 9 parámetros y 0% de cobertura, no se explica qué parámetros aplican a cada concepto ni la estructura exacta del resultado. El agente puede no saber cuándo completar opciones como incluir_indemnizacion o dias_pendientes_salario, lo que deja brechas claras para una herramienta de cálculo con costo.
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?
La cobertura del esquema es 0% y la descripción solo aclara el parámetro 'concepto' enumerando sus tres valores válidos. Los otros 8 parámetros (fecha_ingreso, salario_diario, dias_pendientes_salario, etc.) quedan sin explicación, forzando al agente a depender de los títulos y valores por defecto. Esto no compensa suficientemente la falta de descripciones en el esquema.
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?
La descripción usa un verbo específico ('Calculo') e identifica el recurso exacto: cálculo laboral mexicano bajo LFT, con los conceptos 'aguinaldo', 'prima_vacacional' y 'finiquito'. Esto la distingue claramente de herramientas hermanas como calcular_imss o calcular_isr, que apuntan a otros ámbitos.
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?
El texto delimita el uso a tres conceptos laborales concretos, lo que le dice a un agente cuándo invocarla. Sin embargo, no menciona explícitamente alternativas ni exclusions (por ejemplo, 'para IMSS use calcular_imss'), dejando esa diferenciación a la inferencia. El contexto es claro pero sin exclusiones explícitas.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Most tools fall into clear families such as validar_*, verificar_* and consultar_*, but there is semantic overlap among consultar_catalogo, catalogo_leyes and catalogo_servicios, and between acreditar_fondeo and verificar_pago since both process CEP XML. The descriptions usually clarify the intent, but an agent could still choose the wrong generic catalog or payment tool.
The dominant pattern is Spanish infinitive_noun, e.g. validar_rfc, verificar_empresa and consultar_saldo, but there are noticeable deviations such as catalogo_leyes, estado_servicio, tipo_cambio and verificacion_completa. The English-style screening_listas and screening_monitorear also break the Spanish verb pattern, making the naming readable but inconsistent.
With 30 tools, the server sits well above the recommended MCP range and will add significant context/selection overhead. The broad multi-domain scope explains some of the size, but several account/meta tools could be consolidated, and the overall surface feels heavier than ideal.
The core workflows are well covered: company/invoice/payment verification, legal search and lookup, fiscal calculations, identity validations, screening and constancy validation are all present. However, there are dead ends: crear_fondeo_x402 requires an out-of-band REST liquidation step, screening_monitorear has no management/removal counterpart, and registrar_obligacion has no list/delete tools.