fluig-mcp

fluig_form_save

Publishes or updates a Fluig form as a reversible version by submitting all files and events, with explicit test or production targeting and production confirmation.

Instructions

Publica/atualiza um formulário (nova versão revertível). Manda TODOS os arquivos+eventos. files:[{fileName,content}], events:[{eventId,eventDescription}]. Faça fluig_form_full antes e altere só o que precisa.

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": {
      "documentId": "<documentId>",
      "datasetName": "<datasetName>",
      "cardDescription": "<cardDescription>",
      "files": "<files>",
      "env": "<env>"
    },
    "name": "fluig_form_save"
  }
}

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.
`files`	Yes	[{fileName, content}] TODOS os arquivos
`events`	No	[{eventId, eventDescription}] TODOS os eventos
`confirm`	No	obrigatório em env="prod" (em homologação passa direto)
`documentId`	Yes	documentId
`datasetName`	Yes	nome do dataset do form
`versionOption`	No	0=manter versão, 2=nova versão (default 2)
`cardDescription`	Yes	descrição do form
`descriptionField`	No	campo descritor (pode vazio)

Schema Changelog

Changes observed during successful MCP inspections.

Changed10 schema fields changedv1.3.0Nov 2, 2026

changedInput schema / properties / cardDescription / description

Previous value: -"Form description."New value: +"descrição do form"

addedInput schema / properties / confirm

Added value: +{
+  "description": "obrigatório em env=\"prod\" (em homologação passa direto)",
+  "type": "boolean"
+}

changedInput schema / properties / datasetName / description

Previous value: -"Name of the form dataset."New value: +"nome do dataset do form"

changedInput schema / properties / descriptionField / description

Previous value: -"Descriptor field (may be empty)."New value: +"campo descritor (pode vazio)"

changedInput schema / properties / documentId / description

Previous value: -"Form documentId."New value: +"documentId"

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 / events / description

Previous value: -"[{eventId, eventDescription}] — ALL events."New value: +"[{eventId, eventDescription}] TODOS os eventos"

changedInput schema / properties / files / description

Previous value: -"[{fileName, content}] — ALL files."New value: +"[{fileName, content}] TODOS os arquivos"

changedInput schema / properties / versionOption / description

Previous value: -"0 = keep version, 2 = new version (default 2)."New value: +"0=manter versão, 2=nova versão (default 2)"

changedInput schema / required

Previous value: -[
-  "documentId",
-  "datasetName",
-  "cardDescription",
-  "files"
-]New value: +[
+  "documentId",
+  "datasetName",
+  "cardDescription",
+  "files",
+  "env"
+]

First observedv0.1.0Jul 29, 2026

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 disclose the two traits that matter most: the operation produces a revertible new version, and the payload is a full replacement ('Manda TODOS os arquivos+eventos'), warning the agent that omitted items will be dropped. It does not explain permissions, the prod confirmation flow, or what the call returns.

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?

Four short sentences, front-loaded with the action and versioning behavior, with zero filler. The inline array shape listings duplicate the schema and are the one mildly redundant element.

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 a 9-parameter mutation tool with no annotations and no output schema, the description covers the critical semantics (full replacement, versioning, prerequisite read) but says nothing about the return value — e.g. the new documentId or version number — which the agent cannot learn from anywhere else.

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 env, confirm, versionOption and the rest are already documented in structured fields. The description only restates the files/events element shapes and repeats the 'TODOS' emphasis already present in the schema, adding little new meaning. Baseline 3 applies.

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 pair and resource ('Publica/atualiza um formulário') plus the key side effect ('nova versão revertível'), which tells an agent this is a versioned write rather than a plain edit. It does not explicitly distinguish itself from the sibling fluig_form_create, leaving that boundary to inference.

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?

'Faça fluig_form_full antes e altere só o que precisa' gives an explicit prerequisite call and a read-modify-write workflow, naming the sibling to run first. It stops short of stating when to use this versus fluig_form_create or fluig_globalevent_save, and gives no when-not condition.

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

Deploy Server