160+ calculadoras fiscales, financieras, laborales y de salud en español. Cubre IRPF, autónomos, hipotecas, sucesiones, nóminas, inversiones, IMC y más. Compatible con Claude Desktop, Cursor, Windsurf. Gratuito, sin registro ni API key.
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 42 of 42 tools scored.
Each tool targets a very specific calculator or conversion task with no overlap. Even within similar domains (e.g., running-related tools like calcular_pace_running and calcular_prediccion_running), the purposes are distinct (pace vs. race time prediction). An agent can easily select the correct tool.
All tool names follow a clear verb_noun pattern in snake_case, with most using 'calcular_' for calculations. Variations like 'convertir_', 'consultar_', 'escalar_', and 'recomendar_' are consistent within their functional groups, making the naming predictable and logical.
With 42 tools, the server is far beyond the typical 3-15 range for a coherent set. Although each tool is individually useful, the massive count and extremely broad scope (fitness, photography, cooking, finance, etc.) make the surface feel like a collection of utilities rather than a focused tool set. This undermines coherence.
Within the domain of general-purpose calculators and converters, the server covers a wide range of topics thoroughly. Most individual tools provide full functionality (e.g., IMC with categories, running predictors, etc.). Minor omissions (e.g., lack of a currency converter or generic equation solver) prevent a perfect score, but overall the surface is quite complete for its type.
calcular_1rm_gimnasioACalcula la repetición máxima (1RM) en cualquier ejercicio de fuerza usando las fórmulas Epley y Brzycki. Devuelve el 1RM estimado y una tabla de cargas de entrenamiento por porcentaje.
| Name | Required | Description | Default |
|---|---|---|---|
| peso_kg | Yes | Peso levantado en kilogramos | |
| repeticiones | Yes | Número de repeticiones completadas con ese peso (idealmente 1-12 para mayor precisión) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
La anotación readOnlyHint=true es consistente con la descripción que indica un cálculo. La descripción añade que utiliza las fórmulas Epley y Brzycki y devuelve una tabla de cargas, proporcionando contexto útil que no está en las anotaciones ni en el esquema.
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?
Dos oraciones concisas y frontales. Cada oración aporta información esencial: propósito, fórmulas usadas y salida. Sin redundancias ni palabras de relleno.
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?
Dado que no hay esquema de salida, la descripción describe correctamente la salida (1RM estimado y tabla de cargas). Para una calculadora simple con dos parámetros, la información es suficiente. Podría mencionar el rango de repeticiones válido, pero ya está en el esquema.
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 del 100%, por lo que la línea base es 3. La descripción no agrega significado adicional a los parámetros más allá de lo que ya está en las descripciones del 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?
El verbo 'calcula' y el recurso 'repetición máxima (1RM)' son claros y específicos. Se distingue fácilmente de los hermanos, que son otras calculadoras temáticas no relacionadas con la fuerza.
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?
La descripción indica que es para cualquier ejercicio de fuerza, pero no proporciona pautas sobre cuándo usarla frente a alternativas, ni menciona limitaciones de uso (ej. rango de repeticiones). No hay hermanos directos, pero podría mejorar con instrucciones explícitas.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
calcular_astrofoto_exposicionACalcula el tiempo máximo de exposición sin estelas de estrellas para astrofotografía. Usa la fórmula NPF (precisa, tiene en cuenta pixel pitch y declinación) y la regla 500/300. Evalúa si el tiempo elegido producirá estrellas puntuales, microestelas o star trails.
| Name | Required | Description | Default |
|---|---|---|---|
| sensor | Yes | Tipo de sensor: ff = Full Frame, apsc15 = APS-C Nikon/Sony (×1,5), apsc16 = APS-C Canon (×1,6), m43 = Micro 4/3 (×2,0) | |
| apertura | Yes | Apertura del diafragma en valor f (ej. 2.8 para f/2.8) | |
| focal_mm | Yes | Focal de la lente en milímetros (ej. 14 para un gran angular de 14mm) | |
| megapixeles | Yes | Resolución del sensor en megapíxeles (ej. 24 para 24 MP, 45 para 45 MP) | |
| tiempo_elegido_s | Yes | Tiempo de exposición que quieres evaluar, en segundos (ej. 20 para 20 segundos) | |
| declinacion_grados | Yes | Declinación de la zona del cielo en grados (0 = ecuador celeste, 90 = polo celeste). Para la Vía Láctea usa entre 0-30. Para Polaris usa ~89. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true, so the description's disclosure of calculation behavior is consistent and adds value by detailing the formulas and evaluation criteria. 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 two sentences long, front-loaded with the main purpose, and each sentence provides essential information 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?
For a calculator with no output schema, the description explains what the tool evaluates (point stars, microstreaks, star trails) and the formulas used. It could specify the exact return format, but overall it is sufficiently complete given the tool's 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 the schema adequately describes each parameter. The description adds context about the formulas used but does not provide additional per-parameter semantics 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 clearly states it calculates maximum exposure time without star trails using NPF and 500/300 rules, and evaluates a chosen exposure. It specifically targets astrophotography and distinguishes from sibling calculators, which are unrelated.
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?
While the description explains what the tool does, it does not provide explicit guidance on when to use it over alternatives like calcular_exposicion_equivalente. Usage context is implied but not stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
calcular_bitrate_videoAEstima el bitrate necesario y el tamaño de archivo de un vídeo según resolución, fps, duración y códec. Incluye comparativa entre H.264, H.265, ProRes 422 y RAW.
| Name | Required | Description | Default |
|---|---|---|---|
| fps | Yes | Frame rate (ej. 24, 30, 60, 120) | |
| codec | No | Códec de vídeo. Por defecto h264 | |
| resolucion | Yes | Resolución del vídeo | |
| duracion_min | Yes | Duración del vídeo en minutos |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations include readOnlyHint=true, indicating safe read operation. The description adds value by mentioning the comparative aspect among codecs, which is behavioral context beyond the annotation.
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, no fluff, front-loaded with the core purpose. Every phrase earns its place.
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 calculation tool with no output schema, the description adequately explains inputs and that outputs include bitrate, file size, and comparison. Could mention estimation nature or accuracy assumptions, but 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?
With 100% schema description coverage, the baseline is 3. The description reiterates parameters (resolución, fps, duración, códec) and adds the concept of 'comparativa', but does not significantly enhance 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 clearly states the tool estimates bitrate and file size based on resolution, fps, duration, and codec, including a comparison. This verb+resource combination is specific and distinguishes it from sibling calculator 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 what the tool does but provides no explicit guidance on when to use it versus alternatives, such as other video-related calculators. There are no exclusions or contextual tips.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
calcular_breakeven_electricoACalcula el año en que un coche eléctrico empieza a ser más barato que uno de gasolina equivalente (punto de equilibrio). Necesita los precios de ambos coches y los km anuales. Opcionales: subsidio MOVES III (0/4500/7000€), consumos, precio luz y gasolina, coste cargador. Devuelve año de break-even, ahorro anual estimado, inversión neta extra y coste por km de cada opción.
| Name | Required | Description | Default |
|---|---|---|---|
| kmAnuales | Yes | Kilómetros que se conducen al año (ej: 15000) | |
| precioLuz | No | Precio de la electricidad doméstica en €/kWh. Por defecto: 0,18 | |
| costeCargador | No | Coste de instalación del cargador doméstico en euros. Por defecto: 800 | |
| subsidioMoves | No | Subsidio MOVES III aplicable: 0 (sin subsidio), 4500 (sin achatarramiento) o 7000 (con achatarramiento). Por defecto: 0 | |
| precioGasolina | Yes | Precio del coche de gasolina equivalente en euros (ej: 22000) | |
| consumoGasolina | No | Consumo del gasolina en L/100km. Por defecto: 7 | |
| precioElectrico | Yes | Precio del coche eléctrico en euros (ej: 32000) | |
| consumoElectrico | No | Consumo del eléctrico en kWh/100km. Por defecto: 16 | |
| precioGasolinaLitro | No | Precio de la gasolina en €/L. Por defecto: 1,65 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only behavior. The description goes beyond by detailing what outputs are produced (break-even year, savings, etc.) and mentions default values for optional parameters. It adds helpful context for a calculation tool.
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 efficiently covers purpose, required inputs, optional inputs, and outputs. It is front-loaded with the main purpose. Could be slightly more structured, but 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?
Given 9 parameters and no output schema, the description lists outputs but does not specify return format (e.g., numbers vs text) or underlying assumptions (like static prices). It is fairly complete but lacks some detail for parameter-rich tool.
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 9 parameters have descriptions in the schema, providing 100% coverage. The description repeats some but adds grouping (required vs optional). It does not add significant semantic detail beyond what the schema already provides.
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 specific verb 'Calcula' and the resource 'año en que un coche eléctrico empieza a ser más barato que uno de gasolina'. It distinguishes the tool from siblings like calcular_combustible and recomendar_vehiculo by focusing on the economic break-even point.
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 lists required and optional inputs, which guides usage, but it does not explicitly state when to use this tool over alternatives or when not to use it. It implies context but lacks direct exclusion or comparison with sibling calculators.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
calcular_camara_lentaACalcula el factor de ralentización de un vídeo slow motion a partir de los fps de grabación y reproducción. Devuelve el multiplicador (ej. 4×), el obturador correcto según la regla 180° y la duración del clip ralentizado.
| Name | Required | Description | Default |
|---|---|---|---|
| fps_grabacion | Yes | FPS a los que se graba (ej. 60, 120, 240, 960) | |
| fps_reproduccion | Yes | FPS a los que se reproducirá (ej. 24, 25, 30) | |
| duracion_grabacion_s | No | Duración del clip grabado en segundos. Opcional: si se indica, calcula la duración ralentizada |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description accurately describes a read-only calculation (consistent with readOnlyHint annotation) and discloses the 180° shutter rule. No hidden behaviors or side effects are implied. It adds context beyond annotations by mentioning the specific calculation method.
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 with no extraneous words. It front-loads the core purpose and immediately lists outputs. Every sentence serves a purpose.
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 simple calculation tool with 3 parameters (all documented) and no output schema, the description sufficiently covers what the agent needs: inputs, calculation, and outputs. It lacks details on error handling or edge cases, but these are not critical for a deterministic calculator.
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 the baseline is 3. The description adds minimal extra meaning: it confirms duration is used to compute final clip length, but this is already implied by the schema description. No deeper semantics are added.
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 slow-motion factor from recording and playback fps, listing outputs (multiplier, shutter, duration). It is specific and useful, but does not explicitly differentiate from sibling calculators like 'calcular_regla_180_video', which might offer overlapping functionality.
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 guidance is provided on when to use this tool versus alternatives. The description only states what it does, without indicating context, prerequisites, or exclusion criteria. Given many sibling calculator tools, this omission leaves the agent without decision support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
calcular_combustibleACalculadora de combustible con dos modos: (1) consumo: dado un trayecto real (km recorridos + litros gastados), calcula el consumo en L/100km, el coste por km y la autonomía con 50€. (2) viaje: dada la distancia de un trayecto y el consumo medio del vehículo, calcula los litros necesarios y el coste total del viaje.
| Name | Required | Description | Default |
|---|---|---|---|
| modo | Yes | consumo = calcular consumo real de un trayecto ya hecho | viaje = estimar coste de un trayecto futuro | |
| litros | No | (Modo consumo) Litros gastados en ese trayecto | |
| kilometros | No | (Modo consumo) Kilómetros recorridos en el trayecto de referencia | |
| distanciaKm | No | (Modo viaje) Distancia del trayecto en kilómetros | |
| consumoL100km | No | (Modo viaje) Consumo medio del vehículo en litros cada 100 km | |
| precioCombustible | Yes | Precio del combustible en €/litro (ej: 1.65 para 1,65 €/L) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, and the description aligns by describing pure calculations. It adds value by detailing the computed outputs for each mode (L/100km, cost per km, autonomy, liters needed, total cost), which is beyond what annotations convey. 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 two sentences long, front-loads the mode summary, and wastes no words. Every sentence contributes 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?
Given 6 parameters, 2 required, and no output schema, the description sufficiently covers the two modes and what each computes. It could hint at the output format (e.g., returning numbers), but the calculator nature makes it reasonable. Overall complete for its 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% with descriptions for all 6 parameters. The description adds context by explaining the two modes and their associated parameters (litros+kilometros for consumo, distanciaKm+consumoL100km for viaje), but does not add substantial meaning beyond the schema's own 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?
The description clearly states it's a fuel calculator with two distinct modes (consumption and trip), and its verb 'calcular' combined with 'combustible' distinguishes it from sibling calculators like 'calcular_imc' or 'calcular_porcentaje'.
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 mode: consumption for a real trip already taken, trip for estimating a future trip. It provides clear context but does not explicitly state when not to use this tool or mention alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
calcular_dia_semanaADice qué día de la semana (lunes, martes...) cae una fecha concreta. Indica también si es hoy, ayer, mañana o cuántos días faltan/han pasado.
| Name | Required | Description | Default |
|---|---|---|---|
| fecha | Yes | Fecha a consultar en formato YYYY-MM-DD o "hoy" |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations provide readOnlyHint=true, and the description adds that the tool returns day of week and relative time context. This goes beyond annotations by detailing the output type and scope. 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 two sentences, front-loaded with the core purpose, and concisely adds extra details without redundancy. Every part is useful.
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 adequately explains the return values (day of week + relative info). It is complete for a simple read-only date tool, though may lack exact formatting details.
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%, and the parameter 'fecha' is already described in the schema. The description does not add additional meaning beyond what the schema provides, so it meets the baseline.
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 day of the week for a given date and also provides relative information (today, yesterday, etc.). This distinguishes it from sibling tools like calcular_diferencia_fechas (date difference) and calcular_fecha_resultado (result date).
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 usage for finding the day of the week or relative date info, but does not explicitly state when to use this tool over alternatives or provide any exclusions. Given the presence of sibling tools, some guidance would be helpful.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
calcular_diferencia_fechasACalcula cuánto tiempo hay entre dos fechas: días totales, semanas, meses y desglose exacto en años/meses/días. Útil para plazos, antigüedad, tiempo transcurrido o tiempo restante hasta un evento.
| Name | Required | Description | Default |
|---|---|---|---|
| fechaFin | Yes | Fecha final en formato YYYY-MM-DD o "hoy" | |
| fechaInicio | Yes | Fecha inicial en formato YYYY-MM-DD o "hoy" |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the types of outputs (days, weeks, months, years/months/days) and mentions the 'hoy' input option. Annotations already indicate readOnlyHint=true, so the description adds value by specifying the calculation scope and input flexibility.
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 efficiently convey purpose, output details, and use cases. No extraneous text; 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?
Despite no output schema, the description fully explains what the tool returns (days, weeks, months, exact breakdown). It covers input format and 'hoy' special value. All necessary information is present.
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 clear descriptions for both parameters (fechaInicio, fechaFin). The description does not add meaning beyond what the schema already provides; it only restates the concept of two dates.
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 time difference between two dates, listing specific outputs (days, weeks, months, exact breakdown). It distinguishes itself from sibling tools like 'calcular_edad' and 'calcular_dia_semana' by focusing on date ranges.
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 context on when to use the tool: 'Útil para plazos, antigüedad, tiempo transcurrido o tiempo restante hasta un evento.' It does not explicitly exclude cases or name alternatives, but the use cases are clear and relevant.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
calcular_edadACalcula la edad exacta en años, meses y días a partir de una fecha de nacimiento. Indica también el total de días vividos y cuándo es el próximo cumpleaños.
| Name | Required | Description | Default |
|---|---|---|---|
| fechaNacimiento | Yes | Fecha de nacimiento en formato YYYY-MM-DD (ej: 1990-05-15) | |
| fechaReferencia | No | Fecha en la que calcular la edad en formato YYYY-MM-DD o "hoy". Por defecto hoy. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, indicating no side effects. The description adds behavioral context by specifying the computed outputs (total days lived, next birthday) beyond mere reading. This enriches the agent's understanding of what the tool returns.
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 purpose. Every word adds value; there is no redundancy or fluff. It is concise yet informative.
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 lack of an output schema, the description adequately outlines expected return values (years, months, days, total days, next birthday). It covers both input parameters implicitly. However, edge cases (e.g., invalid dates, future birth dates) are not addressed, which slightly limits 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 both parameters having clear descriptions in the schema (format and default). The description adds no additional parameter semantics beyond referencing 'fecha de nacimiento'. Baseline 3 is appropriate as the description does not enhance or expand on 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 uses a specific verb ('calcula') and clearly identifies the resource ('edad exacta en años, meses y días'), along with additional outputs. It distinguishes itself from sibling tools like calcular_diferencia_fechas by focusing specifically on age calculation from a birth date.
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 usage for calculating age from a birth date but provides no explicit guidance on when to use this tool versus alternatives (e.g., calcular_diferencia_fechas for date difference, convertir_edad_mascota for pet age). No exclusion criteria 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.
calcular_estadisticasACalcula los principales descriptores estadísticos de un conjunto de datos numéricos: media, mediana, moda, varianza, desviación típica, percentiles (Q1/Q2/Q3), rango intercuartílico, coeficiente de variación y asimetría de Fisher. Muy útil para analizar rendimientos de inversiones, precios, gastos, ingresos, etc. Encadenable con cualquier tool que devuelva series de valores numéricos. Ideal para: "Analiza estas rentabilidades mensuales de mi cartera: [2.3, -1.1, 3.4, ...]"
| Name | Required | Description | Default |
|---|---|---|---|
| nombre | No | Nombre descriptivo del conjunto de datos (ej: "Rendimientos cartera 2024"). | |
| valores | Yes | Lista de valores numéricos a analizar (mínimo 2, máximo 1.000). Ejemplos: rendimientos mensuales, precios, gastos. | |
| decimales | No | Número de decimales para los resultados. Por defecto 4. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true, so the description does not need to state safety. It adds behavioral context by listing exactly which statistics will be computed. However, it does not mention any permissions, rate limits, or edge cases (e.g., behavior with NaN or extreme values).
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 core purpose and lists statistics, followed by usage examples. It is efficient and avoids redundancy, though it could be slightly more structured (e.g., bullet points for statistics).
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 the tool's purpose, output statistics, usage scenarios, and chainability. With no output schema, listing the computed statistics is sufficient. The description is complete for this tool's complexity and rich annotations.
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 no additional meaning to parameters beyond the schema; it reiterates that 'valores' is a list of numbers but does not provide extra syntax or formatting details.
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 principal statistical descriptors of numerical datasets, listing many specific metrics (media, mediana, etc.). It distinguishes from sibling calculators by focusing on statistical analysis of numerical data, as opposed to other 'calcular_' tools for specific domains.
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 explicit usage context: useful for analyzing returns, prices, expenses, and chainable with any tool returning numerical series. It includes an example query. However, it does not explicitly state when NOT to use it or mention alternatives among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
calcular_exposicion_equivalenteACalcula exposiciones fotográficas equivalentes variando uno de los tres parámetros del triángulo de exposición (ISO, apertura o velocidad de obturación) manteniendo el mismo valor de exposición (EV). Útil para adaptar la exposición a trípode, movimiento, ruido o bokeh sin cambiar la luz registrada.
| Name | Required | Description | Default |
|---|---|---|---|
| iso_base | Yes | ISO de la exposición original (ej. 100, 400, 1600, 3200) | |
| nuevo_valor | Yes | Nuevo valor del parámetro elegido, en las mismas unidades: ISO sin unidades (ej. 800), f-number para apertura (ej. 5.6), segundos para obturador (ej. 0.002) | |
| apertura_base | Yes | Apertura original en valor f (ej. 2.8 para f/2.8, 8 para f/8) | |
| parametro_fijo | Yes | Parámetro que cambias tú manualmente (el sistema ajusta los otros para mantener EV): iso = cambias el ISO, apertura = cambias el diafragma, obturador = cambias la velocidad | |
| obturador_base_s | Yes | Velocidad de obturación original en segundos (ej. 0.01 para 1/100s, 0.004 para 1/250s, 2 para 2 segundos) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true, so the description carries a lower burden. The description adds usage context but does not disclose any additional behavioral traits beyond being a read-only calculation. This is sufficient but not exceptional.
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. The first sentence defines the core functionality, and the second provides use cases. No wasted words, and the most important information is front-loaded.
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 required parameters and no output schema. The description explains the inputs and their relationship but does not specify the exact output format (e.g., what parameters are returned). Given the complexity, it is minimally adequate but could be more 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 detailed parameter descriptions. The description adds overall context about the exposure triangle and purpose, but each parameter is already well-described in the schema. 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 tool calculates equivalent photographic exposures by varying one of the three exposure triangle parameters (ISO, aperture, shutter speed) while maintaining the same EV. It also mentions specific use cases (tripod, motion, noise, bokeh), which is specific and distinguishes it from the sibling calculator 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 provides context on when to use the tool: to adapt exposure for tripod, motion, noise, or bokeh without changing light. It does not explicitly exclude scenarios, but given the sibling tools are all different calculators, this is clear and adequate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
calcular_fecha_resultadoASuma o resta días, semanas, meses o años a una fecha para obtener otra fecha. Útil para calcular plazos, vencimientos, fechas futuras o pasadas.
| Name | Required | Description | Default |
|---|---|---|---|
| unidad | Yes | Unidad de tiempo: dias, semanas, meses o anios | |
| cantidad | Yes | Número de unidades a sumar o restar | |
| fechaBase | Yes | Fecha de partida en formato YYYY-MM-DD o "hoy" | |
| operacion | Yes | "sumar" para obtener una fecha futura, "restar" para una fecha pasada |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=true, which the description aligns with (pure calculation). However, the description does not add behavioral details beyond the annotation, such as error handling or edge cases.
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 clear sentences that efficiently convey the core functionality with no fluff. Could be slightly more structured, but adequate.
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?
Missing return value description (likely a date string) is a gap, especially with no output schema. The tool has 4 params and the description is too brief for full context.
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 does not add additional meaning beyond the schema; it merely summarizes the operation.
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 explicitly states it adds or subtracts days, weeks, months, or years to a date, clearly distinguishing it from siblings like 'calcular_diferencia_fechas' and 'calcular_dia_semana'.
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 context for deadlines and expirations, but does not explicitly state when to avoid this tool or compare with alternatives like 'calcular_diferencia_fechas'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
calcular_filtro_nd_videoACalcula qué filtro ND necesitas para cumplir la regla de los 180° en exteriores. Introduce el frame rate y la velocidad de obturación actual para obtener las paradas exactas y el filtro recomendado de la gama ND2–ND1000.
| Name | Required | Description | Default |
|---|---|---|---|
| fps | Yes | Frame rate de grabación (ej. 25, 30, 60) | |
| obturador_actual_s | Yes | Velocidad de obturación actual en segundos (ej. 0.002 para 1/500, 0.004 para 1/250) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, indicating a safe read operation. The description adds context (outdoor use, 180° rule) and is consistent with read-only behavior. No additional behavioral traits are needed.
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 sentences with no wasted words. Key information is front-loaded: purpose and required inputs are immediately clear.
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 simple calculator with two parameters and no output schema, the description adequately covers purpose, inputs, and expected output (stops and recommended filter). It is sufficiently complete for a tool of 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 documentation covers both parameters (100% coverage). The description adds meaning by explaining their role in the 180° rule and providing examples (e.g., '0.002 para 1/500').
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 ND filter needed for the 180-degree rule in outdoor video, using specific verbs like 'Calcula' and specifying the resource. It distinguishes from sibling tools like calcular_regla_180_video by focusing on ND filter selection.
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 tells users to input frame rate and shutter speed to get exact stops and recommended ND filter. It provides clear context (outdoor 180° rule) but does not explicitly mention when not to use it or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
calcular_fov_videoACalcula el ángulo de campo (FOV) horizontal, vertical y diagonal para una focal y sensor dados. Incluye comparativa entre Full Frame, APS-C y Micro 4/3 con el focal equivalente en 35mm.
| Name | Required | Description | Default |
|---|---|---|---|
| sensor | No | Tipo de sensor: ff = Full Frame, apsc15 = APS-C Nikon/Sony, apsc16 = APS-C Canon, m43 = Micro 4/3. Por defecto ff | |
| focal_mm | Yes | Focal del objetivo en milímetros (ej. 24, 35, 50, 85) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint: true, so the description need not reiterate safety. It adds value by specifying that it includes sensor comparisons and equivalent focal lengths, which are behavioral traits beyond the annotation.
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 sentences with no wasted words. Every sentence adds value: first states the core function, second states the extended feature (comparison). Perfectly front-loaded.
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 moderate complexity (2 params, no output schema, but clear calculation), the description explains the output (FOV angles, comparison). It could specify if results are in degrees, but it's sufficient for an agent to infer correct 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%, so the schema already documents parameters. The description adds examples (ej. 24, 35) and explains sensor enums, but this adds only marginal meaning beyond the schema. 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 it calculates horizontal, vertical, and diagonal FOV for given focal and sensor, and includes sensor comparison and equivalent focal. The verb 'Calcula' and resource 'ángulo de campo' are specific, and it distinguishes from other 'calcular' tools by its unique function.
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 FOV calculation but does not provide explicit guidance on when to use this tool versus alternatives, nor does it mention exclusions or prerequisites. Usage is only inferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
calcular_ganacheACalcula las proporciones exactas de chocolate y nata para un ganache según el tipo de chocolate (negro extra/negro/semi-fondant/con leche/blanco) y la textura deseada (glaseado/trufa/firme). El ratio se ajusta automáticamente al porcentaje de cacao.
| Name | Required | Description | Default |
|---|---|---|---|
| textura | No | glaseado: fluido para tartas/eclairs | trufa: para bolear trufas y rellenar bombones | firme: muy denso para modelar. Por defecto trufa. | |
| total_g | No | Gramos totales de ganache a preparar. Por defecto 200g. | |
| tipo_chocolate | No | negro_extra >70% | negro 55-70% | semi_fondant 40-55% | con_leche 28-40% | blanco 0% cacao. Por defecto negro. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already signals no side effects. The description adds that the ratio adjusts automatically to cacao percentage, providing some behavioral context. However, it does not disclose default behaviors or output format beyond 'proporciones exactas'.
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 sentences that front-load the core purpose and immediately follow with the crucial automatic adjustment behavior. No redundant or extraneous information.
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 simple calculator with three parameters and no output schema, the description is adequate but could be slightly more complete by specifying the output format (e.g., 'proporciones en gramos') or clarifying the result type. Still, it covers the essential purpose and 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?
Schema description coverage is 100%, with each parameter already having detailed descriptions including defaults and cacao ranges. The tool description restates the parameter choices but adds minimal new meaning beyond summarizing 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 clearly states the verb ('Calcula las proporciones exactas') and the resource (ganache). It specifies the input factors (chocolate type and texture) and distinguishes this tool from sibling calculators by being specific to ganache.
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 usage for ganache proportion calculations via its specific input parameters, but does not provide explicit when-to-use or when-not-to-use guidance, nor does it mention alternatives among the many sibling calculator tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
calcular_gasto_energeticoACalcula el consumo eléctrico mensual del hogar y la factura estimada. A partir de los electrodomésticos (potencia, horas de uso, días al mes) calcula los kWh totales y desglosa la factura con todos los conceptos: coste de energía, término de potencia, impuesto eléctrico (5.113%) e IVA (21%).
| Name | Required | Description | Default |
|---|---|---|---|
| preciokWh | No | Precio del kWh en euros. Por defecto 0.15 €/kWh (mercado libre orientativo). PVPC media ~0.13 €/kWh. | |
| electrodomesticos | Yes | Lista de electrodomésticos con su potencia y uso | |
| potenciaContratadaKW | No | Potencia contratada en kW. Habitual: 3.45, 4.6, 5.75, 6.9, 8.05 kW. Por defecto 4.6 kW. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, so the tool is read-only. The description adds context about the calculation breakdown (kWh total, concepts like impuesto eléctrico and IVA), which goes beyond the annotation. There is 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?
Two sentences, no fluff. First sentence states the primary purpose; second sentence details the calculation and output. Every word earns its place.
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 the tool's purpose, inputs (implied), and output breakdown. While no output schema exists, the description sufficiently explains what the tool returns. Annotations confirm read-only behavior. Slight gap: exact output format is not specified, but acceptable for a calculator tool.
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 parameters are already documented. The description adds meaning by stating the bill includes specific concepts (coste de energía, término de potencia, impuesto eléctrico 5.113%, IVA 21%), which clarifies the output beyond what the schema covers.
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 monthly household electricity consumption and estimated bill. The verb 'Calcula' and resource 'consumo eléctrico mensual' are specific. The tool is well-differentiated from siblings (many other calculators) by its focus on household energy billing.
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 usage for household electricity billing but lacks explicit guidance on when to use this tool versus alternatives. No exclusions or alternative tool references are provided, though the name and context make the purpose clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
calcular_hidratacion_panACalcula la hidratación de una masa de pan o los gramos de agua necesarios para una hidratación objetivo. Bidireccional: agua→% o %→agua. Clasifica la hidratación y da ejemplos de panes típicos.
| Name | Required | Description | Default |
|---|---|---|---|
| modo | No | calcular_porcentaje: da harina_g + agua_g → devuelve %. calcular_agua: da harina_g + hidratacion_pct → devuelve gramos de agua. Por defecto calcular_porcentaje. | |
| agua_g | No | Gramos de agua. Requerido si modo=calcular_porcentaje. | |
| harina_g | Yes | Peso de la harina en gramos. | |
| hidratacion_pct | No | Porcentaje de hidratación objetivo. Requerido si modo=calcular_agua. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide readOnlyHint=true, already indicating safe read operation. Description adds value by disclosing bidirectional behavior (agua→% or %→agua) and that it classifies hydration and provides example breads. 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 efficiently cover core functionality and additional features (bidirectional, classification, examples). Front-loaded with main purpose, no redundant 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?
Given no output schema, description provides sufficient context: what inputs are needed, what output to expect (hydration percentage or water grams), plus classification and examples. Lacks specifics on classification thresholds or error handling, but adequate for a simple calculator tool.
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. Description mentions bidirectional modes, which aligns with the 'modo' parameter's enum descriptions. Does not add novel semantics beyond what schema already provides for each parameter.
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 bread dough hydration, either from water to percentage or percentage to water. Uses specific verb 'Calcula' and resource 'hidratación de pan'. Distinguishes from sibling 'calcular_porcentaje_panadero' by focusing on bread hydration and bidirectional functionality.
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?
Description implies usage for bread hydration calculations (e.g., when adjusting water or flour), but does not explicitly state when to avoid or recommend alternatives. No direct comparison to related siblings like 'calcular_porcentaje_panadero'. Context is clear but lacks explicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
calcular_imcACalcula el Índice de Masa Corporal (IMC) a partir del peso y la altura. Devuelve la categoría (normopeso, sobrepeso, obesidad...), el rango de peso saludable y cuántos kg faltan o sobran para alcanzarlo. ⚕️ Herramienta orientativa — no reemplaza valoración médica.
| Name | Required | Description | Default |
|---|---|---|---|
| pesoKg | Yes | Peso en kilogramos (ej: 75) | |
| alturaCm | Yes | Altura en centímetros (ej: 175) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, and the description adds a disclaimer about medical use, reinforcing safe behavior. 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?
Three sentences, no redundancy. Includes emoji for readability and disclaimer. 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?
Despite lacking an output schema, the description mentions return values (category, healthy range, deviation). Sufficient for a simple calculation tool with read-only intent.
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?
Input schema covers 100% of parameters with detailed descriptions and examples. The description adds minimal extra meaning beyond the schema (e.g., example values). 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 it calculates BMI from weight and height, returns category and healthy range. The verb 'calcula' and resource 'Índice de Masa Corporal' are specific and distinct from sibling tools which cover different domains.
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 says it's orientative and does not replace medical evaluation, which guides appropriate use. However, it doesn't specify when to use versus alternative tools or exclude specific populations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
calcular_inflacionACalcula el equivalente en poder adquisitivo de una cantidad monetaria entre dos años cualquiera de la historia de España (1961-2025). Usa el IPC histórico del INE (base 2021 = 100) para determinar: el valor equivalente en el año destino, la inflación acumulada en el período y la inflación media anual (CAGR). Útil para comparar salarios, precios o inversiones entre épocas diferentes.
| Name | Required | Description | Default |
|---|---|---|---|
| cantidad | Yes | Cantidad monetaria en euros (o pesetas históricas, el resultado será proporcional) | |
| anoOrigen | Yes | Año de la cantidad original (1961-2025) | |
| anoDestino | Yes | Año al que se quiere convertir (1961-2025). Puede ser anterior al año origen para calcular hacia atrás. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only provide readOnlyHint=true. The description adds transparency by stating the data source (IPC histórico del INE base 2021=100) and the specific outputs (valor equivalente, inflación acumulada, inflación media anual). 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 two sentences, efficiently front-loading purpose and methodology. Every sentence adds 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?
Given full schema coverage and annotations indicating read-only, the description explains the outputs (equivalente, inflación acumulada, CAGR) and data source. No return value schema exists, but outputs are clearly described.
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 already clear parameter descriptions. The description adds little beyond restating the year range and mentioning 'o pesetas históricas', which is implied. 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 tool calculates the purchasing power equivalent of a monetary amount between two years in Spain (1961-2025), specifying the verb, resource, and scope. It distinguishes itself from sibling calculator tools by focusing on inflation adjustment.
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 context for when to use the tool ('Útil para comparar salarios, precios o inversiones entre épocas diferentes'), but does not explicitly exclude cases or compare with siblings. However, siblings are all distinct calculator tools, so no exclusion is necessary.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
calcular_kilometrajeACalcula la compensación o deducción fiscal por uso de vehículo propio en actividades económicas. Para empleados: exención IRPF hasta 0,26 €/km (RIRPF art. 9.B.2 — módulo AEAT 2025). Para autónomos: deducción en IRPF e IVA según exclusividad del uso del vehículo. Encadenable con calcular_irpf, calcular_cuota_autonomo, comparar_autonomo_vs_sl. Ideal para: "¿Cuánto me puedo deducir por usar el coche en el trabajo?" o "Mi empresa me paga 0,20€/km, ¿es correcto?"
| Name | Required | Description | Default |
|---|---|---|---|
| perfil | Yes | "empleado" = trabajador por cuenta ajena. "autonomo" = autónomo o profesional. | |
| costeRealPorKm | No | Coste real del vehículo por km (combustible, amortización, seguro, etc.) en euros. Por defecto 0,20 €/km. | |
| tipoMarginalIRPF | No | Tipo marginal IRPF para calcular el ahorro fiscal en porcentaje. Por defecto 30%. | |
| totalGastosVehiculo | No | Para autónomos: total de gastos del vehículo en el año (combustible, seguro, reparaciones, amortización) en euros. | |
| usoExclusivoActividad | No | Para autónomos: ¿el vehículo está afecto exclusivamente a la actividad? (difícil de acreditar para turismos). Por defecto false. | |
| kmProfesionalesAnuales | Yes | Kilómetros profesionales anuales (desplazamientos laborales o de la actividad económica). | |
| compensacionRecibidaPorKm | No | Para empleados: compensación que paga la empresa por km en euros. Por defecto 0. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds value beyond the readOnlyHint annotation by explaining the tax rules, rates, and conditions (e.g., exclusivity for autónomos). It clarifies that the tool performs calculations based on inputs, which is consistent with a read-only operation. No contradictions 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 paragraphs with front-loaded purpose and legal references. It is relatively concise but could be slightly more concise by removing the example queries or legal citations. Structure is good, with clear separation of employee vs. autónomo use cases.
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 adequately explains the tool's purpose and parameters but does not specify the output format (e.g., what values are returned). Given the complexity and lack of output schema, more detail on return values would improve completeness. Still, the description provides sufficient context for a calculation tool.
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 already fully documents all 7 parameters with descriptions (100% coverage). The description provides high-level context about rates and legal references but does not add new parameter-level details. Baseline of 3 is appropriate as the schema does the heavy lifting.
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 compensation or tax deduction for using a personal vehicle in economic activities, distinguishing between employees and autónomos. It provides specific legal references and example queries, making the purpose unequivocal and distinct from sibling 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 explicitly states when to use the tool (for compensation/deduction calculations) and gives example queries. It also mentions it can be chained with other tools like calcular_irpf, indicating when not to use it alone. Additionally, it distinguishes scenarios for employees vs. autónomos, providing clear usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
calcular_macrosACalcula las necesidades calóricas diarias y la distribución óptima de macronutrientes. Usa la fórmula Mifflin-St Jeor para la TMB (Tasa Metabólica Basal) y multiplica por el factor de actividad para obtener el TDEE. Ajusta las calorías según el objetivo (definición -500 kcal, mantenimiento 0, volumen +400 kcal) y distribuye en proteínas, carbohidratos y grasas. ⚠️ Orientativo — consultar con dietista-nutricionista titulado para planes personalizados.
| Name | Required | Description | Default |
|---|---|---|---|
| edad | Yes | Edad en años | |
| peso | Yes | Peso corporal en kilogramos | |
| sexo | Yes | Sexo biológico (determina la constante de la fórmula Mifflin-St Jeor) | |
| altura | Yes | Altura en centímetros | |
| objetivo | Yes | "definicion" (déficit -500 kcal, 30P/40C/30G%), "mantenimiento" (0 kcal, 25P/50C/25G%), "volumen" (superávit +400 kcal, 25P/50C/25G%) | |
| nivelActividad | Yes | "sedentario" (sin ejercicio), "ligero" (1-3 días/semana), "moderado" (3-5 días), "activo" (6-7 días), "muy_activo" (ejercicio intenso diario o 2x/día) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, and the description adds detailed behavioral context: the formula used (Mifflin-St Jeor), multiplication by activity factor for TDEE, calorie adjustments for goals, and macronutrient distribution percentages. 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?
Description is concise (5 sentences), front-loaded with the primary purpose, and efficiently structured: purpose, method, adjustments, disclaimer. No extraneous information.
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 6 required parameters and no output schema, the description explains the entire calculation process thoroughly. However, it doesn't specify the output format (e.g., calories, grams of protein/carbs/fat), which slightly 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 coverage is 100% with precise descriptions for all 6 parameters. The description adds overall methodology but does not enhance parameter meaning beyond what the schema provides. 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 daily caloric needs and optimal macronutrient distribution using a specific formula (Mifflin-St Jeor), distinguishing it from sibling calculators like 'calcular_gasto_energetico' which focus only on energy expenditure.
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 alternatives like 'calcular_imc' or 'calcular_gasto_energetico'. The disclaimer about consulting a dietitian is a safety note, not usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
calcular_mcd_mcmACalcula el Máximo Común Divisor (MCD) y el Mínimo Común Múltiplo (MCM) de dos o más números enteros positivos. Incluye: algoritmo de Euclides paso a paso (si son 2 números), factorización en números primos de cada número, factores del MCD (primos comunes con exponente mínimo) y del MCM (exponente máximo), y lista de todos los divisores comunes.
| Name | Required | Description | Default |
|---|---|---|---|
| numeros | Yes | Lista de 2 a 10 números enteros positivos. Ejemplo: [12, 18, 24] |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the computational steps and outputs (algorithm steps, factorization, lists of divisors), adding value beyond the readOnlyHint annotation. 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 and informative, though a slightly more structured format (e.g., bullet points) could improve readability. No unnecessary 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?
Given no output schema, the description adequately explains what results are provided (parameter coverage is 100%). The tool has low complexity, and the description covers the key output details.
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 schema already covers the parameter description fully (100% coverage). The tool description does not add extra meaning beyond stating what the tool does with the array.
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 computes MCD and MCM of positive integers, listing specific methods (Euclidean algorithm, factorization). It distinguishes the tool from siblings that compute other quantities.
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 when-to-use or when-not-to-use guidance is provided. However, the sibling context makes the tool's unique purpose clear, so the absence of guidelines is not critical.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
calcular_pace_runningACalcula el pace (ritmo por kilómetro), velocidad media, splits por km y proyecciones para 5K, 10K, media maratón y maratón a ese mismo ritmo.
| Name | Required | Description | Default |
|---|---|---|---|
| tiempo_s | Yes | Tiempo empleado en segundos (ej. 3000 para 50 minutos) | |
| distancia_km | Yes | Distancia recorrida en kilómetros (ej. 10 para un 10K) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only. The description adds value by listing the computed outputs (pace, speed, splits, projections), providing behavioral context beyond the annotation.
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 covering all outputs, efficient but slightly lengthy. Could be front-loaded with key outputs first.
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 output schema, the description adequately lists expected outputs (pace, speed, splits, projections). Units are implied but not explicitly stated.
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 clear parameter descriptions and examples. The tool description adds no additional parameter-specific information, 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 tool calculates pace, average speed, splits, and projections for standard running distances. The verb 'calcula' and specific resources are explicit.
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 alternatives like 'calcular_prediccion_running'. Usage is implied but not differentiated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
calcular_porcentajeARealiza cálculos con porcentajes. Cinco modos disponibles: (1) percentOf: ¿cuánto es el X% de Y?, (2) whatPercent: ¿qué % es X de Y?, (3) increase: aumentar X en Y%, (4) decrease: disminuir X en Y%, (5) variation: variación porcentual de X a Y.
| Name | Required | Description | Default |
|---|---|---|---|
| modo | Yes | Tipo de cálculo: percentOf = ¿cuánto es el X% de Y?, whatPercent = ¿qué % es X de Y?, increase = aumentar X en Y%, decrease = disminuir X en Y%, variation = variación porcentual de X a Y | |
| valor1 | Yes | Primer valor. Según el modo: percentOf → porcentaje (ej: 15 para 15%), whatPercent → cantidad parcial, increase/decrease → valor inicial, variation → valor inicial | |
| valor2 | Yes | Segundo valor. Según el modo: percentOf → cantidad base, whatPercent → cantidad total, increase/decrease → porcentaje a aplicar, variation → valor final |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description accurately indicates the tool performs calculations, consistent with the readOnlyHint annotation. It adds minimal behavioral context beyond the annotation, but there is 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 sentence that conveys the purpose and modes, but it is somewhat lengthy (65 words). It could be more concise or structured (e.g., using bullet points) for easier scanning.
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 calculation tool with three parameters and no output schema, the description adequately explains all modes and parameter roles. No critical information is missing.
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 covers 100% of parameters with descriptions. The tool description restates the modes but does not add additional semantic meaning beyond what the schema already provides. 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 tool performs percentage calculations with five distinct modes, each briefly explained. It effectively distinguishes from sibling tools (other calculators) by specifying its unique functionality.
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 lists five modes and their use cases, providing clear guidance on when to use each. However, it lacks explicit instructions on when not to use this tool or comparisons to alternatives, which would make it more comprehensive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
calcular_porcentaje_panaderoACalcula el porcentaje del panadero (baker's percentage) para una receta. La harina siempre es 100%; cada ingrediente se expresa como % de su peso. Detecta el agua automáticamente para calcular la hidratación.
| Name | Required | Description | Default |
|---|---|---|---|
| harina_g | Yes | Peso de la harina en gramos (siempre 100% en el sistema del panadero). | |
| ingredientes | Yes | Lista de ingredientes además de la harina. | |
| peso_porcion_g | No | Peso de cada pieza/porción en gramos. Opcional: calcula el número de porciones. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the agent knows the tool is read-only. The description adds the behavioral detail that water is automatically detected for hydration, which is helpful but not essential given the annotation coverage. 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, front-loaded with the core purpose, and each sentence adds value. Zero 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?
For a simple calculation tool with 3 parameters, no output schema, and good annotations, the description covers the main behavior (baker's percentage, hydration detection). It could mention that the result includes percentages and possibly number of portions if peso_porcion_g is provided, but it is still quite 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%, so each parameter is already described. The description adds context that harina_g is always the 100% base and that water detection happens automatically, but these are minor enhancements 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 clearly states it calculates baker's percentage, specifying that harina is always 100% and each ingredient is expressed as a percentage of flour weight. It also mentions automatic water detection for hydration, which distinguishes it from sibling tools like calcular_hidratacion_pan or escalar_receta.
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 calculating baker's percentages but does not explicitly state when to use this tool versus alternatives like calcular_hidratacion_pan (which focuses only on hydration) or escalar_receta (scaling). No exclusions 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.
calcular_potencia_ciclismoAAnaliza el rendimiento en ciclismo: ratio W/kg con nivel, 6 zonas de entrenamiento basadas en FTP y opcionalmente VAM (velocidad ascensional media) para subidas cronometradas.
| Name | Required | Description | Default |
|---|---|---|---|
| ftp_w | Yes | FTP (Functional Threshold Power) en vatios: potencia máxima sostenible durante 1 hora | |
| peso_kg | Yes | Peso del ciclista en kilogramos | |
| desnivel_m | No | Desnivel positivo de una subida en metros (para calcular VAM). Opcional | |
| tiempo_min | No | Tiempo empleado en subir ese desnivel en minutos (para calcular VAM). Opcional |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations include readOnlyHint=true, and the description does not contradict it. The description adds functional context (zones, VAM) beyond the annotation but does not detail any side effects, which is acceptable given read-only 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?
One sentence that covers the main point, though slightly lengthy. It is well-structured and front-loaded.
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 adequately explains the computed results (W/kg, zones, VAM). It sufficiently compensates for missing output schema for a calculation tool.
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 meaning by explaining how parameters relate to outputs (e.g., FTP used for zones, desnivel and tiempo for VAM).
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 uses the specific verb 'analiza' and resource 'rendimiento en ciclismo', detailing outputs like W/kg ratio, 6 training zones based on FTP, and optional VAM. It clearly distinguishes from sibling calculation 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 implies usage for cycling power analysis, and the tool name is self-explanatory. However, it lacks explicit when-not-to-use or alternative tool mentions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
calcular_prediccion_runningAPredice el tiempo de carrera en cualquier distancia usando la fórmula Riegel (T2 = T1 × (D2/D1)^1.06). Devuelve el tiempo estimado, pace, velocidad y predicciones estándar para 5K, 10K, media maratón y maratón.
| Name | Required | Description | Default |
|---|---|---|---|
| tiempo_base_s | Yes | Tiempo real en esa distancia en segundos (ej. 1500 para 25 minutos) | |
| distancia_base_km | Yes | Distancia de referencia conocida en kilómetros (ej. 5 para un 5K, 10 para un 10K) | |
| distancia_objetivo_km | Yes | Distancia para la que se quiere predecir el tiempo en kilómetros (ej. 42.195 para maratón) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds behavioral context beyond the readOnlyHint annotation by specifying the formula (Riegel) and the output items (time, pace, speed, standard predictions). 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 efficiently conveys the tool's purpose, formula, and outputs. No unnecessary words or 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?
Despite lacking an output schema, the description explicitly lists the return values (estimated time, pace, speed, standard predictions for 5K, 10K, half marathon, marathon). This fully informs the agent about what to expect.
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 three parameters are fully described in the schema with clear explanations (e.g., time in seconds, distances in km). The description adds the formula context but does not add significant meaning beyond the 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?
The description explicitly states it predicts race time using the Riegel formula, and returns estimated time, pace, speed, and standard predictions. This clearly distinguishes it from sibling tools like 'calcular_pace_running' which likely only calculates pace.
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 usage for predicting race times from a known distance, providing clear context. However, it does not explicitly state when not to use or mention alternatives, but the purpose is clear enough for the agent to infer appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
calcular_profundidad_campoACalcula la profundidad de campo (DoF) para una combinación de focal, apertura, distancia y tipo de sensor. Devuelve la distancia hiperfocal, los límites near/far de enfoque nítido y una clasificación del bokeh. Útil para saber cuánto fondo quedará desenfocado o qué apertura usar en paisaje para máxima nitidez.
| Name | Required | Description | Default |
|---|---|---|---|
| sensor | Yes | Tipo de sensor: ff = Full Frame (35mm), apsc15 = APS-C Nikon/Sony (factor ×1,5), apsc16 = APS-C Canon (factor ×1,6), m43 = Micro 4/3 (factor ×2,0) | |
| apertura | Yes | Apertura del diafragma en valor f (ej. 2.8 para f/2.8, 8 para f/8) | |
| focal_mm | Yes | Focal de la lente en milímetros (ej. 50 para un 50mm, 85 para un 85mm) | |
| distancia_m | Yes | Distancia de enfoque en metros (ej. 3 para 3 metros, 0.5 para 50 cm) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations set readOnlyHint=true, consistent with a calculation tool. Description and annotations align: no destructive actions, output is computed values. Description discloses returned fields (hyperfocal distance, near/far limits, bokeh classification) 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?
Two sentences, no redundant information. First sentence states operation and outputs; second sentence gives usage context. Efficient 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?
No output schema, but description lists returned values (hyperfocal distance, near/far limits, bokeh classification). Parameter count (4) and schema coverage are adequate. For a calculation tool, the description sufficiently informs the agent about inputs and outputs. Minor gap: no explicit indication of result format or units, but they are implied.
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 clear parameter descriptions (e.g., sensor enum explained). The tool description adds context by listing parameters in the first sentence but does not enhance understanding beyond what the schema already provides. Baseline 3 for high 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?
Description clearly states the tool calculates depth of field for given focal length, aperture, distance, and sensor type, specifying outputs (hyperfocal distance, near/far limits, bokeh classification). It uniquely distinguishes from sibling 'calcular' tools which cover different domains (fitness, cooking, etc.).
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?
Description provides practical use cases: determining background blur or aperture for landscapes. It implies when to use but does not explicitly mention when not to use or list alternatives. Given distinct sibling tools, no alternatives needed, but slight lack of exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
calcular_propinaACalcula la propina de una cuenta de restaurante y la divide entre varias personas. Conoce los porcentajes habituales de propina por país (España, EE. UU., Japón, etc.).
| Name | Required | Description | Default |
|---|---|---|---|
| pais | No | País para aplicar el porcentaje habitual. Valores válidos: espana, usa, reino_unido, alemania, francia, italia, japon | |
| monto | Yes | Importe total de la cuenta en euros (número positivo) | |
| personas | No | Número de personas entre las que dividir la cuenta. Por defecto 1. | |
| porcentaje | No | Porcentaje de propina a aplicar, por ejemplo 15 para 15%. Si no se indica, se usa el porcentaje habitual del país. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide readOnlyHint=true, meaning the tool is a pure computation with no side effects. The description adds that it 'knows' habitual percentages by country, which is useful behavioral context, but does not elaborate on other behavioral aspects (e.g., default behavior when porcentaje is omitted). 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 extremely concise: two sentences that front-load the core function (calculate tip and split) and add a secondary feature (country knowledge). Every sentence adds value with no redundancy or fluff.
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 low complexity and complete parameter schema, the description covers the essential purpose and a notable feature (country defaults). However, it does not mention that users can override the percentage or that splitting is optional, but these are conveyed by the schema and default values. Overall, it is sufficiently complete for a straightforward calculator tool.
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 the baseline is 3. The description mentions country-specific percentages, which adds minimal context beyond the schema's description of the 'pais' parameter. It does not explain the 'porcentaje' or 'personas' parameters beyond what the schema already provides.
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 restaurant tips and splits bills, using a specific verb ('calcula') and resource ('propina'). It distinguishes itself from sibling calculation tools by focusing on a specific domain (restaurant tips with country-specific percentages).
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 guidance is given on when to use this tool versus alternatives like 'calcular_porcentaje' or other calculators. The description implies usage for tip calculation but does not provide explicit when/not-to-use criteria or mention alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
calcular_puntos_azucarAIdentifica la fase de cocción del azúcar según la temperatura en °C: almíbar ligero, bola blanda, bola firme, bola dura, caramelo blando, caramelo duro, caramelo rubio, caramelo oscuro. Incluye usos típicos y prueba del vaso de agua fría.
| Name | Required | Description | Default |
|---|---|---|---|
| temperatura_c | Yes | Temperatura del almíbar en °C medida con termómetro de cocina. Rango útil: 100–200°C. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explains it identifies phases and includes typical uses, which adds beyond the readOnlyHint annotation. It discloses the temperature range (100-200°C) already in schema, but 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 a single sentence that front-loads the main purpose, though it lists many phases, making it slightly lengthy but still concise.
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 simple tool with one parameter and no output schema, the description adequately covers the purpose, phases, and typical uses. It could mention the output format but overall is 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% for the single parameter, which already describes the temperature and range. The tool description adds minimal extra meaning 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 clearly states the tool identifies sugar cooking phases based on temperature, listing specific stages. It distinguishes from sibling tools which are mostly unrelated (fitness, photography, etc.).
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 when you have a syrup temperature from a candy thermometer, and it includes typical uses and the cold water test. It does not explicitly state when not to use or 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.
calcular_regla_180_videoACalcula la velocidad de obturación correcta para vídeo según la regla de los 180°. El obturador debe ser el doble del frame rate para conseguir motion blur natural. Devuelve el obturador recomendado y una tabla con todos los fps comunes.
| Name | Required | Description | Default |
|---|---|---|---|
| fps | Yes | Frame rate de grabación (ej. 24, 25, 30, 50, 60, 120, 240) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description fully discloses the output ('obturador recomendado y una tabla') and the rule used. Annotations declare readOnlyHint=true, and the description aligns, indicating no destructive effects. 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 that efficiently state purpose, the rule, and the output. No redundant or extraneous information. Ideal length for quick comprehension.
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 is simple with one parameter and no output schema. The description adequately covers what it does, the rule, and what it returns. No gaps given the low 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?
The single parameter (fps) has high schema coverage (100%), and the description adds value by explaining the 180-degree rule rationale ('el obturador debe ser el doble del frame rate'), enriching understanding beyond the schema's basic description.
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 correct shutter speed for video based on the 180-degree rule, which directly differentiates it from sibling tools like calcular_camara_lenta (slow motion calculations) and calcular_filtro_nd_video (ND filter calculations). The verb 'calcula' and specific resource 'velocidad de obturación' 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?
The description explains the tool's function but does not explicitly state when to use it versus alternatives (e.g., when to use this instead of calcular_camara_lenta). The context is clear but lacks exclusionary guidance, so it scores at the 'implied usage' level.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
calcular_regla_tresAResuelve reglas de tres simples (directa e inversa) y compuestas. La regla de tres directa: si A→B entonces C→X (X = B×C/A). La inversa: si A×B = C×X (X = A×B/C). La compuesta maneja dos variables simultáneas con cualquier combinación directa/inversa. Muestra la fórmula y los pasos de resolución.
| Name | Required | Description | Default |
|---|---|---|---|
| a | Yes | Valor A (referencia 1 de la variable principal) | |
| b | Yes | Valor B (resultado 1 de la variable principal) | |
| c | Yes | Valor C (referencia 2 de la variable principal, para la que buscamos X) | |
| d | No | Valor D (referencia 1 de la segunda variable). Solo para tipo "compuesta". | |
| e | No | Valor E (referencia 2 de la segunda variable). Solo para tipo "compuesta". | |
| tipo | Yes | "simple-directa": proporción directa (más de A → más de B). "simple-inversa": proporción inversa (más de A → menos de B). "compuesta": dos variables simultáneas. | |
| relacionSegundaVariable | No | Relación de la segunda variable: "directa" (más D → más X) o "inversa" (más D → menos X). Solo para tipo "compuesta". |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds behavioral context beyond annotations by detailing that the tool shows formulas and resolution steps. It does not contradict the readOnlyHint annotation.
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?
Three sentences that front-load the purpose and provide essential details without redundancy. 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 mathematical calculator tool with full schema coverage and no output schema, the description adequately covers the behavior (formulas, steps) and context. 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?
Schema coverage is 100%, so parameter descriptions are already in the schema. The description adds overall context but does not elaborate on individual parameter meaning beyond what the schema provides.
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 resolves rule of three problems: direct, inverse, and compound, with exact formulas. It distinguishes from sibling calculators by stating its specific function.
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?
Usage is implied by the description, but there are no explicit when-to-use or when-not-to-use statements, nor comparisons with sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
calcular_sustitucion_gelatinaAConvierte entre tipos de gelatina según el bloom strength: hojas de bronce (120), plata (160), oro (200, estándar europeo), platino (250), gelatina en polvo 200/250 bloom y agar-agar. Devuelve la tabla completa de equivalencias en gramos y hojas.
| Name | Required | Description | Default |
|---|---|---|---|
| unidad | No | Unidad de medida. hojas solo aplica para tipos hoja_*. Por defecto gramos. | |
| cantidad | Yes | Cantidad a convertir (en gramos u hojas según la unidad). | |
| tipo_origen | Yes | Tipo de gelatina que tienes o que indica la receta. hoja_oro es la más común en supermercados. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotation readOnlyHint=true already indicates a safe read operation. The description adds behavioral detail by stating it returns 'la tabla completa de equivalencias en gramos y hojas', which informs the agent about the output format. No contradictions 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 front-loads the purpose with 'Convierte entre tipos de gelatina'. It lists all types efficiently but could be slightly improved by splitting into two sentences for readability. Overall concise and 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?
Given no output schema, the description explains what the tool returns ('la tabla completa de equivalencias en gramos y hojas'), which provides sufficient context for the agent to understand the result. It covers the core functionality without missing critical details.
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 schema covers all parameters with descriptions, but the description adds value by explaining the bloom strengths for each type (e.g., 'hojas de bronce (120), plata (160), ...'), which helps the agent understand the meaning behind the enum values. This context goes 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 clearly states the verb 'convierte' (converts) and the resource 'tipos de gelatina según el bloom strength', listing all supported gelatin types. It distinguishes from sibling tools like 'convertir_unidades' by focusing specifically on gelatin substitution.
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 does not provide guidance on when to use this tool versus alternatives. There is no mention of when to use this tool for gelatin conversions versus using 'convertir_unidades' or other sibling calculators, leaving the agent without clear usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
calcular_sustitucion_masa_madreACalcula cuánta masa madre activa usar para sustituir levadura fresca, seca o instantánea. Incluye el ajuste de harina y agua que hay que restar de la receta para compensar lo que aporta la masa madre.
| Name | Required | Description | Default |
|---|---|---|---|
| levadura_g | Yes | Gramos de levadura que pide la receta. | |
| tipo_levadura | No | Tipo de levadura de la receta original. Por defecto seca. | |
| hidratacion_mm_pct | No | Hidratación de tu masa madre en % (agua/harina × 100). Por defecto 100 (igual de harina que agua). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations confirm read-only nature, and description adds that the tool includes adjustments for flour and water, which is important behavioral context 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?
Two sentences with clear front-loading: first states main purpose, second adds necessary detail. No extraneous 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?
No output schema exists, but description explains that the output includes flour and water adjustments. Sufficient for a simple calculator with three parameters.
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 overall context about adjusting flour and water but does not elaborate on individual parameters 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?
The description clearly states the tool calculates sourdough starter substitution for fresh, dry, or instant yeast, distinguishing it from sibling tools like hydration or recipe scaling.
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 usage for yeast-to-sourdough substitution but lacks explicit guidance on when to use this tool versus alternatives 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.
calcular_swolf_natacionACalcula el índice SWOLF (segundos + brazadas por largo) como medida de eficiencia en natación. Clasifica el nivel del nadador y proporciona consejo de mejora técnica. Compatible con piscinas de 25m y 50m.
| Name | Required | Description | Default |
|---|---|---|---|
| metros_largo | No | Longitud del largo en metros: 25 (defecto) o 50 | |
| brazadas_largo | Yes | Número de brazadas por largo | |
| tiempo_s_largo | Yes | Tiempo por largo en segundos (ej. 20 para nadar 25m en 20 segundos) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds behavioral context beyond the readOnlyHint annotation: it states that the tool classifies level and provides advice, which are outputs. It does not contradict the annotation (readOnlyHint=true implies no side effects, consistent). No additional behavioral details needed.
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?
Three efficient sentences: defines SWOLF, states outputs (classification, advice), and notes pool lengths. No filler; front-loaded with core purpose. Every sentence earns its place.
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 inputs and outputs adequately for a calculator, but does not specify the classification scale or detail of advice. However, given no output schema, this is a minor gap. It is almost complete for the tool's 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%, baseline 3. The description adds value by explaining what SWOLF means (segundos + brazadas por largo) and mentioning compatibility with 25m and 50m pools, which clarifies the metros_largo parameter. This exceeds the schema's 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?
The description clearly states the tool calculates SWOLF index, classifies swimmer level, and provides improvement advice. It is specific about verb (calcula) and resource (índice SWOLF and nivel del nadador), and it is distinct from sibling tools which are unrelated domains.
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 or alternatives. The usage is implied by the domain (swimming efficiency), but the description does not include exclusions or comparison with other tools, so it relies on context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
calcular_temperatura_masaACalcula la temperatura exacta del agua de amasado para alcanzar la DDT (Desired Dough Temperature). Usa la fórmula T_agua = DDT×3 − T_ambiente − T_harina − T_fricción, con variante de 4 factores si hay preferment.
| Name | Required | Description | Default |
|---|---|---|---|
| t_harina_c | No | Temperatura de la harina en °C. Si no se indica, se asume igual a la temperatura ambiente. | |
| t_ambiente_c | Yes | Temperatura ambiente de la cocina en °C. | |
| ddt_objetivo_c | No | Temperatura final deseada de la masa en °C. Típico: 23-25°C para masa madre, 26-28°C para levadura comercial. Por defecto 24°C. | |
| t_preferment_c | No | Temperatura del preferment (poolish, levain, biga) si la receta lo usa. Activa la fórmula de 4 factores. | |
| tipo_amasadora | No | Tipo de amasado (cada uno genera distinta fricción). Por defecto manual. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the description's role is supplementary. It adds the formula and mentions a 4-factor variant, but doesn't detail friction calculation based on mixer type or default behaviors beyond what's in the schema.
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-loading the core purpose and formula. Every sentence adds value with no fluff. It is highly concise and structured effectively.
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 calculator with 5 parameters and no output schema, the description explains the formula and variant conditions. It covers the essential behavioral context. However, it could mention the return value format (likely the water temperature in °C) for 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 the schema already documents all parameters with meaning. The description repeats the formula context but does not add new semantics beyond what the parameter descriptions already provide. 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 tool's purpose: calculating exact water temperature to achieve desired dough temperature, using a specific formula. It distinguishes itself from sibling calculators like 'calcular_hidratacion_pan' by focusing on this specific variable.
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?
Usage is implied by the description: use when you need to compute water temperature for dough. However, no explicit guidance on when not to use or alternatives is provided. Sibling tools may cover similar baking calculations, but no comparison is made.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
calcular_zonas_cardiacasACalcula las 5 zonas de frecuencia cardíaca personalizadas con la fórmula de Karvonen. Más precisa que el simple % FCmáx porque tiene en cuenta la FC en reposo. Devuelve los rangos de pulsaciones para cada zona y su beneficio de entrenamiento.
| Name | Required | Description | Default |
|---|---|---|---|
| edad | Yes | Edad en años | |
| fc_maxima | No | FCmáx medida en un test de esfuerzo en ppm. Opcional: si no se indica, se estima con 220−edad | |
| fc_reposo | Yes | Frecuencia cardíaca en reposo en ppm (medida por la mañana antes de levantarse) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, indicating safety. The description adds value by detailing the formula (Karvonen), the reason for accuracy (resting HR), and the output (ranges per zone and training benefit), enhancing transparency 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 two sentences with no wasted words. The first sentence states the action and method, the second explains the advantage and output. It is front-loaded and every sentence earns its place.
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 moderate complexity (3 parameters, formula). No output schema, but the description states it returns 'los rangos de pulsaciones para cada zona y su beneficio de entrenamiento,' which adequately covers return values. Annotations provide readOnlyHint. No critical information missing.
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 the schema already documents all three parameters. The description does not add new parameter-specific details beyond the schema's existing descriptions, meeting the baseline of 3.
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 specifies the tool calculates the 5 customized heart rate zones using the Karvonen formula, which is more accurate than simple max heart rate percentage. This clearly distinguishes it from sibling calculator tools, as none are dedicated to heart rate zones.
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 why to use this tool over simpler methods ('Más precisa que el simple % FCmáx porque tiene en cuenta la FC en reposo'), providing clear context for when it is appropriate. However, it does not explicitly state when not to use it or mention alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
consultar_etiqueta_dgtACalcula la etiqueta medioambiental DGT (CERO, ECO, C, B o Sin etiqueta) de un vehículo según su combustible y año de matriculación. También informa del acceso a las Zonas de Bajas Emisiones (ZBE) de Madrid, Barcelona, Valencia, Sevilla, Zaragoza, Valladolid y Bilbao. Encadenable con recomendar_vehiculo para completar el perfil de un vehículo en consideración.
| Name | Required | Description | Default |
|---|---|---|---|
| combustible | Yes | electrico = BEV | phev = híbrido enchufable | hibrido = híbrido convencional HEV | gnc_glp = gas natural/propano | gasolina | diesel | |
| autonomiaPhevKm | No | Solo para PHEV: autonomía eléctrica en km. ≥40km → etiqueta CERO, <40km → ECO. Por defecto: 0 | |
| anioMatriculacion | Yes | Año de primera matriculación del vehículo (ej: 2018) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the burden is lower. Description adds context about ZBE access but does not disclose limitations or data sources. 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?
Two sentences, front-loaded with the core purpose, then additional outputs and chaining tip. Every sentence adds value; 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?
No output schema exists, so description should clarify what the tool returns. It mentions 'informa del acceso a las ZBE' but not the format (e.g., string, object). Missing edge cases. Adequate but not comprehensive.
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%, and the description restates the key parameters (combustible, anioMatriculacion). It adds no new semantics beyond the 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 the verb 'Calcula' and the resource 'etiqueta medioambiental DGT', enumerates possible labels. Also mentions additional ZBE access info and chainability with recomendar_vehiculo, distinguishing it from siblings like calcular_combustible.
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?
Usage context is implied (for environmental label), but there is no explicit when-to-use vs alternatives or exclusions. The chainability hint provides some guidance, but not enough for a higher score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
convertir_edad_mascotaAConvierte la edad de un perro o gato a años humanos equivalentes y determina su etapa de vida con recomendaciones de cuidado. Para perros usa factores por tamaño (pequeño, mediano, grande, gigante). Para gatos: primer año = 15 años humanos, segundo = 9, resto × 4.
| Name | Required | Description | Default |
|---|---|---|---|
| edadMascota | Yes | Edad de la mascota en años. Puede tener decimales (ej: 0.5 = 6 meses, 1.5 = 1 año y medio). | |
| tamanoPerro | No | Tamaño del perro (solo si tipoMascota="perro"): "pequeno" <10kg, "mediano" 10-25kg, "grande" 25-45kg, "gigante" >45kg. Por defecto "mediano". | |
| tipoMascota | Yes | Tipo de mascota |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide readOnlyHint=true, and the description adds behavioral details: conversion factors for dogs by size and cats by age formula, determination of life stage, and care recommendations. These go beyond annotations by disclosing the conversion logic and output content.
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 purpose, and each sentence provides essential information. 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?
While the description mentions outputs (etapa de vida, recomendaciones de cuidado), it does not specify the exact format or structure of the output (e.g., JSON fields). Since no output schema exists, more detail would be beneficial for a complete understanding.
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 meaning by explaining the conversion formulas (e.g., 'primer año = 15 años humanos, segundo = 9, resto × 4' for cats) and specifying default dog size, which the schema lacks. This adds value 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 clearly states 'Convierte la edad de un perro o gato a años humanos equivalentes y determina su etapa de vida con recomendaciones de cuidado.' This is a specific verb (convertir) and resource (edad mascota), and it distinguishes from sibling tools like calcular_edad which are generic age calculators.
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 usage for converting pet ages but does not explicitly state when to use this tool versus alternatives or when not to use it. 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.
convertir_unidadesConvierte entre unidades de medida en 12 categoríasAConvierte entre unidades de medida en 12 categorías: longitud (m, km, cm, mm, mi, yd, ft, in, nmi, au, ly), masa (kg, g, mg, t, lb, oz, st), temperatura (C, F, K, R), area (m2, km2, cm2, ha, acre, ft2), volumen (l, ml, m3, gal, qt, pt), tiempo (s, min, h, d, semana, mes, ano), velocidad (ms, kmh, mph, kn, mach), datos (b, B, KB, MB, GB, TB, Kb, Mb, Gb), presion (Pa, kPa, bar, atm, psi, mmHg), energia (J, kJ, cal, kcal, Wh, kWh, BTU, eV), fuerza (N, kN, lbf, kgf), potencia (W, kW, MW, hp, cv).
| Name | Required | Description | Default |
|---|---|---|---|
| valor | Yes | Valor numérico a convertir | |
| categoria | Yes | Categoría de la conversión | |
| unidadOrigen | Yes | Unidad de origen (ver listado en la descripción). Ejemplos: "km", "lb", "C", "ha", "kWh" | |
| unidadDestino | Yes | Unidad destino. Ejemplos: "mi", "kg", "F", "acre", "BTU" |
| Name | Required | Description |
|---|---|---|
| formula | Yes | |
| unidades | Yes | |
| categoria | Yes | |
| valorOrigen | Yes | |
| unidadOrigen | Yes | |
| valorDestino | Yes | |
| equivalencias | Yes | |
| unidadDestino | Yes | |
| factorConversion | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the tool is known to be read-only. The description adds no further behavioral context such as return format or side effects. It simply lists units, which are more parameter-related than behavioral. 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 sentence, front-loaded with the main purpose and followed by a comprehensive but compact list of units. Every part is useful, though it is lengthy and could be structured with line breaks for readability. It remains appropriately concise 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?
The tool has an output schema (per context), so return values needn't be described. The description covers all relevant units and categories, making it nearly complete for a conversion tool. Minor gaps include not clarifying case sensitivity or unit-category validation, but these are secondary.
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 for all four parameters, providing a baseline of 3. The description adds substantial value by enumerating valid units for each category, which clarifies how to fill unidadOrigen and unidadDestino. This pushes it above baseline.
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 'Convierte' (converts) and identifies the resource as 'unidades de medida en 12 categorías', listing each category and its units. This is specific and distinguishes the tool from sibling calculators and converters.
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 clearly implies when to use this tool (for unit conversion across the listed categories) but does not explicitly handle when-not-to-use or alternatives among siblings. The context is clear, so it earns a 4 rather than 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
escalar_recetaAEscala una receta a más o menos raciones. Aplica factor no lineal para levadura, polvo de hornear y especias. Redondea cantidades de forma práctica según la unidad. La temperatura del horno no cambia; indica si el tiempo necesita ajuste.
| Name | Required | Description | Default |
|---|---|---|---|
| ingredientes | Yes | Lista de ingredientes de la receta original. | |
| raciones_nueva | Yes | Número de raciones/porciones que quieres obtener. | |
| raciones_original | Yes | Número de raciones/porciones de la receta original. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide readOnlyHint=true, and the description adds substantial behavioral context: non-linear scaling for certain ingredient categories, practical rounding, oven temperature unchanged, and an indication of time adjustment. This goes beyond the annotations and fully informs the agent of the tool's 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?
Three sentences efficiently convey the tool's purpose, key behaviors, and constraints. No redundant or extraneous information. The first sentence immediately states the core function, and subsequent sentences add critical details.
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 three parameters (all required) and no output schema. The description explains the input processing but does not describe the output format. Given the complexity, an agent might need to know what the result looks like. Without output schema, the description should provide more detail on the return value.
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 covers 100% of parameters with descriptions. The description adds value by explaining how the 'categoria' property affects scaling (non-linear for yeast, etc.). While the schema already lists category options, the description provides operational context that helps the agent understand parameter significance.
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 scales a recipe to more or fewer servings. It specifies non-linear scaling for yeast, baking powder, and spices, practical rounding, and that oven temperature does not change. This distinguishes it from sibling tools that handle other recipe calculations (e.g., hydration, bread temperatures).
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 indicates the tool is for scaling recipes. It explains what it does (non-linear factors, rounding, oven temp constant) but does not explicitly state when not to use it or mention alternatives among siblings. However, the purpose is clear enough that an agent would know this is the right tool for scaling.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
recomendar_vehiculoARecomienda el segmento (urbano, compacto, SUV, familiar) y la motorización (gasolina, diésel, híbrido, eléctrico) más adecuados según el perfil del usuario. Necesita al menos los km anuales. Opcionales: uso principal, pasajeros, presupuesto, zona y si hay ZBE. Devuelve segmento recomendado, motorización, razón principal, coste anual estimado y alertas contextuales.
| Name | Required | Description | Default |
|---|---|---|---|
| zbe | No | true si la ciudad tiene Zona de Bajas Emisiones activa (Madrid, Barcelona, Valencia...). Por defecto: false | |
| zona | No | Zona principal de uso del vehículo. Por defecto: ciudad | |
| carga | No | Necesidad de maletero: poca/normal/mucha. Por defecto: normal | |
| kmAnuales | Yes | Kilómetros que conduce al año (ej: 15000) | |
| pasajeros | No | Número habitual de ocupantes incluyendo el conductor. Por defecto: 4 | |
| presupuesto | No | Presupuesto disponible para la compra. Por defecto: 15k_25k | |
| usoPrincipal | No | urbano = mayoría en ciudad | mixto = ciudad+carretera | carretera = mayoría autopista. Por defecto: mixto |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, and the description adds return fields (segment, motorization, reason, cost, alerts). No side effects or limitations are disclosed, but the tool's behavior is sufficiently transparent.
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, front-loaded with main purpose, and efficiently covers inputs and outputs without unnecessary 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?
Given the 7 parameters and no output schema, the description adequately explains inputs and outputs. However, it could provide more detail on output format or edge cases for full 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 good parameter descriptions. The description adds value by listing required vs. optional parameters and summarizing return fields, exceeding what schema provides.
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 recommends vehicle segment and motorization based on user profile, specifying required and optional parameters. It is distinct from sibling tools which are calculation- or conversion-oriented.
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 usage for vehicle recommendation but does not explicitly contrast with sibling tools or state when to avoid use. Context is clear but not explicit about 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!
