Skip to main content
Glama

astrea_processos_por_cliente

Read-onlyIdempotent

Processos (casos) no Astrea. Respostas COMPACTAS pra economizar contexto. Ações:

  • buscar: ACHA o processo pelo NÚMERO CNJ (ou trecho dele) e/ou por texto do título/cliente, devolvendo o id interno que as outras tools pedem (case_id). Mande TODOS os números de uma vez em numeros[] — a busca varre a conta UMA vez pra lista inteira (triagem de publicações: 30 números = 1 chamada). Por padrão inclui encerrados (status "All"), que é onde ficam execuções/recursos antigos. Resposta: encontrados[{consulta, processos[]}], nao_encontrados[], varredura{paginas, processos_varridos, truncado}. truncado=true significa que a varredura parou antes do fim (já achou tudo que foi pedido, ou bateu o teto) — pode haver outros processos casando um número PARCIAL.

  • list: UMA página de processos (não varre a conta toda). Filtros: contact_id, tag_id, status. Pagine com cursor (devolvido em cada resposta). Pra achar UM processo específico use buscar, não pagine list.

  • count: total de processos (mesmos filtros) rápido, use pra "quantos".

  • por_cliente: resumo por cliente (qtd + soma do valor da causa), ordenado. Use top_n pra limitar. Respeita o status. Sem o detalhe dos processos, pra detalhar chame list com contact_id.

  • novos_por_mes: nº de processos novos por mês (data de distribuição). Respeita o status. por_cliente e novos_por_mes varrem a conta e também devolvem varredura{paginas, processos_varridos, truncado, motivo}. truncado=true significa que o resultado é PARCIAL (motivo "tempo" = a conta é grande demais pra varrer inteira numa chamada; "teto_de_paginas" = passou de 5000 processos) — diga isso ao usuário em vez de apresentar o número como total do escritório, e use count pro total exato ou list com filtros pra recortar. Campos por processo (list): id, number, customer/customerId, title, court, lawsuitType, amount (valor da causa), convictionAmount (valor da condenação, só vem quando preenchido no Astrea), distribuitionDate, lastMovement, active (true=em andamento, false=encerrado), currentInstanceNumber (grau/instância), situacao (rótulo pronto, ex.: "Encerrado 1º Grau"), tagIds.

[Flattened action: por_cliente]

Bulk support: accepts contact_ids, tag_ids for batched execution.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNo
textoNo
top_nNo
cursorNo
statusNo
tag_idNo
numerosNo
tag_idsNo
contact_idNo
contact_idsNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changed
    • addedInput schema / properties / numeros
      Added value: +{
      +  "items": {
      +    "type": "string"
      +  },
      +  "type": "array"
      +}
    • removedInput schema / properties / status / default
      Removed value: -"Active"
    • addedInput schema / properties / texto
      Added value: +{
      +  "type": "string"
      +}
  2. Changed1 schema field changed
    • changedInput schema / properties / status / enum
      Previous value: -[
      -  "Active",
      -  "Archived"
      -]New value: +[
      +  "Active",
      +  "Inactive",
      +  "Archived",
      +  "All"
      +]
  3. First observed

TDQS

A3.7/5.0
Behavior5/5

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

The description goes far beyond the readOnly/idempotent annotations by disclosing concrete behavior: numeros[] enables a single account scan for a batch, status 'All' includes closed cases by default, list pages instead of scanning the whole account, and por_cliente/novos_por_mes return varredura with truncado/motivo to signal partial results. It even instructs the agent to tell the user when a total is partial rather than presenting it as complete. No contradiction with annotations exists.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The bullet structure is readable and information is front-loaded, but the text is long and includes full instructions for multiple actions that may be out of scope for this flattened por_cliente tool. The '[Flattened action: por_cliente]' line is cryptic rather than a clear natural-language statement, so not every sentence earns its place.

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?

Given the absence of an output schema, the description covers return shapes and edge cases well: encontrados/nao_encontrados/varredura for buscar, truncation semantics with motivo for por_cliente/novos_por_mes, and per-process fields for list. It also tells the agent how to recurse to count or list for exact/partial results. Missing are the meaning of limit and an explicit statement of which action this flattened tool actually executes.

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?

With 0% schema description coverage, the description does substantial work: it explains numeros[] batching, the status default and meaning, cursor pagination, top_n limiting, contact_id/tag_id filters, and bulk contact_ids/tag_ids. The main gap is the 'limit' parameter, which is never explicitly described, and some parameters like numeros/texto belong to other actions, leaving parameter-to-action mapping ambiguous.

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

Purpose3/5

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

The description does contain a valid por_cliente definition ('resumo por cliente (qtd + soma do valor da causa), ordenado') and names the Astrea process resource, so it is not a tautology. However, it presents a broad multi-action 'Ações' list for buscar/list/count/novos_por_mes and only reveals the actual tool purpose via a single bullet plus the cryptic '[Flattened action: por_cliente]' footer. This muddles the tool's scope and does not clearly distinguish it from sibling tools like astrea_processos_list and astrea_processos_count.

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

Usage Guidelines3/5

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

There is useful internal guidance, such as 'Pra achar UM processo específico use buscar, não pagine list' and 'use count pro total exato', which tells the agent when to choose one operation over another. But the guidance treats alternatives as sub-actions instead of naming the sibling MCP tools, and if this tool is truly flattened to por_cliente only, much of the guidance points to operations handled by other tools. The conditions to use this tool versus siblings are implied, not explicit.

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.