Skip to main content
Glama

obter_decisao

Retrieves the available part of a Brazilian court decision—summary, full text, vote, or certificate—after a jurisprudence search, with official URL and timestamp for citation.

Instructions

Obtém a parte disponível de uma decisão do acervo (texto entre delimitadores de documento oficial).

parte: ementa|inteiro_teor|voto|certidao. Muitas fontes trazem só a ementa (STJ espelhos, acórdãos do TJDFT): a parte não capturada devolve parte_indisponivel, nunca outro documento no lugar. status: encontrada | parte_indisponivel | ambiguous (identificador repetido em tribunais distintos: informe tribunal) | nao_encontrado_no_acervo (só o acervo local; não é inexistência). Texto paginado por offset; max_chars padrão 8000, máximo: 50.000. Alternativa (experimental): parte_idx (>= 0) devolve a parte de ordem parte_idx do texto, em partes de parte_tamanho (500 a 10.000; padrão 2.000) pontos de código com sobreposição de 200, e o campo particao (partes_total, intervalo, sha256_parte, sha256_texto); não combina com offset diferente de 0 nem com max_chars. Use depois de pesquisar_jurisprudencia, para ler e citar com url oficial e fetched_at.

Input Schema

NameRequiredDescriptionDefault
idYes
parteNoementa
offsetNo
tribunalNo
max_charsNo
parte_idxNo
parte_tamanhoNo

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed7 schema fields changedv1.3.2
    • addedInput schema / properties / max_chars / anyOf
      Added value: +[
      +  {
      +    "maximum": 50000,
      +    "minimum": 1,
      +    "type": "integer"
      +  },
      +  {
      +    "type": "null"
      +  }
      +]
    • changedInput schema / properties / max_chars / default
      Previous value: -8000New value: +null
    • removedInput schema / properties / max_chars / maximum
      Removed value: -50000
    • removedInput schema / properties / max_chars / minimum
      Removed value: -1
    • removedInput schema / properties / max_chars / type
      Removed value: -"integer"
    • addedInput schema / properties / parte_idx
      Added value: +{
      +  "anyOf": [
      +    {
      +      "maximum": 10000000,
      +      "minimum": 0,
      +      "type": "integer"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null,
      +  "title": "Parte Idx"
      +}
    • addedInput schema / properties / parte_tamanho
      Added value: +{
      +  "anyOf": [
      +    {
      +      "maximum": 10000,
      +      "minimum": 500,
      +      "type": "integer"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null,
      +  "title": "Parte Tamanho"
      +}
  2. Changed1 schema field changedv1.3.0
    • addedInput schema / properties / tribunal
      Added value: +{
      +  "anyOf": [
      +    {
      +      "maxLength": 256,
      +      "type": "string"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null,
      +  "title": "Tribunal"
      +}
  3. 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 the non-substitution guarantee ("nunca outro documento no lugar"), the four possible status outcomes, that nao_encontrado_no_acervo refers only to the local corpus and not to real-world nonexistence, and that partial text is paged. It also states the mutual-exclusion rules between parte_idx and offset/max_chars, which an agent could not infer from the schema.

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?

Purpose is front-loaded in the first sentence, followed by parameter semantics and then usage, which is a sensible order. The middle paragraph is dense and runs statuses, paging and the experimental alternative together without line breaks, so it reads as a block rather than scannable chunks, but almost every clause carries non-obvious information.

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 seven-parameter read tool with no annotations and two competing paging modes, the description covers failure modes, ambiguity handling, limits and mode incompatibility, and an output schema already documents return fields such as `particao`. The remaining gap is `id`: where it comes from and what it looks like is only implied.

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

Parameters5/5

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

Schema coverage is 0%, so the description must define all seven parameters, and it defines six of them meaningfully: parte's enum values, offset as paging, max_chars default 8000 / cap 50.000, parte_idx ordering semantics with parte_tamanho range 500–10.000, default 2.000 and 200-codepoint overlap, plus tribunal's role in disambiguation. Only `id` is left without format or provenance detail beyond the implied link to pesquisar_jurisprudencia.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

"Obtém a parte disponível de uma decisão do acervo" gives a specific verb and resource, and the parenthetical delimits the return as official-document text. It also names the sibling predecessor (pesquisar_jurisprudencia), so the agent can place it in a workflow, though it doesn't explicitly contrast with obter_evidencia or obter_registro.

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

Usage Guidelines4/5

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

"Use depois de pesquisar_jurisprudencia, para ler e citar com url oficial e fetched_at" states the entry condition and downstream use, and the status list tells the agent what to do when the identifier is ambiguous (informe `tribunal`). It stops short of explicit when-not-to-use guidance versus the other lookup siblings.

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