fluig-mcp

fluig_process_diagram_set

⚠️ ESCRITA. Atualiza o SVG do diagrama de uma versão do processo (PUT .../diagram). Necessário depois de mudar a topologia no XML, senão o desenho publicado fica desatualizado. Exige confirm=true.

Instructions

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": {
      "processId": "<processId>",
      "processVersion": "<processVersion>",
      "svg": "<svg>",
      "env": "<env>"
    },
    "name": "fluig_process_diagram_set"
  }
}

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.
`svg`	Yes	conteúdo SVG do diagrama
`confirm`	No	obrigatório true
`processId`	Yes	id do processo
`processVersion`	Yes	versão do processo

Schema Changelog

Changes observed during successful MCP inspections.

Changed6 schema fields changedv1.3.0Nov 2, 2026

changedInput schema / properties / confirm / description

Previous value: -"Must be true to actually perform the operation."New value: +"obrigatório true"

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

Previous value: -"Process id."New value: +"id do processo"

changedInput schema / properties / processVersion / description

Previous value: -"Process version."New value: +"versão do processo"

changedInput schema / properties / svg / description

Previous value: -"SVG content of the diagram."New value: +"conteúdo SVG do diagrama"

changedInput schema / required

Previous value: -[
-  "processId",
-  "processVersion",
-  "svg"
-]New value: +[
+  "processId",
+  "processVersion",
+  "svg",
+  "env"
+]

First observedv0.1.0Jul 29, 2026

TDQS

A4.2/5.0

Behavior4/5

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

With no annotations, the description carries the burden and does reasonably well: it flags a write operation ("⚠️ ESCRITA"), discloses the confirm=true gate, and explains the consequence of skipping it (stale published diagram). It does not mention required permissions, whether the previous SVG is lost, or the response, which keeps it below 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.

Conciseness5/5

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

The warning marker and the write verb are front-loaded, and every sentence earns its place: purpose, trigger, and the confirm gate. No restatement of the parameter list.

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 mutation tool with no annotations and no output schema, the description covers what it writes, why it matters, and the safety gate. The only real gap is what the call returns or how failures surface, which is minor for this kind of endpoint.

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 coverage is 100% and the env parameter is documented in depth in the schema itself, so the schema does the heavy lifting. The description only reinforces that confirm=true is mandatory and links the svg payload to the XML topology change; it adds little beyond that. Baseline 3 applies.

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?

States a specific verb and resource ("Atualiza o SVG do diagrama de uma versão do processo") and even names the endpoint (PUT .../diagram). This clearly separates it from the read-side sibling fluig_process_diagram_get, so an agent can tell the two apart without opening either schema.

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?

Gives a concrete trigger: use it after changing topology in the XML, otherwise the published drawing stays stale. That is a clear when-to-use condition. It never names the alternative explicitly (diagram_get for reading the SVG), so routing is implied rather than spelled out.

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

Deploy Server