Skip to main content
Glama

Gover MCP

by io.github.pedro381
OverviewDiscussionsAdmin

Localizar dados do Gover por termos de negócio

gover_explorar_estrutura
Read-onlyIdempotent

Lê a estrutura REAL do banco de dados (tabelas, colunas, tipos, chaves primárias e estrangeiras) a partir de termos de negócio extraídos da pergunta do usuário, ex.: ["solicitacao","status"] ou ["hospedagem","centro de custo"]. Use SEMPRE antes de gerar qualquer SQL para gover_executar_consulta; nunca adivinhe nome de tabela ou coluna. Datas, períodos e agregações não são termos: entram depois, no SQL. O resultado vem compactado e ordenado por relevância, com o nome em 3 partes pronto para o FROM, as FKs (->) para montar JOIN, os JOINs que o código do Gover faz entre essas tabelas (inclusive entre bancos, onde não há FK), as tabelas que o catálogo nunca lista (logs) com suas colunas, e as armadilhas conhecidas de cada tabela. Views e tabelas vazias não aparecem. Dois servidores independentes: "gover" (padrão: solicitações, viajantes, reservas, aprovações, custos, consolidação) e "dsg" (PNR, produtos reservados no fornecedor, hotel v2, usuários DSG, localidades e logs de comando/execução do DSG). Reduz o retorno com "banco" ou "tabela" quando já souber o alvo; use detalhe "completo" só para uma tabela já identificada. Uso interno: o conteúdo devolvido serve para montar o SQL e nunca deve ser mostrado nem descrito ao usuário. Categorias de negócio conhecidas: gerais (Cadastros e entidades transversais: cliente, funcionário, centro de custo, estrutura organizacional, solicitação e workflow de aprovação.); aereo (Pesquisa, reserva, emissão e políticas do produto aéreo, incluindo o PNR e os produtos reservados no DSG.); hotel (Pesquisa, reserva e políticas de hospedagem, incluindo a integração HRS e o hotel v2 do DSG.); veiculo (Pesquisa, reserva e políticas de locação de veículo.); integracao (Consolidação (SSIS), integrações com back office e fornecedores, filas e robôs.); logs (Logs de execução, comandos, auditoria e monitoramento — a maioria fora do catálogo do GetBanco.).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
bancoNoOpcional. Restringe a um banco, ex.: "gover_prod_corp" ou "dsg_tol_prod".
tabelaNoOpcional. Nome exato de uma tabela já identificada, para ver todas as colunas dela.
termosYesTermos de negócio da pergunta (1 a 5), ex.: ["solicitacao","status"]. Cada termo vira uma leitura filtrada do catálogo.
detalheNo"resumo" devolve PK, FKs, datas e colunas que casam com os termos; "completo" devolve todas as colunas (use com "tabela").resumo
servidorNoServidor a explorar: "gover" (padrão) ou "dsg" para PNR, reservas no fornecedor e logs do DSG. Bancos dsg_* só existem em "dsg".gover
descricaoNoOpcional. Filtro adicional pela descrição das tabelas/colunas; hoje pouquíssimas têm descrição, use só como reforço.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • changedInput schema / properties / banco / description
      Previous value: -"Opcional. Restringe a um banco, ex.: \"gover_prod_corp\"."New value: +"Opcional. Restringe a um banco, ex.: \"gover_prod_corp\" ou \"dsg_tol_prod\"."
    • addedInput schema / properties / servidor
      Added value: +{
+  "default": "gover",
+  "description": "Servidor a explorar: \"gover\" (padrão) ou \"dsg\" para PNR, reservas no fornecedor e logs do DSG. Bancos dsg_* só existem em \"dsg\".",
+  "enum": [
+    "gover",
+    "dsg"
+  ],
+  "type": "string"
+}
  2. Added

TDQS

A4.8/5.0
Behavior5/5

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

With readOnlyHint, idempotentHint, and destructiveHint already present, the description adds substantial behavioral context: results are compacted and relevance-ordered, include 3-part table names, FKs for JOINs, cross-server joins, log tables outside the catalog, known pitfalls, and excludes views and empty tables. It also warns that results are internal-only and must not be shown to the user.

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

Conciseness4/5

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

The description is long, but it is dense and front-loaded with the core purpose and mandatory usage rule. The later content about return content, servers, and business categories earns its place for a schema-exploration tool with no output schema, though it could be trimmed without losing key guidance.

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?

There is no output schema, so the description carries the full burden of explaining what the agent will receive. It covers return shape, ordering, JOIN hints, known pitfalls, exclusions (views/empty tables), server distinctions, and parameter-based scoping. This is unusually complete for a tool with six parameters and no output schema.

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

Parameters4/5

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

Schema description coverage is 100%, so the baseline is 3. The description adds value by explaining how parameters are meant to be used: each term becomes a filtered catalog read, banco/tabela narrow the return, detalhe "completo" is intended only for an already identified table, and the dsg server hosts PNR/DSG-specific data. This goes beyond the schema's field descriptions.

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

Purpose5/5

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

The description states a specific verb and resource: "Lê a estrutura REAL do banco de dados (tabelas, colunas, tipos, chaves primárias e estrangeiras)" from business terms. It also differentiates itself from the sibling workflow by explicitly tying it to gover_executar_consulta and warning against guessing table/column names.

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

Usage Guidelines5/5

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

The description gives explicit usage direction: "Use SEMPRE antes de gerar qualquer SQL para gover_executar_consulta; nunca adivinhe nome de tabela ou coluna." It also provides when-not-to-use guidance by stating that dates, periods, and aggregations are not terms, and gives scoping strategies with banco, tabela, and servidor.

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

All Gover MCP toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources