Skip to main content
Glama

meskeIA MCP

by com.meskeia

calcular_breakeven_electrico

Read-only

Calcula 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.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
kmAnualesYesKilómetros que se conducen al año (ej: 15000)
precioLuzNoPrecio de la electricidad doméstica en €/kWh. Por defecto: 0,18
costeCargadorNoCoste de instalación del cargador doméstico en euros. Por defecto: 800
subsidioMovesNoSubsidio MOVES III aplicable: 0 (sin subsidio), 4500 (sin achatarramiento) o 7000 (con achatarramiento). Por defecto: 0
precioGasolinaYesPrecio del coche de gasolina equivalente en euros (ej: 22000)
consumoGasolinaNoConsumo del gasolina en L/100km. Por defecto: 7
precioElectricoYesPrecio del coche eléctrico en euros (ej: 32000)
consumoElectricoNoConsumo del eléctrico en kWh/100km. Por defecto: 16
precioGasolinaLitroNoPrecio de la gasolina en €/L. Por defecto: 1,65

TDQS

A3.8/5.0
Behavior4/5

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.

Conciseness4/5

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.

Completeness3/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines3/5

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.

All meskeIA MCP toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A3.8/5.0
Disambiguation4/5

Most tools are cleanly separated by domain and purpose, but a few close pairs exist: calcular_camara_lenta and calcular_regla_180_video both touch the 180° shutter rule, and calcular_pace_running and calcular_prediccion_running both produce race projections. The descriptions are detailed enough to resolve the ambiguity, but misselection is possible if they are not read carefully.

Naming Consistency5/5

All tool names follow a consistent Spanish verb_noun snake_case pattern, with calcular_ dominating and the other verbs (convertir_, consultar_, recomendar_, escalar_) used for genuinely different action types. There is no mixed casing or style inconsistency.

Tool Count2/5

42 tools is far above the 25+ threshold and the set spans many unrelated domains such as cooking, fitness, photography, vehicles, dates, and finance. While each individual calculator may be useful, the server is not well-scoped and would be much easier to navigate if split into domain-specific MCP servers.

Completeness3/5

Coverage inside each sub-domain is quite thorough, but there are notable gaps: calcular_kilometraje references calcular_irpf, calcular_cuota_autonomo, and comparar_autonomo_vs_sl, none of which exist in this server. These dangling cross-references can lead an agent to attempt calling unavailable tools.

Resources