Skip to main content
Glama

MCP Compras.gov.br

compras_uasg_buscar

Read-onlyIdempotent

Busca UASGs por trecho do nome (match parcial, ignora acento e caixa).

✅ Restaurada em 2026-08-05, com busca local. Duas correções:

  1. A rota exige statusUasg; sem ele devolvia 404 (mesma causa de compras_uasg_listar).

  2. O parâmetro nome não existe no contrato da rota e era ignorado pelo upstream — enviá-lo devolvia o universo inteiro (~22 mil UASGs) como se fossem resultados de busca. Corrigir só o item 1 teria trocado um erro visível (404) por um erro silencioso, que é pior: o analista receberia "TCU - SECRETARIA DE INFORMATICA" como 1º resultado de qualquer termo.

Como não há filtro textual upstream, a busca é feita localmente: a tool varre as páginas da rota (500 registros cada, ~8s no universo completo), filtra por termo e pagina o resultado filtrado. O varrido fica em cache por 24h, então só a primeira busca do dia paga o custo.

O payload informa _busca_local, _paginas_varridas e _universo_varrido — se a varredura for truncada, isso fica explícito em vez de virar silêncio.

Cache 24h.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
termoYesTrecho do nome da UASG (match literal, ignora acento e caixa). Ex.: 'aquaviarios', 'tribunal regional', 'exercito'. Siglas raramente funcionam — os nomes vêm por extenso no cadastro ('AGÊNCIA NACIONAL DE TRANSPORTES AQUAVIÁRIOS', não 'ANTAQ').
paginaNoPágina de resultados (1-based). Padrão 1.
tamanho_paginaNoQuantidade de registros por página. Padrão 50, máximo 500.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. First observed

TDQS

A4/5.0
Behavior5/5

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

Annotations already mark it read-only and idempotent, and the description adds substantial context: the route requires statusUasg, nome is ignored upstream, search is performed by scanning ~500-record pages (~8s full universe), results are cached for 24h, and the payload exposes _busca_local, _paginas_varridas, and _universo_varrido to make truncated scans 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.

Conciseness4/5

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

The definition is front-loaded with the purpose and then organized into a restoration note, numbered bugs, local-search explanation, and cache note. It is longer than strictly necessary because of the incident history, but the extra detail is mostly relevant to expectations about cost and result completeness.

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

Completeness5/5

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

Given the output schema and annotations, the description covers the key operational facts an agent needs: local filtering, pagination, first-search cost, 24h cache, and explicit truncation signaling. Nothing essential for invoking the tool correctly is missing.

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 100%, so the schema already documents termo, pagina, and tamanho_pagina with examples and caveats. The description does not add parameter-level meaning beyond mentioning the local-search mechanics; baseline 3 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 opening sentence states a specific operation: buscar UASGs by partial name, ignoring accents and case. It is clearly scoped to name-fragment search, but it does not explicitly contrast with sibling tools like compras_uasg_listar or compras_uasg_consultar, so differentiation is left mostly to the tool name and semantics.

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 (partial-name search) is implied by the first sentence and reinforced by the explanation that there is no upstream textual filter, so search is done locally with a 24h cache. However, there is no explicit when-to-use/when-not-to-use statement or named alternative such as compras_uasg_consultar for exact lookup.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A3.6/5.0
Disambiguation3/5

Most tools target distinct resources, and descriptions are extremely detailed, often explicitly warning about look-alikes. However, there is real overlap between composite and single-purpose tools (e.g., compras_checar_sancoes_fornecedor vs compras_perfil_fornecedor_completo vs compras_sancao_*), and similar-looking pairs like compras_contratos_consultar vs compras_contrato_comprasnet_consultar or compras_arp_listar vs compras_pncp_atas_listar require careful reading. With 100 tools, an agent will still face meaningful selection ambiguity.

Naming Consistency3/5

The dominant pattern is snake_case with a compras_ prefix, but the order and style vary: some are domain-first (compras_catmat_buscar), some are verb-first (compras_buscar_contratacoes_similares), and some are bare entity names with no verb (compras_sancao_ceis, compras_pncp_modalidades). The many listar/consultar/buscar variants are readable, but the convention is not predictable enough for a 100-tool surface.

Tool Count1/5

100 tools is an extreme count for any MCP server, regardless of domain breadth. Even if each tool has a legitimate upstream endpoint, this volume will heavily tax context windows and make reliable tool selection harder. Many tools could be consolidated into parameterized families (e.g., contratos, sancoes, pncp resources).

Completeness4/5

The server covers the Brazilian procurement domain remarkably well: catalogs, ARPs, 14.133 contracts, legacy regime, price research, suppliers, sanctions, PGC/PCA, PNCP, and Comprasnet contract subresources. Minor gaps remain, such as listing a supplier's full contract history without specifying an órgão, and some upstream limitations are only papered over with client-side workarounds.