Skip to main content
Glama

Clerk - IA Legal Dominicana

Leer un decreto o reglamento

leer_decreto
Read-only

El texto de un decreto o reglamento del Poder Ejecutivo, por páginas, extraído de su PDF oficial en la Consultoría Jurídica. Se pide con el doc_id que devuelve buscar_decretos.

Seis modos. Sin más argumentos, la FICHA: cuántas páginas tiene. Con estructura, los TÍTULOS, CAPÍTULOS y Secciones con su página y su primer artículo, sin el texto. Con articulo, la página donde empieza ese artículo (reconoce el encabezado «Art. N.-», no las menciones del artículo dentro de otros). Con buscar, las páginas donde aparece el término y su contexto. Con desde/hasta, ese tramo entero. Con pagina, esa página sola.

⚠️⚠️ Un reglamento puede pasar de cien páginas. NO lo leas entero: pide la estructura o el articulo, y lee con desde/hasta solo el capítulo que responde la pregunta.

⚠️ Cita SOLO lo leído con pagina o desde/hasta, literal: el contexto de buscar localiza, no se cita. Si la respuesta trae aviso_cobertura, la búsqueda NO miró el documento entero.

⚠️⚠️ El PDF es un recorte de la Gaceta Oficial: puede traer el final del decreto anterior y el principio del siguiente. Cita solo desde el encabezado «NUMERO: N-AA» del que buscas hasta el del siguiente (decretos_que_empiezan_aqui).

⚠️ Un decreto puede modificar o derogar otros: los considerandos y el dispositivo lo dicen. Comprueba la vigencia antes de citarlo como derecho aplicable.

⚠️ La primera lectura tarda unos segundos; las siguientes son inmediatas. No reintentes por lentitud.

Input Schema

NameRequiredDescriptionDefault
desdeNoPrimera página de un tramo a leer entero (1-based).
hastaNoÚltima página del tramo. Si pides demasiadas, se recorta y se dice.
buscarNoTérmino a localizar dentro del documento. No distingue tildes ni mayúsculas.
doc_idYesEl `doc_id` que trae cada resultado de buscar_decretos.
paginaNoPágina del PDF a leer entera (1-based).
articuloNoNúmero del artículo a localizar. Devuelve la página donde empieza.
estructuraNotrue: los TÍTULOS, CAPÍTULOS y Secciones con su página y su primer artículo, sin el texto.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / estructura
      Added value: +{
      +  "description": "true: los TÍTULOS, CAPÍTULOS y Secciones con su página y su primer artículo, sin el texto.",
      +  "type": "boolean"
      +}
  2. First observed

TDQS

A4.4/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is set. The description nonetheless adds substantial behavioral context beyond annotations: the PDF is a Gaceta Oficial excerpt that may contain adjacent decrees, decretos_que_empiezan_aqui marks boundaries, first read is slow (don't retry), and decrees may amend/repeal others. These are valuable, but the emoji warnings crowd out return-shape detail (covered separately by output schema absence).

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?

Front-loaded with the resource and the six modes, then grouped warnings. Mostly earns its length, though the stacked ⚠️ blocks and repeated emphasis add bulk; a tighter version could convey the same boundaries with less repetition.

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?

For a 7-parameter tool with no output schema, the description supplies the missing context: what each mode returns, pagination/truncation behavior (hasta recorta y se dice), aviso_cobertura semantics, and citation hygiene. An agent has everything needed to invoke correctly and interpret results.

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 parameters are already documented. The description still adds real semantics: articulo matches the 'Art. N.-' header rather than in-text mentions, buscar is accent/case-insensitive, desde/hasta reads a contiguous range, and the mode-selection logic itself clarifies parameter interaction beyond the flat 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 (leer) and resource (decreto/reglamento del Poder Ejecutivo), scoped to pages of the official PDF from Consultoría Jurídica, and explicitly ties doc_id to buscar_decretos, distinguishing it from that sibling. An agent knows immediately this is the fetch-by-id read tool, not a search tool.

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

Usage Guidelines5/5

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

Enumerates all six modes and the exact argument that selects each (estructura, articulo, buscar, desde/hasta, pagina, or bare call = ficha). Adds explicit when-not guidance: don't read a 100-page reglamento whole, use estructura/articulo first and read only the relevant chapter, and when to distrust buscar results via aviso_cobertura.

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