Skip to main content
Glama

Buscar causas por fecha de ingreso

buscar_causa_por_fecha
Read-onlyIdempotent

Find court cases filed within a date range by specifying start and end dates, optionally narrowed by tribunal or corte. Helps identify filings against a party when you know the court but not the case number.

Instructions

Causas ingresadas en un rango de fechas.

Es la cuarta búsqueda que la plataforma ofrece, y sin ella no hay forma de responder "qué ingresó contra esta empresa esta semana" sabiendo el tribunal pero no el rol.

Un solo día en un solo tribunal puede devolver decenas de causas, así que conviene acotar el rango antes de subir el tope de páginas.

El listado publica lo que la columna trae, y varios campos son de una competencia sola: ruc en cobranza y penal; estado en apelaciones, cobranza, laboral, penal y suprema; tipo_recurso en suprema; ubicacion en apelaciones. En nulo significa que esa competencia no lo publica, no que la causa no lo tenga.

Y no trae historia, partes ni notificaciones: eso es obtener_detalle_causa, repitiendo tipo, rol, año Y competencia, más el tribunal o la corte. Sin repetirlos abre el mismo rol de otra competencia o de otro juzgado, que existe y se ve bien. Si la búsqueda ya iba acotada se reusa ese mismo código; si no, la fila publica el NOMBRE del tribunal o de la corte y el código se resuelve con listar_tribunales o listar_cortes. En suprema no hay ninguno de los dos que resolver ni que repetir, y la competencia se repite igual que en el resto. En penal no hay detalle: se rechaza por decisión, no por no estar medido.

Las búsquedas por nombre, por RUT y por fecha hay que acotarlas, y con qué depende de la competencia: civil, cobranza, laboral y penal exigen tribunal; apelaciones exige corte y NO acepta tribunal; suprema no exige ninguna de las dos. La búsqueda por rol no exige acotar en ninguna.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
corteNoCódigo de la corte, para acotar la búsqueda. Obligatorio cuando la competencia es una de: apelaciones, donde la plataforma responde 'Por favor seleccione una Corte para la búsqueda'. En el resto, OMITIR salvo certeza: fijarla produce falsos negativos, porque excluye causas radicadas en otra jurisdicción.
desdeYesFecha inicial del rango, DD/MM/AAAA.
hastaYesFecha final del rango, DD/MM/AAAA.
paginasNoCuántas páginas de resultados recorrer como máximo. La plataforma devuelve 100 por página. Si la búsqueda excede este tope, la herramienta falla en vez de devolver una lista recortada, porque un listado truncado en silencio se leería como si no hubiera más resultados.
tribunalNoCódigo del tribunal, para acotar la búsqueda. Obligatorio cuando la competencia es una de: civil, cobranza, laboral y penal. En apelaciones y suprema la plataforma no lo usa.
competenciaNoUna de: apelaciones, civil, cobranza, laboral, penal, suprema.civil

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. Changed10 schema fields changedv0.19.3
    • changedInput schema / properties / corte / description
      Previous value: -"Código de la corte. Obligatorio en las búsquedas de nombre, RUT y fecha cuando la competencia es una de: apelaciones, donde la plataforma responde 'Por favor seleccione una Corte para la búsqueda'. En el resto, OMITIR salvo certeza: fijarla produce falsos negativos, porque excluye causas radicadas en otra jurisdicción."New value: +"Código de la corte, para acotar la búsqueda. Obligatorio cuando la competencia es una de: apelaciones, donde la plataforma responde 'Por favor seleccione una Corte para la búsqueda'. En el resto, OMITIR salvo certeza: fijarla produce falsos negativos, porque excluye causas radicadas en otra jurisdicción."
    • changedInput schema / properties / tribunal / description
      Previous value: -"Código del tribunal. Obligatorio en las búsquedas de nombre, RUT y fecha cuando la competencia es una de: civil, cobranza, laboral, penal. En apelaciones, suprema la plataforma no lo usa. En la búsqueda por rol es opcional siempre, y omitirlo AMPLÍA los resultados."New value: +"Código del tribunal, para acotar la búsqueda. Obligatorio cuando la competencia es una de: civil, cobranza, laboral y penal. En apelaciones y suprema la plataforma no lo usa."
    • removedOutput schema / $defs / CausaEncontrada / description
      Removed value: -"Una fila del listado de resultados de búsqueda.\n\nLos campos opcionales existen porque las competencias no publican las mismas columnas:\nla civil no trae estado ni RUC, la penal trae los dos, y la de apelaciones trae la\nubicación física del expediente. Se declaran como opcionales en vez de inventar un valor,\nporque vacío y ausente no son lo mismo."
    • removedOutput schema / $defs / CausaEncontrada / properties / competencia / description
      Removed value: -"Competencia en la que se encontró."
    • removedOutput schema / $defs / CausaEncontrada / properties / estado / description
      Removed value: -"Lo que la competencia publica en su columna de estado, textual. No es el mismo dato en todas: cobranza publica 'Estado Procesal' y laboral, penal, apelaciones y suprema publican 'Estado Causa'. Civil no publica ninguno. Se entrega sin normalizar para no aplanar dos cosas distintas en una."
    • removedOutput schema / $defs / CausaEncontrada / properties / referencia / description
      Removed value: -"Identificador opaco para pedir el detalle. Caduca a los 30 minutos; no se construye ni se guarda, se usa en el acto."
    • removedOutput schema / $defs / CausaEncontrada / properties / ruc / description
      Removed value: -"Sólo en penal y cobranza."
    • removedOutput schema / $defs / CausaEncontrada / properties / tipo_recurso / description
      Removed value: -"Sólo en suprema."
    • removedOutput schema / $defs / CausaEncontrada / properties / tribunal / description
      Removed value: -"Tribunal o corte donde está radicada. En apelaciones y suprema es la corte."
    • removedOutput schema / $defs / CausaEncontrada / properties / ubicacion / description
      Removed value: -"Sólo en apelaciones."
  2. Addedv0.4.0

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already mark the tool as read-only and idempotent, and the description adds substantial behavioral detail: competencia-specific fields, null meaning absence of publication rather than absence of data, absence of history/partes/notifications, pagination failure instead of silent truncation, and the penal no-detail decision. This goes well beyond the safety profile provided by annotations.

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?

The description is long but organized into thematic paragraphs that each carry useful information. There is minor fluff such as 'Es la cuarta búsqueda que la plataforma ofrece' and the aside 'que existe y se ve bien', but overall the structure makes the dense content navigable.

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?

Given the tool's complexity, the presence of an output schema, and rich annotations, the description is complete: it covers invocation rules, result semantics, null behavior, pagination limits, and the path to obtener_detalle_causa. Nothing material needed to call and interpret this tool correctly is missing.

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?

The input schema already has 100% coverage and detailed descriptions, so the baseline is 3. The tool description adds meaningful cross-parameter context: which competencias require tribunal versus corte, that suprema requires neither, and how to resolve tribunal/corte names for the detail call. Some of this overlaps with the schema, but the operational framing adds value.

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 clearly identifies the resource ('causas ingresadas en un rango de fechas') and the filter being applied, aided by the title's explicit verb. It also distinguishes this tool from sibling searches by explaining the unique scenario it answers ('qué ingresó contra esta empresa esta semana' knowing the tribunal but not the rol).

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?

The description gives explicit when-to-use guidance: date searches must be bounded, and the required bound depends on competencia. It names alternatives such as obtener_detalle_causa and explains when to use listar_tribunales/listar_cortes, while also noting that rol searches do not require bounds.

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

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/notluquis/mcp-pjud-cl'

If you have feedback or need assistance with the MCP directory API, please join our Discord server