Skip to main content
Glama

Próceres · escritos judiciales de España: papeleta, demanda y recursos

Valoración del daño personal con el baremo del automóvil (secuelas, días de curación y fallecimiento)

valorar_danos_personales
Read-only

Valora el daño corporal con las cuantías del baremo del automóvil de 2026, llamando al mismo motor que la puerta POST /api/accidentes: las secuelas por su puntuación y la edad del lesionado, los días de curación por grado y las intervenciones, y el fallecimiento por perjudicados de la tabla 1.A. Devuelve cada partida con su suelo y su techo, los dos totales y —separado, sin perderse— lo que no se puede cuantificar sin el informe médico o las facturas. NO decide culpa ni responsabilidad: eso no se le pide. Lo que se le da son hechos: puntuaciones de 1 a 100, días, edades e importes acreditados. No pide ni devuelve datos personales: el nombre, el DNI, el domicilio y el contacto NO están entre sus campos (el escrito los deja como huecos entre corchetes para que los rellene quien lo presenta). No le pidas esos datos y no los escribas en la llamada.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "valorar_danos_personales"
  }
}

Input Schema

NameRequiredDescriptionDefault
muerteNoEl fallecimiento: los perjudicados de la tabla 1.A, con su clave.
secuelasNoLas secuelas del informe: las puntuaciones psicofísicas y la edad del lesionado en la fecha del accidente.
temporalNoLas lesiones temporales: los días de curación, por grado, y las intervenciones.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A3.7/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnly/openWorld=false/destructive=false, yet the description adds real behavioral context: it describes the return shape (each partida with suelo and techo, two totals, plus a separate list of items that cannot be quantified without the medical report or invoices) and states it neither asks for nor returns personal data. It stops short of specifying precision/currency or how the two totals are composed.

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?

Core purpose and scope are front-loaded in the first two clauses. It is on the long side: the personal-data prohibition is stated twice ('No pide ni devuelve datos personales…' and 'No le pidas esos datos y no los escribas en la llamada'), which is redundant, though the emphatic style is defensible for a safety-critical guardrail.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a nested three-block tool with no output schema, the description covers what is computed, what is returned and what is deliberately excluded (fault, personal data). The main remaining gap is that all parameters are optional yet nothing says a call must carry at least one of muerte/secuelas/temporal to be meaningful.

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?

Schema coverage is 100% with per-field descriptions for every nested property, so the schema already carries parameter meaning. The description restates the input nature ('puntuaciones de 1 a 100, días, edades e importes acreditados') and adds little syntax or constraint detail beyond it — baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource — 'Valora el daño corporal con las cuantías del baremo del automóvil de 2026' — and enumerates the three damage blocks it covers (secuelas, días de curación, fallecimiento), including the exact tables (1.A, 2.C). It does not name any sibling tool, so the differentiation from the rest of the catalogue (mostly document-writing tools) is only implicit in the wording.

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?

Usage is implied: feed it facts (puntuaciones 1-100, días, edades, importes acreditados) and it returns the valuation. It usefully excludes fault/liability determination ('NO decide culpa ni responsabilidad'), but gives no explicit when-to-use vs. alternatives — notably no mention of how it relates to the sibling `valor_de_puntos` — and no note that at least one of the three blocks must be supplied.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources