fluig-mcp

fluig_rm_db_query

Execute read-only SELECT queries directly against RM/Corpore database tables without WS.### sentences, requiring explicit environment selection and production confirmation.

Instructions

SELECT DIRETO no banco do RM/Corpore (/jdbc/Corpore). Lê qualquer tabela do RM (VPCOMPL, PFUNCAOCOMPL, PPESSOA, PFUNC, TMOV...) sem precisar de sentença WS.###. ⚠️ Mesma ressalva do fluig_db_query: a consulta é read-only, mas a tool grava ds_claude_rmdbquery no servidor para executá-la. Em env="prod" exige confirm=true. Se existir sentença WS.### para o que você quer, prefira fluig_rm_query — essa não grava nada.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "sql": "<sql>",
      "env": "<env>"
    },
    "name": "fluig_rm_db_query"
  }
}

Input Schema

Name	Required	Description
`env`	Yes	OBRIGATÓRIO. Ambiente alvo: "teste" (homologação, o host de FLUIG_HOST) ou "prod" (PRODUÇÃO REAL, o host de FLUIG_HOST_PROD). Não há default: a escolha é sempre explícita, para que ninguém leia homologação achando que é produção nem escreva em produção achando que é teste.
`sql`	Yes	SELECT ... (somente SELECT/WITH)
`confirm`	No	obrigatório em env="prod": ciente de que grava dataset e histórico em produção

Schema Changelog

Changes observed during successful MCP inspections.

Changed4 schema fields changedv1.3.0Nov 2, 2026

addedInput schema / properties / confirm

Added value: +{
+  "description": "obrigatório em env=\"prod\": ciente de que grava dataset e histórico em produção",
+  "type": "boolean"
+}

addedInput schema / properties / env

Added value: +{
+  "description": "OBRIGATÓRIO. Ambiente alvo: \"teste\" (homologação, o host de FLUIG_HOST) ou \"prod\" (PRODUÇÃO REAL, o host de FLUIG_HOST_PROD). Não há default: a escolha é sempre explícita, para que ninguém leia homologação achando que é produção nem escreva em produção achando que é teste.",
+  "enum": [
+    "teste",
+    "prod"
+  ],
+  "type": "string"
+}

changedInput schema / properties / sql / description

Previous value: -"SELECT ... (SELECT/WITH only)."New value: +"SELECT ... (somente SELECT/WITH)"

changedInput schema / required

Previous value: -[
-  "sql"
-]New value: +[
+  "sql",
+  "env"
+]

First observedv0.1.0Jul 29, 2026

TDQS

A4.3/5.0

Behavior4/5

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

With no annotations, the description carries the full burden and does well: it discloses the non-obvious side effect that the tool writes a dataset `ds_claude_rmdbquery` on the server even though the query itself is read-only, and flags the production confirm gate. It stops short of describing return shape, row limits, or error behavior, which keeps it from a 5.

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?

Purpose, then the warning, then the alternative — front-loaded in three dense sentences with no wasted framing. The table enumeration is slightly padded but serves to show the resource class, so it earns its place.

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

Completeness4/5

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

For a raw-SQL read tool with no output schema, the definition covers purpose, the surprising server-side write, the environment split, and the preferred sibling. The remaining gap — what a result set looks like or how large it may be — is minor but real.

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% and the env enum is already documented in detail, so the schema does the heavy lifting and a 3 baseline applies. The description reinforces the prod/confirm coupling but adds no new syntax or constraint detail beyond what the schema states.

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

Purpose5/5

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

The description opens with a specific verb and resource — a direct SELECT against the RM/Corpore database via /jdbc/Corpore — and names concrete tables (VPCOMPL, PFUNCAOCOMPL, PPESSOA, PFUNC, TMOV). It explicitly differentiates itself from fluig_rm_query and, by reference to the same caveat, from fluig_db_query, so an agent can route correctly without opening any schema.

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?

It states the selecting condition precisely: use this when no WS.### sentence exists for the data you need, and prefer fluig_rm_query when one does. It also gives the hard prerequisite that env="prod" requires confirm=true, which is exactly the gate an agent needs before invoking.

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

Deploy Server