Skip to main content
Glama
elpabloultron

Open Legal Chile

by elpabloultron
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Local

recurso_proteccion_generar

Generate a standardized Recurso de Protección (Chilean protection writ) with annexes, producing structured PDF and document files compliant with Supreme Court rules. Input case details to get court-ready filings.

Instructions

Genera y estandariza un Recurso de Protección conforme al Auto Acordado de la Corte Suprema (Acta N.° 94-2015) y OJV, produciendo escritos estructurados (.md, .html, .txt, .json) y expedientes PDF consolidando anexos con marcadores TOC.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
anexosNoLista de anexos probatorios: [{'num': 'ANEXO N.° 1', 'title': '...', 'desc': '...', 'path': 'ruta.pdf'}]
hechosYesCronología de hechos numerados. Cada elemento puede ser texto o dict con 'texto' y 'anexo' (ej. 'Anexo 1')
oficiosNoLista de oficios solicitados bajo apercibimiento del Numeral 5.°: [{'organismo': '...', 'materia': '...'}]
tribunalYesCorte de Apelaciones competente (ej. 'Ilustrísima Corte de Apelaciones de Santiago')
garantiasYesGarantías del Art. 19 CPR invocadas (ej. ['19_1', '19_2', '19_3_5', '19_10', '19_24'])
recurridoYesDatos de la recurrida: nombre, rut (opcional o 'se desconoce'), domicilio (opcional), email (opcional), representante_legal (opcional)
fecha_actoYesFecha del acto lesivo o de su conocimiento fehaciente (formato YYYY-MM-DD) para cómputo fatal de 30 días corridos
recurrenteYesDatos del recurrente: nombre, run, domicilio, email, profesion_oficio, representado_nombre (opcional), representado_run (opcional)
acto_lesivoYesDescripción precisa del acto u omisión arbitrario e ilegal impugnado
compilar_pdfNoSi es True, compila automáticamente el PDF principal y el dossier consolidado con anexos y marcadores TOC
quinto_otrosiNoQuinto otrosí especial opcional: {'titulo': '...', 'contenido': '...'}
petitorio_concretoNoPeticiones concretas específicas (opcional)
fecha_interposicionNoFecha de interposición (opcional, por defecto hoy YYYY-MM-DD)
orden_de_no_innovarNoConfiguración de la ONI: solicita (bool), fumus_boni_iuris, periculum_in_mora, medida_suspension
estatutos_especialesNoEstatutos protectores especiales (ej. ['ninez_21430', 'tea_21545', 'deporte_19712_ds22', 'denuncia_cpp'])

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.5.11

TDQS

A3.9/5.0
Behavior4/5

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

With no annotations provided, the description carries the full disclosure burden. It transparently states that the tool produces structured outputs (.md, .html, .txt, .json) and consolidated PDF dossiers with TOC bookmarks. It does not mention file destinations, overwrite behavior, or permissions, but the generative behavior is otherwise clearly disclosed.

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

Conciseness5/5

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

The description is a single dense, front-loaded sentence that moves from verb and object to governing legal standard and then to concrete output artifacts. Every clause earns its place, with no filler or redundant restatement of the tool name.

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?

For a complex 15-parameter, 7-required tool with no annotations and no output schema, the description covers the document type, legal framework, and output artifacts. However, it omits what the caller receives back (paths, status, errors) and any side-effect caveats, leaving some important operational context unstated.

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 description coverage is 100%, so the baseline is 3; the schema already documents all 15 parameters. The description adds useful legal-standard context and the PDF/TOC consolidation behavior for annexos, but it does not add significant parameter format or constraint details beyond 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?

The description opens with a specific verb-resource pair: 'Genera y estandariza un Recurso de Protección' and ties it to the Supreme Court Auto Acordado (Acta N.° 94-2015) and OJV. This clearly identifies what the tool produces and distinguishes it from the many search/analysis tools in the sibling list.

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 implies the intended use: drafting standardized Recurso de Protección filings under a specific legal framework. However, it does not explicitly state when to prefer this tool over alternatives or mention any exclusion cases, so the usage guidance remains implied rather than explicit.

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

Deploy Server

Other Tools