Skip to main content
Glama

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

Auditar un escrito contra las reglas de valoración de la prueba del CGPJ

auditar_escrito
Read-only

Mide el TEXTO de un escrito contra las 176 reglas de valoración del CGPJ —sana crítica, valoración conjunta, indicios, credibilidad del testigo, pericial, documental, electrónica, ilicitud y carga de la prueba— y devuelve el informe regla a regla: qué nombra, qué le falta, qué fórmula usa que la doctrina tiene por vicio, y el literal y la fuente de cada regla. Es lo mismo que hacen /formacion/auditoria y su ruta POST /api/formacion/auditoria, y es la herramienta con la que una IA revisa lo que acaba de redactar antes de entregárselo a nadie. El orden es obligatorio —las reglas se aplican dentro de un orden— y fase decide qué se mide: alegacion (demanda, contestación: solo la carga de la prueba y la ilicitud) o valoracion (conclusiones, sentencia, recurso por error en la valoración), que es la que se aplica por defecto. No es un juez: es una lista de comprobación explicable, regla a regla, con el literal de la fuente que la sostiene. El texto llega hasta 60.000 caracteres. Este texto no debe llevar datos de nadie: el nombre, el DNI/NIF, el domicilio, el teléfono, el correo y la matrícula se sustituyen por huecos —[nombre y apellidos], [DNI], [domicilio]— y los rellena quien presenta el escrito. Si lo que revisas los lleva, cámbialos antes de usarlo. El texto no se guarda —se mide y se devuelve— y no se repite en la respuesta. 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

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "texto": "<texto>",
      "orden": "<orden>"
    },
    "name": "auditar_escrito"
  }
}

Input Schema

NameRequiredDescriptionDefault
faseNo`alegacion` (demanda, contestación, proposición de prueba) o `valoracion` (conclusiones, sentencia, recurso por error en la valoración). Por defecto, `valoracion`.
ordenYesEl orden jurisdiccional del escrito, obligatorio: sin él no se sabe qué reglas le tocan. `militar` se audita con el rulebook penal, porque la disposición adicional primera de la LO 2/1989 manda aplicar la LECrim a los procedimientos penales militares en lo que la ley castrense no regula.
textoYesEl texto del escrito que se audita, pegado tal cual y sin sus datos de identidad (van como huecos entre corchetes). Hasta 60.000 caracteres.
mediosNoLimita la auditoría a unos medios de prueba. Sin este campo se miden todos los que le tocan al orden y a la fase.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.5/5.0
Behavior5/5

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

Goes well beyond the readOnly/non-destructive annotations: text is not stored, is not echoed in the response, is capped at 60,000 characters, and must be pseudonymised before calling. It also confirms no personal data is requested or returned, which the annotations cannot express.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The core purpose and constraints are front-loaded, but the personal-data point is restated three times in the last third ('Este texto no debe llevar datos de nadie…', 'No pide ni devuelve datos personales…', 'No le pidas esos datos…'), which pads an otherwise dense and useful description.

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

Completeness5/5

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

With no output schema, the description carries the return-value burden and does so (rule-by-rule report: what is named, what is missing, defective formulas, plus literal source for each rule). Size limit, default phase, mandatory order and privacy handling are all covered, so an agent has what it needs to call it correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3, but the description adds real meaning: `orden` is mandatory because rules apply within one jurisdictional order, and `fase` controls which rules are measured (alegacion limits the audit to burden of proof and illicit evidence). The `medios` scoping parameter is described only in the schema.

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?

States a specific verb and object: it measures the TEXT of a legal filing against 176 CGPJ evidentiary-valuation rules and returns a rule-by-rule report. It also disambiguates against a sibling surface by naming the equivalent route (`/formacion/auditoria`, `POST /api/formacion/auditoria`) and clarifies what it is not ('No es un juez: es una lista de comprobación explicable').

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives concrete when-to-use framing ('la herramienta con la que una IA revisa lo que acaba de redactar antes de entregárselo a nadie') and explains how `fase` selects the applicable rule subset (alegacion vs valoracion, with document examples). It does not explicitly name a sibling alternative such as criterios_de_valoracion or catalogo_escritos_procesales, so the routing among siblings is only partly covered.

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