Skip to main content
Glama
cmsdutra

mcp-pje-trf1

by cmsdutra
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

mcp-pje-trf1

Servidor MCP local, em TypeScript, para automação de consulta e download de documentos do PJe do TRF1 por usuários autenticados. O servidor usa Node.js, @modelcontextprotocol/sdk, Playwright, Chromium e transporte MCP via stdio.

O servidor implementa a infraestrutura segura de sessão, filesystem, MCP, logging, validação CNJ, manifesto de downloads e testes, além da navegação autenticada real de processos e documentos (consulta de metadados, listagem da timeline dos autos digitais e download de documentos).

Arquitetura

src/
├── server.ts
├── config.ts
├── types.ts
├── cli/
│   ├── auth.ts
│   └── inspect.ts
├── pje/
│   ├── client.ts
│   ├── auth.ts
│   ├── urls.ts
│   ├── autos.ts          # navegação + extração do DOM dos autos digitais (Playwright)
│   ├── autos-parse.ts    # parsing puro dos dados extraídos (sem Playwright, testável)
│   ├── process.ts
│   ├── documents.ts
│   ├── downloads.ts
│   ├── inspect.ts
│   └── selectors.ts
├── utils/
│   ├── cnj.ts
│   ├── filesystem.ts
│   ├── logger.ts
│   └── errors.ts
└── tools/
    ├── consultar-processo.ts
    ├── listar-documentos.ts
    ├── baixar-documento.ts
    ├── baixar-inteiro-teor.ts
    └── status-autenticacao.ts

Related MCP server: playwright-sse-mcp-server

Requisitos

  • Node.js 22 ou superior.

  • Chromium instalado pelo Playwright.

  • Conta PJe TRF1 com acesso legítimo aos processos consultados.

Instalação

Clone local

git clone https://github.com/cmsdutra/trf1-pje-mcp-bridge.git
cd trf1-pje-mcp-bridge
npm install
npx playwright install chromium
npm run build

Também há scripts para instalar as dependências e compilar:

.\scripts\install-deps.ps1
sh scripts/install-deps.sh

Para instalar dependências sem compilar:

.\scripts\install-deps.ps1 -SkipBuild
sh scripts/install-deps.sh --skip-build

Direto do GitHub

Para registrar o servidor sem manter um clone manual, use npx com o repositório GitHub. O pacote executa npm run build durante a instalação via script prepare.

codex mcp add pje-trf1 -- npx -y github:cmsdutra/trf1-pje-mcp-bridge

O Chromium do Playwright precisa existir na máquina de destino. Instale uma vez:

npx -y playwright install chromium

Configuração

Copie .env.example para .env se quiser sobrescrever padrões:

PJE_DOWNLOAD_DIR=
PJE_STORAGE_STATE_PATH=
PJE_HEADLESS=true
LOG_LEVEL=info

Sem sobrescrita, o MCP usa diretórios persistentes do usuário:

  • Windows: %APPDATA%\mcp-pje-trf1\downloads e %APPDATA%\mcp-pje-trf1\storage-state.json.

  • Linux/macOS: ~/.mcp-pje-trf1/downloads e ~/.mcp-pje-trf1/storage-state.json.

O diretório de downloads é a raiz autorizada para gravações. Caminhos que escapem dessa raiz são bloqueados.

Autenticação

npm run auth

O comando abre Chromium visível, navega até o PJe e aguarda o login manual. Ele não preenche senha, não automatiza certificado digital, não contorna MFA, não resolve CAPTCHA e não salva credenciais. Após confirmação, salva apenas o storageState do Playwright no caminho configurado.

Para autenticar diretamente no segundo grau:

npm run auth -- 2

Em instalação direta via GitHub/npx:

npx -y -p github:cmsdutra/trf1-pje-mcp-bridge mcp-pje-trf1-auth
npx -y -p github:cmsdutra/trf1-pje-mcp-bridge mcp-pje-trf1-auth 2

Interface autenticada mapeada

consultar_processo, listar_documentos e baixar_inteiro_teor/baixar_documento operam sobre a tela de autos digitais (Processo/ConsultaProcesso/Detalhe/listAutosDigitais.seam), uma página JSF/RichFaces server-rendered. Ela é uma superfície distinta do painel do usuário interno — este último é uma SPA Angular servida num iframe cross-origin e não é usada por nenhuma das tools.

O fluxo implementado (src/pje/autos.ts) é:

  1. GET <baseUrl>/seam/resource/rest/pje-legacy/processo/<numeroCnj>/enderecoAutos devolve, em texto puro, a URL dos autos digitais já com o idProcesso interno e o token de navegação ca. É o mesmo endpoint que a caixa "Acesso rápido" do menu lateral do PJe chama ao pressionar Enter, então basta o cookie de sessão — não é preciso reproduzir o popup de busca rápida.

  2. Navegação para essa URL e leitura do cabeçalho (#maisDetalhes, #poloAtivo, #poloPassivo) e da timeline (#divTimeLine). A timeline usa rolagem infinita: as páginas restantes são carregadas via novaPagina() até #paginaAtual alcançar #totalPaginas.

  3. Download por HTTP direto em <baseUrl>/seam/resource/rest/pje-legacy/documento/download/<idProcessoDocumento> (a mesma URL que o visualizador do PJe usa como src do iframe), com fallback para a variante .../download/<TRIBUNAL>/<grau>g/<idProcesso>/<id> usada pelo botão "abrir em outra aba".

Armadilhas confirmadas contra o PJe real

Todas custaram uma rodada de depuração; estão codificadas na implementação e não devem ser "simplificadas":

  • O número tem de ir com máscara (0000000-00.0000.0.00.0000) no enderecoAutos. A forma só-dígitos, embora aceita pelo regex do JavaScript da própria tela do PJe, faz o endpoint responder 204 No Content.

  • 204 No Content é o "não encontrei" desse endpoint (não 404). Ele também aparece de forma transitória, daí a retentativa única antes de concluir PROCESS_NOT_FOUND.

  • A URL precisa terminar com &aba=. O endpoint devolve sem esse parâmetro, mas o navegador real sempre acaba com ele; navegar sem aba= joga o Seam em error.seam de forma intermitente.

  • A abertura dos autos falha esporadicamente mesmo assim (error.seam?cid=...), por instabilidade do Seam. abrirAutosDigitais tenta duas vezes, resolvendo um ca novo — observado corrigindo a falha em execução real.

  • listAutosDigitais.seam abre uma conversação do Seam: não navegue para ela duas vezes na mesma aba. Por isso baixarInteiroTeor abre os autos uma única vez e tira cabeçalho e timeline da mesma página.

  • O desempenho do PJe oscila muito. O mesmo lote de 14 documentos levou 12s numa execução e mais de 160s em outra, com um PDF de ~1 MB estourando o timeout. Downloads são retentados até 3 vezes em erro de rede ou 5xx.

Notas de implementação relevantes para quem for mexer nisso:

  • Documentos redigidos no editor do PJe são devolvidos como HTML; só os anexos costumam ser PDF. A extensão do arquivo gravado vem do content-type da resposta, não de uma suposição. (No processo usado como teste: 6 peças em text/html, 8 anexos em application/pdf.)

  • IDs gerados pelo JSF (j_id...) mudam a cada build da aplicação e não são usados como seletores.

  • Não existe mais uma flag authenticatedSelectors.inspected. O sinal de "a interface mudou" é a ausência, em tempo de execução, dos elementos esperados — o que também cobre mudanças futuras do PJe.

  • O token ca é removido da URL antes de ela ir para ProcessoMetadata.url/manifest.json, para não vazar credencial de sessão em arquivo exportado.

  • Uma falha ao paginar a timeline aborta com PJE_INTERFACE_CHANGED em vez de devolver lista parcial: uma listagem incompleta de documentos de um processo judicial é pior do que um erro explícito.

Reinspecionar após mudança do PJe

Se a interface mudar, recapture os artefatos com sessão real e reveja src/pje/selectors.ts:

npm run inspect -- 0000000-00.0000.4.01.0000
npm run inspect -- 0000000-00.0000.4.01.0000 2

Em instalação direta via GitHub/npx:

npx -y -p github:cmsdutra/trf1-pje-mcp-bridge mcp-pje-trf1-inspect 0000000-00.0000.4.01.0000

O comando abre Chromium visível com a sessão salva, pausa em dois pontos (abertura do processo — que no PJe já mostra os autos digitais/lista de documentos — e abertura/download de um documento) aguardando você navegar manualmente, e grava HTML, screenshots e metadados de rede em <PJE_STORAGE_STATE_PATH.../>inspection/<timestamp>/ (fora do repositório por padrão).

Atenção: os arquivos capturados contêm dados reais do processo consultado (partes, documentos). Use apenas processos aos quais sua conta PJe tenha acesso legítimo, e não commite nem compartilhe os arquivos gerados sem necessidade.

Execução

npm start

O servidor MCP usa stdio.

Tools MCP

  • status_autenticacao: informa se há sessão salva, se parece válida, grau verificado e se precisa de nova autenticação.

  • autenticar: abre Chromium visível para autenticação manual. Para uso operacional, prefira npm run auth.

  • consultar_processo: valida número CNJ, abre os autos digitais e devolve classe, assunto, órgão julgador, partes e representantes, data de distribuição, idProcesso interno e os demais detalhes do cabeçalho.

  • listar_documentos: valida número CNJ, carrega a timeline completa dos autos digitais e devolve os documentos em ordem cronológica (movimentos sem documento anexado são descartados; anexos vêm junto do documento principal).

  • baixar_documento: valida entrada, protege o diretório de destino e baixa um documento pelo documento_id (o idProcessoDocumento devolvido por listar_documentos).

  • baixar_inteiro_teor: cria diretório exclusivo, lista documentos, baixa cada item sem abortar o lote e gera manifest.json. Usa uma única sessão de navegador para todo o processo.

Downloads

Estrutura gerada por baixar_inteiro_teor:

downloads/
└── 0000000-00.0000.4.01.0000/
    ├── manifest.json
    ├── 001_peticao_inicial.html
    ├── 002_procuracao_(2_procuracao).pdf
    ├── 003_documento_de_identificacao_(6_rg).pdf
    └── 004_decisao.html

O prefixo numérico é a ordem cronológica do documento nos autos. A extensão vem do content-type da resposta — peças escritas no editor do PJe são .html e anexos costumam ser .pdf (ver "Interface autenticada mapeada").

O manifest.json contém número do processo, grau, data/hora da coleta, URL de origem, metadados do processo, totais e status individual de cada documento (incluindo contentType e bytes do que foi gravado). Nada é sobrescrito: numa segunda coleta do mesmo processo, o manifesto anterior é preservado e o novo vira manifest-1.json, e arquivos com nome repetido ganham sufixo -1, -2, ...

Segurança

Este MCP reproduz somente operações que o usuário autenticado poderia executar pela interface do PJe. Ele não implementa bypass de autenticação, CAPTCHA, MFA, certificado digital, segredo de justiça ou controle de acesso. Cookies, tokens, headers de autenticação, credenciais e storageState nunca são retornados por tools MCP nem registrados em logs.

Logs estruturados vão para stderr nos níveis error, warn, info e debug.

Codex CLI

A sintaxe verificada localmente em 07/08/2026 é:

Para instalação direta do GitHub:

codex mcp add pje-trf1 -- npx -y -p github:cmsdutra/trf1-pje-mcp-bridge mcp-pje-trf1

Para clone local com caminho absoluto:

codex mcp add pje-trf1 -- node "C:\Users\to48109\Documents\500 - Drive\100 - Projetos\trf1-pje-mcp-bridge\dist\server.js"

Configuração TOML equivalente para clone local:

[mcp_servers.pje-trf1]
command = "node"
args = ["C:\\Users\\to48109\\Documents\\500 - Drive\\100 - Projetos\\trf1-pje-mcp-bridge\\dist\\server.js"]
startup_timeout_sec = 120.0

[mcp_servers.pje-trf1.env]
LOG_LEVEL = "error"

Configuração TOML equivalente para GitHub/npx:

[mcp_servers.pje-trf1]
command = "npx"
args = ["-y", "-p", "github:cmsdutra/trf1-pje-mcp-bridge", "mcp-pje-trf1"]
startup_timeout_sec = 120.0

[mcp_servers.pje-trf1.env]
LOG_LEVEL = "error"

Após alterar ~/.codex/config.toml, reinicie completamente o cliente Codex ou ChatGPT Desktop e use /mcp para confirmar que pje-trf1 foi inicializado.

Configuração por projeto

Para restringir o MCP a um projeto específico, crie .codex/config.toml dentro desse projeto em vez de usar a configuração global. Exemplo com caminho relativo para um clone local do servidor:

[mcp_servers.pje-trf1]
command = "node"
args = ["..\\..\\..\\Documents\\500 - Drive\\100 - Projetos\\trf1-pje-mcp-bridge\\dist\\server.js"]
cwd = "."
startup_timeout_sec = 120.0

[mcp_servers.pje-trf1.env]
PJE_DOWNLOAD_DIR = "Sandbox"
LOG_LEVEL = "error"

Com cwd = ".", valores relativos como PJE_DOWNLOAD_DIR = "Sandbox" são resolvidos a partir da raiz do projeto que contém .codex/config.toml. Isso evita PATH_TRAVERSAL ao baixar para uma pasta de trabalho local. Se usar configuração por projeto, remova a seção global [mcp_servers.pje-trf1] de ~/.codex/config.toml para evitar duplicidade.

Práticas Iniciais Recomendadas

Comece verificando se o servidor está ativo no cliente:

/mcp

Em seguida, teste a sessão autenticada em linguagem natural:

Use o MCP pje-trf1 para verificar o status da autenticação.

Se a sessão estiver ausente ou expirada, autentique novamente:

npx -y -p github:cmsdutra/trf1-pje-mcp-bridge mcp-pje-trf1-auth

Depois do status válido, faça testes graduais antes de baixar documentos:

Use o MCP pje-trf1 para consultar o processo 0000000-00.0000.4.01.0000 no 1º grau.
Use o MCP pje-trf1 para listar os documentos do processo 0000000-00.0000.4.01.0000 no 1º grau.
Use o MCP pje-trf1 para baixar o inteiro teor do processo 0000000-00.0000.4.01.0000 no 1º grau.

Use apenas processos aos quais sua conta PJe tenha acesso legítimo.

Desenvolvimento

npm test
npm run build
npm run lint

Inspeção realizada

Inspeção pública com Playwright em 07/08/2026:

  • https://pje1g.trf1.jus.br/pje/login.seam redireciona para SSO sso.cloud.pje.jus.br, client ID pje-trf1-1g.

  • https://pje2g.trf1.jus.br/pje/login.seam redireciona para SSO sso.cloud.pje.jus.br, client ID pje-trf1-2g.

  • Login público expõe campos #username, #password, botão #kc-login e botão de certificado #kc-pje-office.

  • Consulta pública redireciona para pje1g-consultapublica.trf1.jus.br e pje2g-consultapublica.trf1.jus.br.

  • Consulta pública usa campo #fPP\:numProcesso-inputNumeroProcessoDecoration\:numProcesso-inputNumeroProcesso e botão #fPP\:searchProcessos.

Inspeção autenticada com sessão real em 07/08/2026 (grau 1), origem dos seletores e endpoints hoje implementados:

  • A área autenticada tem duas superfícies distintas: o painel do usuário interno (SPA Angular em iframe cross-origin, com shadow DOM) e os autos digitais (listAutosDigitais.seam, JSF server-rendered). Só a segunda é usada pelas tools.

  • Nenhuma chamada JSON de API sustenta a tela de autos digitais — a estratégia correta é raspagem do HTML server-rendered, complementada pelos dois endpoints REST legados (.../processo/<cnj>/enderecoAutos e .../documento/download/<id>).

  • Detalhes de fluxo, seletores e decisões estão em "Interface autenticada mapeada" e em src/pje/selectors.ts.

Validação fim a fim

Em 07/08/2026 as três tools foram executadas contra um processo real do 1º grau, com sessão legítima:

  • consultar_processo: cabeçalho, 15 campos de detalhe e 7 partes/representantes dos dois polos.

  • listar_documentos: 14 documentos (6 principais + 8 anexos) em ordem cronológica correta, apesar de a timeline vir em ordem decrescente no DOM.

  • baixar_inteiro_teor: 14/14 baixados, 0 erros, em ~12s. Arquivos íntegros no disco (PDFs com assinatura %PDF-), manifest.json completo e sem vazar o token ca nem o JSESSIONID.

As retentativas descritas em "Armadilhas confirmadas" não são teóricas: a de error.seam e a de download por falha de rede foram observadas salvando execuções reais.

Troubleshooting

  • SESSION_MISSING: autentique com npm run auth no clone local ou npx -y -p github:cmsdutra/trf1-pje-mcp-bridge mcp-pje-trf1-auth na instalação via GitHub/npx.

  • SESSION_EXPIRED: repita a autenticação manual com o mesmo comando usado inicialmente.

  • PJE_INTERFACE_CHANGED: os elementos esperados não foram encontrados na página — a interface do PJe mudou desde o último mapeamento. Rode npm run inspect -- <numero-processo> (ver "Reinspecionar após mudança do PJe") e atualize src/pje/selectors.ts/src/pje/autos.ts com os artefatos capturados.

  • PROCESS_NOT_FOUND / PROCESS_NOT_ACCESSIBLE: o processo não existe naquele grau ou a conta autenticada não tem acesso a ele. Confira o número e o grau.

  • DOCUMENT_NOT_FOUND / DOCUMENT_NOT_ACCESSIBLE: o documento_id não existe ou está fora do alcance da sessão. Use um documento_id vindo de listar_documentos.

  • DOWNLOAD_FAILED / TIMEOUT: o PJe não respondeu a tempo mesmo após as retentativas automáticas. Costuma ser lentidão momentânea do PJe — repita a chamada. Em baixar_inteiro_teor o lote não é abortado: o documento que falhou fica com status: "erro" no manifest.json e os demais são baixados normalmente.

  • INVALID_INPUT: número CNJ malformado/dígito verificador inválido, ou documento_id vazio.

  • "O PJe redirecionou a abertura dos autos para uma página de erro": instabilidade do Seam, não mudança de interface. Tente novamente em alguns instantes.

  • Erro de Chromium: execute npx playwright install chromium.

  • Downloads fora da raiz configurada são recusados por proteção contra path traversal.

Perguntas Frequentes

O servidor MCP precisa ser iniciado manualmente?

Não no uso normal. O Codex inicia o processo configurado em ~/.codex/config.toml quando abre uma sessão. Inicie manualmente apenas para diagnóstico.

O que fazer se aparecer MCP startup interrupted?

Prefira a configuração com binário explícito, aumente startup_timeout_sec e defina LOG_LEVEL = "error". Em Windows, se npx falhar no app mas funcionar no PowerShell, use clone local com caminho absoluto para node.exe e dist/server.js.

Como vejo as tools disponíveis?

No Codex, use /mcp. Se pje-trf1 estiver ativo, peça as ações em linguagem natural, por exemplo: "Use o MCP pje-trf1 para verificar o status da autenticação."

Onde ficam sessão e downloads por padrão?

No Windows, em %APPDATA%\mcp-pje-trf1\storage-state.json e %APPDATA%\mcp-pje-trf1\downloads. Em Linux/macOS, em ~/.mcp-pje-trf1/.

Como configuro downloads em uma pasta do projeto?

Use uma variável relativa no .codex/config.toml do projeto:

[mcp_servers.pje-trf1.env]
PJE_DOWNLOAD_DIR = "Sandbox"

Crie a pasta Sandbox/ ou deixe o MCP criá-la quando fizer o primeiro download. Não passe caminhos absolutos como argumento da tool se eles estiverem fora da raiz configurada.

Posso usar .env com instalação via GitHub?

Sim, mas variáveis declaradas no config.toml do Codex são mais previsíveis para servidores MCP iniciados pelo cliente. Use PJE_DOWNLOAD_DIR, PJE_STORAGE_STATE_PATH, PJE_HEADLESS e LOG_LEVEL em [mcp_servers.pje-trf1.env].

Available Tools

6 tools
autenticarA

Abre Chromium visível para autenticação manual e salva storageState. Não automatiza credenciais, MFA, CAPTCHA ou certificado.

ParametersJSON Schema
NameRequiredDescriptionDefault
grauNo1

TDQS

A3.8/5.0
Behavior4/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It states that the tool opens a visible Chromium window and saves storageState, which is a side effect. It also explicitly discloses what the tool does NOT do (automate credentials, MFA, CAPTCHA, certificate). This is good transparency, though it omits details like storage location or prerequisites.

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

Conciseness5/5

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

The description is concise, consisting of exactly two sentences that deliver the essential information: what the tool does and what it does not do. Every word earns its place, and the structure is front-loaded with the main action followed by limitations. No unnecessary filler.

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

Completeness3/5

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

The tool is relatively simple with one optional parameter and no output schema. The description covers the core behavior well, but it omits explanation of the 'grau' parameter, which is a significant gap for correct invocation. It also lacks context on how this fits with sibling tools (e.g., that it should precede data access tools), but given the tool's simplicity, the description is minimally adequate yet incomplete.

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

Parameters1/5

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

The description does not mention the only parameter, 'grau', at all. The schema has an enum of '1' or '2' with a default, but no description of what these values mean. Since schema description coverage is 0%, the description should compensate, but it fails to provide any semantic meaning, leaving the agent guessing about the parameter's purpose.

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 states the tool's purpose: 'Abre Chromium visível para autenticação manual e salva storageState' (opens visible Chromium for manual authentication and saves storageState). It also distinguishes from siblings by focusing on authentication, not queries or downloads. The negative statement about not automating credentials/MFA/CAPTCHA/certificate adds further clarity.

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?

The description provides clear context for when to use the tool: when manual authentication is needed, as opposed to automated. It explicitly excludes automating credentials, MFA, CAPTCHA, or certificates, which signals when not to rely on this tool for automated flows. However, it does not name specific alternatives among sibling tools, so it stops short of full guidance.

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

baixar_documentoB

Baixa um documento acessível do processo preservando o arquivo original quando disponível.

ParametersJSON Schema
NameRequiredDescriptionDefault
grauYes
documento_idYes
numero_processoYes
diretorio_destinoNo

TDQS

B3/5.0
Behavior3/5

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

The description reveals a meaningful behavioral trait: it preserves the original file when available. However, with no annotations, it does not disclose authentication needs, error behaviors, or side effects. The single nuance is helpful but incomplete for a tool operating on legal documents.

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

Conciseness5/5

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

The description is a single sentence that conveys purpose and a key behavior. It is concise and free of filler, earning every word.

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

Completeness2/5

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

For a tool with four parameters, no annotations, and no output schema, the description is too sparse. It does not cover authentication requirements, output format, or the meaning of parameters, making it insufficient for an agent to use the tool confidently in real scenarios.

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 coverage is 0% and the description mentions no parameter names or meanings. The required parameters (numero_processo, grau, documento_id) are undocumented, and the optional diretorio_destino is not explained. The description's reference to 'processo' and 'documento' provides only general context, not parameter-level semantics.

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?

The description clearly states the action ('Baixa') and the resource ('documento acessível do processo'), and adds a distinguishing detail about preserving the original file. It is specific enough to differentiate from siblings like baixar_inteiro_teor, though it does not explicitly name alternatives.

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

Usage Guidelines2/5

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

There is no guidance on when to use this tool versus siblings such as listar_documentos or baixar_inteiro_teor. The description does not mention prerequisites like authentication, which is a notable omission given the sibling tool autenticar.

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

baixar_inteiro_teorB

Baixa todos os documentos acessíveis do processo em diretório exclusivo e gera manifest.json.

ParametersJSON Schema
NameRequiredDescriptionDefault
grauYes
numero_processoYes
diretorio_destinoNo

TDQS

B3.1/5.0
Behavior2/5

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

No annotations are provided, so the description carries the burden. It mentions creating an exclusive directory and manifest.json, which is useful, but omits critical behavioral details such as authentication requirements, error handling for inaccessible documents, whether the directory is overwritten, or any rate limits. The description gives a brief high-level effect but not enough for safe invocation.

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

Conciseness5/5

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

The description is a single sentence with no fluff, immediately stating the action and output. It is appropriately sized and front-loaded, wasting no words.

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

Completeness2/5

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

For a tool with three parameters, no output schema, and no annotations, the description is too thin. It does not explain the meaning of grau, the optional diretorio_destino, what manifest.json contains, or any prerequisites like authentication. The existence of sibling tools (e.g., baixar_documento) is not leveraged to clarify boundaries, leaving the overall context incomplete.

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

Parameters1/5

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

Schema description coverage is 0%, and the description does not explain any of the three parameters (numero_processo, grau, diretorio_destino). While parameter names are somewhat self-explanatory, the description fails to clarify the meaning of 'grau' (degree/instance) or the role of diretorio_destino, leaving the agent to guess. No compensation for low schema coverage.

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 states the tool downloads all accessible documents from a process and generates a manifest.json file. It distinguishes itself from sibling tools like baixar_documento (singular download) and listar_documentos (listing) by focusing on bulk download.

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?

The usage context is implied: use this when you need all accessible documents from a process, as opposed to baixar_documento for a single document. However, there is no explicit 'when to use' or direct comparison with alternatives, leaving some ambiguity for an agent.

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

consultar_processoB

Consulta metadados de processo PJe TRF1 acessível à sessão autenticada.

ParametersJSON Schema
NameRequiredDescriptionDefault
grauYes
numero_processoYes

TDQS

B3/5.0
Behavior2/5

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

No annotations are provided, so the description must carry the behavioral burden. It only discloses that the tool requires an authenticated session, but does not state whether it is read-only, side-effect free, or describe return format or error conditions.

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 a single concise sentence that is front-loaded with the action and resource. It is efficient but may be too sparse for the missing schema context.

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

Completeness2/5

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

With no output schema and no parameter descriptions, the description is incomplete for this tool. It fails to mention what metadata is returned or how to format the parameters, though the tool is relatively simple.

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

Parameters1/5

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

Schema description coverage is 0%, and the description does not explain the parameters. While the schema defines 'grau' with an enum and 'numero_processo' as a string, no additional meaning is provided, leaving the agent to infer format and purpose.

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 explicitly states 'Consulta metadados de processo' (queries process metadata) for PJe TRF1, using a specific verb and resource. This distinguishes it from siblings like 'listar_documentos' and 'baixar_documento' which focus on documents.

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?

The description implies usage via the query verb but does not provide explicit when-to-use guidance or mention alternatives. The phrase 'acessível à sessão autenticada' indicates an authentication prerequisite but no exclusions or comparison with sibling tools.

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

listar_documentosB

Lista documentos do processo acessíveis à sessão autenticada.

ParametersJSON Schema
NameRequiredDescriptionDefault
grauYes
numero_processoYes

TDQS

B3.1/5.0
Behavior3/5

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

With no annotations, the description carries a heavy transparency burden. It does disclose that results are filtered by the authenticated session's access, which is a meaningful behavioral trait. However, it does not describe the return format (metadata vs. content), pagination, ordering, or error behavior.

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

Conciseness5/5

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

A single, tightly written sentence that front-loads the action and includes the essential access constraint. There is no wasted wording or unnecessary repetition.

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

Completeness2/5

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

Although the tool is simple, the description leaves out return-value details and fully explains neither the parameters nor the authentication flow. Without annotations or an output schema, this is under-specified for reliable agent invocation.

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

Parameters1/5

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

Schema description coverage is 0%, and the description adds no meaning to either 'numero_processo' or 'grau'. It fails to explain that 'grau' likely represents court instance (1 or 2) or the format expected for 'numero_processo'. Parameter names alone are insufficient for a Portuguese legal context.

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 uses a specific verb ('Lista') with a clear resource ('documentos do processo') and scope ('acessíveis à sessão autenticada'). It is distinguishable from sibling tools like baixar_documento, which downloads a specific document, and consultar_processo, which presumably retrieves process data.

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

Usage Guidelines2/5

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

No guidance is given on when to use this tool versus alternatives. It does not mention prerequisites, relationship to authentication tools, or when not to use it. The context is only implied by the tool name and description.

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

status_autenticacaoB

Informa se há storageState salvo e se a sessão parece válida, sem expor cookies ou tokens.

ParametersJSON Schema
NameRequiredDescriptionDefault
grauNo1

TDQS

B3.3/5.0
Behavior3/5

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

With no annotations, the description carries the full burden. It discloses a key behavioral trait: 'sem expor cookies ou tokens' (without exposing cookies or tokens), and uses 'parece válida' to indicate a heuristic check. However, it omits other traits like side effects, network use, or how 'grau' influences behavior, providing only partial transparency.

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

Conciseness5/5

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

The description is a single concise sentence that front-loads the main action ('Informa') and includes essential scope. Every word adds value, with no redundancy or filler.

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

Completeness2/5

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

For a simple status tool, the description covers the primary purpose and a safety trait, but it is incomplete due to the unexplained 'grau' parameter and lack of clarifications on the output format or what constitutes a 'valid' session. The absence of an output schema heightens the need for more detail, which is not provided.

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

Parameters1/5

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

The single parameter 'grau' has 0% schema description coverage, and the description does not mention it at all. The enum values '1' and '2' are undefined, leaving the agent with no guidance on what this parameter controls. The description fails to compensate for the schema's lack of information.

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 states the tool's purpose: 'Informa se há storageState salvo e se a sessão parece válida' (reports whether there is saved storageState and if the session seems valid). It uses a specific verb and resource, and distinguishes itself from siblings like 'autenticar' by focusing on status rather than creation. The additional 'sem expor cookies ou tokens' further clarifies its scope.

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?

The description implies usage as a preliminary check before authenticated operations, but it does not explicitly state when to use it versus siblings such as 'autenticar' or 'consultar_processo'. No exclusion criteria or alternative recommendations are provided, leaving the usage context implicit.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 6 tool updatesv1.0.0
    • First observedautenticar
    • First observedbaixar_documento
    • First observedbaixar_inteiro_teor
    • First observedconsultar_processo
    • First observedlistar_documentos
    • First observedstatus_autenticacao
Deploy Server
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A3.6/5.0

Scored across 6 tools

Disambiguation5/5

Each tool targets a distinct action: process metadata, document listing, single download, bulk download, auth status, and authentication. There is no overlap in purpose; even the two baixar tools are clearly differentiated by scope (one vs. all).

Naming Consistency4/5

Most tools follow a verb_noun pattern in Portuguese (consultar_processo, listar_documentos, baixar_documento, baixar_inteiro_teor, autenticar). The exception is status_autenticacao, which is noun_noun, a minor deviation from the otherwise consistent verb-first style.

Tool Count5/5

Six tools is well-scoped for a PJe document access server. Each tool serves a necessary step in the workflow—authentication, status check, process lookup, document listing, and download—without unnecessary redundancy.

Completeness5/5

The tool set covers the full lifecycle needed for the server's purpose: authenticate, verify authentication, retrieve process metadata, list documents, download a single document, and download all documents. No critical operation is missing for its stated domain.

Maintenance

ActivitySlowing
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers

  • Playwright Server

    williamvd4
    A
    license
    B
    quality
    Not graded
    maintenance
    A MCP server that provides browser automation tools, allowing users to navigate websites, take screenshots, click elements, fill forms, and execute JavaScript through Playwright.
    8
    2
    Apache 2.0

  • playwright-sse-mcp-server

    MCP-Mirror
    F
    license
    Not graded
    quality
    Not graded
    maintenance
    An MCP server that provides browser automation capabilities via Playwright using Server-Sent Events (SSE). It enables clients to perform web operations and scraping through a containerized Docker environment.
    -

  • Tribunal TRF1: Processo

    mcp-dir
    A
    license
    Not graded
    quality
    C
    maintenance
    MCP server to query legal process information from Brazil's Tribunal Regional Federal da 1ª Região (TRF1), providing a read-only consultation tool using official sources.
    MIT