Skip to main content
Glama
Sign In
fluig-mcp

fluig-mcp

by alucardigo
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

fluig_rm_db_exec

Executes INSERT/UPDATE/DELETE against the RM/Corpore database for controlled writes, requiring confirm=true and an explicit test or prod environment.

Instructions

⚠️ Executa INSERT/UPDATE/DELETE no RM/Corpore (/jdbc/Corpore). Exige confirm=true. OBS: a conexão /jdbc/Corpore costuma ser READ-ONLY p/ tabelas do RM — escrita de laudo etc. vai pelo DataServer (RhuPessoaData), não por aqui.

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>",
      "confirm": "<confirm>",
      "env": "<env>"
    },
    "name": "fluig_rm_db_exec"
  }
}

Input Schema

NameRequiredDescriptionDefault
envYesOBRIGATÓ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.
sqlYesINSERT/UPDATE/DELETE
confirmYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changedv1.3.0
    • removedInput schema / properties / confirm / description
      Removed value: -"Must be true to actually perform the operation."
    • 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: -"INSERT/UPDATE/DELETE statement."New value: +"INSERT/UPDATE/DELETE"
    • changedInput schema / required
      Previous value: -[
-  "sql",
-  "confirm"
-]New value: +[
+  "sql",
+  "confirm",
+  "env"
+]
  2. First observedv0.1.0

TDQS

A3.8/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 a good job: it declares the destructive mutation class, the confirm=true safety gate, and the non-obvious fact that the /jdbc/Corpore connection is often READ-ONLY for RM tables, so the call may fail. It does not cover transaction/commit behavior, whether multiple statements are allowed, or what is returned (row counts, errors).

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?

Two tight sentences, warning-first and caveat-second, with no filler. The caveat is slightly compressed (abbreviations, mixed language) but every clause carries operational meaning.

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

Completeness3/5

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

For an unannotated destructive SQL execution tool with no output schema, the description covers the biggest risks (destructive class, confirm gate, read-only caveat) but omits return shape, commit semantics, and failure modes an agent needs to interpret results or recover.

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?

The env parameter is already fully documented in the schema, so no credit there. The description does add value for confirm, stating it must be true, which the bare boolean schema does not say. However, sql is described only as 'INSERT/UPDATE/DELETE' in both schema and description, with no guidance on statement limits, placeholders, or parameterization, leaving that at 67% coverage uncompensated.

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?

States a specific verb class (INSERT/UPDATE/DELETE) against a specific resource (/jdbc/Corpore no RM/Corpore), which separates it from the read-oriented siblings like fluig_rm_db_query and fluig_db_query. It does not name the sibling write tool (fluig_rm_save_record) that would actually be the alternative, so differentiation is by inference rather than explicit routing.

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

Usage Guidelines4/5

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

The OBS is real guidance: it says writes to RM tables such as laudo should go through the DataServer (RhuPessoaData) instead of this tool, which is an explicit when-not-to-use. It also surfaces the confirm=true precondition. It stops short of naming the concrete alternative tool and never contrasts with the query siblings for reads.

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

Deploy Server

Other Tools