Skip to main content
Glama
Sign In
fluig-mcp

fluig-mcp

by alucardigo
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

fluig_deploy_process

Deploy BPMN process definitions to TOTVS Fluig by importing and releasing .ecm30.xml via SOAP, without Fluig Studio, with explicit environment and confirmation.

Instructions

⚠️ DEPLOY estrutural de PROCESSO (BPMN) headless via SOAP WorkflowEngineService (importProcess+releaseProcess, token do TokenService) — SEM Fluig Studio. Publica o .ecm30.xml (…). Exige confirm=true. 1º uso: validar com round-trip (baixar um processo real e re-deployar idêntico).

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

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.
xmlNoconteúdo do .ecm30.xml inline (alternativa a xmlPath)
isNewNotrue = processo novo; false (default) = nova versão de existente
confirmYes
svgPathNoarquivo .processimage.svg (opcional), dentro de FLUIG_SAIDA_DIR (padrão: ~/fluig-mcp-saida); caminho relativo é relativo a ela, e caminho fora dela é recusado
xmlPathNoarquivo .ecm30.xml (alternativa a xml), dentro de FLUIG_SAIDA_DIR (padrão: ~/fluig-mcp-saida); caminho relativo é relativo a ela, e caminho fora dela é recusado
overWriteNosobrescrever (default true)
processIdNoid do processo (opcional; extraído do XML se omitido)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed9 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 / isNew / description
      Previous value: -"true = new process; false (default) = new version of an existing one."New value: +"true = processo novo; false (default) = nova versão de existente"
    • changedInput schema / properties / overWrite / description
      Previous value: -"Overwrite (default true)."New value: +"sobrescrever (default true)"
    • changedInput schema / properties / processId / description
      Previous value: -"Process id (optional; taken from the XML when omitted)."New value: +"id do processo (opcional; extraído do XML se omitido)"
    • changedInput schema / properties / svgPath / description
      Previous value: -"Optional path to the .processimage.svg."New value: +"arquivo .processimage.svg (opcional), dentro de FLUIG_SAIDA_DIR (padrão: ~/fluig-mcp-saida); caminho relativo é relativo a ela, e caminho fora dela é recusado"
    • changedInput schema / properties / xml / description
      Previous value: -"Inline .ecm30.xml content (alternative to xmlPath)."New value: +"conteúdo do .ecm30.xml inline (alternativa a xmlPath)"
    • changedInput schema / properties / xmlPath / description
      Previous value: -"Path to a .ecm30.xml file (alternative to xml)."New value: +"arquivo .ecm30.xml (alternativa a xml), dentro de FLUIG_SAIDA_DIR (padrão: ~/fluig-mcp-saida); caminho relativo é relativo a ela, e caminho fora dela é recusado"
    • changedInput schema / required
      Previous value: -[
-  "confirm"
-]New value: +[
+  "confirm",
+  "env"
+]
  2. First observedv0.1.0

TDQS

B3.4/5.0
Behavior3/5

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

With no annotations, the description does useful work by disclosing the SOAP auth path (TokenService token) and that deploy is a two-step importProcess+releaseProcess, which signals that publishing is immediate. It stops short of the risk profile an agent needs for a mutation tool: what happens to an already-released version, whether running instances are affected, or what overWrite=true default destroys.

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?

A single dense sentence, front-loaded with the warning and the core action, with the confirm precondition and round-trip advice following. Parenthetical technical asides are compact and earn their place; only minor redundancy in spelling out the token flow.

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 8-parameter mutation tool with no annotations and no output schema, the description covers what the tool is and one validation practice, but leaves the agent uninformed about the response (process id/version returned?), failure modes, and the prod-vs-teste blast radius. Adequate, not complete.

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 88%, so the schema already documents env, xml, xmlPath, svgPath, isNew, overWrite and processId thoroughly. The description adds essentially no parameter-level meaning beyond the .ecm30.xml payload hint and the confirm requirement, so 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 and resource: 'DEPLOY estrutural de PROCESSO (BPMN)' and names the underlying mechanism (SOAP WorkflowEngineService, importProcess+releaseProcess). It does not, however, differentiate from the close sibling fluig_process_import_xml or explain its relationship to fluig_deploy_list, so the agent must infer the boundary.

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

Usage Guidelines3/5

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

Gives a precondition ('Exige confirm=true') and an onboarding recommendation ('1º uso: validar com round-trip'), but never says when to choose this tool over fluig_process_import_xml or what the exclusions are. Usage is implied rather than routed.

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