How do I use MCP PJe Pernambuco?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@MCP PJe Pernambuco consulte o andamento do processo 0001234-56.2023.8.17.0001" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

MCP PJe Pernambuco

by bbpropulse

Overview Schema Source Related Servers Discussions Admin

Python

Local

MCP PJe Pernambuco — versão 0.7

Servidor MCP stdio, local e independente, para usar serviços judiciais de Pernambuco no Codex ou no Claude Code. O TJPE permanece operacional com SICAJUD, consulta pública, login assistido, Acervo, Autos, Pesquisa Geral, PJeDocs e, a partir da versão 0.7, o chat da CAP1G (Central de Atendimento Processual do 1º Grau). A versão 0.6 iniciou adaptadores separados para TRT6 e TRF5/JFPE em modo de descoberta, além de uma camada de aprendizagem estrutural local sem banco de dados.

Este repositório é a distribuição pública: recebe um snapshot a cada versão (veja o CHANGELOG); o histórico de desenvolvimento fica em repositório privado. Licença MIT. Sugestões e problemas: abra uma issue aqui.

TRT6 e TRF5 ainda não executam login, pesquisa ou leitura autenticada nesta versão. O catálogo informa seus ambientes oficiais e suas políticas sem atribuir a eles as permissões já auditadas para o TJPE.

O projeto não depende do Processa AI nem do Railway. O Chromium executa na máquina do usuário, credenciais opcionais ficam no cofre do sistema operacional e o protocolo MCP nunca recebe CPF, senha ou semente MFA como argumento.

Ferramentas desta versão

Ferramenta	O que faz	Altera o tribunal?
`status_servidor`	Mostra versão, segurança e recursos	Não
`listar_tribunais_suportados`	Lista instâncias, maturidade, capacidades e avisos de TJPE, TRT6 e TRF5	Não
`status_navegacao_adaptativa`	Mostra modo, retenção e adaptadores locais	Não; nem abre navegador
`listar_falhas_navegacao`	Lê observações estruturais sanitizadas do JSONL	Não; somente arquivo local
`validar_adaptadores_offline`	Reavalia as observações contra os YAML empacotados	Não; sem rede ou clique
`listar_ambientes`	Lista PJe 1G/2G e consulta pública	Não
`diagnosticar_ambiente`	Testa Chromium e endpoints oficiais	Não
`diagnosticar_pjeoffice`	Verifica passivamente a porta local e o botão de certificado no SSO 1G/2G	Não; não clica nem envia dados ao aplicativo
`consultar_processo_publico`	Consulta um NPU público em 1G ou 2G	Não
`pesquisar_classes_custas`	Pesquisa classes CNJ no SICAJUD	Não
`simular_custas`	Calcula uma estimativa pública de custas	Não gera guia
`testar_login`	Testa CPF/senha/MFA guardados localmente	Somente autenticação
`abrir_login_certificado`	Abre o SSO visível e inicia o fluxo no PJeOffice	Somente autenticação assistida
`verificar_login_certificado`	Confirma a sessão com uma requisição protegida sem clicar novamente	Não
`consultar_metadados_processo`	Metadados públicos de um NPU na API DataJud do CNJ (TJPE, TRT6, TRF5), sem navegador nem sessão	Não
`listar_jurisdicoes_acervo`	Lista as jurisdições do Acervo deste grau, sem selecionar nenhuma	Não
`listar_acervo`	Lista ou pesquisa o Acervo de uma jurisdição — busca no próprio PJe por parte, documento, OAB, classe ou assunto —, percorre até 20 páginas, filtra localmente por termos e registra os NPUs elegíveis nesta sessão/grau	Não
`preparar_acesso_pesquisa_geral`	Pesquisa somente um NPU exato e prepara sua abertura sem clicar no resultado	Não abre o processo
`abrir_autos_pesquisa_geral`	Abre uma vez o resultado preparado após confirmação literal	Sim; o PJe pode registrar o acesso nos termos da Resolução CNJ 121
`consultar_autos`	Lê cabeçalho, movimentos e documentos do Acervo ou o cache de uma abertura confirmada	Não faz novo acesso para resultado da Pesquisa Geral
`ler_documento_autos`	Extrai texto de documento retornado por processo do Acervo e calcula SHA-256	Não
`baixar_documento_autos`	Grava documento de processo do Acervo e seu sidecar `.sha256` no diretório local configurado	Não no tribunal; grava arquivos locais
`preparar_download_pjedocs`	Valida processo, sessão, grau e interface e prepara uma referência efêmera para a íntegra	Não; não clica em `DOWNLOAD`
`solicitar_download_pjedocs`	Solicita uma vez a geração da íntegra após confirmação literal	Sim; cria um trabalho assíncrono no PJeDocs
`listar_downloads_pjedocs`	Consulta a Área de download e devolve estado e referência opaca do resultado	Não
`baixar_resultado_pjedocs`	Baixa o resultado pronto com teto independente, SHA-256 e sidecar local	Não no tribunal; grava arquivos locais
`verificar_chat_cap1g`	Lê a página do chat Mibew da CAP1G e diz se há operador, sem abrir conversa	Não
`preparar_chat_cap1g`	Valida nome, e-mail e mensagem inicial pelas boas práticas da CAP1G e devolve a frase de confirmação	Não; nada é enviado
`iniciar_chat_cap1g`	Abre a conversa em janela visível do Chrome após a frase literal	Sim; cria um atendimento real com um servidor da CAP1G
`ler_chat_cap1g`	Devolve estado, operador e mensagens da conversa em andamento	Não
`aguardar_resposta_chat_cap1g`	Bloqueia até chegar mensagem nova ou mudar o estado, com teto de tempo	Não
`enviar_mensagem_chat_cap1g`	Envia uma mensagem e confirma o eco no chat; recusa repetição e caixa alta	Sim; fala em nome do usuário
`encerrar_chat_cap1g`	Encerra a conversa, fecha a janela e grava a transcrição com sidecar SHA-256	Sim; fecha o atendimento

Estágio por tribunal

Adaptador	Instâncias iniciais	Estado da versão 0.6
TJPE	1º e 2º graus	Operacional; comportamento anterior preservado
TRT6	1º grau, 2º grau e consulta pública unificada	Descoberta; URLs e política de acesso catalogadas, sem navegação autenticada
TRF5/JFPE	SJPE 1º grau, TRF5 2º grau/TRU e Turmas Recursais	Descoberta; instâncias separadas, sem navegação autenticada

No TRT6, o Tribunal informa bloqueio automático quando um usuário ultrapassa 1.500 acessos a processos de terceiros em 30 dias; reincidência pode levar a bloqueio definitivo. O perfil da v0.6 registra esse teto e reserva um limite local conservador de 1.000 para a futura implementação, mas ainda não abre esses processos. A consulta pública não entra na contagem segundo o comunicado oficial do TRT6.

No TRF5, pje1g.trf5.jus.br atende toda a 5ª Região. Um futuro acesso da JFPE deverá comprovar a jurisdição Pernambuco dentro da sessão; o hostname sozinho não basta. O ambiente pje2g representa as Turmas Recursais, enquanto o 2º grau do Tribunal usa pjett; os identificadores internos do SSO não são usados como grau jurídico.

Aprendizagem e correção sem banco de dados

A aprendizagem desta versão é um mecanismo determinístico de feedback, não um modelo que se retreina sozinho. Quando a Pesquisa Geral do TJPE deixa de encontrar o botão ou o campo de NPU no formato esperado, o MCP pode registrar um snapshot estrutural sanitizado em:

<PJE_TJPE_DATA_DIR>/adaptive/events-v1.jsonl

Em sistemas POSIX, o diretório recebe permissão 0700; eventos, lock e chave HMAC recebem 0600. No Windows, esses bits POSIX não são simulados: o diretório de dados herda a ACL do perfil do usuário e deve permanecer inacessível a outras contas. O arquivo é limitado e rotacionado, usa lock entre processos e pode ser inspecionado pelo Codex ou Claude para propor uma alteração revisada no YAML. Nenhuma estratégia observada é promovida automaticamente. Processos MCP que compartilham o mesmo diretório também devem usar a mesma retenção; o primeiro writer persiste essa política e configurações divergentes falham sem truncar o histórico.

Os modos são:

observe (padrão): mantém a descoberta auditada e registra falhas sanitizadas;
shadow: também avalia, apenas sobre a falha capturada, quais estratégias YAML teriam encontrado um candidato, sem alterar a navegação;
active: aceita somente sinônimos semânticos presentes em YAML empacotado e aprovado no Git. Correspondência única, submit nativo, formulário POST, allowlists de rede, NPU exato, avisos e a fronteira de efeito continuam obrigatórios em Python.

A v0.6 aprova para o TJPE apenas alternativas estreitas, como Consultar para o submit e Numeração única para o campo. Os YAML de TRT6 e TRF5 estão deliberadamente com approved_for_active: false.

O JSONL nunca guarda NPU, CPF/CNPJ, nomes, HTML, screenshots, texto livre, cookies, ViewState, query strings, tokens SSO, PIN ou OTP. Identificadores de controles viram HMAC local; palavras são reduzidas a uma lista semântica fechada; segmentos desconhecidos do caminho são descartados. A captura é recusada depois de qualquer possível clique que possa abrir Autos.

Para revisar uma falha: consulte listar_falhas_navegacao, altere o YAML em um commit, rode validar_adaptadores_offline e execute a suíte. A ativação é uma decisão de código revisável, não uma mutação autônoma feita pelo MCP.

A consulta processual valida o dígito do NPU, preserva a sessão JSF necessária para abrir o detalhe e mascara CPF/CNPJ antes de devolver dados ao cliente MCP. Se o portal exigir CAPTCHA, a ferramenta solicita interação humana e nunca tenta contorná-lo.

O simulador usa diretamente a tela pública de simulação do SICAJUD. Ele verifica a classe efetivamente selecionada, o valor interpretado pelo formulário, cada item de preparo e a soma total. O resultado é uma estimativa oficial, não uma guia, cobrança ou prova de valor definitivo.

Metadados públicos pelo DataJud/CNJ

consultar_metadados_processo consulta a API pública DataJud do CNJ por HTTPS direto: sem navegador, sem sessão, sem certificado e sem MFA. Vale para os três tribunais do catálogo — TJPE, TRT6 e TRF5 — e nenhum acesso é registrado no PJe por essa via.

O que ela entrega: classe, assuntos, órgão julgador, grau, sistema, formato, data de ajuizamento, última atualização e a linha de movimentações, da mais recente para a mais antiga. O que ela não entrega: partes, advogados, CPF/CNPJ, documentos, intimações e prazos — o DataJud simplesmente não publica esses campos, e por isso não há o que mascarar na resposta. É complementar à leitura autenticada, nunca substituta: para os Autos e o Acervo continua valendo o fluxo com sessão do advogado.

Barreiras da ferramenta: o NPU é validado contra o segmento de Justiça/tribunal do catálogo e o dígito verificador antes de qualquer requisição; a consulta ao Elasticsearch é montada aqui a partir do NPU, e nunca aceita uma query vinda do chamador; o host e a rota do índice são fixos; nenhum redirecionamento é seguido; e a resposta é recusada se o número devolvido divergir do consultado ou se o nivelSigilo não for o nível público.

A chave do CNJ é pública e fixa, mas o próprio CNJ avisa que pode rotacioná-la. Ela vem embutida como padrão e é sobrescrevível por PJE_TJPE_DATAJUD_API_KEY; se o CNJ trocá-la, a ferramenta devolve um erro dizendo exatamente isso e onde obter a vigente.

Leitura autenticada segura

A leitura autenticada usa sempre a mesma sessão que concluiu o login. Para um processo do Acervo, o fluxo é:

Concluir e verificar o login no grau desejado.
Executar listar_jurisdicoes_acervo nesse grau. O Acervo do TJPE é particionado por jurisdição e a lista de processos só popula depois que uma delas é escolhida. (listar_acervo sem jurisdicao também informa as disponíveis, mas como erro de validação; a ferramenta de descoberta existe para não exigir uma chamada com falha.)
Repetir listar_acervo no mesmo grau informando jurisdicao (o rótulo é comparado sem acento e sem diferenciar maiúsculas; um prefixo ambíguo é recusado pedindo o rótulo completo). A ferramenta abre somente a aba Acervo e registra em memória os processos efetivamente apresentados pelo PJe ao usuário. autos_disponiveis=true indica que o link GET dos Autos foi reconhecido e validado sem ser acionado.
Executar consultar_autos para um desses NPUs, no mesmo grau e na mesma sessão.
Usar a referencia_documento retornada pelos Autos em ler_documento_autos ou baixar_documento_autos. A referência também fica vinculada à mesma sessão, grau e processo.

Se a sessão for renovada ou encerrada, o Acervo deve ser listado novamente. A automação falha de forma fechada se detectar uma interface desconhecida, uma referência expirada ou qualquer sinal de expediente pendente de ciência. Ela não abre as áreas Expedientes, Intimações ou Agrupadores, não aceita diálogo de ciência e não clica em controles para mover processos, criar caixas, favoritar ou incluir lembretes.

Ao consultar Autos provenientes do Acervo, o MCP não clica novamente no NPU. Ele faz um único GET HTTPS da rota clássica previamente auditada, não segue redirecionamentos e processa o HTML em um contexto descartável com JavaScript e Service Workers desativados, sem cookies e com toda a rede bloqueada. Se um item do Acervo não oferecer essa rota reconhecida — inclusive quando usar somente a navegação Angular — ele continua visível com autos_disponiveis=false, mas não pode ser aberto por esta versão. Para origem pesquisa_geral, consultar_autos não repete esse GET: entrega apenas o snapshot guardado pela abertura confirmada.

Pesquisa Geral autenticada por NPU exato

A Pesquisa Geral é uma alternativa controlada somente para processo que não tenha aparecido no Acervo da sessão e do grau atuais. Ela não aceita nome, CPF/CNPJ, fragmento do número, curingas, listas ou paginação automática. O fluxo é deliberadamente dividido:

O Manual do Advogado documenta a pesquisa e a abertura dos Autos. As regras oficiais RN452/RN469 tratam o acesso de terceiro e seu registro; a RN397 trata separadamente a ciência em intimação pendente. Por isso, esta versão autoriza apenas a primeira operação confirmada e continua bloqueando a segunda.

preparar_acesso_pesquisa_geral pesquisa o NPU completo, exige um único resultado inequívoco e devolve uma referência efêmera com a frase literal de confirmação. Não abre o link dos Autos.
O cliente deve aguardar uma nova mensagem do usuário contendo exatamente a frase devolvida. Não pode copiar a frase automaticamente nem interpretar uma aprovação genérica.
abrir_autos_pesquisa_geral revalida sessão, grau, NPU e resultado antes de abrir uma única vez. A ferramenta é marcada como mutável/destrutiva porque, conforme a Resolução CNJ 121, o PJe pode registrar o acesso de advogado não vinculado. Se o desfecho ficar incerto depois da possível abertura, o estado é indeterminado e o MCP não tenta novamente.
consultar_autos devolve somente o conteúdo guardado em memória durante essa abertura, sem emitir outra requisição de acesso. O campo origem vale pesquisa_geral, e documentos sem bytes capturados aparecem com conteudo_disponivel=false.

O cache e as referências valem apenas durante a vida do processo MCP e da mesma geração de sessão. Reiniciar o servidor ou refazer o login exige nova preparação e nova confirmação. ler_documento_autos, baixar_documento_autos e todo o fluxo PJeDocs permanecem restritos a processos provenientes do Acervo: a confirmação da Pesquisa Geral não autoriza novo acesso, download de documento ou geração de íntegra.

O MCP não aceita automaticamente aviso de sigilo, permissão, ciência ou responsabilização diferente do contrato reconhecido para a abertura preparada. Processo sigiloso de terceiro, resultado ambíguo, interface alterada ou qualquer tentativa de abrir Expedientes faz a operação falhar de forma fechada.

ler_documento_autos devolve o texto extraído, tamanho e SHA-256 dos bytes recebidos. baixar_documento_autos publica o arquivo com permissão local restrita e cria, ao lado, um arquivo <nome>.sha256 no formato aceito por utilitários de verificação. O hash identifica exatamente os bytes baixados, mas não substitui a assinatura digital nem constitui, isoladamente, prova de autenticidade jurídica.

Para PDFs, a extração textual acontece em um subprocesso descartável. O MCP limita memória residente, CPU, tempo de relógio, número de páginas e quantidade de caracteres; se qualquer teto for alcançado, encerra o parser sem derrubar o servidor e orienta o uso do arquivo baixado. Apenas um parser pode executar por vez; chamadas concorrentes recebem backpressure curto, e o limite continua ocupado até o subprocesso terminar mesmo se o cliente cancelar a solicitação.

O download direto tem teto local padrão de 3 MiB (3.145.728 bytes), controlado por PJE_TJPE_MAX_DOCUMENT_BYTES. O fluxo assíncrono PJeDocs, a íntegra do processo e arquivos maiores usam outro caminho e outro teto. O transporte direto não segue redirecionamentos e lê os bytes de forma incremental, interrompendo a conexão assim que o teto for ultrapassado.

Íntegra assíncrona pelo PJeDocs

O PJeDocs opera somente sobre processo que já apareceu no Acervo da sessão autenticada atual e do mesmo grau. Nesta versão, ele solicita exclusivamente a íntegra: o formulário fica sem filtros de tipo, ID ou período, e as opções Incluir expediente e Incluir movimentos são sempre verificadas como Não. O fluxo é deliberadamente dividido em quatro chamadas:

preparar_download_pjedocs revalida NPU, grau, sessão, Autos e a interface conhecida do PJeDocs, registra uma linha de base da Área de download e devolve uma referência efêmera e a frase literal exigida para confirmação. Esta etapa não aciona a geração.
Depois da preparação, o cliente deve aguardar uma nova mensagem do usuário contendo a frase literal antes de invocar solicitar_download_pjedocs. A ferramenta é marcada no protocolo como mutável/destrutiva para que o host possa pedir aprovação. Ela revalida todos os vínculos e clica uma única vez em DOWNLOAD. Essa é uma mutação técnica: cria um trabalho assíncrono de geração, sem protocolar, peticionar ou alterar os Autos. Se o resultado do clique ficar incerto, o MCP marca a solicitação como indeterminada e não a repete automaticamente. O servidor stdio valida a transição em duas etapas, mas não consegue provar sozinho a autoria humana da frase; essa garantia depende da interface e da política de aprovação do cliente MCP. A proteção contra clique duplicado vale durante a vida do processo MCP; depois de reiniciar o servidor, reconcilie a Área de download antes de preparar outra solicitação.
listar_downloads_pjedocs consulta a Área de download e tenta reconciliar somente uma nova linha inequívoca com a solicitação. Enquanto o arquivo não estiver pronto, devolve o estado de processamento; não mantém polling contínuo. Se a linha for inequivocamente reconhecida como expirada, uma chamada posterior a preparar_download_pjedocs cria uma nova referência e exige outra confirmação. Antes dessa comprovação, preparar e solicitar continuam idempotentes e nunca repetem automaticamente o clique anterior.
baixar_resultado_pjedocs resolve o link novamente no momento do uso e baixa o arquivo pronto de forma incremental. A URL temporária nunca é armazenada nem exposta pelo protocolo MCP.

Segundo o manual oficial do TJPE, o arquivo gerado permanece disponível por 24 horas, e o link mostrado na Área de download é renovado a cada 2 minutos. Por isso, o MCP usa uma referência opaca e sempre obtém um link novo; ele não oferece uma URL para copiar, reutilizar ou compartilhar. O nome remoto da linha também não é devolvido: o modelo usa somente o nome sintético Íntegra do processo <NPU> para impedir que texto inesperado da interface transporte uma URL ou capability temporária.

O download do resultado tem teto local independente, com padrão de 512 MiB (536.870.912 bytes), configurado por PJE_TJPE_MAX_PJEDOCS_BYTES. O arquivo recebe nome derivado do NPU e do hash, permissão 0600 e publicação atômica em diretórios 0700; ao lado, o MCP cria um sidecar .sha256 também restrito. O conteúdo não é extraído nem executado. O hash identifica os bytes recebidos, mas não substitui a validação oficial por QR Code ou número único descrita no manual.

Os valores 3 MB e 3 MiB não são equivalentes nem configuram o mesmo controle. O manual usa 3 MB para distinguir o download individual do fluxo PJeDocs. Já 3 MiB (3.145.728 bytes) é o teto local desta aplicação para ler_documento_autos e baixar_documento_autos; ele não altera o PJe nem o limite do PJeDocs. O teto de 512 MiB protege separadamente o arquivo final da íntegra.

A automação falha de forma fechada diante de sessão, grau ou processo divergente, referência vencida, aviso de ciência ou acesso, formulário desconhecido, controles ambíguos, resultado que não possa ser reconciliado com segurança, link fora do host/grau esperado, redirecionamento, resposta HTML ou arquivo acima do teto. Ela não tenta contornar essas condições.

Atendimento pelo chat da CAP1G

A Central de Atendimento Processual do 1º Grau atende advogados e partes por chat, das 8h às 19h em dias úteis, ou pelo telefone (81) 3181-0506. O chat é um Mibew Messenger 2.x hospedado em www.tjpe.jus.br/mibew; a estrutura observada está em docs/chat-cap1g.md. Quem responde é um servidor do tribunal, então o MCP trata a conversa como ação externa em nome do usuário:

verificar_chat_cap1g baixa somente o documento HTML do chat (sem scripts, estilos ou imagens) e lê o startFrom que o Mibew embute: survey significa operador disponível; leaveMessage significa ninguém em linha — e a CAP1G desativou o recado fora do horário, então não há nada a deixar. Um GET da página não cria conversa.
preparar_chat_cap1g exige nome e e-mail (as boas práticas da CAP1G pedem identificação para direcionar o pedido) e uma mensagem inicial objetiva. Ele recusa mensagem vazia, acima de 2.000 caracteres ou quase toda em caixa alta, confirma que há operador e devolve referencia_preparo, a mensagem normalizada que será enviada e a frase literal de confirmação. A preparação expira em 10 minutos; nada é enviado.
iniciar_chat_cap1g só aceita a frase literal em nova mensagem do usuário. Ele abre o Chrome visível (PJE_TJPE_CHAT_HEADLESS=false por padrão), preenche o formulário de identificação, clica em Iniciar Chat e mantém a janela aberta: é o próprio cliente Mibew que faz o polling a cada 2 segundos e conserva a conversa viva. A resposta só volta depois que a pergunta inicial ecoa na conversa (ou, se o formulário não tiver esse campo, depois de enviá-la como primeira mensagem); se a página já abrir direto no chat, o formulário é pulado. Uma vez aberta a conversa, uma falha na primeira mensagem vira aviso na resposta, não fechamento da janela. O advogado acompanha tudo na janela e pode digitar nela por conta própria. Há uma conversa por vez; a mesma preparação nunca abre um segundo chat.
ler_chat_cap1g e aguardar_resposta_chat_cap1g leem os modelos do cliente Mibew (thread, user, messages), não o HTML pintado: cada mensagem volta com id, tipo (visitante, operador, info…), autor e horário. A espera devolve assim que chega mensagem nova desde a última entregue ou o estado muda (operador entrou, encerrou), e respeita timeout_segundos (1 a 300; padrão 60) — o teto do cliente MCP também vale. Um monitor interno lê a página a cada 2 segundos e grava uma transcrição parcial, para nada se perder entre chamadas.
enviar_mensagem_chat_cap1g digita no campo do chat, clica em Enviar e só retorna quando a mensagem ecoa na conversa. Se o eco não vier no prazo, a mensagem é tratada como enviada mesmo assim: o erro pede para conferir com ler_chat_cap1g, e o texto idêntico passa a ser recusado. Também recusa texto igual ao último enviado e avisa quando a mensagem segue outra sua sem resposta do operador — a CAP1G pede que não se repita mensagem em sequência.
encerrar_chat_cap1g aciona o controle Fechar chat do Mibew, fecha a janela e publica a transcrição em Markdown, com permissão 0600 e sidecar .sha256, em Downloads/PJe-TJPE/TJPE/CAP1G/. Se o operador encerrar antes, a conversa volta como encerrado e o envio é recusado; se a janela for fechada à mão, o atendimento acaba com esse motivo registrado.

Cinco processos por atendimento. A CAP1G aceita encaminhamento de até 5 processos por chat (regra operacional informada por quem usa o serviço; não consta do PDF de boas práticas). O MCP conta os NPUs distintos que o visitante cita — na mensagem inicial, em enviar_mensagem_chat_cap1g e no que for digitado à mão na janela — e devolve processos_solicitados e processos_restantes em cada leitura. preparar_chat_cap1g recusa mensagem inicial com mais processos que o limite, e enviar_mensagem_chat_cap1g recusa a mensagem que citaria o sexto. Sessões sucessivas são livres: para mais processos, divida em lotes de até 5, encerre o chat e inicie outro — há uma conversa por vez, mas quantas forem necessárias. O limite é configurável por PJE_TJPE_CAP1G_PROCESSOS_POR_CHAT, caso a CAP1G mude a regra.

O token da conversa do Mibew nunca sai da página: os modelos devolvidos ao protocolo MCP não o contêm. O que um servidor informa no chat é orientação de atendimento, não decisão judicial; confira nos Autos antes de agir.

Related MCP server: cloud-to-local

Fora do escopo seguro

Esta versão não:

pesquisa por nome, CPF/CNPJ, NPU parcial, curingas ou listas na Pesquisa Geral;
percorre mais de 20 páginas do Acervo numa chamada: o painel entrega cerca de 40 processos por página, e cada avanço é um round-trip a4j;
reutiliza a abertura da Pesquisa Geral para novo acesso, documento individual ou PJeDocs;
contorna as permissões, restrições de sigilo ou avisos de acesso do PJe;
gera ou paga guia;
registra ciência ou abre expediente pendente;
cria caixas, favoritos ou qualquer outro estado no PJe;
solicita habilitação, junta, assina ou protocola documentos;
lê ou armazena certificado, chave privada ou PIN, nem controla token criptográfico;
escolhe o certificado ou aprova a autenticação no lugar do usuário;
expõe um cliente MNI universal;
inicia conversa na CAP1G sem a frase literal do usuário, mantém mais de uma conversa por vez, envia anexos pelo chat ou deixa recado fora do horário.

Ciência, habilitação, assinatura, peticionamento e protocolo continuam fora desta versão e exigiriam uma fase separada, com confirmação explícita e trilha de auditoria própria. A solicitação de íntegra no PJeDocs não autoriza nenhuma dessas ações.

Requisitos e instalação

macOS, Linux ou Windows;
Python 3.11 a 3.14 (Python 3.13 recomendado);
uv;
Google Chrome instalado — o navegador é aberto pelo canal chrome do Playwright, e não pelo Chromium empacotado. O PJe do TJPE serve conteúdo diferente ao Chromium puro, e o PJeOffice espera um Chrome real;
Codex ou Claude Code com suporte a MCP local.

Para login por certificado, também são necessários o PJeOffice/PJeOffice Pro oficial instalado e em execução, além de um certificado digital válido e reconhecido pelo aplicativo. Esses itens não são necessários para as ferramentas públicas.

git clone https://github.com/bbpropulse/mcp-pje-tjpe-dist.git mcp-pje-tjpe
cd mcp-pje-tjpe
uv sync
uv run playwright install chrome
uv run pje-tjpe doctor

playwright install chrome só confirma (ou instala) o Google Chrome do sistema; o Chromium empacotado do Playwright não é usado pelo servidor — apenas pela suíte de testes (uv run playwright install chromium, opcional).

O diagnóstico deve confirmar SICAJUD, PJe 1G e PJe 2G. Credenciais não são necessárias para consulta pública ou simulação de custas.

Sem clonar, o uvx resolve o pacote direto do Git a cada execução (o Chrome continua sendo requisito da máquina):

uvx --from git+https://github.com/bbpropulse/mcp-pje-tjpe-dist pje-tjpe doctor

Para atualizar um clone, git pull seguido de uv sync; cada versão chega como um único commit com a tag correspondente (v0.7.0, …).

Codex

Substitua o caminho abaixo pelo caminho absoluto do clone:

codex mcp add --env PJE_TJPE_AUTH_HEADLESS=false pje-tjpe -- \
  "/CAMINHO/ABSOLUTO/mcp-pje-tjpe/.venv/bin/pje-tjpe" serve
codex mcp list

O navegador de autenticação já é visível por padrão; a opção foi escrita no comando para tornar essa exigência do fluxo por certificado explícita.

Depois de abrir o PJeOffice/PJeOffice Pro, peça ao Codex, nesta ordem:

Use o pje-tjpe para diagnosticar o PJeOffice.
Abra o login assistido por certificado no primeiro grau. Não peça meu PIN.
Verifique se o login por certificado no primeiro grau foi concluído, sem clicar novamente.

Para remover:

codex mcp remove pje-tjpe

Claude Code

claude mcp add --transport stdio --scope user pje-tjpe \
  --env PJE_TJPE_AUTH_HEADLESS=false -- \
  "/CAMINHO/ABSOLUTO/mcp-pje-tjpe/.venv/bin/pje-tjpe" serve
claude mcp list

Ou, sem clone, deixando o uvx buscar a versão publicada:

claude mcp add --transport stdio --scope user pje-tjpe -- \
  uvx --from git+https://github.com/bbpropulse/mcp-pje-tjpe-dist pje-tjpe serve

PJE_TJPE_AUTH_HEADLESS=false também já é o padrão; ele aparece no comando para documentar que o fluxo assistido precisa do navegador visível.

No Claude Code, use o mesmo fluxo em três pedidos:

Use o servidor pje-tjpe para executar diagnosticar_pjeoffice.
Execute abrir_login_certificado com grau 1g. Eu concluirei a aprovação no PJeOffice.
Execute verificar_login_certificado com grau 1g, sem iniciar outra tentativa.

Para remover:

claude mcp remove --scope user pje-tjpe

Desde novembro de 2025, o TJPE exige autenticação multifator para usuários externos. O fluxo atual redireciona 1G/2G ao SSO nacional do PJe e depois retorna ao tribunal.

Salve CPF e senha somente pelo terminal local:

uv run pje-tjpe setup

Por padrão, não é necessário guardar a semente TOTP. Para digitar o código MFA no navegador, mantenha PJE_TJPE_AUTH_HEADLESS=false, que já é o padrão da aplicação. PJE_TJPE_HEADLESS controla apenas o navegador das operações públicas e não substitui essa configuração.

O setup também oferece, de forma opt-in, guardar a semente TOTP no Keychain. Isso automatiza o código, mas reduz a separação entre os fatores porque senha e semente ficam no mesmo cofre. O fluxo por certificado não usa essas credenciais e não exige executar setup.

Certificado digital

O fluxo de certificado, introduzido na versão 0.2, é assistido:

Instale e abra o PJeOffice/PJeOffice Pro oficial e conecte o token, se houver.
Execute diagnosticar_pjeoffice. O teste apenas tenta abrir uma conexão TCP em localhost:8800 (IPv4 e IPv6) e procura Certificado Digital nas telas SSO de 1G e 2G. Ele não clica no botão nem envia challenge, cookie, CPF, senha ou PIN ao serviço local. Porta aberta não prova que o processo seja o PJeOffice.
Execute abrir_login_certificado com grau igual a 1g ou 2g. O MCP abre o SSO em um Chromium visível, aciona Certificado Digital uma vez e mantém esse contexto somente em memória.
Escolha o certificado e digite o PIN exclusivamente na interface nativa do PJeOffice/PJeOffice Pro. Conclua também eventual MFA solicitado pelo SSO.
Execute verificar_login_certificado para consultar a mesma tentativa. Essa ferramenta não altera a aba visível nem clica novamente: ela confirma os cookies com uma requisição de leitura a uma página protegida. O retorno expõe somente a URL canônica do ambiente, nunca query, token SSO ou caminho de processo.

Se você cancelar a janela nativa ou quiser começar de novo no mesmo grau, execute abrir_login_certificado com reiniciar=true. O MCP encerra o contexto anterior antes de fazer um único novo clique. Ele também impede tentativas simultâneas de 1G e 2G enquanto uma delas aguarda interação humana.

Nunca forneça o PIN ao Codex, ao Claude, ao chat, a uma ferramenta MCP, ao terminal ou a uma variável de ambiente. Digite-o somente na janela oficial do PJeOffice/PJeOffice Pro.

O MCP não seleciona o certificado, não lê a chave privada, não captura o PIN e não aprova a operação. Fechar o servidor encerra a sessão mantida em memória.

Os testes automatizados validam socket, navegador, domínios e estados com mocks. Um teste ponta a ponta real não pode ser concluído de forma autônoma: ele exige o PJeOffice/PJeOffice Pro instalado e aberto, certificado válido, acesso ao SSO e interação humana para selecionar o certificado e informar PIN e eventual MFA. Por isso, a suíte padrão não afirma que um login real por certificado foi validado.

Remova os segredos locais com:

uv run pje-tjpe clear-credentials

Exemplos de pedidos ao MCP

Consulte o processo público 0000000-00.2026.8.17.0000 no primeiro grau.

Pesquise classes de custas contendo "procedimento comum".

Simule no SICAJUD as custas do código 7, Procedimento Comum Cível,
com valor da causa de R$ 50.000,00.

Diagnostique o acesso aos serviços públicos do TJPE.

Diagnostique passivamente o PJeOffice e os botões de certificado de 1G e 2G.

Abra o login assistido por certificado no segundo grau. Eu selecionarei o
certificado e digitarei o PIN somente no PJeOffice.

Verifique a tentativa de login por certificado do segundo grau sem clicar novamente.

Liste meu Acervo do primeiro grau. Não abra Expedientes nem registre ciência.

Consulte os Autos do processo que acabou de ser retornado pelo Acervo.

Prepare a Pesquisa Geral autenticada pelo NPU exato no primeiro grau. Ainda não
abra o resultado.

Abra o resultado preparado usando exatamente a referencia_preparo e a frase de
confirmação que enviei nesta nova mensagem.

Consulte os Autos em cache desse processo, sem realizar um novo acesso.

Leia o documento usando a referencia_documento retornada pelos Autos.

Baixe esse documento direto, gere o sidecar SHA-256 e informe os dois caminhos.

Prepare o download da íntegra pelo PJeDocs para o processo retornado pelo meu
Acervo do primeiro grau. Ainda não solicite a geração.

Solicite a geração usando a referencia_preparo e exatamente a frase de
confirmação retornadas pela preparação.

Consulte a Área de download usando a referencia_solicitacao. Não repita a
solicitação se o arquivo ainda estiver sendo processado.

Baixe o resultado pronto usando a referencia_resultado, valide o teto local e
informe os caminhos do arquivo e do sidecar SHA-256. Não exponha a URL temporária.

Verifique se a CAP1G está com operador no chat. Não abra conversa.

Prepare o chat da CAP1G em meu nome, com meu e-mail, pedindo que informem se o
alvará do processo tal já foi expedido. Ainda não inicie.

Inicie o chat usando a referencia_preparo e exatamente a frase de confirmação
que envio nesta mensagem.

Aguarde a resposta do operador por até dois minutos e me diga o que ele escreveu.

Responda ao operador informando o número da OAB e aguarde de novo.

Encerre o chat e me informe o caminho da transcrição e o SHA-256.

Tenho 12 processos para pedir certidão na CAP1G: divida em lotes de 5, um chat
por lote, e me mostre o que o operador respondeu em cada um.

Use sempre um NPU real que você esteja autorizado a consultar. O NPU do exemplo é apenas ilustrativo e não passa na validação.

Configuração

Variável	Padrão	Finalidade
`PJE_TJPE_HEADLESS`	`true`	Exibe ou oculta o Chromium usado em operações públicas
`PJE_TJPE_AUTH_HEADLESS`	`false`	Mantém visível o Chromium de autenticação; deve ser `false` para certificado
`PJE_TJPE_CHAT_HEADLESS`	`false`	Mantém visível a janela do chat da CAP1G para o advogado acompanhar e intervir
`PJE_TJPE_CAP1G_PROCESSOS_POR_CHAT`	`5`	Quantos processos distintos um atendimento da CAP1G aceita encaminhar (1 a 50)
`PJE_TJPE_TIMEOUT_MS`	`30000`	Timeout do portal em milissegundos
`PJE_TJPE_MAX_DOCUMENT_BYTES`	`3145728` (3 MiB)	Limite local para leitura e download direto de um documento
`PJE_TJPE_MAX_PJEDOCS_BYTES`	`536870912` (512 MiB)	Teto local independente para baixar a íntegra pronta do PJeDocs
`PJE_TJPE_ADAPTIVE_MODE`	`observe`	Modo `observe`, `shadow` ou `active`; valor inválido impede a inicialização
`PJE_TJPE_ADAPTIVE_MAX_EVENTS`	`200`	Retenção do JSONL local, de 1 a 10.000; deve coincidir entre processos
`PJE_TJPE_DATAJUD_API_KEY`	chave pública vigente do CNJ	Sobrescreve a chave da API DataJud se o CNJ a rotacionar
`PJE_TJPE_DATA_DIR`	diretório de dados do SO	Reserva dados locais do MCP
`PJE_TJPE_DOWNLOAD_DIR`	`Downloads/PJe-TJPE`	Destino dos documentos, íntegras, transcrições do chat e sidecars SHA-256

Testes

uv run pytest
uv run ruff check .
uv run pyright

O teste ao vivo do SICAJUD apenas simula valores e nunca gera guia:

RUN_TJPE_LIVE_TESTS=1 uv run pytest -m live

Para também testar uma consulta pública real, use somente um processo autorizado:

RUN_TJPE_LIVE_TESTS=1 \
TJPE_TEST_NPU="NNNNNNN-DD.AAAA.8.17.OOOO" \
TJPE_TEST_GRAU="1g" \
uv run pytest -m live

Esse marcador cobre serviços públicos; ele não executa login ponta a ponta por certificado e não substitui a validação humana descrita acima.

Distribuição pública

Cada versão chega a este repositório como um único commit, gerado no repositório de desenvolvimento por scripts/publicar_distribuicao.py: o script exige árvore limpa, roda ruff e a suíte, exporta só os arquivos rastreados (git archive), varre o snapshot procurando NPU ou CPF com dígitos válidos, e-mail real ou caminho pessoal — qualquer achado interrompe a publicação — e então commita e etiqueta (vX.Y.Z) na pasta de distribuição. O histórico de desenvolvimento não é publicado.

Referências oficiais

O próprio Manual do Advogado alerta que parte do conteúdo foi migrada da antiga Wiki e pode estar desatualizada. Por isso, o código de autenticação foi conferido contra o SSO atual e a comunicação mais recente do TJPE sobre MFA.

Available Tools

35 tools

abrir_autos_pesquisa_geralD

DestructiveIdempotent

Abre o resultado somente após nova mensagem literal; o PJe pode registrar o acesso.

ParametersJSON Schema

Name	Required	Description	Default
`grau`	Yes
`numero`	Yes
`confirmacao`	Yes
`referencia_preparo`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`grau`	Yes
`aviso`	Yes
`estado`	Yes
`numero`	Yes
`acessado_em`	Yes
`reutilizada`	Yes
`referencia_acesso`	Yes

TDQS

D1.9/5.0

Behavior2/5

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

Annotations indicate destructiveHint=true, but the description only mentions that the PJe may record access—a minor side effect. It does not disclose the destructive nature, such as potential data loss or irreversible changes. This is a significant omission given the annotation.

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 description is very short, which is concise, but the information is too sparse. It mentions a necessary condition and a side effect, but the structure does not front-load the core action or provide a clear purpose. It is under-specified rather than efficiently concise.

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

Completeness1/5

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

Given 4 required parameters, zero schema coverage, and no output schema details, the description is thoroughly inadequate. The agent has no clue about the format of inputs, what the 'literal message' should be, or what the result will look like. This tool is virtually unusable without external knowledge.

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 coverage is 0% and the description provides no parameter information. The parameters 'numero', 'grau', 'referencia_preparo', and 'confirmacao' are not explained at all; the agent has to guess their format and purpose.

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

Purpose2/5

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

The description says 'opens the result only after a new literal message,' but it does not specify what 'result' refers to or what resource is being opened. It lacks a clear verb-resource pair, and the tool name suggests opening case files ('autos') in a general search, but the description does not clarify this.

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?

The description implies that a new literal message is required before opening, but it does not explain when to use this tool versus alternatives like 'preparar_acesso_pesquisa_geral' or 'consultar_autos'. There is no explicit guidance on preconditions or step sequencing.

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

abrir_login_certificadoC

Abre o SSO visível e delega certificado/PIN ao PJeOffice instalado localmente.

ParametersJSON Schema

Name	Required	Description	Default
`grau`	Yes
`reiniciar`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`grau`	Yes
`estado`	Yes
`mensagem`	Yes
`url_atual`	Yes
`autenticado`	Yes
`modo_autenticacao`	No

TDQS

C2.9/5.0

Behavior3/5

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

With no annotations, the description carries the burden. It discloses that the SSO is visible and that certificate/PIN handling is outsourced to a local PJeOffice, which is useful behavioral context. It still omits consequences such as user interaction for PIN, side effects on session state, and failure modes.

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?

One sentence, no filler, action front-loaded; 'visível' and 'instalado localmente' add operational meaning rather than padding.

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 presence of an output schema and simple parameter set raises the baseline, but the definition is still thin for an interactive login tool. Missing prerequisites, user-interaction expectations, and the meaning of reiniciar mean it is only minimally viable.

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 parameter semantics. It never explains grau (1g/2g) or reiniciar, so the agent is left to infer their roles from names and enum values.

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 states a concrete action ('Abre o SSO visível') and resource ('PJeOffice instalado localmente'), making the tool's function clear. It is distinguishable from siblings like verificar_login_certificado, but it does not explicitly contrast itself with them.

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 conditions, prerequisites, or alternative routing are provided. The only hint is the local PJeOffice dependency; an agent cannot tell when to choose this over testar_login or verificar_login_certificado.

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

aguardar_resposta_chat_cap1gC

Read-onlyIdempotent

Espera mensagem nova desde a última entregue, ou mudança de estado, até o tempo dado.

ParametersJSON Schema

Name	Required	Description	Default
`desde_id`	No
`referencia_chat`	Yes
`timeout_segundos`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`aviso`	Yes
`fonte`	No
`estado`	Yes
`operador`	No
`encerrado`	Yes
`mensagens`	Yes
`ultimo_id`	Yes
`iniciado_em`	Yes
`pode_enviar`	Yes
`transcricao`	No
`atualizado_em`	No
`aviso_do_chat`	No
`nome_visitante`	Yes
`novas_mensagens`	Yes
`referencia_chat`	Yes
`total_mensagens`	Yes
`operador_digitando`	No
`processos_restantes`	Yes
`processos_solicitados`	No
`limite_processos_por_atendimento`	Yes

TDQS

C2.9/5.0

Behavior3/5

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

Annotations indicate readOnlyHint=true, destructiveHint=false, idempotentHint=true, so the tool is safe and idempotent. The description adds the block/wait behavior and the concept of 'timeout', which is beyond annotations. However, it doesn't disclose what happens on timeout (error? empty result?), nor it explains the 'desde_id' semantics in the context of blocking behavior. No contradictions.

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, short sentence that is front-loaded with the core action (espera mensagem nova) and the key condition (desde a última entregue). It is concise, though it omits necessary details, but structure is clean.

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?

The tool is a blocking wait operation with three parameters, but the description lacks critical information such as return value, timeout behavior, and how 'desde_id' is used. While an output schema exists, the description doesn't clarify what triggers the return (new message vs state change) or what the return object contains. An agent would need to infer too much.

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%, so the description must clarify each parameter, but it fails to do so. It doesn't explain what 'referencia_chat' refers to (chat ID?), what 'desde_id' means (last message ID?), or how 'timeout_segundos' affects the call. The description only mentions 'tempo dado' which hints at timeout but doesn't tie it to the parameter clearly.

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 states the core function: waiting for a new message or state change until a timeout. However, it is vague about what the tool returns (the message? the state change?) and how it relates to the chat lifecycle. It is distinguishable from siblings like 'enviar_mensagem_chat_cap1g' and 'ler_chat_cap1g' but does not clearly differentiate itself, e.g., it could be confused with 'verificar_chat_cap1g' which might also check for updates.

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: call this after sending a message and when expecting a response, and it waits for a new message or state change. However, it does not explicitly say when to use it versus 'ler_chat_cap1g' or 'verificar_chat_cap1g', nor does it mention any prerequisites like needing an active chat session (which likely exists given sibling tools like 'iniciar_chat_cap1g').

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

baixar_documento_autosC

Baixa um documento enumerado nos Autos e grava arquivo e sidecar SHA-256.

ParametersJSON Schema

Name	Required	Description	Default
`grau`	Yes
`numero`	Yes
`referencia_documento`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`grau`	Yes
`aviso`	Yes
`numero`	Yes
`sha256`	Yes
`titulo`	Yes
`caminho`	Yes
`obtido_em`	No
`tipo_mime`	Yes
`nome_arquivo`	Yes
`tamanho_bytes`	Yes
`caminho_sha256`	Yes
`referencia_documento`	Yes

TDQS

C2.7/5.0

Behavior2/5

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

With no annotations, the description must carry the full behavioral burden. It discloses that the tool writes a file and a SHA-256 sidecar, indicating a side effect, but provides no information about permissions, rate limits, reversibility, or any other behavioral traits. This is insufficient for a tool that mutates the filesystem.

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 immediately states the action and output. No wasted words exist; it is front-loaded and to the point.

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 required parameters, no annotations, and an output schema, the description lacks essential context. It does not explain what 'Autos' refers to, what constitutes an 'enumerado' document, or why a SHA-256 sidecar is created. It also omits any interaction with sibling tools or the overall workflow, making the description inadequate for correct 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%, so the description must compensate. It fails to explain 'numero', 'grau', or 'referencia_documento'. The phrase 'documento enumerado nos Autos' vaguely hints at the reference but does not clarify the parameters' meaning, format, or allowed values. This leaves the agent without the information needed to populate them correctly.

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 verb 'Baixa' (download) and the resource 'um documento enumerado nos Autos', and specifies the output (file and SHA-256 sidecar). It is specific enough to distinguish from 'ler_documento_autos' (read) and other download-related siblings, though it does not explicitly name the 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?

No guidance is given on when to use this tool versus other download tools like 'preparar_download_pjedocs' or 'ler_documento_autos'. There is no mention of context, prerequisites, or exclusions, so agents are left to infer applicability.

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

baixar_resultado_pjedocsC

Baixa um resultado pronto e vinculado, gravando o arquivo e seu SHA-256.

ParametersJSON Schema

Name	Required	Description	Default
`grau`	Yes
`numero`	Yes
`referencia_resultado`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`grau`	Yes
`aviso`	Yes
`numero`	Yes
`sha256`	Yes
`caminho`	Yes
`obtido_em`	No
`tipo_mime`	Yes
`nome_arquivo`	Yes
`tamanho_bytes`	Yes
`caminho_sha256`	Yes
`referencia_resultado`	Yes

TDQS

C2.9/5.0

Behavior2/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 mentions that it 'grava o arquivo e seu SHA-256', which is a useful side effect, but it does not clarify whether the file is stored persistently, what happens on duplicate downloads, any authentication or permissions needed, or the implications of the destructive write.

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, efficient sentence that front-loads the purpose and includes the key side effect. It wastes no words, though it could be slightly expanded to include usage context without sacrificing brevity.

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?

Given the existence of an output schema (not detailed here, but indicated by 'has output schema: true'), the return format may be documented elsewhere. However, for a download tool with three required parameters and no annotation coverage, the description lacks critical information about prerequisites (e.g., that a result must already be prepared), the significance of the SHA-256 hash, and what constitutes a successful vs. failed download.

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%, so the description must compensate, but it provides no parameter-specific meanings. It does not explain what 'numero', 'grau', or 'referencia_resultado' represent or how they relate to the download. This is a significant gap for an agent trying to supply correct values.

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 states a clear verb ('Baixa') and resource ('resultado pronto e vinculado'), distinguishing it from related download operations like 'baixar_documento_autos' and 'preparar_download_pjedocs'. While it could name the sibling explicitly, the phrase 'resultado pronto e vinculado' provides enough specificity to infer it is for downloading a completed result rather than a raw document.

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 a prerequisite: the result must be 'pronto e vinculado', suggesting it should be used after a download has been prepared or solicited. However, it does not explicitly state when to use this tool over alternatives like 'preparar_download_pjedocs' or 'baixar_documento_autos', nor does it mention any required prior steps.

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

consultar_autosC

Lê Autos do Acervo ou o cache de uma abertura confirmada na Pesquisa Geral.

ParametersJSON Schema

Name	Required	Description	Default
`grau`	Yes
`numero`	Yes
`limite_documentos`	No
`limite_movimentos`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`grau`	Yes
`aviso`	Yes
`fonte`	No
`numero`	Yes
`origem`	No
`cabecalho`	Yes
`documentos`	Yes
`movimentos`	Yes
`capturado_em`	No
`documentos_parciais`	Yes

TDQS

C2.9/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 full burden of behavioral disclosure. The description only says it 'reads' data, which implies a read operation, but it doesn't disclose whether this requires prior authentication, whether it hits the network or only local cache, what happens if the cache doesn't exist, or whether it can fail when the Acervo is unavailable. The mention of 'cache de uma abertura confirmada' hints at a prerequisite but doesn't explain the behavior when that prerequisite isn't met.

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 front-loads the main action ('Lê') and the resource. It's efficient and doesn't waste words. It could be slightly more structured with usage guidance, but for what it is, it's appropriately sized.

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?

The tool has 4 parameters, no annotations, and an output schema. The description is too thin to be complete. It doesn't explain the relationship to 'abrir_autos_pesquisa_geral' (which likely produces the cache), doesn't clarify parameter semantics, and doesn't state prerequisites or failure modes. The output schema exists but the description doesn't help the agent understand when this tool is the right choice versus siblings like 'consultar_metadados_processo' or 'ler_documento_autos'.

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%, so the description must compensate for the 4 parameters. It doesn't. The description doesn't explain what 'numero' refers to (process number? case number?), what 'grau' means beyond the enum values, or what the limits control. The parameter names and types are visible in the schema, but the description adds no semantic meaning to help the agent fill them correctly.

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 states a specific verb ('Lê' = reads) and resource ('Autos do Acervo ou o cache de uma abertura confirmada na Pesquisa Geral'), which clearly distinguishes it from sibling tools like 'abrir_autos_pesquisa_geral' (which opens) and 'ler_documento_autos' (which reads a specific document). It could be slightly clearer about what 'Autos' means in this context, but the verb+resource combination is specific enough.

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 context: it reads from the Acervo or from the cache of a confirmed opening in Pesquisa Geral. This suggests it should be used after 'abrir_autos_pesquisa_geral' or when working with Acervo. However, it doesn't explicitly state when to prefer this over 'ler_documento_autos' or 'consultar_metadados_processo', nor does it state exclusions or alternatives.

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

consultar_metadados_processoA

Read-onlyIdempotent

Metadados públicos de um NPU na API DataJud do CNJ, sem navegador nem sessão.

ParametersJSON Schema

Name	Required	Default
`numero`	Yes
`tribunal`	No	tjpe
`limite_movimentos`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`grau`	No
`aviso`	Yes
`fonte`	No
`classe`	No
`numero`	Yes
`formato`	No
`sistema`	No
`assuntos`	No
`tribunal`	Yes
`movimentos`	No
`capturado_em`	No
`nivel_sigilo`	No
`codigo_classe`	No
`orgao_julgador`	No
`data_ajuizamento`	No
`total_movimentos`	No
`ultima_atualizacao`	No
`movimentos_truncados`	No

TDQS

A3.6/5.0

Behavior4/5

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false. The description adds useful behavioral context beyond those annotations: the operation hits the public DataJud API and requires no browser or session, implying no authentication ceremony is needed. 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.

Conciseness4/5

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

The description is a single front-loaded sentence with no filler. It conveys the core action and the key differentiator ('sem navegador nem sessão') efficiently. It could include more parameter guidance, but conciseness itself is well handled.

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 three parameters, no schema-level parameter descriptions, and a description that mentions none of them, the tool is not fully documented for correct invocation. The output schema reduces the need to explain return values, but the description still leaves the meaning and format of numero and limite_movimentos unexplained, which is a significant gap.

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%, so the description must compensate for the lack of parameter documentation. It does not: it never explains numero format, the tribunal enum values, or what limite_movimentos controls. The only indirect hint is 'NPU', which suggests numero, but no meaningful semantic detail is added.

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 tool as returning public metadata for an NPU via the CNJ DataJud API, and explicitly states it works without a browser or session. This distinguishes it from the many browser/session-based sibling tools such as consultar_autos or abrir_autos.

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 phrase 'sem navegador nem sessão' provides clear context for when this tool is appropriate: when the agent needs public metadata through the API without authenticating or driving a browser. It does not name alternatives or give exclusion criteria, but the context is clear enough to guide selection.

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

consultar_processo_publicoB

Consulta os dados públicos de um NPU do TJPE e mascara CPF/CNPJ no retorno.

ParametersJSON Schema

Name	Required	Description	Default
`grau`	Yes
`numero`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`grau`	Yes
`fonte`	No
`classe`	No
`numero`	Yes
`partes`	No
`assunto`	No
`url_fonte`	Yes
`movimentos`	No
`observacao`	No
`valor_causa`	No
`capturado_em`	No
`orgao_julgador`	No

TDQS

B3/5.0

Behavior3/5

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

With no annotations, the description carries the behavioral transparency burden. It does disclose an important behavior: CPF/CNPJ values are masked in the response, and it identifies the data as public. However, it does not mention other behaviors such as error cases, response size, or whether any authentication is needed.

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, tightly constructed sentence with no filler. It front-loads the core purpose and then adds the important masking behavior, earning its place efficiently.

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?

Even with an output schema present, the description leaves key operational context unresolved: the meaning of 'grau', how to construct the NPU, and when this tool is the right choice among several process-related siblings. For a large toolset, this is insufficient for reliable tool selection.

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?

The schema has 0% description coverage, so the description must compensate. It gives meaning to 'numero' by referring to an NPU, but it does not explain 'grau' (1g/2g) or provide format/validation guidance for the numero parameter. This is only partial parameter-level help.

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 ('Consulta'), the resource ('dados públicos de um NPU do TJPE'), and a distinctive behavior ('mascara CPF/CNPJ no retorno'). It is specific enough to convey what the tool does, though it does not explicitly differentiate itself from similar siblings like consultar_metadados_processo or consultar_autos.

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?

The description gives no guidance on when to use this tool versus alternatives. The word 'públicos' implies it is for public data, but there are no explicit exclusions, prerequisites, or comparisons to sibling tools.

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

diagnosticar_ambienteA

Testa Chromium, SICAJUD e consultas públicas do TJPE sem fazer login.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`itens`	Yes
`sucesso`	Yes

TDQS

A3.7/5.0

Behavior3/5

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

With no annotations, the description carries the disclosure burden. It does state the important no-login trait, which implies no credential side effects, and 'Testa' suggests a read-only diagnostic posture. It does not mention whether Chromium is launched, whether network calls are made, or any side effects beyond the existing output schema.

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?

One short sentence; every phrase adds information. The action and targets are front-loaded, and the no-login qualifier is a meaningful constraint.

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 zero-parameter diagnostic with an output schema, the description names the subjects and the key authentication constraint, which is enough to invoke the tool. It is not a 5 because it does not situate the tool among the numerous sibling diagnostics, leaving some selection ambiguity.

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?

There are zero parameters and 100% schema coverage, so there is no parameter burden for the description to carry. The baseline for a zero-parameter tool is 4, and the description adds relevant domain context around what is tested.

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 uses the verb 'Testa' and names three concrete resources (Chromium, SICAJUD, and public TJPE queries), so an agent can tell it is an environment diagnostic rather than a generic status check. It stops short of contrasting with sibling tools like diagnosticar_pjeoffice or status_servidor, but the scope is specific enough.

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?

'sem fazer login' implies this is a pre-authentication environment check, offering some contextual guidance. However, it never states when to prefer this over sibling diagnostics such as diagnosticar_pjeoffice or status_servidor, nor does it name alternatives or exclusions.

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

diagnosticar_pjeofficeA

Verifica passivamente porta local e botões SSO, sem clicar ou enviar dados.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`sso`	Yes
`mensagem`	Yes
`porta_local`	Yes
`aviso_seguranca`	No
`pronto_para_login`	Yes

TDQS

A3.6/5.0

Behavior4/5

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

No annotations are provided, so the description carries the full behavioral burden. It explicitly discloses that the tool is non-invasive ('sem clicar ou enviar dados') – a key safety trait for agents deciding between diagnostics and active actions. It could add more, but the essential side-effect profile is well covered.

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 efficient sentence that front-loads the main action, then supplies the safety qualifier. No wasted words, no redundancy.

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 description covers what the tool does and its non-invasive nature, and an output schema exists to define returns. However, it omits context such as prerequisites (e.g., whether PJeOffice must be installed/running), what the diagnostic results should be used for, or how this relates to sibling diagnostic steps – notable gaps for a 0-parameter tool.

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 parameters, the baseline is 4 per the rubric. The description does not need to explain parameter meaning since there is nothing to supply.

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 states a specific verb ('Verifica' – checks), specific resources ('porta local e botões SSO'), and a behavioral mode ('passivamente... sem clicar ou enviar dados'). This clearly distinguishes it from active tools like testar_login or abrir_login_certificado, though it does not explicitly name any sibling differentiator.

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 such as testar_login, verificar_login_certificado, or diagnosticar_ambiente. The 'passive' wording implies it is a safe pre-check, but the agent must infer that; no explicit condition or exclusion is stated.

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

encerrar_chat_cap1gB

DestructiveIdempotent

Encerra a conversa, fecha a janela e grava a transcrição com sidecar SHA-256.

ParametersJSON Schema

Name	Required	Description	Default
`referencia_chat`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`aviso`	Yes
`sha256`	Yes
`mensagens`	Yes
`iniciado_em`	Yes
`transcricao`	Yes
`encerrado_em`	No
`estado_final`	Yes
`encerrado_por`	Yes
`caminho_sha256`	Yes
`referencia_chat`	Yes
`total_mensagens`	Yes
`processos_solicitados`	No

TDQS

B3.2/5.0

Behavior3/5

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

Annotations already declare destructiveHint=true, readOnlyHint=false, and idempotentHint=true. The description adds specific behavioral details: it closes the window and writes a transcript with a sidecar SHA-256 hash, going beyond the annotations. However, it doesn't mention potential side effects like data loss or whether the transcript is persistent. Since annotations cover the core destructive nature, the added context earns a mid score.

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 sentence, efficiently listing the primary action and two key side effects. It is concise without unnecessary fluff. It front-loads the core action and follows with consequences, which is well structured.

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?

Given that the tool has an output schema (though not provided) and annotations covering safety, the description covers the main behavior. However, it omits critical details like whether the chat must be in a particular state, the meaning of the reference, and potential failure modes. Since it is a destructive operation with one parameter, more context might be needed for safe invocation.

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

Parameters3/5

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

Schema description coverage is 0%, so the description must compensate for the parameter 'referencia_chat'. The description doesn't explain what the reference is or how to format it. The schema only provides the name and type, leaving the semantic meaning ambiguous. Since there is only one parameter, a baseline of 3 seems harsh, but the description adds no value for the parameter.

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 ('encerrar a conversa'), the resource (chat), and additional effects (closes window, saves transcript with sidecar SHA-256). It distinguishes from siblings like 'enviar_mensagem_chat_cap1g' and 'aguardar_resposta_chat_cap1g' by focusing on termination. However, it doesn't explicitly name alternatives, but the purpose is clear.

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 others, such as after receiving the final response or before reading. It also doesn't mention prerequisites like whether a chat must be active or whether the reference must be valid. The description implies use for closing, but no explicit context or exclusions.

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

enviar_mensagem_chat_cap1gA

Destructive

Envia uma mensagem ao operador e confirma o eco no chat; recusa repetição.

ParametersJSON Schema

Name	Required	Description	Default
`mensagem`	Yes
`referencia_chat`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`aviso`	Yes
`fonte`	No
`estado`	Yes
`operador`	No
`encerrado`	Yes
`mensagens`	Yes
`ultimo_id`	Yes
`iniciado_em`	Yes
`pode_enviar`	Yes
`transcricao`	No
`atualizado_em`	No
`aviso_do_chat`	No
`nome_visitante`	Yes
`novas_mensagens`	Yes
`referencia_chat`	Yes
`total_mensagens`	Yes
`operador_digitando`	No
`processos_restantes`	Yes
`processos_solicitados`	No
`limite_processos_por_atendimento`	Yes

TDQS

A3.6/5.0

Behavior3/5

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

It adds useful behavior beyond annotations: the tool confirms the echo in the chat and refuses repetition. However, despite destructiveHint=true, it does not disclose that sending a real message is irreversible or what consequences that may have.

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 dense sentence front-loads the action, then gives the outcome and a guard condition. There is no wasted text.

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 output schema and annotations cover return values and safety, but the description does not place the tool within the cap1g chat lifecycle or explain what 'referencia_chat' refers to. It is minimally viable for a simple two-parameter tool.

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?

The schema has 0% description coverage, and the tool description does not clarify 'referencia_chat' or any constraints on 'mensagem'. 'mensagem' is reasonably inferable, but the identifier semantics and expected format are left entirely to the agent.

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 ('Envia'), names the resource ('mensagem ao operador'), and states the expected outcome ('confirma o eco no chat'). It clearly distinguishes this send action from the chat workflow siblings like ler_chat_cap1g or encerrar_chat_cap1g.

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 this tool is used when a message must be sent to the operator, and the 'recusa repetição' clause warns against duplicate sends. However, it does not state prerequisites (e.g., after iniciar_chat_cap1g) or explicitly compare against the many cap1g chat siblings.

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

iniciar_chat_cap1gB

DestructiveIdempotent

Abre o chat preparado, em janela visível, somente após a frase literal do usuário.

ParametersJSON Schema

Name	Required	Description	Default
`confirmacao`	Yes
`referencia_preparo`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`aviso`	Yes
`fonte`	No
`estado`	Yes
`operador`	No
`encerrado`	Yes
`mensagens`	Yes
`ultimo_id`	Yes
`iniciado_em`	Yes
`pode_enviar`	Yes
`transcricao`	No
`atualizado_em`	No
`aviso_do_chat`	No
`nome_visitante`	Yes
`novas_mensagens`	Yes
`referencia_chat`	Yes
`total_mensagens`	Yes
`operador_digitando`	No
`processos_restantes`	Yes
`processos_solicitados`	No
`limite_processos_por_atendimento`	Yes

TDQS

B3.3/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=false, destructiveHint=true, idempotentHint=true, and openWorldHint=true, so the safety profile is covered. The description adds useful context: the action opens a visible window (GUI side effect) and is gated on a literal user phrase. However, it never reconciles the benign-sounding 'open window' action with destructiveHint=true, leaving why this is destructive undisclosed.

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?

A single front-loaded sentence with no filler: the action, the visibility condition, and the gating condition all earn their place. It is appropriately compact for a two-parameter tool. The ambiguity of 'frase literal' costs a point on clarity, but structurally it is efficient.

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?

This is a state-changing tool in a multi-step workflow (verificar → preparar → iniciar → ler/enviar → encerrar) with two required, undocumented parameters. The description omits workflow prerequisites beyond 'prepared', does not explain whether the prepared state is consumed, and never addresses the destructiveHint annotation. An output schema exists so return values are covered, but workflow integration is thin.

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

Parameters3/5

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

Schema description coverage is 0%, so the description carries the burden. It hints that 'referencia_preparo' maps to the prepared chat and 'confirmacao' maps to the user's literal phrase, which adds some meaning beyond the bare names. But it never states what value confirmacao must hold (exact quote, specific trigger phrase?) or that referencia_preparo should come from preparar_chat_cap1g, leaving both parameters ambiguous.

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 states a concrete action: opening the prepared chat in a visible window, gated on the user's literal phrase. This differentiates it from siblings like preparar_chat_cap1g (prepares) and verificar_chat_cap1g (checks status). The 'frase literal do usuário' condition is somewhat vague, but the core purpose is clear.

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 two preconditions: the chat must be prepared ('chat preparado') and the user must have uttered a literal phrase, which maps to the required confirmacao parameter. However, it never explicitly names sibling tools or states when not to use this tool, leaving the workflow routing to inference from the sibling list.

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

inspecionar_aba_painelB

Read-onlyIdempotent

Descreve a estrutura de uma aba consultiva do painel, sem preencher ou submeter.

ParametersJSON Schema

Name	Required	Description	Default
`aba`	Yes
`grau`	Yes
`jurisdicao`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`aba`	Yes
`grau`	Yes
`aviso`	Yes
`fonte`	No
`botoes`	No
`iframes`	No
`paginacao`	No
`contadores`	No
`formularios`	No
`alternadores`	No
`capturado_em`	No
`motivo_quadro`	No
`quadros_vistos`	No
`campos_visiveis`	No
`criterios_busca`	No
`linhas_na_lista`	No
`pagina_embutida`	No
`abas_disponiveis`	No
`conteudo_embutido_lido`	No

TDQS

B3.4/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, so the safety profile is established. The description adds a concrete behavioral guarantee 'sem preencher ou submeter' (without filling or submitting), which reinforces the read-only nature, but it does not add further behavioral context such as preconditions or side effects beyond what annotations provide.

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 core purpose and includes the key read-only constraint. There is no redundancy or filler; every word contributes to the meaning.

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?

With an output schema present and annotations covering safety, the description’s main gap is context about preconditions or how the parameters shape the request. It clearly states the tool’s purpose, but does not explain what an 'aba consultiva' is or when this inspection is appropriate relative to other navigation/panel tools, leaving some contextual ambiguity.

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 mention any of the three parameters (aba, grau, jurisdicao). It does not explain how these parameters affect the inspection result or what values are expected, so it fails to compensate for the complete lack of schema descriptions.

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 the specific verb 'Descreve' (describes) and a specific resource: 'a estrutura de uma aba consultiva do painel' (the structure of a consultive panel tab). It also clarifies that it does not fill or submit ('sem preencher ou submeter'), distinguishing it from mutation tools. Among siblings, it is clearly distinct from similar inspection tools like 'inspecionar_estrutura_autos' because it targets the panel tab rather than court records.

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: use this tool when you need to inspect the structure of a consultive panel tab. However, it does not provide explicit when-to-use/when-not-to-use guidance or name alternative tools such as 'inspecionar_estrutura_autos', so the agent must infer the appropriate context from the purpose alone.

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

inspecionar_estrutura_autosA

Read-onlyIdempotent

Descreve a estrutura da timeline dos Autos, sem abrir ou ler peça alguma.

ParametersJSON Schema

Name	Required	Description	Default
`grau`	Yes
`numero`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`grau`	Yes
`aviso`	Yes
`fonte`	No
`numero`	Yes
`contagens`	No
`documentos`	No
`capturado_em`	No
`timeline_existe`	No

TDQS

A4/5.0

Behavior4/5

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false. The description adds a meaningful operational guarantee beyond these: no peça is opened or read, making the tool's non-invasive scope explicit. No contradiction with annotations.

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 sentence front-loads the purpose and the critical boundary. It contains no filler, no repetition of schema fields, and every phrase earns its place.

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 output schema and annotations cover return values and safety, so the description need not explain those. However, with zero parameter coverage, the description should provide more guidance on the two required inputs and when exactly to choose this over content-reading siblings.

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%, and the description says nothing about 'numero' or 'grau'. The parameter names and the grau enum are somewhat self-explanatory, but the description does not compensate for the missing format or context of 'numero'.

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 opens with 'Descreve a estrutura da timeline dos Autos', giving a specific verb and resource. It also explicitly states 'sem abrir ou ler peça alguma', which distinguishes it from content-reading siblings like ler_documento_autos and consultar_autos.

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 clause 'sem abrir ou ler peça alguma' clearly orientates when to use this tool: when only the timeline structure is needed, not document contents. It does not name sibling alternatives explicitly, but the context is clear enough.

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

ler_chat_cap1gA

Read-onlyIdempotent

Lê estado e mensagens do chat em andamento sem esperar nem enviar nada.

ParametersJSON Schema

Name	Required	Description	Default
`desde_id`	No
`referencia_chat`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`aviso`	Yes
`fonte`	No
`estado`	Yes
`operador`	No
`encerrado`	Yes
`mensagens`	Yes
`ultimo_id`	Yes
`iniciado_em`	Yes
`pode_enviar`	Yes
`transcricao`	No
`atualizado_em`	No
`aviso_do_chat`	No
`nome_visitante`	Yes
`novas_mensagens`	Yes
`referencia_chat`	Yes
`total_mensagens`	Yes
`operador_digitando`	No
`processos_restantes`	Yes
`processos_solicitados`	No
`limite_processos_por_atendimento`	Yes

TDQS

A3.9/5.0

Behavior3/5

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false. The description adds context that the operation is non-blocking and scoped to an ongoing chat, but it does not cover edge cases like missing/invalid chat references or the effect of the 'desde_id' parameter.

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?

One sentence with no filler, front-loaded with the core behavior and immediately followed by the key exclusion ('sem esperar nem enviar nada'). Every part 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?

For a simple read tool with rich annotations and an output schema, the description covers the key decision factors: read-only, non-blocking, scoped to ongoing chat. The main gap is the absence of any input-parameter guidance, but this is a minor omission given the low complexity.

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% and the description provides no parameter details. The parameter names 'referencia_chat' and 'desde_id' are somewhat self-explanatory, but the agent receives no guidance on their format, origin, or incremental-reading semantics.

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 gives a specific verb and resource: 'Lê estado e mensagens do chat em andamento' (reads state and messages of the ongoing chat). It also explicitly contrasts with waiting or sending, which clearly distinguishes it from sibling chat tools.

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 phrase 'sem esperar nem enviar nada' communicates clearly when to use this tool: for non-blocking inspection only. It implicitly rules out uses handled by waiting/sending siblings, though it does not name them explicitly.

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

ler_documento_autosA

Extrai texto de documento já enumerado nos Autos e informa seu SHA-256.

ParametersJSON Schema

Name	Required	Description	Default
`grau`	Yes
`numero`	Yes
`max_paginas`	No
`max_caracteres`	No
`referencia_documento`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`grau`	Yes
`aviso`	Yes
`texto`	Yes
`numero`	Yes
`sha256`	Yes
`titulo`	Yes
`truncado`	Yes
`tipo_mime`	Yes
`paginas_lidas`	No
`tamanho_bytes`	Yes
`paginas_totais`	No
`referencia_documento`	Yes

TDQS

A3.5/5.0

Behavior3/5

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

No annotations are provided, so the description bears the full burden of behavioral disclosure. It adequately describes the core behavior (extracting text and computing SHA-256) and signals a non-destructive read operation by implication, but it does not disclose potential truncation behavior, authentication needs, or what happens when the document is unavailable.

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 the action, target, and output with no filler or redundant information. It is front-loaded and efficient.

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?

Given the presence of many sibling tools and five parameters with no documented semantics, the description is too terse. It does not explain how to identify the document, when to use limits, or how this tool relates to alternatives, so an agent may not have enough context to invoke it correctly.

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%, and the description does not explain any parameter. It only indirectly suggests that 'referencia_documento' refers to a document already in the Autos, but it does not clarify 'numero', 'grau', 'max_paginas', or 'max_caracteres'. The agent must infer most parameter semantics from parameter names alone.

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 states a specific verb 'Extrai texto', a specific resource ('documento já enumerado nos Autos'), and a concrete output (SHA-256). This clearly distinguishes it from sibling tools like baixar_documento_autos and consultar_autos, which serve different purposes.

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 phrase 'já enumerado nos Autos' implies the tool is intended for documents that have already been enumerated in the case files, giving some usage context. However, it does not explicitly state when to use this tool versus alternatives, nor does it mention exclusions or preconditions beyond enumeration.

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

listar_acervoC

Lista ou pesquisa o Acervo de uma jurisdição; a busca roda no próprio PJe.

ParametersJSON Schema

Name	Required	Description	Default
`oab`	No
`grau`	Yes
`parte`	No
`classe`	No
`filtro`	No
`limite`	No
`assunto`	No
`paginas`	No
`pesquisa`	No
`documento`	No
`jurisdicao`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`grau`	Yes
`aviso`	Yes
`fonte`	No
`parcial`	Yes
`processos`	Yes
`capturado_em`	No
`total_carregado`	Yes
`paginas_percorridas`	No
`total_na_jurisdicao`	No

TDQS

C2.6/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 full behavioral burden. It only discloses that the search runs in the PJe environment, but does not state whether the operation is read-only, what it returns, how pagination works, or what failures may occur. For an 11-parameter search action, this is under-transparent.

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 description is short, front-loaded, and has no redundant clauses. However, a single sentence is under-sized for a tool with 11 parameters and zero schema-level descriptions, so the conciseness comes at the cost of usefulness.

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

Completeness1/5

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

Despite having an output schema, the description is materially incomplete: it lacks parameter semantics, usage context, and behavioral expectations. With no annotations and 0% schema coverage, the one-line description does not give an agent enough to call this tool correctly or choose it among siblings.

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 mention or explain any of the 11 parameters, including key filters like grau, filtro, pesquisa, parte, or assunto. The description fails to compensate for the schema gap, forcing agents to guess parameter purposes.

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 states a specific action ('Lista ou pesquisa o Acervo') and a scope ('de uma jurisdição'), and adds the useful context that the search runs inside PJe. It does not explicitly contrast with sibling tools, but the resource and scope are identifiable enough for an agent to distinguish it from tools like listar_jurisdicoes_acervo.

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 intended use is implied by the verbs 'listar/pesquisar' and the note that the search runs in PJe, but there is no explicit when-to-use guidance, no exclusions, and no mention of alternatives. An agent is left to infer when this tool should be preferred over other search/consultation tools.

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

listar_ambientesA

Lista URLs oficiais configuradas para o PJe/TJPE de 1º e 2º graus.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4/5.0

Behavior3/5

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

No annotations are present, so the description must bear the full burden. It states the action is 'Lists', which implies a non-destructive read operation, but does not disclose potential side effects, prerequisites, or authentication needs. Since the tool is a simple listing, the description is adequate but minimal.

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, concise and front-loaded with the action and object. No unnecessary words or redundancy.

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 that there is an output schema and no parameters, the description covers the necessary information for an agent to understand the tool's purpose. It could have elaborated on the exact detail of 'oficiais configuradas' but is sufficient for a simple listing tool.

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 tool has zero parameters, so the baseline is 4. The description does not need to explain parameters, as there are none.

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 a specific verb ('Lista') and resource ('URLs oficiais configuradas para o PJe/TJPE de 1º e 2º graus'), making it distinct from sibling tools like 'listar_tribunais_suportados' which lists supported courts. It precisely identifies what the tool does.

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—this tool is used to retrieve official PJe/TJPE environment URLs—but it does not explicitly state when to use it versus alternatives, nor any exclusions. No usage context is provided beyond the core action.

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

listar_downloads_pjedocsA

Consulta o estado do resultado solicitado no PJeDocs sem abrir outros processos.

ParametersJSON Schema

Name	Required	Description	Default
`grau`	Yes
`numero`	Yes
`referencia_solicitacao`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`grau`	Yes
`aviso`	Yes
`numero`	Yes
`parcial`	Yes
`downloads`	Yes
`referencia_solicitacao`	Yes

TDQS

A3.7/5.0

Behavior3/5

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

With no annotations provided, the description carries the burden of behavioral disclosure. It signals a read-only query ('Consulta') and guarantees no process is opened, which is a meaningful behavioral trait. It does not mention prerequisites, polling behavior, or side effects, but for a simple status query these are less critical. The description adds some value beyond the tool name.

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, front-loaded sentence that states the core action and a relevant caveat. There is no filler or redundancy; every phrase contributes to understanding what the tool does and its boundary. It is easy to parse and appropriately sized.

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?

The description is minimal and does not place the tool in the broader PJeDocs workflow, such as being called after solicitar_download_pjedocs and before baixar_resultado_pjedocs. With zero schema coverage on the parameters, the agent must infer the meaning of the three inputs from names alone. The existence of an output schema helps with return values, but the tool remains incomplete for correct invocation.

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%, and the description does not explain any of the three required parameters ('numero', 'grau', 'referencia_solicitacao'). The phrase 'resultado solicitado' hints at the reference parameter, but there is no mapping, format, or guidance for how to fill the inputs. The description fails to compensate for the lack of schema descriptions.

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 ('Consulta') with a clear resource ('estado do resultado solicitado no PJeDocs'), identifying this as a status-check tool. It also adds 'sem abrir outros processos,' which distinguishes it from process-opening alternatives and aligns it with lightweight polling. This clearly separates it from sibling tools like solicitar_download_pjedocs or baixar_resultado_pjedocs.

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 implies a clear use case: checking the state of a previously requested PJeDocs result. The caveat 'sem abrir outros processos' gives an exclusion boundary, indicating this tool is non-intrusive and not for opening processes. However, it does not explicitly mention when to use it relative to other download-related tools or name alternatives, so it stops short of full workflow guidance.

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

listar_falhas_navegacaoB

Read-onlyIdempotent

Lê eventos estruturais sanitizados; nunca retorna HTML, NPU, credencial ou texto livre.

ParametersJSON Schema

Name	Required	Description	Default
`limite`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

B3.3/5.0

Behavior4/5

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

The annotations already establish read-only, idempotent, and non-destructive behavior. The description adds a meaningful sanitization guarantee—never returning HTML, NPU, credentials, or free text—which is not derivable from the annotations. It omits details like ordering or pagination, but still provides useful behavioral context beyond the structured metadata.

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, front-loaded sentence. The first clause states the function and the second adds a relevant safety guarantee. There is no filler, redundancy, or unnecessary structure.

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?

With one optional parameter, an output schema, and strong annotations, the description is nearly sufficient for invocation. However, it leaves 'eventos estruturais' undefined and never mentions 'falhas' directly, so the agent cannot fully understand what the returned events represent. The sanitization guarantee helps, but the core resource remains vague.

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?

The schema has one optional parameter, 'limite', with a default of 20 and 0% description coverage. The description does not mention this parameter or clarify whether it caps result count, page size, or a time window. Although the parameter name is fairly transparent, the description fails to compensate for the absent schema documentation.

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 specifies a concrete action ('lê') and resource ('eventos estruturais sanitizados'), and adds a clear output boundary: it never returns HTML, credentials, or free text. However, it does not explicitly say 'falhas de navegação' or contrast with sibling tools, so the agent must infer the exact purpose from the tool name.

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 alternatives such as status_navegacao_adaptativa or diagnosticar_ambiente. The description states what the tool does but does not provide conditions, prerequisites, or exclusions that would help the agent select it correctly.

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

listar_jurisdicoes_acervoA

Lista as jurisdições do Acervo deste grau, para escolher uma em listar_acervo.

ParametersJSON Schema

Name	Required	Description	Default
`grau`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`grau`	Yes
`aviso`	Yes
`fonte`	No
`jurisdicoes`	Yes
`capturado_em`	No

TDQS

A3.8/5.0

Behavior3/5

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

With no annotations, the description's verb 'Lista' is the main behavioral signal and indicates a read-only operation on jurisdictions. It also adds the 'deste grau' scoping constraint, which is useful context, but it doesn't state that no data is modified or what the output contains (the latter is partly covered by the output schema).

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 well-structured sentence that front-loads the action and resource, then adds the purpose clause. There is no redundant or filler content.

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?

For a simple, low-complexity list tool with an output schema, the essential purpose and workflow are present. However, because the required 'grau' parameter is undocumented and 'Acervo' is never defined, the description leaves the agent to guess about domain-specific meaning before calling listar_acervo.

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?

The schema provides only the enum values '1g'/'2g' with no descriptions (0% coverage). The description's phrase 'deste grau' weakly ties the parameter to the listing, but it never explains what the two grau values mean or how an agent should choose one, so it does not compensate for the schema gap.

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 the specific verb 'Lista' with a specific resource, 'as jurisdições do Acervo deste grau,' and explains its downstream purpose: 'para escolher uma em listar_acervo.' This differentiates it from the sibling listar_acervo by naming it as the next step rather than the main listing tool.

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 explicitly names the intended workflow context: call this tool before listar_acervo in order to pick a jurisdiction. It doesn't list alternatives or exclusions, so it stops short of a full when-not-to-use statement.

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

listar_tribunais_suportadosA

Read-onlyIdempotent

Lista ambientes oficiais e informa claramente quais adaptadores ainda estão em descoberta.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.9/5.0

Behavior4/5

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

Annotations already establish read-only, idempotent, non-destructive behavior, so the description's job is lighter. It adds useful behavioral context by saying the tool clearly reports which adapters are still in discovery, and it does not contradict annotations.

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 front-loaded sentence that states the core action and the distinctive second clause about adapters in discovery. No filler.

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 no-parameter, read-only list with an output schema, the description supplies the essential selection information. It could be more complete by clarifying the relationship to listar_ambientes, but nothing needed to invoke it 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 tool has zero parameters and 100% schema coverage, so the description owes no parameter-level detail. Per the 0-parameter baseline this is a strong score; the description doesn't need to compensate.

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 identifies the action (lists) and the object (official environments) and adds the specific nuance of reporting adapters still in discovery. It is clear, but it relies on the tool name 'tribunais suportados' to fully anchor the resource and does not explicitly position itself against siblings like listar_ambientes.

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 context is implied: call this when you need official environments and adapter discovery status. However, it never states when to prefer this over listar_ambientes, status_servidor, or validar_adaptadores_offline, nor does it give any exclusions.

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

pesquisar_classes_custasB

Pesquisa códigos e descrições de classes na lista oficial do SICAJUD.

ParametersJSON Schema

Name	Required	Description	Default
`termo`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

B3.1/5.0

Behavior2/5

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

Não há annotations, então a descrição carrega toda a responsabilidade de transparência comportamental. 'Pesquisa' sugere uma operação somente leitura, mas não declara explicitamente a ausência de efeitos colaterais, requisitos de autenticação, limites ou qualquer outra característica além da busca em si.

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 descrição é uma única frase objetiva, sem palavras desnecessárias e com a informação principal no início. É adequadamente concisa para uma ferramenta simples, mesmo que outras dimensões sofram com a falta de detalhes.

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?

A ferramenta é de baixa complexidade, com apenas um parâmetro obrigatório e schema de saída presente, então a descrição não precisa detalhar valores de retorno. Porém, sem annotations e com pouca orientação sobre o significado do parâmetro, a descrição deixa lacunas importantes para o agente invocar a ferramenta corretamente.

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

Parameters3/5

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

A cobertura de descrição do schema é 0%, então a descrição precisa compensar pelo parâmetro 'termo'. Ela implica que 'termo' é a palavra-chave de busca, mas não especifica se a busca é por código, descrição, parcial/exata, sensível a maiúsculas ou qual formato é aceito.

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?

A descrição usa um verbo específico ('Pesquisa') e identifica o recurso ('códigos e descrições de classes na lista oficial do SICAJUD'), deixando claro o que a ferramenta retorna. Porém, não diferencia explicitamente de ferramentas irmãs como simular_custas ou consultar_metadados_processo.

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?

A descrição informa apenas a ação de pesquisa, sem indicar quando usar esta ferramenta em vez de alternativas, nem quando não usar. Não há menção a pré-requisitos, exceções ou contexto de decisão entre as ferramentas irmãs.

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

preparar_acesso_pesquisa_geralA

Read-onlyIdempotent

Pesquisa um NPU exato e prepara sua abertura sem registrar o acesso ao processo.

ParametersJSON Schema

Name	Required	Description	Default
`grau`	Yes
`numero`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`grau`	Yes
`aviso`	Yes
`numero`	Yes
`expira_em`	Yes
`frase_confirmacao`	Yes
`referencia_preparo`	Yes

TDQS

A3.5/5.0

Behavior4/5

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

The annotations already declare the tool read-only, idempotent, and non-destructive. The description adds a meaningful behavioral detail beyond those annotations: it does not register the access to the process, which is useful for predicting side effects in a workflow context.

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, focused sentence that states the main action and the key behavioral caveat without any filler. It is front-loaded and easy to parse.

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 output schema and annotations cover return values and safety, so the description does not need to explain those. However, the description omits parameter-level guidance and does not clearly distinguish this tool from its sibling 'abrir_autos_pesquisa_geral', leaving moderate gaps for an agent deciding how and when to invoke it.

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%, so the description must compensate, but it only references 'NPU' in prose without explicitly mapping it to 'numero' or explaining the 'grau' parameter. The enum values are visible in the schema, but no format, meaning, or relationship between the parameters is described.

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: searching for an exact NPU and preparing its opening, without registering access to the process. It is specific about the resource and behavior, though it does not explicitly contrast it with the sibling tool 'abrir_autos_pesquisa_geral'.

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 the use case: use this when you need to prepare access to an exact NPU but avoid logging that access. However, it does not explicitly name alternatives or provide when-not-to-use guidance, leaving the routing decision partially implicit.

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

preparar_chat_cap1gA

Read-only

Valida identificação e mensagem inicial e prepara o chat sem iniciá-lo.

ParametersJSON Schema

Name	Required	Description	Default
`nome`	Yes
`email`	Yes
`mensagem_inicial`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`nome`	Yes
`aviso`	Yes
`email`	Yes
`expira_em`	Yes
`disponivel`	Yes
`mensagem_inicial`	Yes
`frase_confirmacao`	Yes
`referencia_preparo`	Yes
`processos_na_mensagem`	No
`limite_processos_por_atendimento`	Yes

TDQS

A3.8/5.0

Behavior3/5

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

Annotations already cover the read-only and non-destructive safety profile. The description adds that it validates inputs and does not start the chat, but it does not explain what 'prepara' means in terms of state or prerequisites. No contradiction with the annotations is present.

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 concise sentence contains the core purpose and the key non-start boundary, with no filler or repetition of schema fields.

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?

For a simple three-string-parameter tool with annotations and an output schema, this is serviceable but thin: it leaves the meaning of 'preparar' ambiguous and does not state that the prepared chat should later be followed by 'iniciar_chat_cap1g'. The output schema covers return values, but workflow context is missing.

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%, so the description carries the burden, but it only loosely maps parameters to 'identificação' (nome/email) and 'mensagem inicial'. It does not define validation rules, formats, or relationships among the three required parameters.

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 names the resource ('chat') and uses specific verbs: it validates 'identificação' and 'mensagem inicial' and prepares the chat. The clause 'sem iniciá-lo' explicitly separates this tool from the sibling 'iniciar_chat_cap1g'.

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 establishes clear context: this is a pre-start preparation step, and the explicit 'sem iniciá-lo' tells the agent not to expect the chat to be started. It does not name sibling tools or spell out a full when-to-use/when-not-to-use rule, so it stops short of a 5.

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

preparar_download_pjedocsB

Prepara a solicitação da íntegra no PJeDocs sem disparar a geração.

ParametersJSON Schema

Name	Required	Description	Default
`grau`	Yes
`numero`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`grau`	Yes
`modo`	No
`aviso`	Yes
`numero`	Yes
`expira_em`	Yes
`frase_confirmacao`	Yes
`inclui_movimentos`	No
`inclui_expedientes`	No
`referencia_preparo`	Yes

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 must carry the full burden. It discloses that generation is not triggered, but says nothing about side effects, permissions, error conditions, or what happens on success or failure. The behavioral disclosure is minimal and does not go beyond the obvious.

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, tight sentence with no wasted words. It front-loads the action and the key qualifier ('sem disparar a geração') is placed immediately. Perfectly concise.

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?

Given that this tool is part of a download workflow with siblings like 'solicitar_download_pjedocs' and 'baixar_resultado_pjedocs', the description lacks essential context: when to use it (before triggering generation), what it returns (though an output schema exists), and any preconditions. The description is too thin for an agent to correctly sequence it.

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% (no descriptions on parameters). The description does not explain the meaning or format of 'numero' or 'grau'. While the names are somewhat self-explanatory, the description adds no semantic value and fails to compensate for the missing schema documentation.

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 states a clear verb ('Prepara'), a specific resource ('a solicitação da íntegra no PJeDocs'), and explicitly notes it does not trigger generation, distinguishing it from sibling 'solicitar_download_pjedocs'. This is specific and unambiguous.

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?

The description implies a workflow distinction by saying 'sem disparar a geração', but it does not explicitly state when to use this tool versus alternatives, nor any preconditions or sequencing. No mention of when-not-to-use or recommended context.

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

simular_custasB

Simula taxa e custas no SICAJUD; não cria, vincula ou paga uma guia.

ParametersJSON Schema

Name	Required	Description	Default
`classe`	Yes
`valor_causa`	Yes
`codigo_classe`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`aviso`	Yes
`fonte`	No
`itens`	Yes
`classe`	Yes
`natureza`	No
`url_fonte`	Yes
`valor_causa`	Yes
`valor_total`	Yes
`capturado_em`	No
`versao_sicajud`	No

TDQS

B3.3/5.0

Behavior3/5

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

With no annotations provided, the description carries the full burden. It discloses a key behavioral trait: simulation is non-committal (does not create, link, or pay). This is meaningful and prevents misuse. However, it does not mention other potential side effects, authentication requirements, rate limits, or whether the operation is read-only. The description adds some value but not comprehensive 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, succinct sentence that immediately states the core action and resource, then clarifies the boundary with a negation. It is front-loaded and contains no fluff. It earns a high score for efficiency.

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 description is adequate for a simple simulation tool, but it lacks parameter semantics and any mention of prerequisites or error conditions. Since an output schema exists, the lack of return-value explanation is acceptable. However, given the tool is part of a larger set with siblings, there is no context on when to choose this over alternatives, making it somewhat incomplete.

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%, meaning the description provides no explanation of the parameters. The input schema has titles like 'Classe' and 'Valor Causa', which give minimal cues, but the description adds nothing about parameter meaning, format, or constraints. For a 3-parameter tool, the description should compensate for the schema gap, but it does not.

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 ('Simula' – simulates) and the resource ('taxa e custas no SICAJUD' – fees and costs in SICAJUD). It explicitly lists what it does NOT do (create, bind, or pay a fee), which helps delineate its scope. However, it does not name any specific sibling tool to differentiate from, so it falls short of a 5.

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 context: use this tool when you need to estimate fees/costs without executing an actual payment or binding action. It gives no explicit guidance on when NOT to use it or what alternative tool to choose (e.g., siblings like 'pesquisar_classes_custas' might be related). The negation hints at exclusions but does not name alternatives.

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

solicitar_download_pjedocsC

DestructiveIdempotent

Solicita a íntegra preparada somente após nova mensagem do usuário com a frase literal.

ParametersJSON Schema

Name	Required	Description	Default
`grau`	Yes
`numero`	Yes
`confirmacao`	Yes
`referencia_preparo`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`grau`	Yes
`aviso`	Yes
`estado`	Yes
`numero`	Yes
`reutilizada`	Yes
`solicitado_em`	Yes
`referencia_solicitacao`	Yes

TDQS

C2.6/5.0

Behavior3/5

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

Annotations already declare destructiveHint=true and readOnlyHint=false. The description adds the user-phrase precondition, which is useful behavioral context, but it does not disclose what side effects occur (e.g., whether it deletes or marks the prepared document). With annotations present, the bar is lower, but the destructive action remains unexplained.

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 description is a single sentence, which is efficient and front-loaded, but it omits critical details such as parameter meanings and workflow context. It is under-specified rather than appropriately concise, so it does not earn full marks for structure.

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 required parameters, no schema descriptions, and a large sibling set, the description fails to explain the meaning of 'prepared', the required user phrase, or the tool's role in the download workflow. It is far from complete for correct 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 mentions none of the four required parameters (numero, grau, referencia_preparo, confirmacao). The tool provides zero guidance on what these parameters mean or how to fill them, leaving the agent completely in the dark.

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 states a specific verb ('solicita') and resource ('íntegra preparada'), but the meaning of 'prepared' is unclear and it does not distinguish this tool from siblings like 'baixar_resultado_pjedocs' or 'baixar_documento_autos'. It is not a tautology but leaves the scope ambiguous.

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?

It gives a clear timing precondition ('somente após nova mensagem do usuário com a frase literal'), but does not mention any alternatives, when not to use it, or how it fits into the workflow among many download-related siblings. The condition is helpful but incomplete.

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

status_navegacao_adaptativaA

Read-onlyIdempotent

Informa modo, retenção e adaptadores locais sem abrir navegador ou acessar tribunal.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`modo`	Yes
`aviso`	Yes
`observacoes`	Yes
`persistencia`	No
`schema_version`	No
`ultimo_erro_local`	No
`adaptadores_active`	Yes
`limite_observacoes`	Yes
`adaptadores_carregados`	Yes

TDQS

A3.7/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the agent knows it's a safe, non-destructive read. The description adds context about what it informs (mode, retention, adapters) and the non-browser/non-tribunal aspect, but doesn't disclose any other behavioral traits like output format or potential side effects. No contradiction.

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 immediately conveys the core purpose and the key differentiator (no browser/tribunal access). Every word earns its place, no fluff.

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 tool has zero parameters and no output schema details are needed (though an output schema exists, its structure isn't provided in the signal), the description sufficiently covers what the tool does and its scope. The absence of usage exclusions is a minor gap, but for such a simple tool, it's nearly complete.

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 tool has zero parameters, and the schema coverage is 100% (vacuously). The description explains what the tool returns (mode, retention, adapters), which adds meaning beyond the empty schema. With no parameters, there is nothing else to document, so a baseline of 4 is appropriate.

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 verb 'Informa' (informs) and the resource: mode, retention, and local adapters. It also distinguishes itself by noting it does so without opening a browser or accessing the court, which sets it apart from navigation-related tools. However, it doesn't explicitly name sibling tools for differentiation.

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 when to use this tool (when you need status information without browser/tribunal access), but it doesn't explicitly state when not to use it or suggest alternatives. Sibling tools like 'diagnosticar_ambiente' or 'validar_adaptadores_offline' could be related, but no guidance is given.

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

status_servidorA

Informa versão, segurança e recursos disponíveis sem abrir o navegador.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`nome`	Yes
`versao`	Yes
`revisao`	No
`tribunal`	Yes
`transporte`	Yes
`modo_seguro`	Yes
`recursos_ativos`	Yes
`credenciais_configuradas`	Yes

TDQS

A4/5.0

Behavior3/5

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

With no annotations provided, the description carries the full behavioral burden. It discloses that the tool does not open the browser and implies read-only behavior through 'Informa', but it does not discuss access requirements, side effects, or failure modes. The presence of an output schema mitigates the need to explain return values.

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 focused sentence that front-loads the verb and resource and adds the key browser-free constraint. Every word 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?

For a zero-parameter status tool with an output schema, the description is nearly complete. It states the type of information returned and the non-browser behavior, though 'segurança e recursos' could be slightly more explicit.

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 tool has zero parameters and an empty input schema, so there is nothing for the description to clarify. Baseline 4 applies.

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 ('Informa') and a clear resource ('versão, segurança e recursos disponíveis'), and adds a distinguishing behavior ('sem abrir o navegador'). This makes it easy to separate from browser-focused sibling tools like status_navegacao_adaptativa.

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 phrase 'sem abrir o navegador' implies the use case of retrieving server status without launching a browser, but there is no explicit when-to-use or when-not-to-use guidance, nor mention of an alternative. Usage is mostly inferred.

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

testar_loginC

Testa o login pessoal salvo no Keychain, sem abrir processo ou expediente.

ParametersJSON Schema

Name	Required	Description	Default
`grau`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`grau`	Yes
`estado`	Yes
`mensagem`	Yes
`url_atual`	Yes
`autenticado`	Yes
`modo_autenticacao`	No

TDQS

C2.9/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 full burden. It says the tool tests a saved login without opening a process, but it doesn't disclose what happens on success/failure, whether it makes network calls, whether it modifies anything, or what the output looks like. The negative scope is useful but insufficient for a tool that likely performs authentication checks.

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 in Portuguese, front-loading the main action and adding a useful negative scope. It earns its place with no wasted words, though it could benefit from a bit more detail on behavior.

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 annotations, no parameter description, and a single required parameter, the description is too thin. An agent doesn't know what 'grau' means, what a successful test looks like, or what side effects (if any) occur. The output schema exists but the description still needs to explain the tool's purpose and parameter semantics more fully.

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%, and the description does not explain the 'grau' parameter at all. The schema defines it as an enum of '1g' or '2g' with title 'Grau', but the description doesn't clarify what grau means in this context (e.g., court degree/instance) or how it affects the login test. The description should compensate for the schema's lack of description but doesn't.

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 states a specific verb ('Testa' = tests) and resource ('login pessoal salvo no Keychain'), and clarifies it does not open a process or expediente. This distinguishes it from sibling tools like abrir_login_certificado and verificar_login_certificado, though it doesn't explicitly name them.

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 this is for testing a saved personal Keychain login, and the negative clause ('sem abrir processo ou expediente') gives some context. However, it doesn't explicitly state when to use this vs alternatives like verificar_login_certificado or diagnosticar_ambiente, nor does it mention prerequisites like needing a saved login.

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

validar_adaptadores_offlineB

Read-onlyIdempotent

Reavalia o JSONL com os YAML empacotados sem rede, clique ou preenchimento.

ParametersJSON Schema

Name	Required	Description	Default
`limite`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`aviso`	Yes
`resultados`	Yes
`rede_utilizada`	No
`observacoes_avaliadas`	Yes

TDQS

B3/5.0

Behavior3/5

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the description does not need to restate safety. It adds useful context by emphasizing that the re-evaluation happens offline with no clicks or form fills. No additional behavioral traits, such as what a successful re-evaluation changes or how long it takes, are disclosed.

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?

One short sentence with no filler, and the core action plus offline condition are front-loaded. Some technical jargon is packed into 'JSONL com os YAML empacotados', but nothing is redundant.

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 simple: one optional parameter, an output schema, and strong safety annotations. The description is close to sufficient but lacks any rationale for when to run the offline re-evaluation and does not define 'adaptadores' or clarify the meaning of 'limite', leaving moderate gaps for an agent deciding whether to invoke it.

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% and the description never mentions 'limite'. With no schema documentation, the description must explain the parameter, but it does not. Agents only have the field title 'Limite' and the default value to infer that it caps the number of entries processed.

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 names a specific action ('Reavalia') and a concrete resource ('o JSONL com os YAML empacotados'), and adds a key condition ('sem rede, clique ou preenchimento'). It is not a tautology and is clearly distinct from the diagnostic and navigation siblings, though 'adaptadores' remains somewhat undefined.

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 explicit guidance is given about when to call this tool instead of alternatives such as diagnosticar_ambiente or listar_falhas_navegacao. The phrase 'sem rede, clique ou preenchimento' implies an offline/headless use case, but that is a behavioral constraint, not a usage rule with conditions or alternatives.

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

verificar_chat_cap1gA

Read-onlyIdempotent

Verifica passivamente se a CAP1G tem operador no chat, sem abrir conversa.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`url`	Yes
`aviso`	Yes
`fonte`	No
`grupo`	No
`portal`	Yes
`mensagem`	Yes
`telefone`	No
`disponivel`	Yes
`modo_inicial`	Yes
`verificado_em`	No
`dentro_do_horario`	Yes
`horario_atendimento`	No
`limite_processos_por_atendimento`	Yes

TDQS

A3.9/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the description does not need to repeat those. The description adds the 'passive' and 'without opening conversation' behavioral details, which go beyond the annotations. However, it doesn't clarify potential latency or network behavior, but for a zero-parameter background check, this is acceptable.

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 is concise, informative, and front-loads the key point ('verifica passivamente') and the resource. It contains no filler or redundant 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?

Given that there are no parameters, an output schema exists, and annotations cover safety, the description is nearly complete. The only minor gap is the lack of an explicit statement about what the response indicates (e.g., boolean presence of operator), but the output schema likely covers that. The tool is simple, so this is adequate.

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?

There are zero parameters, and the schema description coverage is 100% (trivially, as there are no properties). The description does not need to add parameter details, and it doesn't. The score is high because the absence of parameters is fully represented in the schema, and the description clarifies the tool's scope.

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 states a specific action ('verifica passivamente'), a resource (CAP1G), and the goal (whether an operator is in the chat), and adds a constraint ('sem abrir conversa'). It is clear and distinct from sibling tools like 'iniciar_chat_cap1g' and 'enviar_mensagem_chat_cap1g', though it doesn't explicitly name those siblings.

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 implies this should be used before starting or engaging in a chat, and the 'passively' and 'without opening conversation' provide clear context. However, it doesn't explicitly state when NOT to use it or mention alternative tools for checking chat status.

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

verificar_login_certificadoC

Verifica a tentativa existente sem clicar novamente ou solicitar PIN.

ParametersJSON Schema

Name	Required	Description	Default
`grau`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`grau`	Yes
`estado`	Yes
`mensagem`	Yes
`url_atual`	Yes
`autenticado`	Yes
`modo_autenticacao`	No

TDQS

C2.9/5.0

Behavior3/5

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

No annotations are provided, so the description carries the full burden. It does disclose a meaningful behavioral trait: checking an existing attempt without clicking or requesting a PIN, implying a non-interactive verification. But it does not clarify whether the tool polls, what state changes occur, or whether the attempt is consumed or preserved, which is important for a tool with no annotation safety profile.

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 one sentence with no filler and the core action is front-loaded. However, it is so terse that it omits necessary parameter semantics, so brevity comes at the cost of completeness.

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 an output schema exists, this is a no-annotation tool with one required enum parameter and several closely related siblings. The description gives only a high-level purpose and leaves invocation requirements, parameter meaning, and sibling differentiation unresolved. That is not enough for correct standalone use.

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 required parameter, grau, is completely absent from the description. With schema description coverage at 0%, the description needed to explain what grau means and how to choose between '1g' and '2g'. It does neither, so an agent cannot reliably select the correct value.

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 states a specific action: 'Verifica a tentativa existente' (checks the existing attempt) and adds a key constraint: 'sem clicar novamente ou solicitar PIN' (without clicking again or requesting a PIN). This distinguishes it from tools that start a login, though it does not explicitly name siblings or define what 'tentativa existente' means in detail.

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 when to use the tool: when an attempt already exists and the user wants to avoid re-triggering a click or PIN prompt. However, it provides no explicit when-not-to-use guidance and does not name alternatives like testar_login or abrir_login_certificado, leaving the routing between siblings to inference.

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.

35 tool updatesv0.7.2Sep 18, 2026
- First observedabrir_autos_pesquisa_geral
- First observedabrir_login_certificado
- First observedaguardar_resposta_chat_cap1g
- First observedbaixar_documento_autos
- First observedbaixar_resultado_pjedocs
- First observedconsultar_autos
- First observedconsultar_metadados_processo
- First observedconsultar_processo_publico
- First observeddiagnosticar_ambiente
- First observeddiagnosticar_pjeoffice
- First observedencerrar_chat_cap1g
- First observedenviar_mensagem_chat_cap1g
- First observediniciar_chat_cap1g
- First observedinspecionar_aba_painel
- First observedinspecionar_estrutura_autos
- First observedler_chat_cap1g
- First observedler_documento_autos
- First observedlistar_acervo
- First observedlistar_ambientes
- First observedlistar_downloads_pjedocs
- First observedlistar_falhas_navegacao
- First observedlistar_jurisdicoes_acervo
- First observedlistar_tribunais_suportados
- First observedpesquisar_classes_custas
- First observedpreparar_acesso_pesquisa_geral
- First observedpreparar_chat_cap1g
- First observedpreparar_download_pjedocs
- First observedsimular_custas
- First observedsolicitar_download_pjedocs
- First observedstatus_navegacao_adaptativa
- First observedstatus_servidor
- First observedtestar_login
- First observedvalidar_adaptadores_offline
- First observedverificar_chat_cap1g
- First observedverificar_login_certificado

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

C2.9/5.0

Scored 2026-09-18 01:56 across 35 tools

Disambiguation4/5

Tool purposes are mostly clear because descriptions specify source (SICAJUD, DataJud, PJe, PJeDocs) and workflow phase (prepare, solicit, open, encerrar). A few pairs require close reading—listar_ambientes versus listar_tribunais_suportados, consultar_processo_publico versus consultar_metadados_processo, and the staged PJeDocs tools—so selection is not entirely automatic.

Naming Consistency4/5

The set overwhelmingly follows the Portuguese verb_noun imperative pattern, such as listar, consultar, baixar, and encerrar, and groups tools by subdomain. The two status_* names break the imperative pattern, and a few compound names are overloaded, but there is no mixed casing or random verbing.

Tool Count2/5

35 tools is a heavy surface for an MCP server, even for the broad PJe domain. The many prepare/request/list/download staging tools inflate the count and force an agent to navigate a large state machine when selecting the right operation.

Completeness4/5

Core workflows—environment diagnostics, public consultation, autos access, document extraction/download, PJeDocs, and CAP1G chat—are represented without obvious dead ends. Minor gaps include no explicit session logout/cleanup and no standalone document enumeration tool beyond the autos inspection and reading tools.

Maintenance

ActivityMaintained

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Related MCP Connectors

OneDroid SynapseOAuth
ai.onedroid
Governed MCP gateway: one endpoint for your tools, with credential custody and audit log.
Security Observability
1
a2aidentitytoll-mcp
com.clauxel.a2aidentitytoll
Remote MCP for A2A caller identity, scope policy, verdict receipts, and audit history.
Security Autonomous Agents
2
Sensact
io.github.sensact-agents
An authenticated remote MCP server for user-owned devices and one-shot capability invocation.
OS Automation App Automation
2
skybridgepackager-mcp
com.clauxel.skybridgepackager
A paid remote MCP for Skybridge, built to return verdicts, receipts, usage logs, and audit-ready JSO
Security Observability
2

Related MCP Servers

AuroraDocs MCP Server
Cloud Platforms Project Management Documentation Access
henrikogaard
A
license
Not graded
quality
A
maintenance
Enables local MCP clients to interact with an AuroraCloud workspace, supporting object listing, content reading, search, and task management through authenticated API calls.
Updated a month ago (2026-09-04 22:52 UTC)
17 npm
Apache 2.0
cloud-to-local
File Systems Command Line OS Automation
plhys
A
license
Not graded
quality
A
maintenance
Enables cloud agents to securely operate local machine resources (files, commands, screenshots) via standard MCP protocol.
Updated 2 months ago (2026-07-20 08:37 UTC)
MIT
mcp-gateway
Agent Orchestration Developer Tools
thargy
A
license
Not graded
quality
B
maintenance
Enables multiple MCP clients to securely access various third-party MCP backends through a single HTTP gateway, with modern MCP handshake compatibility and session lifecycle management.
Updated a month ago (2026-08-24 17:50 UTC)
35 npm
MIT
mcp-gateway
Agent Orchestration Security
R0Wi
A
license
Not graded
quality
A
maintenance
Enables clients to access multiple backend MCP servers through a single endpoint, with OAuth 2.1 authorization, namespaced tools, and secure credential management.
Updated 7 days ago (2026-09-24 09:20 UTC)
1
MIT

MCP PJe Pernambuco — versão 0.7

Ferramentas desta versão

Estágio por tribunal

Aprendizagem e correção sem banco de dados

Metadados públicos pelo DataJud/CNJ

Leitura autenticada segura

Pesquisa Geral autenticada por NPU exato

Íntegra assíncrona pelo PJeDocs

Atendimento pelo chat da CAP1G

Fora do escopo seguro

Requisitos e instalação

Codex

Claude Code

Login individual e MFA

Certificado digital

Exemplos de pedidos ao MCP

Configuração

Testes

Distribuição pública

Referências oficiais

Available Tools

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers