Skip to main content
Glama
Sign In
FREOA Verifica

FREOA Verifica

by rickfreoa
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

pesquisar_jurisprudencia

Searches Brazilian case law by topic, CNJ number, or court class and number across covered courts and sources, returning candidate decisions with per-court coverage notes.

Instructions

Pesquisa jurisprudência por tema, por número CNJ ou por classe e número, nas fontes cobertas.

Recorte por tribunal (listar_fontes traz o do acervo instalado): STJ, ementas de espelhos mensais, só acervo local; TCU, acórdãos do recorte instalado, sem busca ao vivo; STF, súmulas e súmulas vinculantes (busca livre sob WAF, sem contorno); TJDFT, semente temática e API oficial ao vivo (acórdão só com ementa); CVM Colegiado, decisões da semente; TJSP, consulta pontual (CAPTCHA, sem contorno). Aceita siglas e nomes dos tribunais. Busca temática é lexical, não semântica.

Devolve CANDIDATOS, não prova. status: ok | parcial (truncado ou parte indisponível) | indisponivel | nao_confirmado_no_acervo (só acervo local; não é inexistência). O bloco cobertura diz, por tribunal, o que foi consultado (acervo, ao vivo), o recorte, o total informado pela fonte (nulo se ela não informou) e o motivo de não ter consultado: leia-o antes de concluir que algo não existe e complemente em outra fonte. Depois: obter_decisao. Pode gravar cache local. limite máximo: 50.

Input Schema

NameRequiredDescriptionDefault
qYes
ateNo
desdeNo
cursorNo
limiteNo
tribunaisNo
autoridade_minNo

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv1.3.0
    • changedInput schema / properties / tribunais / anyOf
      Previous value: -[
-  {
-    "items": {
-      "enum": [
-        "stj",
-        "tcu",
-        "tjsp",
-        "cvm",
-        "cvm_colegiado"
-      ],
-      "maxLength": 32,
-      "type": "string"
-    },
-    "maxItems": 5,
-    "type": "array"
-  },
-  {
-    "type": "null"
-  }
-]New value: +[
+  {
+    "items": {
+      "maxLength": 256,
+      "type": "string"
+    },
+    "maxItems": 5,
+    "type": "array"
+  },
+  {
+    "type": "null"
+  }
+]
  2. First observedv1.0.0

TDQS

A4.4/5.0
Behavior5/5

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

With no annotations, the description carries the full burden and does so: it discloses that results are 'CANDIDATOS, não prova', enumerates the status vocabulary (ok | parcial | indisponivel | nao_confirmado_no_acervo) with the key caveat that the last is not proof of nonexistence, warns that search is lexical not semantic, and notes local cache writes. That is unusually rich disclosure for a retrieval tool.

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 core verb and the source enumeration, then the return-semantics caveats — a sensible order. The per-tribunal recorte block is long but each clause carries distinct operational information; only the 'limite máximo: 50' line is wasted repetition.

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

Completeness4/5

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

For a multi-source, multi-modal retrieval tool this covers the hard parts: coverage semantics, failure modes, and next-step routing (an output schema exists, so return shape needn't be spelled out). The gap is the four undocumented parameters, which leaves the agent guessing about date filtering and pagination.

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

Parameters2/5

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

Schema description coverage is 0% across 7 parameters, so the description must compensate and largely doesn't: `desde`, `ate`, `cursor` and `autoridade_min` are never mentioned. It adds real meaning for `q` (the three query forms) and `tribunais` (aceita siglas e nomes), but 'limite máximo: 50' merely restates the schema's maximum rather than explaining pagination interaction with `cursor`.

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 resource ('Pesquisa jurisprudência') plus the three search modes (tema, número CNJ, classe e número) and the scope ('nas fontes cobertas'). It also names the sibling it hands off to (obter_decisao) and the one that enumerates the corpus (listar_fontes), so the agent can distinguish it from neighbors 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.

Usage Guidelines5/5

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

Per-tribunal guidance is explicit: which sources are live vs. local-only, where a CAPTCHA or WAF blocks scraping, and what each court returns (e.g. 'TCU ... sem busca ao vivo', 'acórdão só com ementa'). It also states the sequencing rule — read `cobertura` before concluding something doesn't exist, then complement in another source, then call obter_decisao.

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