Redacta papeleta, demanda y recursos de España con los preceptos del BOE. Sin datos personales.
Scored across 15 tools
Each tool composes a distinct procedural instrument with explicit distinguishing criteria (e.g. alegaciones_denuncia_trafico vs. alegaciones_procedimiento_sancionador, papeleta_conciliacion vs. demanda_juzgado_social). The catalogo vs. impugnacion_justicia_gratuita pair is clearly separated as 'list of valid IDs' vs. 'compose the brief'. No two tools plausibly collide.
Names are uniformly Spanish snake_case and mostly follow a document-type_noun pattern (papeleta_conciliacion, demanda_juzgado_social, oposicion_providencia_apremio). A few deviate into full descriptive phrases (escrito_resolucion_del_letrado, reforma_y_apelacion_penal), so it is not a strict uniform verb_noun scheme.
15 tools sits squarely in the well-scoped range, and each corresponds to a genuinely different legal document rather than a redundant variant. No tool feels padded or missing from the set's apparent intent.
The surface covers a broad cross-domain lifecycle: papeleta/reclamación previa before demand, demandas (social, tutela), and many recurso/impugnación routes plus the catalogo workflow. It is curated rather than exhaustive (e.g. no suplicación, no genérica apelación civil), but agents can work around the gaps.
Compone las alegaciones contra una denuncia de tráfico, con los motivos que se elijan (requisitos de la denuncia, notificación, error del radar, caducidad, prescripción, identificación del conductor). Los motivos cambian el cuerpo del escrito: elige los que se sostengan en el caso. 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.
| Name | Required | Description | Default |
|---|---|---|---|
| hechos | No | Lo que cuenta el ciudadano, con sus palabras. | |
| organo | Yes | Quién sanciona o instruye (Jefatura Provincial de Tráfico, Ayuntamiento…). | |
| importe | No | Importe de la multa, si consta. | |
| motivos | Yes | Qué se alega: hechos, requisitos, notificacion, metrologico, caducidad, prescripcion, identificacion. | |
| velocidad | No | Si fue un radar: el límite de la vía y la velocidad captada. | |
| expediente | No | Número de expediente o de boletín de denuncia, si lo tienes a mano. | |
| fechaNotificacion | No | Fecha de la notificación (AAAA-MM-DD). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only cover the safety profile (readOnly, non-destructive, closed-world), and the description adds genuinely new behavioral facts: no personal data is requested or returned, and the escrito leaves name/DNI/domicile as bracketed placeholders. That is information an agent cannot get from the schema or annotations and directly shapes how the call should be made.
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?
Front-loaded with the action and the motivos list, and the personal-data constraint is stated early. The closing sentence ('No le pidas esos datos y no los escribas en la llamada') largely repeats the preceding clause about bracketed placeholders, a minor 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?
With no output schema, the description carries the return burden, and it does describe the output shape (an escrito with bracketed gaps). For a 7-field generator tool with a nested velocidad object, this is close to complete; only the document format/length is left unspecified.
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 seven fields. The description still adds meaning beyond the schema by stating that the motivos selection determines the body of the escrito, which is a semantic consequence not evident from the enum list alone.
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?
Names a specific verb and resource ('Compone las alegaciones contra una denuncia de tráfico') and enumerates the motivos that shape the document, so the agent knows exactly what the tool produces. It does not explicitly name a sibling to route against (reposicion_contra_sancion_trafico, identificacion_conductor), leaving differentiation to the domain phrasing.
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?
Gives real selection guidance: 'Los motivos cambian el cuerpo del escrito: elige los que se sostengan en el caso', plus explicit when-not instructions ('No le pidas esos datos y no los escribas en la llamada'). It never names an alternative tool for a different procedural stage, so the routing guidance is contextual rather than exhaustive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compone las alegaciones contra un acuerdo de iniciación que no dice los hechos ni la sanción que la ley le obliga a decir (art. 64.2 Ley 39/2015) y pide el archivo cuando lo imputado no consta acreditado (art. 89.1). Sirve para cualquier Administración que instruya un expediente sancionador. 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.
| Name | Required | Description | Default |
|---|---|---|---|
| anio | No | El año del procedimiento, si consta. | |
| numero | No | El número del procedimiento, si consta. | |
| organo | Yes | El órgano al que se dirige el escrito, tal como figura en la resolución («Juzgado de lo Social nº 3 de Madrid»). | |
| sancion | No | Con qué se sanciona, tal y como lo dice el acuerdo. | |
| resolucion | Yes | La resolución que se recurre o se contesta, como se la nombra en el escrito. | |
| hechoImputado | No | El hecho que el acuerdo imputa y no está acreditado. | |
| administracion | Yes | La Administración que instruye el expediente. | |
| fechaResolucion | No | La fecha de esa resolución, tal como consta en ella (por ejemplo «12 de septiembre de 2026»). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, destructiveHint=false and openWorldHint=false, so safety is covered. The description adds genuinely non-derivable behavior: it neither requests nor returns personal data, and the output leaves name/DNI/address/contact as bracketed placeholders. It does not describe length or formatting of the produced writing, hence not a 5.
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 dense sentences plus a closing prohibition; the actionable scope and the exclusion warning are front-loaded and each sentence carries distinct information. Slightly verbose in the legal citations, but nothing is pure filler.
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?
With no output schema, the description usefully explains the shape of the produced document (bracketed placeholders for personal data) and the legal basis it will invoke. An agent knows what to pass and what not to pass; only the exact return format/structure is unaddressed.
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% across 8 params, so the schema already carries the per-field meaning (organo, resolucion, sancion, hechoImputado, etc.). The description's only parameter-level contribution is a negative: which data are NOT fields. That is useful but does not exceed the schema 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?
States a specific verb and output ('Compone las alegaciones') against a precisely named target document and legal defect, citing arts. 64.2 and 89.1. It also scopes applicability ('cualquier Administración que instruya un expediente sancionador'), which distinguishes it from traffic- or social-court-specific siblings like reposicion_contra_sancion_trafico.
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?
Gives clear trigger conditions: use when the acuerdo de iniciación omits the facts/sanction the law requires, or when the imputed fact is unproven. It also states an explicit when-not ('No le pidas esos datos'), but it never names an alternative draft tool for adjacent scenarios, so routing among siblings is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compone el recurso de apelación contra el auto que declara la inadmisión del recurso contencioso-administrativo sin haber dado antes traslado del motivo (art. 51.4 LJCA): alega que el auto es apelable (art. 80.1.c) y pide volver al momento anterior para poder alegar. 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.
| Name | Required | Description | Default |
|---|---|---|---|
| anio | No | El año del procedimiento, si consta. | |
| numero | No | El número del procedimiento, si consta. | |
| organo | Yes | El órgano al que se dirige el escrito, tal como figura en la resolución («Juzgado de lo Social nº 3 de Madrid»). | |
| resolucion | Yes | La resolución que se recurre o se contesta, como se la nombra en el escrito. | |
| administracion | Yes | La Administración demandada, como se la nombra en el procedimiento. | |
| fechaResolucion | No | La fecha de esa resolución, tal como consta en ella (por ejemplo «12 de septiembre de 2026»). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish readOnlyHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds genuinely useful behavior beyond that: no personal data is requested or returned, and the generated writing leaves name/DNI/domicile/contact as bracketed gaps for the filer to complete, with an explicit instruction not to solicit or write those 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?
Three sentences, front-loaded with the action and its legal basis, followed by the data-handling caveat. The final sentence ('No le pidas esos datos y no los escribas en la llamada') restates the preceding clause for emphasis, which is defensible given the compliance risk but is mild 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?
There is no output schema, so the description must convey what the tool returns; it does so by explaining that the escrito is produced with bracketed placeholders rather than personal data. Combined with the legal framing and complete schema coverage, an agent has enough to invoke it correctly, though filing/permission prerequisites are unstated.
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 6 well-documented parameters, so the schema carries the parameter burden and baseline 3 applies. The description's contribution is negative-space information (which personal-data fields are deliberately absent), which is helpful but does not add syntax or format detail for the actual parameters.
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?
States a specific verb and resource ('Compone el recurso de apelación contra el auto que declara la inadmisión del recurso contencioso-administrativo') and anchors it in concrete legal grounds (art. 51.4 LJCA, art. 80.1.c), which distinguishes it from the penal appeal sibling reforma_y_apelacion_penal without opening either schema.
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 trigger condition is precise: the auto must declare inadmisión without prior traslado of the motive, and the tool's strategy (allege apelabilidad, request return to the prior moment) is spelled out. It does not name a sibling alternative for the opposite scenario (e.g., where traslado was given), so it falls short of explicit when-not routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Devuelve la lista cerrada de ilegalidades que la herramienta impugnacion_justicia_gratuita sabe contestar: el identificador, qué es, cómo se reconoce y qué escrito lo resuelve con su prioridad y su ventanilla. Es la única lista válida de identificadores: no inventes ninguno. 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.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish readOnly, non-destructive and closed-world behavior, so the bar is low; the description still adds real context by disclosing what the returned entries contain (identifier, recognition rule, resolving document, priority, ventanilla) and by clarifying that no personal data is accepted or returned. It does not discuss size, ordering or pagination of the closed list, but this is a non-issue for a fixed catalog.
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?
Front-loaded with the output content in the first clause, and the operational warnings follow. The no-personal-data point is restated three times in different words, which costs some tightness, but every sentence still carries a distinct instruction.
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?
With no parameters and no output schema, the description carries the return-value burden itself and does so: it enumerates the fields of each catalog entry and explains where personal data goes instead (bracketed gaps in the written document). An agent has everything needed to call it and use the result.
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 tool takes zero parameters, so the baseline is 4. The description uses the empty-schema space productively by confirming that name, DNI, domicilio and contact are deliberately absent from the accepted fields, reinforcing that the call must be made with no arguments.
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?
States a specific verb and resource (devuelve la lista cerrada de ilegalidades) and immediately names the sibling it serves, `impugnacion_justicia_gratuita`. The agent can distinguish it from that sibling and from the other procedural-writing tools without opening any schema.
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 routes the agent: this is the only valid source of identifiers, so none should be invented, and it pairs with `impugnacion_justicia_gratuita` which answers these entries. It also states a clear negative rule about not requesting or passing personal data. It lacks an explicit 'call this before X' sequencing statement, so it falls just short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compone la demanda ante el Juzgado de lo Social (arts. 80 y siguientes LRJS) con la pretensión que se elija —despido, cantidad o reconocimiento de derecho—, con su comparecencia, sus hechos, sus fundamentos y su súplica. Recuerda lo que la ley pide antes de demandar (la conciliación del art. 63, salvo las excepciones del art. 64). 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.
| Name | Required | Description | Default |
|---|---|---|---|
| hechos | No | El relato de hechos del trabajador; si falta, se compone con lo que consta. | |
| organo | No | El Juzgado de lo Social o, mejor, el lugar por el que se reparte («Valencia»); también vale el nombre completo del juzgado. | |
| cantidad | No | La cantidad reclamada, si la pretensión es de cantidad. | |
| pretension | Yes | Qué se reclama: despido, cantidad o derechos. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false. The description adds valuable behavioral context beyond that: it explicitly does not ask for or return personal data, and the generated document leaves name, DNI, and address as bracketed placeholders. It also notes the legal prerequisite of conciliation, which affects invocation timing.
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 front-loaded with the core purpose, followed by a legal reminder and a crucial PII constraint. Each sentence carries useful information, though it could be slightly tighter. It is well-structured and avoids filler.
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 legal-document composition tool with no output schema, the description explains what the output will contain (comparecencia, hechos, fundamentos, súplica) and clarifies that personal data are left as placeholders. It covers the key behavioral and usage constraints an agent needs, though it could explicitly state that it returns a draft text rather than filing anything.
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 four parameters thoroughly. The description repeats the possible pretensiones (despido, cantidad, derechos) that are already in the enum and does not add syntax, format, or meaning for organo, hechos, or cantidad 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?
States a specific verb ('Compone') and resource ('la demanda ante el Juzgado de lo Social') with the exact legal scope (arts. 80 y ss. LRJS) and the three claim types it supports. An agent can distinguish it from siblings like demanda_tutela_derechos_fundamentales or papeleta_conciliacion without opening the schema.
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 by listing the claim types it handles ('despido, cantidad o reconocimiento de derecho') and reminds of the pre-litigation conciliation requirement (art. 63 LRJS). However, it never names an alternative tool or explicitly states when to choose this one over siblings, leaving the routing to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compone la demanda de tutela de derechos fundamentales y libertades públicas (art. 177.1 LRJS) contra la discriminación, el acoso o la represalia por reclamar: alega la inversión de la carga de la prueba (art. 96.1) y pide la nulidad radical, el cese, el restablecimiento y la indemnización (arts. 182.1 y 183.1). 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.
| Name | Required | Description | Default |
|---|---|---|---|
| anio | No | El año del procedimiento, si consta. | |
| numero | No | El número del procedimiento, si consta. | |
| organo | Yes | El órgano al que se dirige el escrito, tal como figura en la resolución («Juzgado de lo Social nº 3 de Madrid»). | |
| conducta | Yes | La conducta que se impugna: el acoso, la represalia o el trato desigual. | |
| derechos | Yes | El derecho o derechos que la conducta lesiona, en lenguaje del escrito. | |
| demandada | Yes | La empresa o entidad demandada. | |
| resolucion | Yes | La resolución que se recurre o se contesta, como se la nombra en el escrito. | |
| indemnizacion | No | La indemnización que se pide por el daño moral, si se concreta. | |
| fechaResolucion | No | La fecha de esa resolución, tal como consta en ella (por ejemplo «12 de septiembre de 2026»). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnlyHint=true, destructiveHint=false), but the description adds a genuinely non-obvious trait: the tool neither requests nor returns PII, and the document leaves name/DNI/address/contact as bracketed placeholders. This is exactly the kind of context that prevents an agent from feeding or fabricating personal data.
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?
Front-loaded with the tool's purpose and legal basis, then the personal-data constraint. The no-PII point is restated three times ('No pide ni devuelve', 'NO están entre sus campos', 'No le pidas... no los escribas'), which is slightly redundant though defensible as emphasis on a critical constraint.
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 document-generation tool with no output schema, the description explains what is produced (the demanda, its petitions: nulidad, cese, restablecimiento, indemnización) and the key input limitation. Sufficient for correct invocation, though it does not describe the output format or size of the generated escrito.
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 all nine parameters are already documented in the schema; the description only clarifies what is absent (personal data) rather than adding syntax or format meaning. Baseline 3 is appropriate when the schema carries the parameter burden.
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?
States a specific verb and resource (compone la demanda de tutela de derechos fundamentales, art. 177.1 LRJS) and pins down the exact case type (discriminación, acoso, represalia), which separates it from the generic demanda_juzgado_social sibling. An agent can identify the tool's niche without opening the schema.
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 case scope (discrimination, harassment, retaliation for claiming) clearly signals when this tool applies, and the closing instruction not to request personal data is actionable guidance. However, it never names a sibling or states when NOT to use it versus the broader social-court demand tool, so routing is left partly to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compone el escrito con el que se impugna una resolución firmada por el Letrado de la Administración de Justicia (diligencia de ordenación o decreto) que decide algo que la ley reserva al juez: interpone reposición y, subsidiariamente, revisión, para que no la cierre quien no podía dictarla. Úsala cuando el documento lo firma el Letrado y lo que decide no es de trámite (inadmite, deniega, archiva, resuelve el fondo). 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.
| Name | Required | Description | Default |
|---|---|---|---|
| anio | No | El año del procedimiento, si consta. | |
| numero | No | El número del procedimiento, si consta. | |
| organo | Yes | El órgano al que se dirige el escrito, tal como figura en la resolución («Juzgado de lo Social nº 3 de Madrid»). | |
| remedio | No | Lo que se pide además de dejar sin efecto lo decidido, si se concreta. | |
| decidido | No | Lo que el Letrado ha decidido, para nombrarlo («inadmite el incidente de nulidad»). | |
| resolucion | Yes | La resolución que se recurre o se contesta, como se la nombra en el escrito. | |
| fechaResolucion | No | La fecha de esa resolución, tal como consta en ella (por ejemplo «12 de septiembre de 2026»). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnlyHint=true, destructiveHint=false, openWorldHint=false), and the description adds genuine context beyond them: it does not request or return personal data, and the generated writ leaves name/DNI/address as bracketed placeholders. That is useful disclosure about input expectations and output shape. No contradiction with the readOnly hint, since it generates a document rather than mutating external state.
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?
Front-loaded with purpose, then usage condition, then a guardrail about personal data. Reasonably sized, though the no-personal-data warning is restated three times ('NO están entre sus campos', 'No le pidas esos datos', 'no los escribas'), which costs a little economy.
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?
With seven parameters and no output schema, the description closes the important gaps: it explains what the tool produces (a writ), which non-parameters it will reject, and the condition that qualifies the tool. Nothing an agent needs to invoke it correctly 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?
Schema description coverage is 100%, so every field (anio, numero, organo, remedio, decidido, resolucion, fechaResolucion) is already documented in the schema. The description contributes no per-parameter semantics beyond telling the caller which data NOT to supply, so the baseline 3 applies.
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?
States a specific verb+resource: 'Compone el escrito con el que se impugna una resolución firmada por el Letrado de la Administración de Justicia... interpone reposición y, subsidiariamente, revisión'. It carves out a precise niche (resolutions signed by the Letrado, not the juez), which materially separates it from siblings like apelacion_auto_inadmision_contencioso or reposicion_contra_sancion_trafico.
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?
'Úsala cuando el documento lo firma el Letrado y lo que decide no es de trámite (inadmite, deniega, archiva, resuelve el fondo)' gives an explicit condition with concrete examples. It implies the when-not (trámite matters do not qualify) but names no alternative tool, so it stops short of a full routing rule.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compone el escrito con el que se identifica al conductor de un vehículo cuando la denuncia llega al titular y no lo conducía él, para no pagar la sanción ni perder puntos. 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.
| Name | Required | Description | Default |
|---|---|---|---|
| hechos | No | Lo que cuenta el ciudadano, con sus palabras. | |
| organo | Yes | Quién sanciona o instruye. | |
| expediente | No | Número de expediente o de boletín de denuncia, si consta. | |
| fechaNotificacion | No | Fecha de la notificación (AAAA-MM-DD). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only cover the safety profile (readOnly, non-destructive, closed-world); the description goes well beyond them by disclosing what the generated document does and does not contain — personal data is neither requested nor returned, and the document leaves name/DNI/address/contact as bracketed placeholders for the filer. This is exactly the behavioral context an agent needs and that annotations cannot supply.
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?
Front-loaded purpose followed by the data constraint, and every sentence carries information. The closing pair ('No le pidas esos datos y no los escribas en la llamada') restates the earlier 'no pide ni devuelve datos personales' for emphasis, which is slightly redundant but serves as an actionable instruction.
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?
With no output schema, the description usefully characterizes the produced document (bracketed gaps, no personal data) and covers the one required parameter's role implicitly. It could still say more about the document's format or what the caller receives back, but the essential calling 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 description coverage is 100%, so the four fields are already documented, giving a baseline of 3. The description adds meaningful boundary information by stating what is deliberately NOT a parameter (nombre, DNI, domicilio, contacto), which prevents the agent from inventing fields the schema explicitly forbids via additionalProperties: false.
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?
Names a concrete verb+resource ('compone el escrito con el que se identifica al conductor de un vehículo') and pins down the exact triggering scenario (denuncia llega al titular y no conducía él). That scenario makes it clearly distinguishable from siblings like reposicion_contra_sancion_trafico or alegaciones_denuncia_trafico without opening their schemas.
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?
States clearly when to use it (when the complaint lands on the registered owner who was not driving, to avoid the fine and points loss) and adds an explicit usage constraint (do not request or include personal data). It never names an alternative sibling tool or an exclusion against them, so routing between the many 'escrito'-style siblings is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compone el escrito (o los escritos) que contestan las ilegalidades cometidas en un expediente de justicia gratuita: se eligen las ILEGALIDADES por su identificador y devuelve el plan —un escrito por ventanilla, con las piezas en el orden procesal (primero el cauce y lo que caduca, luego detener el reloj, luego el fondo)— ya redactado, con su destinatario y su súplica. Los identificadores válidos se leen con catalogo_impugnaciones_justicia_gratuita, y una ilegalidad que no exista no compone nada a medias: falla y dice cuáles hay. 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.
| Name | Required | Description | Default |
|---|---|---|---|
| lugar | No | La localidad, para el juzgado decano. | |
| colegio | No | El Colegio de Abogados concreto. | |
| juzgado | No | El juzgado que lleva el procedimiento, si consta. | |
| comision | No | La Comisión de Asistencia Jurídica Gratuita concreta. | |
| numeroAutos | No | El número de autos o actuaciones, si consta. | |
| ilegalidades | Yes | Los identificadores de las ilegalidades, tal como los publica `catalogo_impugnaciones_justicia_gratuita` (por ejemplo «devuelve_la_carga_al_solicitante», «pie_de_recurso_erroneo»). | |
| fechaSolicitud | No | Fecha de presentación de la solicitud (AAAA-MM-DD). | |
| resolucionTipo | No | Qué clase de resolución se impugna: diligencia y decreto son del Letrado de la Administración de Justicia; providencia y auto, del juez. Decide a quién se presenta. | |
| resolucionFecha | No | Fecha de la resolución que se impugna (AAAA-MM-DD). | |
| resolucionIdentificacion | No | Cómo se identifica la resolución («decreto de 6 de octubre…»). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint=true annotation, the description discloses substantial behavior: it returns a plan with one writing per counter, pieces ordered by procedural stage, already drafted with addressee and prayer. It also defines failure semantics (an nonexistent illegality fails and lists what exists, never composes partially) and a privacy contract (personal data is neither requested nor returned).
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?
Front-loaded with the core action, then ID sourcing and error behavior, then the privacy constraint; every sentence carries a distinct fact. It is dense and long for one paragraph, but nothing is redundant given the tool's 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?
With no output schema and 10 parameters, the description fills the gap by describing the return artifact (the plan, one writing per counter, ordered pieces, addressee, prayer) and the failure mode. Nothing an agent needs to call it correctly 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?
Schema coverage is 100%, so the baseline is 3, but the description adds meaning: it clarifies the required `ilegalidades` values are catalog identifiers and explicitly narrows expectations by stating name, DNI, domicilio and contact are NOT among its fields. The remaining nine parameters are left to 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?
States a specific verb ("Compone el escrito") plus a precise resource (writings contesting illegalities in a justicia gratuita file), and it distinguishes itself from siblings by naming the catalog tool that supplies valid identifiers. An agent can tell what it produces and in what domain without opening the schema.
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?
It gives clear operating context: illegalities are selected by identifier, valid ones come from `catalogo_impugnaciones_justicia_gratuita`, and an invalid identifier fails rather than composing partially. It does not, however, explicitly say when to prefer this tool over the other escrito/impugnación siblings, so it stops short of full routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compone la solicitud de suspensión del acto administrativo antes de que su ejecución deje el recurso sin finalidad (art. 130.1 LJCA), y discute una caución que se fije por la cuantía del pleito y no por los perjuicios (art. 133.1). 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.
| Name | Required | Description | Default |
|---|---|---|---|
| acto | Yes | El acto cuya suspensión se pide. | |
| anio | No | El año del procedimiento, si consta. | |
| numero | No | El número del procedimiento, si consta. | |
| organo | Yes | El órgano al que se dirige el escrito, tal como figura en la resolución («Juzgado de lo Social nº 3 de Madrid»). | |
| perjuicio | No | El perjuicio irreparable que produciría mantenerlo en vigor. | |
| resolucion | Yes | La resolución que se recurre o se contesta, como se la nombra en el escrito. | |
| administracion | Yes | La Administración autora del acto. | |
| fechaResolucion | No | La fecha de esa resolución, tal como consta en ella (por ejemplo «12 de septiembre de 2026»). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so safety is covered. Beyond that the description adds genuine context: it neither requests nor returns personal data, and the writ deliberately leaves name/DNI/domicile/contact as bracketed blanks, plus it discloses the caución content. What it omits is the actual return format of the generated document.
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, purpose and legal basis front-loaded, no filler padding. The privacy point is stated twice ('No pide ni devuelve datos personales… No le pidas esos datos y no los escribas'), a mild redundancy that keeps it from a 5.
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 document-composition tool with 8 fully documented parameters, no output schema and clear annotations, the description supplies the legal grounding, the intended content (suspension plus caución argument) and the data-handling boundary. Only the shape/size of the produced writ is left unstated.
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 every parameter is already documented in the schema and the baseline is 3. The description's data-handling note is cross-cutting rather than per-field and adds no syntax or format meaning beyond 'what is not a field', so it does not lift the score.
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?
States a specific verb and resource: 'Compone la solicitud de suspensión del acto administrativo', anchored to art. 130.1 LJCA, so the agent knows exactly what document is produced. It does not explicitly distinguish itself from the many sibling writ-generation tools (e.g. demanda_juzgado_social, apelacion_auto_inadmision_contencioso), so it falls short of a 5.
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 art. 130.1 premise functions as an implicit when-to-use condition: suspension is sought before execution renders the appeal moot, and art. 133.1 frames the caución discussion. It also gives an explicit exclusion — do not solicit or include personal data. No alternative sibling is named, so no 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compone la oposición a la providencia de apremio por los motivos tasados del art. 167.3 LGT (deuda extinguida o prescrita, aplazamiento pedido en período voluntario, falta de notificación de la liquidación, liquidación anulada o error de la providencia). 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.
| Name | Required | Description | Default |
|---|---|---|---|
| hechos | No | Lo que cuenta el ciudadano, con sus palabras. | |
| organo | Yes | El órgano de recaudación que dictó la providencia. | |
| importe | No | La sanción que se reclama, si consta. | |
| motivos | No | Los motivos tasados que se alegan. Si no se indica ninguno, se alega la falta de notificación. | |
| expediente | No | Número de expediente, si consta. | |
| fechaNotificacion | No | Fecha de la notificación de la providencia (AAAA-MM-DD). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint and non-destructive, and the description adds genuinely useful behavioral context beyond them: the output is a legal brief with personal-data gaps left as bracketed placeholders, so the caller must not supply personal data. It does not address default behavior or length/format of the generated escrito.
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, front-loaded with the legal purpose, then the personal-data constraint, then the operational instruction. Slight redundancy between the two ways of stating the privacy rule, but no wasted content.
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 six parameters, one required, no output schema, and read-only annotations, the definition covers purpose, legal basis, the privacy constraint, and the motivo semantics. It omits procedural timing/deadlines and any indication of the generated brief's structure, which would help an agent set expectations.
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 real value by mapping the motivos enumerated in the text to the schema's enum values and clarifying that personal-data fields are deliberately absent from the parameter set.
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?
Specific verb ('compone la oposición') plus precise legal resource ('providencia de apremio', art. 167.3 LGT), and it enumerates the five tasados motivos, distinguishing it clearly from siblings like reposicion_contra_sancion_trafico or alegaciones_denuncia_trafico.
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 frames the tool's scope (motivos tasados del art. 167.3) and explicitly says which data NOT to request, but it does not name an alternative tool or state the procedural condition under which this opposition is the right filing versus a reposición or apelación.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compone la papeleta de conciliación (art. 63 LRJS) con la pretensión que se elija —despido, cantidad o reconocimiento de derecho— y la dirige al SMAC competente. Es el trámite que va antes de la demanda en la mayoría de los asuntos sociales (art. 64). 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.
| Name | Required | Description | Default |
|---|---|---|---|
| hechos | No | El relato de hechos del trabajador; si falta, se compone con lo que consta. | |
| organo | No | El SMAC competente: basta el lugar («Madrid», «Valencia»), y también vale el nombre completo («SMAC de Madrid»). | |
| cantidad | No | La cantidad reclamada, si la pretensión es de cantidad. | |
| pretension | Yes | Qué se reclama: despido, cantidad (una cifra concreta) o derechos (reconocimiento de un derecho). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/destructive=false, so safety is covered. The description goes further by disclosing a non-obvious behavioral trait: it neither accepts nor returns personal data, and the document leaves those fields as bracketed blanks — directly actionable guidance ('do not ask for that data, do not write it'). It stops short of describing the actual return shape.
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?
Front-loaded with purpose and legal basis, then the personal-data constraint. The warning is stated twice ('no pide ni devuelve datos personales' and 'no le pidas esos datos'), which is mildly redundant, but the emphasis is defensible for an easily-misused constraint.
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 document-composition tool with no output schema, the description covers purpose, triggering context, and the critical input constraint. It could say what the tool actually returns (the composed text), but the 'no personal data in/out' note and the composition verb make the behavior sufficiently clear.
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 already documents all four parameters. The description restates the pretension options (despido/cantidad/reconocimiento de derecho) which mirrors the enum, but adds no format or syntax detail 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?
States a specific verb (compone) and resource (papeleta de conciliación), cites the governing articles (63/64 LRJS), and enumerates the three claim types. It implicitly distinguishes itself from the sibling demanda_juzgado_social by framing itself as the pre-litigation step.
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?
Clearly says this is the step that precedes the demanda in most social matters, giving an agent a strong situational cue. It does not explicitly name the alternative tool to use instead when a lawsuit is required, but the 'before the demand' framing is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compone la reclamación previa ante la entidad gestora (INSS, ISM, mutua…) que deniega una prestación o la calcula sobre una base reguladora que deja fuera cotizaciones acreditadas: es el requisito para poder demandar después (arts. 71.1 y 71.2 LRJS) y el momento de corregir el cálculo (art. 197.1 LGSS). 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.
| Name | Required | Description | Default |
|---|---|---|---|
| anio | No | El año del procedimiento, si consta. | |
| numero | No | El número del procedimiento, si consta. | |
| organo | Yes | El órgano al que se dirige el escrito, tal como figura en la resolución («Juzgado de lo Social nº 3 de Madrid»). | |
| entidad | Yes | La entidad gestora que dictó la resolución («el Instituto Nacional de la Seguridad Social»). | |
| prestacion | Yes | La prestación solicitada («la pensión de incapacidad permanente total»). | |
| resolucion | Yes | La resolución que se recurre o se contesta, como se la nombra en el escrito. | |
| baseAplicada | No | La base reguladora que la resolución aplica, si consta. | |
| baseCorrecta | No | La que correspondería con los períodos de cotización acreditados. | |
| fechaResolucion | No | La fecha de esa resolución, tal como consta en ella (por ejemplo «12 de septiembre de 2026»). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnly/openWorld=false/destructive=false), it discloses unusual and highly relevant behavior: it neither asks for nor returns personal data, and the written document leaves name/DNI/address/contact as bracketed blanks. This tells the agent not to supply or request that data, which the structured fields do not convey.
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 purpose, legal basis and data-privacy constraint are front-loaded in three dense but purposeful sentences, each contributing information. It is slightly heavy for a single paragraph but wastes little.
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 9-parameter composition tool with no output schema and read-only annotations, it covers the essentials: what it produces, the legal trigger, and the data-handling caveat. The absence of an explicit return-format or naming of the successor tool is a minor gap.
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 per-field meanings are already documented and a baseline 3 applies; the description adds value by explicitly stating which expected fields are absent (no name, DNI, address, contact), guiding the agent away from populating non-existent parameters.
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?
States a specific verb and artifact ("Compone la reclamación previa") against the managing entity, and pins its procedural scope (prior claim where a benefit is denied or the base reguladora is wrong) so the agent can distinguish it from the downstream demand and from the sibling allegation-type writs.
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?
Clearly signals when to use it: when a benefit is denied or the base excludes accredited cotizaciones, and it is "el requisito para poder demandar después," which implies the demand is a later, separate step. It stops short of naming the specific alternative sibling tool or stating explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compone el recurso contra la providencia del juez de instrucción que tiene por no interpuesto un recurso (o dicta por providencia lo que por su materia es auto): recurre en reforma y, subsidiariamente, en apelación, y anuncia la queja. Úsala cuando el cómputo del plazo sea en días hábiles donde la LECrim no los interrumpe (arts. 201 y 211). 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.
| Name | Required | Description | Default |
|---|---|---|---|
| anio | No | El año del procedimiento, si consta. | |
| numero | No | El número del procedimiento, si consta. | |
| organo | Yes | El órgano al que se dirige el escrito, tal como figura en la resolución («Juzgado de lo Social nº 3 de Madrid»). | |
| resolucion | Yes | La resolución que se recurre o se contesta, como se la nombra en el escrito. | |
| fechaResolucion | No | La fecha de esa resolución, tal como consta en ella (por ejemplo «12 de septiembre de 2026»). | |
| resolucionRecurrida | No | La resolución que la reforma impugnaba, si consta. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds meaningful context beyond that: it never requests or returns personal data, and the generated document leaves name/DNI/address/contact as bracketed gaps for the filer. It does not describe output format, but for a document-composition tool the annotations carry the rest.
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?
Front-loads the purpose, then the use condition, then the data-privacy caveat. It is slightly long and the no-personal-data point is restated twice ('No pide ni devuelve datos personales...' and 'No le pidas esos datos...'), a minor redundancy rather than a structural flaw.
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?
There is no output schema, but the description makes clear it composes a legal document and handles the personal-data gaps itself, which is the key behavioral fact an agent needs. Combined with the readOnly annotations and full schema coverage, it is complete enough to call correctly.
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 six parameters and the baseline is 3. The description adds useful negative-space information: it explicitly states which data (nombre, DNI, domicilio, contacto) is NOT among its fields, steering the agent away from passing personal data.
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?
States a specific verb (compone/drafts) and a precise resource: a recurso de reforma y, subsidiariamente, apelación contra la providencia que tiene por no interpuesto un recurso, más el anuncio de queja. This is specific enough to distinguish it from siblings like apelacion_auto_inadmision_contencioso or oposicion_providencia_apremio.
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?
Gives an explicit trigger: 'Úsala cuando el cómputo del plazo sea en días hábiles donde la LECrim no los interrumpe (arts. 201 y 211)', which tells the agent when this remedy applies versus other impugnaciones. It does not name alternative sibling tools for contrast, so it stops short of a full when/when-not routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compone el recurso de reposición contra la resolución que sanciona (el plazo es de un mes desde su notificación), con los motivos que se elijan. 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.
| Name | Required | Description | Default |
|---|---|---|---|
| hechos | No | Lo que cuenta el ciudadano, con sus palabras. | |
| organo | Yes | Quién sanciona o instruye. | |
| importe | No | Importe de la sanción, si consta. | |
| motivos | Yes | Qué se alega: hechos, requisitos, notificacion, metrologico, caducidad, prescripcion, identificacion. | |
| velocidad | No | ||
| expediente | No | Número de expediente, si consta. | |
| fechaNotificacion | No | Fecha de la notificación de la sanción (AAAA-MM-DD). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, non-destructive, closed-world), so the bar is lower. The description still adds real behavioral value: it explains that the composed document leaves personal data as bracketed gaps and that the agent must not request or write such data, which is output behavior not captured anywhere in the structured fields.
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?
Purpose is front-loaded in the first sentence, followed by the deadline and the personal-data constraint. The personal-data point is repeated across two sentences, which is slightly redundant, but the emphasis is intentional and the overall length stays reasonable.
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 drafting tool with no output schema and 86% schema coverage, the description covers purpose, timing, and the unusual data-handling rule well. The main remaining gap is that it does not describe the format or structure of the composed written appeal that the agent should 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?
Schema description coverage is 86%, so the schema already documents nearly all parameters (hechos, organo, motivos, etc.). The description adds only negative information about fields that are absent (name, DNI, address), which is useful but does not add meaning to the documented parameters themselves. 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?
States a specific verb (compone) and a precisely named legal instrument (recurso de reposición contra la resolución que sanciona), which inherently distinguishes it from the alegaciones/procedimiento siblings. It stops short of explicitly naming an alternative tool, so sibling differentiation is implicit through legal terminology rather than stated.
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?
Provides contextual timing guidance (one-month deadline from notification), which implies when the tool applies. However, it never says when to use this versus the sibling alegaciones or apelación tools, and gives no explicit exclusions beyond the personal-data caveat.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
alegaciones_denuncia_traficoalegaciones_procedimiento_sancionadorapelacion_auto_inadmision_contenciosocatalogo_impugnaciones_justicia_gratuitademanda_juzgado_socialdemanda_tutela_derechos_fundamentalesescrito_resolucion_del_letradoidentificacion_conductorimpugnacion_justicia_gratuitamedida_cautelar_suspensionoposicion_providencia_apremiopapeleta_conciliacionreclamacion_previa_prestacionreforma_y_apelacion_penalreposicion_contra_sancion_traficoSubvenciones, licitaciones y boletines oficiales de España y Europa para tu IA. Gratis, sin login.
Jurisprudencia, normativa y doctrina oficiales españolas para abogados, con citas verificadas.
Jurisprudencia española verificada para tu IA: sentencias con ECLI, artículos del BOE y doctrina
Spain consolidated legislation — Agencia Estatal Boletín Oficial del Estado (BOE), open-data API.
Add one secure layer between your agents and this server.
