Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@MCP TCE-PR pesquise as licitações do município de Curitiba"
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.
Consulte informações públicas do Tribunal de Contas do Estado do Paraná na conversa com seu assistente de inteligência artificial.
Uma iniciativa da Booknando Livros. Projeto independente, sem vínculo oficial com o TCE-PR.
Este guia foi escrito para quem trabalha em uma prefeitura, câmara municipal ou outro órgão e quer instalar a ferramenta sem precisar saber programar. O passo a passo usa Windows e Claude Desktop.
O programa consulta dados públicos. Não envia prestações de contas, não protocola documentos e não altera informações no TCE-PR. Confira os resultados nas fontes oficiais antes de usá-los em decisões ou documentos de trabalho.
Para a equipe de TI: guia técnico, ferramentas e configurações
Related MCP server: mcp-contrataciones-py
Sua necessidade | Como o MCP pode ajudar |
Consultar obras do município | Localizar registros nas bases públicas de obras |
Pesquisar licitações | Consultar o Mural tradicional e a nova fonte de licitações |
Encontrar decisões do tribunal | Pesquisar acórdãos publicados no ViaJuris |
Consultar um processo | Acessar a consulta pública pelo número do protocolo |
Ler informações do portal | Abrir páginas, seguir links e ler documentos compatíveis |
Explorar dados municipais | Consultar as bases do Portal de Informações para Todos, o PIT |
MCP é a conexão entre o assistente e as fontes de informação. Você escreve uma pergunta; o assistente usa este programa para consultar o TCE-PR e recebe os resultados. Depois, pode organizar os dados e explicar o que encontrou.
O programa roda no seu computador. Não é necessário criar conta no TCE-PR para as fontes públicas atendidas, nem baixar previamente todas as bases. As consultas têm limites e não abrangem automaticamente todos os registros de cada sistema.
Um computador com Windows 10 ou 11 e acesso à internet.
O Claude Desktop instalado e uma conta que permita usar as ferramentas locais do aplicativo. O guia não se aplica à versão aberta apenas no navegador.
Permissão para instalar programas. Se o equipamento for gerenciado pelo município, encaminhe este guia à equipe de TI quando necessário.
O código deste MCP é gratuito sob licença MIT. O aplicativo de IA pode ter seus próprios planos, custos e limites. Use um serviço autorizado pelo seu órgão; consultas e resultados enviados ao assistente seguem as regras de privacidade desse serviço.
Você não precisa instalar Git, ter conta no GitHub ou saber Python. O roteiro abaixo instala os componentes necessários.
Faça uma etapa por vez. Nos blocos de comandos, copie somente o conteúdo do bloco, cole no PowerShell e pressione Enter. Espere o comando terminar antes de continuar.
Clique aqui para baixar o projeto em ZIP. Também pode usar o botão verde Code → Download ZIP nesta página.
Abra a pasta Downloads do Windows.
Clique com o botão direito no ZIP baixado e escolha Extrair Tudo.
Abra a pasta extraída até encontrar README.md, pyproject.toml e uv.lock. Essa é a pasta do projeto. Às vezes, existe uma pasta dentro de outra com o mesmo nome.
Mova essa pasta para um local onde pretende mantê-la, por exemplo Documentos. Pode renomeá-la para mcp-tce-pr.
Não execute dentro do ZIP e não mova a pasta depois da instalação. A conexão usará o endereço dessa pasta. Se mudar o local, repita a instalação e a configuração no novo endereço.
Vamos instalar o uv, um programa que prepara o ambiente necessário para o MCP.
Abra o menu Iniciar, digite PowerShell e abra o aplicativo.
Execute:
winget install --id=astral-sh.uv -eSiga as mensagens do instalador. Se já estiver instalado, prossiga.
Feche o PowerShell e abra-o novamente.
Confira:
uv --versionResultado esperado: uma linha começando com uv, seguida de um número de versão. Se aparecer “não reconhecido”, consulte Se algo não funcionar.
Esse método segue a documentação oficial do uv. Se faltar winget ou o computador bloquear instalações, peça à TI para instalar o uv por um dos métodos oficiais.
No Explorador de Arquivos, abra a pasta que contém pyproject.toml.
Clique na barra de endereço no alto da janela, digite powershell e pressione Enter.
Na janela que abrir, execute:
Test-Path .\pyproject.tomlResultado esperado: True. Se aparecer False, você está na pasta errada. Localize a pasta que contém o arquivo antes de continuar.
No PowerShell aberto na pasta do projeto, execute os comandos um de cada vez:
uv python install 3.12uv sync --locked --python 3.12 --extra navegadoruv run --extra navegador playwright install chromiumO primeiro instala o Python necessário. O segundo instala o MCP e suas dependências. O terceiro instala o navegador usado pelo programa para ler páginas que carregam informações dinamicamente. O download pode levar alguns minutos.
Para conferir, execute:
uv run --extra navegador python -c "from mcp_tce_pr.server import mcp; print('Instalação concluída')"Resultado esperado: Instalação concluída, sem erro. Essa conferência verifica o carregamento do programa; a consulta ao portal será testada no passo 7.
Ainda no mesmo PowerShell, copie e execute todo este bloco:
$pythonMcp = (Resolve-Path .\.venv\Scripts\python.exe).Path
@{
mcpServers = @{
'tce-pr' = @{
command = $pythonMcp
args = @('-m', 'mcp_tce_pr.server')
}
}
} | ConvertTo-Json -Depth 5O comando mostra um texto de configuração com o endereço correto da instalação. Ele não altera as configurações do Claude.
Copie o resultado inteiro, da primeira { até a última }. Ele terá uma estrutura parecida com esta, mas com seu usuário e a pasta escolhida:
{
"mcpServers": {
"tce-pr": {
"command": "C:\\Users\\SEU_USUARIO\\Documents\\mcp-tce-pr\\.venv\\Scripts\\python.exe",
"args": ["-m", "mcp_tce_pr.server"]
}
}
}Use o resultado gerado no seu PowerShell, não o caminho fictício acima. As barras duplas no endereço são normais nesse formato.
Abra o Claude Desktop.
Entre em Settings → Developer → Edit Config — em português, procure Configurações → Desenvolvedor → Editar configuração.
Abra claude_desktop_config.json em um editor de texto, como o Bloco de Notas. No Windows, ele costuma ficar em %APPDATA%\Claude.
Faça uma cópia do arquivo como backup e encerre completamente o Claude, inclusive pelo ícone ao lado do relógio, se houver.
Se o arquivo estiver vazio ou contiver apenas {}, cole todo o resultado do passo 5.
Salve sem mudar o nome do arquivo ou acrescentar .txt.
Abra o Claude Desktop novamente.
Já existem outras configurações ou conexões no arquivo? Preserve-as. Acrescente somente a entrada "tce-pr": { ... } dentro de "mcpServers", separada das outras por vírgula. Se ainda não existir mcpServers, acrescente esse bloco preservando as demais opções. Se já existir tce-pr, substitua apenas essa entrada. Peça ajuda à TI se não estiver seguro ao editar: uma vírgula fora do lugar pode impedir o carregamento.
Referência: guia oficial de conexão de servidores MCP locais. Os menus podem variar entre versões do aplicativo.
Abra uma nova conversa no Claude Desktop e escreva:
Use o MCP tce-pr para listar as áreas públicas disponíveis no portal do TCE-PR.
Se o aplicativo solicitar permissão para usar a ferramenta, confira o pedido e autorize a consulta.
Resultado esperado: o assistente utiliza listar_areas_portal_pr e apresenta as áreas cadastradas. Isso confirma a conexão com o MCP. Em seguida, teste o acesso à internet:
Use o MCP tce-pr para ler a página https://www.tce.pr.gov.br/ e mostrar o título e alguns links encontrados.
Essa segunda consulta deve retornar informações obtidas do portal. Uma resposta genérica, sem uso das ferramentas, não confirma que a instalação funcionou.
Depois de conectado, não precisa deixar o PowerShell aberto. O cliente inicia o MCP quando necessário. Mantenha a pasta do projeto no lugar.
Escreva o município, o período e o assunto desejado. Não precisa decorar os nomes das ferramentas.
O que deseja fazer | Exemplo de pedido |
Ver obras | “Consulte as obras de Curitiba. Mostre a fonte e a data de obtenção dos dados.” |
Pesquisar licitações | “Pesquise licitações de merenda escolar de Londrina na base de 2026. Confira as fontes tradicional e nova e explique a cobertura de cada uma.” |
Consultar processo | “Consulte o processo de protocolo [número/ano] no TCE-PR e mostre os links oficiais encontrados.” |
Encontrar decisões | “Pesquise acórdãos da base de 2026 sobre transporte escolar e apresente as ementas e os links disponíveis.” |
Conferir informações recentes | “Atualize a base de obras antes de consultar meu município e informe quando os dados foram obtidos.” |
Substitua nomes, anos e protocolo pelos que precisa pesquisar. Para consultas extensas, peça ao assistente que continue pelos próximos resultados e informe o que ainda não foi consultado.
Sim. O programa consulta as fontes oficiais durante o uso.
Páginas, documentos, PIT e novo Mural são buscados a cada consulta.
Algumas bases tradicionais usam uma cópia temporária para acelerar as respostas. Por padrão, ela vale por uma hora; depois disso, a próxima consulta busca a fonte novamente.
Você pode pedir uma atualização imediata das bases tradicionais, como no exemplo de obras acima.
Buscar novamente não significa que o TCE-PR publicou dados novos. A data da consulta é diferente da data de atualização dos registros. Se a fonte estiver desatualizada, o MCP não consegue corrigir isso. Sem consultas, o programa não fica monitorando nem baixando dados em segundo plano.
O que apareceu | O que fazer |
| Para uv, feche e reabra o PowerShell após a instalação. Se continuar, ou se faltar winget, encaminhe o passo 2 à TI. |
O teste da pasta retornou | Abra a pasta extraída que contém |
O download falhou ou a rede bloqueou | Guarde a mensagem e peça à TI para verificar conexão e permissões de download. Não desative as proteções do computador. |
A instalação do Chromium falhou | O programa também tenta Edge ou Chrome instalado. Peça à TI para verificar essa alternativa no guia técnico; a leitura de páginas dinâmicas ainda precisa ser testada. |
O MCP não aparece no Claude | Confira se está no aplicativo Desktop, se o arquivo foi salvo como |
Parou depois que a pasta foi movida | Repita os passos 3 a 6 no local definitivo. |
A consulta demorou ou retornou erro | A fonte pode estar indisponível ou a consulta ultrapassar um limite. Tente um município ou período menor e confira o portal oficial. |
Não foram encontrados registros | Confira município, ano e fonte. Isso não comprova que não existam registros em outros sistemas do tribunal. |
Para pedir ajuda, envie à TI o passo em que parou e a mensagem completa do erro. Também pode registrar um problema no projeto, sem incluir senhas ou informações pessoais e sigilosas.
As melhorias do programa são distribuídas pelo GitHub. Isso é diferente da atualização dos dados consultados.
Encerre o Claude Desktop completamente.
Baixe o ZIP novamente pelo link do passo 1.
Extraia em uma nova pasta, mantendo a instalação anterior até conferir a nova.
Repita os passos 3 a 5 na nova pasta.
No arquivo do Claude, substitua a entrada tce-pr pela nova configuração. Preserve as outras entradas.
Reabra o Claude e faça os testes do passo 7.
Não copie a pasta .venv da instalação antiga: ela será criada novamente. O programa não se atualiza sozinho.
Acesso às áreas públicas não garante leitura completa de todos os sistemas, tabelas ou documentos do portal.
Não acessa áreas com login, não resolve CAPTCHA e não realiza peticionamento ou envio de dados ao tribunal.
Pesquisas e documentos grandes podem precisar de várias consultas. PDFs digitalizados como imagem não têm reconhecimento de texto nesta versão.
Mudanças no portal, falhas de rede e arquivos incompatíveis podem interromper consultas.
As fontes do Mural tradicional e do novo Mural têm coberturas diferentes. Não some resultados sem conferir repetições e diferenças.
A IA pode interpretar informações incorretamente. Confira os links oficiais e os dados originais.
O guia técnico reúne configurações de cache, outros sistemas operacionais, transporte HTTP, catálogo das 19 ferramentas, limites de leitura, integração com MCP Brasil e comandos de teste.
O servidor foi validado localmente em Windows com Python 3.12. Os testes do protocolo MCP passaram; a configuração para Claude Desktop segue o guia oficial, mas não representa validação de todas as versões do aplicativo. Veja VALIDACAO.md.
A Booknando Livros oferece serviços e tecnologia para editoras, com atuação em livros digitais, EPUB, acessibilidade editorial e soluções para melhorar os processos de produção.
Este projeto disponibiliza uma conexão aberta entre assistentes de IA e informações públicas do TCE-PR. Conheça nossos serviços e entre em contato pelo site da Booknando.
Copyright © 2026 Booknando Livros e colaboradores. Código aberto sob a licença MIT: você pode usar, copiar, modificar e redistribuir o software, inclusive comercialmente, preservando os avisos da licença.
O uso é por conta e responsabilidade de cada usuário. O software é fornecido no estado em que se encontra, sem garantias de exatidão, completude, funcionamento contínuo ou adequação a uma finalidade específica, nos termos da MIT.
Cabe ao usuário revisar os resultados, conferir as fontes oficiais, seguir as regras do seu órgão e verificar quais informações compartilha com os serviços de IA. O MCP não substitui documentos oficiais, certidões, análise profissional ou os sistemas de prestação de contas.
Na máxima extensão permitida pela legislação aplicável, a Booknando, os autores, os titulares dos direitos e os colaboradores não se responsabilizam por danos ou prejuízos decorrentes do uso ou da impossibilidade de uso do software. A disponibilização do projeto não inclui compromisso de suporte, manutenção ou disponibilidade contínua; serviços contratados separadamente seguem seus próprios termos.
Este projeto não tem vínculo, certificação ou endosso do TCE-PR. A Booknando não controla as informações publicadas pelo tribunal e pelos jurisdicionados, seus prazos de atualização nem as respostas geradas pela IA. A licença MIT cobre o código deste projeto; dados, documentos, marcas e dependências de terceiros mantêm suas condições próprias.
Este aviso complementa a licença, sem alterar suas permissões nem afastar responsabilidades que não possam ser excluídas. Consulte o texto integral em LICENSE.
Busca novamente catálogo e CSV tradicional, ignorando o cache local.
Informe ano para licitacoes/acordaos. Retorna amostra, origem e horário real de obtenção. Não altera o TCE-PR nem garante que a fonte tenha dados novos. PIT, novo Mural, páginas e documentos já são buscados a cada consulta.
| Name | Required | Description | Default |
|---|---|---|---|
| ano | No | ||
| base | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, idempotent, non-destructive behavior, and the description adds meaningful context: it ignores local cache, returns a sample with origin and real retrieval time, does not alter TCE-PR, and does not guarantee new data. This clearly sets expectations beyond what the annotations alone provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short, front-loaded with the core behavior, and uses each sentence for distinct useful information: cache bypass, parameter hint, return contents, safety caveat, and scope exclusion. There is no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists and the annotation set already covers safety and read-only semantics, the description provides adequate context: cache behavior, return sample/origin/time, non-guarantee of freshness, and what is excluded. The main missing piece is a direct comparison with sibling consultar_* tools to fully guide routing, but this is not critical for a simple refresh operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 helps by saying that "ano" should be provided for licitacoes/acordaos, which clarifies the main optional parameter. However, it does not explain what happens when "ano" is null or for other bases, and it does not add meaningful semantics for the "base" choices beyond the schema enum.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action: "Busca novamente catálogo e CSV tradicional, ignorando o cache local." This identifies the resource, the operation, and a distinguishing behavior. However, the name "atualizar_dados_pr" could imply mutation, and "catálogo e CSV tradicional" remain somewhat domain-specific without explaining what those terms mean.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives parameter-level guidance with "Informe ano para licitacoes/acordaos" and implies that PIT, Mural, pages, and documents do not need this tool because they are already fetched each query. It does not explicitly name sibling alternatives or state the exact condition for choosing this tool over them, so usage guidance is present but mostly implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Busca texto navegando até 30 páginas de uma área. Expõe páginas visitadas e falhas; não é busca exaustiva.
| Name | Required | Description | Default |
|---|---|---|---|
| area | No | inicio | |
| texto | Yes | ||
| max_paginas | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
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 behavioral context: it navigates up to 30 pages, exposes visited pages and failures, and is not exhaustive. This goes beyond annotations by specifying output behavior and bounds, though it does not detail error handling or exact return structure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no redundancy. The first states the core action and scope, the second adds output behavior and a limitation. Information is front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 3-parameter tool with 0% schema coverage and an output schema, the description covers the main action and key limitation (30 pages) but lacks parameter explanations and explicit output details (though output schema exists). The 'não é busca exaustiva' note is useful but does not compensate for missing parameter semantics.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must compensate for parameter meanings. It references 'área' and 'até 30 páginas' (implying max_paginas), but does not explicitly explain 'texto', 'area' valid values, or the relationship between max_paginas and the 30-page cap. The agent must infer parameter semantics, which is insufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb and resource: 'Busca texto navegando até 30 páginas de uma área' – search for text across pages of an area. It distinguishes from siblings like 'consultar_base_pr' by emphasizing navigation through pages rather than direct queries. The note 'não é busca exaustiva' further refines scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use it (searching text across pages) and provides a limitation ('não é busca exaustiva'), but it does not explicitly name alternatives or provide exclusion criteria. No contrast with sibling tools like 'ler_pagina_portal_pr' or 'consultar_licitacoes_pr' is given, leaving usage decisions to the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Pesquisa acórdãos do ViaJuris; retorna ementas e links PDF quando publicados no CSV.
| Name | Required | Description | Default |
|---|---|---|---|
| ano | Yes | ||
| texto | No | ||
| limite | No | ||
| relator | No | ||
| entidade | No | ||
| deslocamento | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds that results include ementas and PDF links, but it does not clarify the CSV condition, pagination behavior, or the required 'ano' context. It adds some value beyond annotations but is not richly transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single economical sentence that front-loads the core purpose. It is reasonably concise, though the final clause is syntactically awkward and could have been split into clear, structured statements about the CSV output.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 shape and safety, but the tool still has six input parameters with zero schema coverage and no parameter explanations in the description. An agent is left without critical information about required filters, pagination, and search semantics, so the definition is not complete enough for confident invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 six parameters: ano, texto, limite, relator, entidade, or deslocamento. With no parameter-level guidance anywhere, an agent cannot reason about how to build a correct search using the available inputs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action and resource: 'Pesquisa acórdãos do ViaJuris'. It also adds a useful output detail by mentioning ementas and PDF links in a CSV context, which helps distinguish it from sibling portal tools. It loses the top score because the clause 'quando publicados no CSV' is slightly ambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The intended use is reasonably clear: use this tool to search ViaJuris acórdãos. However, the description provides no explicit guidance about when not to use it or how it compares with other tools like consultar_base_pr or consultar_dados_pit_pr. The sibling names help, but the description itself does not actively route the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Consulta CSV oficial. Filtros são substrings combinadas por E, sem distinguir acentos/caixa.
Use descrever_base_pr para nomes exatos das colunas. texto procura uma expressão em qualquer coluna. ano seleciona o arquivo publicado, não filtra datas dos registros. limite: 1 a 100. deslocamento pagina os resultados; sem ordenação adicional. Inclui fonte, data de obtenção, total e próximo deslocamento. Cache padrão de uma hora.
| Name | Required | Description | Default |
|---|---|---|---|
| ano | No | ||
| base | Yes | ||
| texto | No | ||
| limite | No | ||
| filtros | No | ||
| deslocamento | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds substantial behavior beyond the readOnly/idempotent/openWorld annotations: clarifies that 'ano seleciona o arquivo publicado, não filtra datas dos registros' (a genuine semantic trap), specifies limite range 1–100, states deslocamento pages results with no additional ordering, discloses the response envelope (fonte, data de obtenção, total, próximo deslocamento), and notes one-hour default caching. 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Approximately 80 words covering purpose, filter semantics, sibling routing, five parameter behaviors, response contents, and caching. The core purpose is front-loaded, and every sentence earns its place — density is justified by the 0% schema coverage and six parameters.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Complete for a six-parameter read tool with zero schema descriptions: all parameters explained, edge cases clarified, cache disclosed, response envelope described even though an output schema exists, and a sibling reference for advanced needs. Nothing an agent requires to call it correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With schema_description_coverage at 0%, the description carries the full burden and fully compensates: filtros (substrings, AND, case/accent-insensitive), texto (searches any column), ano (file selection, not record filtering), limite (bounds), deslocamento (pagination behavior). Only 'base' is left to its self-documenting enum, which is acceptable.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Starts with 'Consulta CSV oficial' — a specific verb (consultar) plus resource (official CSV dataset). The description goes on to define exact query semantics (substring filters, AND combination, accent/case insensitivity) that distinguish it from domain-specific siblings like consultar_licitacoes_pr and consultar_obras_pr. The 'base' enum further scopes which datasets it covers.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly routes the agent to sibling descrever_base_pr when exact column names are needed ('Use descrever_base_pr para nomes exatos das colunas'). The generic-CSV positioning provides clear context relative to the specialized consultar_*_pr tools, though it never explicitly states when not to use those alternatives, so exclusion guidance is missing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Consulta um CSV/TXT diretamente dentro de ZIP por faixas HTTP.
Primeiro liste os membros e consulte sem filtros para descobrir campos. Filtros são substrings sem acentos, combinados por E. cursor é o número de registros já examinados. Encoding pode ser utf-8-sig, cp1252 ou latin-1. Não extrai arquivos no disco. Para o PIT consolidado, que contém ZIPs/XMLs aninhados, use consultar_dados_pit_pr.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | ||
| cursor | No | ||
| limite | No | ||
| arquivo | Yes | ||
| filtros | No | ||
| encoding | No | utf-8-sig |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, openWorld, idempotent, and non-destructive. The description adds substantial behavioral detail: it reads by HTTP ranges, does not extract files to disk, filters are accent-insensitive substrings combined with AND, and cursor tracks examined records. It also enumerates valid encodings. This goes well beyond the annotations without contradicting them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded: the core operation appears first, followed by actionable usage details and a routing note. Every sentence contributes a distinct fact, with no repetition or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return-value documentation is unnecessary. The description covers preconditions, pagination semantics, filtering behavior, encoding choices, and the correct sibling for nested PIT data, making it sufficient for an agent to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 explains cursor, filtros, and encoding meaningfully. url, arquivo, and limite are somewhat inferable from the tool name and defaults, but limite is not explicitly described, so it falls just short of complete parameter coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: consult a CSV/TXT inside a ZIP via HTTP ranges. It also distinguishes itself from consultar_dados_pit_pr by noting that the sibling handles nested ZIPs/XMLs, so an agent can tell exactly what this tool is for.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit preparation steps: list the members first and query without filters to discover fields. It also provides a clear when-not-to-use condition by directing the agent to consultar_dados_pit_pr for the consolidated PIT case, leaving no ambiguity about routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Consulta receitas, despesas, contratos, convênios, licitações, obras, diárias e combustível do PIT.
Descubra codigo_municipio nos nomes de listar_arquivos_zip_pr (ex. 410010). Temas: Combustivel, Contrato, Convenio, Despesa, Diarias, Licitacao, Obra, Receita, Relacionamentos. Primeiro omita arquivo para listar os XMLs internos; depois forneça seu nome exato. Filtros: nomes de atributos XML, substrings sem acentos combinadas por E. Não baixa o ZIP anual inteiro. Pagina registros encontrados; retorna total e procedência.
| Name | Required | Description | Default |
|---|---|---|---|
| ano | Yes | ||
| tema | Yes | ||
| limite | No | ||
| arquivo | No | ||
| filtros | No | ||
| deslocamento | No | ||
| codigo_municipio | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover readOnly, idempotent, and non-destructive behavior, so the description correctly avoids repeating them. It adds valuable behavioral context: the tool does not download the entire annual ZIP, it paginates records, returns total and provenance, and requires the two-step arquivo workflow.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with the main purpose, then proceeds to essential usage details. Each sentence adds actionable information, though bullet points or explicit parameter labels could improve scannability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 7-parameter tool with no schema parameter descriptions, the description covers the discovery workflow, theme list, filter semantics, and pagination/provenance behavior. Since an output schema exists, return-value details are not needed; minor ambiguities like exact limite constraints and the meaning of 'Relacionamentos' remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the text compensates by documenting the tema enum, how to obtain codigo_municipio, the arquivo null-then-exact-name workflow, and filtros syntax. Limite and deslocamento are only implied by 'Pagina registros encontrados', so not every parameter is explicitly mapped.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource ('Consulta ... do PIT') and enumerates the covered data types: receitas, despesas, contratos, convênios, licitações, obras, diárias e combustível. It makes the tool's scope clear, but it does not explicitly contrast it with overlapping siblings such as consultar_licitacoes_pr or consultar_obras_pr.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives concrete procedural guidance: find codigo_municipio in listar_arquivos_zip_pr names, omit arquivo first to list XMLs, then supply the exact filename, and use XML-attribute filters combined by AND. However, it never states when to prefer this generic tool over specialized siblings or provides explicit exclusion conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Consulta formulários públicos cadastrados de processos/sanções/inadimplentes.
Primeiro leia a página para obter nomes reais dos campos, valores de opções e botão de pesquisa. Preserva cookies e campos ocultos ASP.NET; não aceita campos ocultos do agente. Não serve para login, requerimentos, peticionamento ou envio de dados de fiscalizados.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | ||
| campos | Yes | ||
| indice | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, openWorld, idempotent, and non-destructive hints. The description adds meaningful behavioral detail beyond those annotations: it preserves cookies and hidden ASP.NET fields, rejects agent-supplied hidden fields, and requires a preliminary page read. This is valuable but does not fully characterize all behaviors such as error handling or pagination.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with the core purpose. Each subsequent sentence adds operational or exclusionary value without redundancy or filler. It covers purpose, workflow, technical constraints, and non-goals in just three sentences.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity—ASP.NET forms, cookies, hidden fields—and the availability of an output schema, the description provides essential workflow guidance and exclusions. The main gap is the undocumented 'indice' parameter, which could be important for selecting among multiple results or form instances. Still, the description is largely sufficient for an agent to call the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no parameter descriptions and a 0% schema coverage. The description compensates partially for the 'campos' parameter by explaining that real field names and option values must come from reading the page first, and that hidden fields from the agent are not accepted. 'url' is implicitly clear from the page-reading instruction, but 'indice' is not explained at all.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as consulting registered public forms related to processes/sanctions/defaulters, with a specific verb and resource. It does not explicitly name sibling alternatives, but the scope is specific enough to distinguish it from the many other portal tools in the sibling list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear operational context: read the page first to discover real field names and option values, and explicitly states when not to use the tool (login, requests, petitions, data submission). It stops short of explicitly naming which sibling tools should be used in those excluded cases, so it earns a 4 rather than a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Pesquisa o Mural de Licitações por ano da base, município e trecho do objeto.
| Name | Required | Description | Default |
|---|---|---|---|
| ano | Yes | ||
| limite | No | ||
| objeto | No | ||
| municipio | No | ||
| deslocamento | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds only the filtering scope and does not disclose pagination behavior, result limits, or data freshness, which is a moderate but not severe gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no redundant words. It efficiently states the action, resource, and primary filter dimensions in a compact form.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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, and the required field ano is identifiable. However, pagination parameters are not explained and there is no guidance distinguishing this tool from the novo_mural siblings, so the description is adequate but not fully self-sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description needed to clarify all five parameters but only maps three of them: ano (base year), municipio, and trecho do objeto for objeto. The pagination-related parameters limite and deslocamento are left completely unexplained, leaving an important gap for an agent trying to control result size and offset.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with the specific verb 'Pesquisa' and names the exact resource 'Mural de Licitações', followed by the meaningful filter dimensions: base year, municipality, and object excerpt. This distinguishes it from sibling tools that target different resources such as obras, acórdãos, or the new mural.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context: use this tool to query the Licitações Mural by base year, municipality, and object text. It does not explicitly mention when to prefer it over consultar_novo_mural_pr or other sibling tools, but the intended use is clear even without an explicit exclusion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Consulta CSV oficial do NOVO Mural, editais a partir de 01/05/2026.
Descobre o ZIP na seção Dados abertos do Power BI e lê os registros por HTTP Range. tipo='itens' consulta mapa de itens; tipo='licitacoes' consulta os certames. Primeiro consulte sem filtros para descobrir os campos. Filtros são substrings sem acentos combinadas por E. cursor é o número de registros já examinados, não página. Requer extra navegador para descobrir a fonte. Não mescla o CSV tradicional.
| Name | Required | Description | Default |
|---|---|---|---|
| ano | Yes | ||
| tipo | No | licitacoes | |
| cursor | No | ||
| limite | No | ||
| filtros | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
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 substantial behavior beyond that: it reads records via HTTP Range, discovers a ZIP from Power BI's open data section, requires an extra browser to find the source, clarifies cursor semantics ('número de registros já examinados, não página'), and explains filter normalization. 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but every sentence earns its place: scope, source mechanism, type variance, filter semantics, cursor meaning, external dependency, and an explicit exclusion. It is front-loaded with the core purpose and avoids redundant restatement of the tool name or schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex tool with an output schema already present, the description covers the key operational details: where the data comes from, how it is read, what the two modes mean, how filtering and cursor work, and the prerequisite to discover the source. The output schema relieves the description from explaining return values, so nothing critical is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 meaningfully explains tipo, filtros, and cursor, and gives a discovery strategy for the fields. However, 'ano' and 'limite' are not explicitly explained, and the filter object's expected keys are left to be discovered, so it is strong but not fully complete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Consulta CSV oficial do NOVO Mural, editais a partir de 01/05/2026.' It clearly distinguishes the two modes via tipo='itens' and tipo='licitacoes', and adds an explicit contrast with 'Não mescla o CSV tradicional,' helping an agent separate it from sibling tools without opening schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives practical usage guidance: 'Primeiro consulte sem filtros para descobrir os campos' and explains how filters behave ('substrings sem acentos combinadas por E'). It also warns about the need for an extra browser and what the tool does not do. It does not explicitly name alternative sibling tools, but provides enough context to route usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Pesquisa obras municipais; confira a última modificação HTTP para avaliar atualidade.
| Name | Required | Description | Default |
|---|---|---|---|
| limite | No | ||
| objeto | No | ||
| municipio | No | ||
| deslocamento | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=true, and destructiveHint=false, so the safety profile is covered. The description adds a small operational hint about checking the last HTTP modification to assess currency, which is useful context, but it does not disclose pagination, filtering behavior, or other response dynamics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short with no filler; the main purpose is front-loaded and the freshness-check instruction is compact. However, the phrase 'confira a última modificação HTTP' is somewhat cryptic and could have been clearer, so it does not earn a perfect score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Although an output schema exists and annotations cover safety, the description leaves out usage guidance and parameter semantics entirely. An agent would need to infer the meaning of 'objeto', how pagination works with limite/deslocamento, and whether municipio is required for meaningful results, so the description is not complete enough for reliable invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 information about limite, objeto, municipio, or deslocamento. The parameter names and defaults are arguably self-explanatory, but the description itself adds zero meaning beyond the schema, which fails to compensate for the complete lack of parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action and resource: 'Pesquisa obras municipais' (searches municipal works). This is clear enough to distinguish it from siblings like consultar_licitacoes_pr and consultar_acordaos_pr, though it does not explicitly name any alternative or contrast its scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 sibling tools, and it does not mention any alternative. The only usage hint is to check HTTP modification data for freshness, but that is about evaluating output recency, not about selecting this tool over others.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Consulta pública por número de protocolo, ex. 196886/26. Retorna a página de resposta e links.
| Name | Required | Description | Default |
|---|---|---|---|
| numero | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnly, idempotent, and non-destructive hints. The description adds useful behavioral detail beyond the annotations by stating that the tool returns the response page and links, and it frames the operation as a public query. 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The entire definition is one dense sentence: purpose, example, and return behavior. It is front-loaded and contains no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter read-only tool with annotations and an output schema, the description covers purpose, trigger, parameter semantics, and return behavior. The only notable absence is explicit guidance on choosing this sibling over the other consultar_* tools, which is a minor completeness gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the sole required parameter `numero` has no schema documentation. The description compensates by mapping `numero` to a protocol number and providing the example format 196886/26, so an agent can populate the parameter correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action — public consultation of a process by protocol number — and gives a concrete example (196886/26). This criterion clearly distinguishes it from sibling consultation tools like consultar_licitacoes_pr and consultar_acordaos_pr.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The trigger condition (having a protocol number) is implied by the description, and an example makes it concrete. However, the description does not explicitly mention alternatives or when not to use this tool, which matters given the large sibling list of similar consultar_* tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retorna nomes originais dos campos e um registro de exemplo para montar filtros.
| Name | Required | Description | Default |
|---|---|---|---|
| ano | No | ||
| base | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds that it returns field names and an example record, which is the core behavior, but it does not disclose potential limitations (e.g., whether the example record is representative, whether field names might be incomplete, or how the output is structured). Since annotations already handle the read-only nature, the description contributes some but not rich behavioral context, so a 3 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with zero waste. It front-loads the key information (returns field names and example record) and appends the purpose (to build filters). Every word earns its place, and it is appropriately concise for a simple read-only metadata tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has only 2 parameters, one required, and an output schema exists. The description adequately states what the tool returns (field names and example record) and why it is used (to build filters). It does not explain error handling or edge cases, but for a read-only tool with clear annotations and an output schema, this is sufficient. The main missing piece is parameter clarification, which is already penalized in that dimension. Overall, the description is complete enough for an agent to call it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 by explaining the parameters. It does not. The description does not clarify what 'base' refers to (though the enum values in the schema are self-explanatory) or what the optional 'ano' (year) parameter does. It only hints at the overall purpose (building filters) but leaves parameter meaning to the agent's inference from the schema. This is insufficient given the low coverage, so a 2 is justified.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb ('Retorna' = returns) and a distinct resource: original field names and an example record for building filters. It differentiates from sibling query tools like consultar_base_pr (which likely returns data) and listar_bases_pr (which lists bases). The phrase 'para montar filtros' adds contextual purpose, making it unambiguous what this tool is for.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by stating the output is for building filters, but it does not explicitly state when to use this tool over alternatives or provide any exclusions. It mentions no sibling tools and gives no when-to-use/when-not-to-use guidance, relying on the agent to infer that it is for obtaining schema metadata before querying. This is implied usage, not explicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lê PDF, DOCX, XLSX, CSV, JSON, XML e texto de URLs públicas do TCE-PR.
PDF: pagina inicial e até 5 paginas. XLSX: pagina seleciona blocos de 100 linhas. Texto extraído é paginado por deslocamento/limite; download máximo 20 MiB. Não faz OCR nem valida assinaturas P7S. Resposta inclui fonte e limites.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | ||
| limite | No | ||
| pagina | No | ||
| paginas | No | ||
| deslocamento | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes well beyond the annotations by disclosing concrete behavioral constraints: PDF page limits, XLSX 100-row block selection, offset/limit pagination, a 20 MiB download cap, no OCR, and no P7S signature validation. This gives an agent realistic expectations about limitations and failure modes. It is consistent with the readOnlyHint, idempotentHint, and openWorldHint annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded: the first sentence states the core purpose, and the following sentences pack limitations and pagination rules into short, scannable segments. There is no filler, no repetition of schema defaults, and every sentence adds distinct information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only tool with five parameters, annotations, and an output schema, the description covers the essential operational details: supported formats, public URL scope, per-format pagination, download size cap, non-capabilities, and response metadata. Minor ambiguities remain about how 'pagina' applies to non-PDF/XLSX formats and the exact semantics of 'limite', but these are not blocking. Overall, the definition is sufficient for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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, and it largely does: 'pagina' and 'paginas' are explained for PDFs, 'pagina' is mapped to XLSX 100-line blocks, and 'deslocamento'/'limite' are tied to extracted-text pagination. The main gaps are the exact unit of 'limite' and the precise URL format requirements, but the default values and surrounding context reduce ambiguity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with the specific verb 'Lê' (reads) and enumerates concrete resource types: PDF, DOCX, XLSX, CSV, JSON, XML, and text from public TCE-PR URLs. This makes the tool's function clear and distinguishes it from the many query-oriented sibling tools. It does not explicitly distinguish from 'ler_pagina_portal_pr', so differentiation is mostly implied rather than stated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies when to use the tool: to read and extract text from public documents and URLs. However, it never explicitly says when not to use it or names an alternative for structured queries, such as consultar_base_pr or consultar_processo_pr. Usage context is present but alternative routing is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lê o novo Mural de editais a partir de 01/05/2026, descobrindo o link no portal.
Navega às seções públicas do Power BI com navegador isolado. Retorna texto e links da seção, não todos os registros do modelo. 'Dados abertos' procura fontes exportáveis.
| Name | Required | Description | Default |
|---|---|---|---|
| secao | No | Visão geral | |
| deslocamento | No | ||
| inicio_links | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds meaningful behavioral detail beyond the annotations: it uses an isolated browser, discovers the link dynamically, and returns only section text/links, not all model records. This supplements the readOnly/idempotent hints without contradicting them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two compact sentences deliver the core purpose, scope, and key behavioral constraint with no filler. The most important information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the tool's purpose and output scope, and an output schema exists to describe return values. However, two input parameters (deslocamento and inicio_links) lack any semantic explanation, which is a meaningful gap for an agent trying to call the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 for the three parameters. It explains the 'Dados abertos' enum value and implies section semantics, but deslocamento and inicio_links are completely unexplained, leaving their meaning, range, and effect on pagination ambiguous.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb ('Lê'), a specific resource ('o novo Mural de editais a partir de 01/05/2026'), and a distinctive behavior ('descobrindo o link no portal'). It also differentiates itself from sibling tools by clarifying that it returns section text/links, not model records.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context: use this for reading the new public Power BI mural sections, discovering the link, and getting text/links rather than full records. It also clarifies the Dados abertos option's special purpose. It does not explicitly name alternatives or state when not to use it, but the intended usage is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lê qualquer página pública TCE-PR: texto, links, iframes e campos de formulários.
renderizar=True usa Chromium isolado para JavaScript/Power BI (extra navegador). Paginação textual por deslocamento; links por inicio_links, lotes de 100. Siga links de tipo iframe para sistemas incorporados. Documentos usam ler_documento_pr.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | ||
| limite | No | ||
| renderizar | No | ||
| deslocamento | No | ||
| inicio_links | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark this as read-only, idempotent, and open-world; the description adds valuable behavioral details beyond that: renderizar=True launches isolated Chromium, text pagination uses deslocamento, and links are fetched via inicio_links in batches of 100. It also instructs the agent to follow iframe links. No contradiction with the read-only annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three compact sentences, each with a distinct role: core capability, key parameter behavior, and routing guidance. The most important information is front-loaded, and no sentence is filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With annotations carrying the safety profile and an output schema available, the description covers the essential invocation decisions: when to render, how to paginate, how to handle iframes, and where to redirect document requests. The only small gap is the exact meaning of limite, which does not significantly impede correct selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema coverage, the description compensates by explaining renderizar ('Chromium isolado'), deslocamento (textual pagination), and inicio_links (link pagination, batches of 100). 'limite' remains undefined, though its default of 20000 suggests a text-length cap; url is obvious from the 'página' context. The coverage is substantial but incomplete for one parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States it reads any public TCE-PR page and enumerates content types: text, links, iframes, and form fields. It specifically routes document requests to ler_documento_pr, distinguishing itself from a key sibling. The verb 'Lê' and the resource scope are 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit routing: documents should use ler_documento_pr, and iframe-type links should be followed for embedded systems. The renderizar flag guidance ('usa Chromium isolado para JavaScript/Power BI') tells the agent when to enable the heavy rendering path. This is clear when-to-use context, even though it does not enumerate all sibling alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lista pontos de entrada de todo o portal; siga links para descobrir outras áreas e sistemas.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false. The description adds value by explicitly stating the tool returns entry points and instructs to follow links, which aligns with and elaborates on the openWorldHint. No contradictions; it provides useful behavioral context beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short clauses, front-loaded with the primary action ('Lista pontos de entrada de todo o portal') and a follow-up instruction. Every word is necessary; no fluff or repetition. Highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters, rich annotations, and an output schema exists (indicated by has output schema: true), the description is complete. It tells the agent what the tool does and how to use the results (follow links), covering all necessary aspects for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the input schema is empty with 100% coverage. The description does not need to explain parameters. Baseline for no parameters is 4, and the description adequately covers what the tool does without parameter details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action: 'Lista pontos de entrada de todo o portal' (Lists entry points of the entire portal). It identifies a distinct resource (entry points) and differentiates from siblings like listar_bases_pr (bases) by focusing on areas/systems. The additional instruction to follow links clarifies its role as a discovery tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for exploring the portal ('siga links para descobrir outras áreas e sistemas'), giving clear context. It does not explicitly name alternatives or state when not to use it, but the context is sufficient for an agent to infer it is the starting point for navigation, distinct from other list/consult tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lista membros de ZIP público remoto com HTTP Range, sem baixar o pacote inteiro.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | ||
| limite | No | ||
| deslocamento | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior. The description adds genuine value beyond these by disclosing the HTTP Range technique and the efficiency trait, which explains how the tool achieves its result. No contradiction with the annotations; a listing operation is consistent with readOnlyHint=true.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single well-formed sentence with zero filler. The core action and resource are front-loaded, and the behavioral note about HTTP Range earns its place by distinguishing the tool's approach.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (3 parameters, 1 required), the annotations richly cover the safety profile, and an output schema documents the return shape. The description conveys the purpose and the key efficiency mechanism, which is enough to call the tool correctly; the remaining gap is parameter detail, already penalized in that dimension.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 of explaining parameters. It implicitly maps to 'url' via 'ZIP público remoto', but it gives no meaning for 'limite' or 'deslocamento' beyond their self-evident names/defaults; 'deslocamento' in particular is an unusual term for offset that would benefit from clarification. The description only partially compensates for the absent schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Lista') and resource ('membros de ZIP público remoto'), and adds the distinctive mechanism ('com HTTP Range, sem baixar o pacote inteiro'). This differentiates it clearly from siblings like consultar_csv_zip_pr and the data-consulting tools, since it is specifically about enumerating ZIP archive members.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'sem baixar o pacote inteiro' gives clear context for when this tool is appropriate: efficient remote listing without full download. It does not explicitly name alternatives or exclusion conditions, so it falls just short of the highest tier, but an agent can infer the intended use case without ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Descobre arquivos e anos efetivamente publicados nos catálogos oficiais do TCE-PR.
| Name | Required | Description | Default |
|---|---|---|---|
| base | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover readOnly, openWorld, idempotent, and non-destructive traits. The description adds the nuance that it lists items 'actually published', implying it reflects real catalog state rather than a static list, which is valuable extra context beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one efficient sentence that front-loads the core purpose. No fluff or redundant phrasing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is a simple discovery operation with an output schema (not shown but implied). The description explicitly states it returns files and years, enough for the agent to understand the outcome. The optionality of the base parameter (null default) suggests listing all bases, but the description does not state this — a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides an enum for the single optional 'base' parameter, listing catalog codes like licitacoes and acordaos. The description does not explain these codes, but the enum itself is self-explanatory for domain users. With 0% schema description coverage, some clarification of the base semantics would help, but the enum reduces the need.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool discovers files and years actually published in TCE-PR official catalogs. This is a specific verb+resource that distinguishes it from sibling tools like listar_arquivos_zip_pr, which focuses on zip files. It is clear but not overly detailed.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. It does not mention conditions for selecting this over consultar_base_pr or listar_arquivos_zip_pr, leaving the agent to infer from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Descobre ZIPs anuais consolidados do PIT pelos links publicados; não baixa os pacotes.
| Name | Required | Description | Default |
|---|---|---|---|
| ano | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, and non-destructive behavior. The description adds useful context beyond those annotations by explicitly stating that the tool only discovers published links and does not download the ZIP packages themselves.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence communicates the tool's purpose and its non-downloading limitation with no filler. Every word contributes meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple listing tool with one optional parameter, rich annotations, and an output schema, the description is largely sufficient. The main shortfall is the undocumented parameter semantics, which slightly reduces completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 'ano' parameter, how it filters results, or what null/default behavior means. The phrase 'ZIPs anuais' only hints at the year concept but adds no real semantic guidance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Descobre...ZIPs anuais consolidados do PIT'), names the resource, and clarifies that it does not download packages. This makes the tool's purpose unmistakable and distinguishes it from download-oriented sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The negative clause 'não baixa os pacotes' implies this tool should not be used when actual downloads are needed, but it does not name a specific alternative or provide explicit when-to-use guidance. Usage context is mostly implied from the tool's discovery role.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.3.0atualizar_dados_prbuscar_no_portal_prconsultar_acordaos_prconsultar_base_prconsultar_csv_zip_prconsultar_dados_pit_prconsultar_formulario_prconsultar_licitacoes_prconsultar_novo_mural_prconsultar_obras_prconsultar_processo_prdescrever_base_prler_documento_prler_novo_mural_prler_pagina_portal_prlistar_areas_portal_prlistar_arquivos_zip_prlistar_bases_prlistar_downloads_pit_prScored across 19 tools
The nine 'consultar_' tools have detailed descriptions that do distinguish their data sources, but several overlap meaningfully: licitações data is reachable through consultar_base_pr, consultar_licitacoes_pr, consultar_dados_pit_pr, and consultar_novo_mural_pr, while acórdãos appear in both consultar_base_pr and consultar_acordaos_pr. An agent must read deeply to pick the right one, especially since consultar_base_pr, consultar_csv_zip_pr, consultar_dados_pit_pr, and consultar_novo_mural_pr share nearly identical query semantics.
All 19 tools follow a uniform [infinitive_verb]_[noun]_pr snake_case pattern in Portuguese, with verbs like listar, atualizar, descrever, consultar, and ler. The convention is applied without exception, making the naming scheme highly predictable.
At 19 tools, the set falls in the heavy range, though the broad TCE-PR domain (traditional CSVs, PIT, old and new murals, portal pages, documents, processes) partially justifies it. Several tools could be consolidated, such as ler_novo_mural_pr/consultar_novo_mural_pr or the four PIT/ZIP-related tools, suggesting some bloat.
For a read-only public data access server, coverage is strong: discovery, metadata, refresh, query, raw page/document access, and portal search are all represented across the major TCE-PR data sources. Minor gaps exist, such as no full-file download endpoint (only ranged reads) and no dedicated municipality directory tool, but these are workable around.
Public search of the Brazilian Federal Court of Accounts (TCU) case law: keyword search across rulin
Consolidated lookup of a company at the Federal Audit Court (TCU) from the CNPJ, gathering sanctions
Search Brazilian government tenders and public procurement (PNCP): find notices and auctions by keyw
Brazilian public procurement (PNCP): search, deadlines, tender markdown, alerts and watches.