Skip to main content
Glama
Sign In
fluig-mcp

fluig-mcp

by alucardigo
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

fluig_process_move

Saves and moves an existing Fluig process request to a target state; send complete cardData because it replaces the card, and take POOL tasks first.

Instructions

SALVA e MOVE uma solicitação existente (saveAndSendTask SOAP). ⚠️ cardData SUBSTITUI o card — envie TODOS os campos que devem persistir (INICIO + etapas), senão são apagados. Faça fluig_process_take antes se a tarefa for de POOL.

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": {
      "processInstanceId": "<processInstanceId>",
      "choosedState": "<choosedState>",
      "env": "<env>"
    },
    "name": "fluig_process_move"
  }
}

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.
confirmNoobrigatório em env="prod" (em homologação passa direto)
cardDataNo{campo:valor} — TODOS os campos (substitui o card)
commentsNocomentário (opcional)
managerModeNomover como gestor do processo (requer ser gestor)
choosedStateYesestado destino (nº do próximo nó/gateway)
colleagueIdsNopróximos responsáveis (opcional)
processInstanceIdYesiProcess (número da solicitação)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed9 schema fields changedv1.3.0
    • changedInput schema / properties / cardData / description
      Previous value: -"{field: value} — ALL fields (replaces the card)."New value: +"{campo:valor} — TODOS os campos (substitui o card)"
    • changedInput schema / properties / choosedState / description
      Previous value: -"Target state (number of the next node or gateway)."New value: +"estado destino (nº do próximo nó/gateway)"
    • changedInput schema / properties / colleagueIds / description
      Previous value: -"Next assignees (optional)."New value: +"próximos responsáveis (opcional)"
    • changedInput schema / properties / comments / description
      Previous value: -"Comment (optional)."New value: +"comentário (opcional)"
    • addedInput schema / properties / confirm
      Added value: +{
+  "description": "obrigatório em env=\"prod\" (em homologação passa direto)",
+  "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 / managerMode / description
      Previous value: -"Move as process manager (requires the manager role)."New value: +"mover como gestor do processo (requer ser gestor)"
    • changedInput schema / properties / processInstanceId / description
      Previous value: -"Instance number."New value: +"iProcess (número da solicitação)"
    • changedInput schema / required
      Previous value: -[
-  "processInstanceId",
-  "choosedState"
-]New value: +[
+  "processInstanceId",
+  "choosedState",
+  "env"
+]
  2. First observedv0.1.0

TDQS

A4/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 delivers the most important behavioral fact: cardData is a destructive full replacement that wipes omitted fields. It does not cover permissions beyond the manager hint, error/failure behavior, or what a successful move returns.

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?

Three short sentences, zero filler: action, then the destructive-data warning, then the prerequisite. The highest-risk information is front-loaded with a warning marker.

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 an 8-parameter destructive mutation with no annotations and no output schema, the description covers the two things that cause real damage: data loss on the card and the POOL/take prerequisite. It omits expected success behavior and any error/failure notes, which is a minor but real gap.

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%, so baseline is 3. The description does add consequence-level meaning to cardData ('senão são apagados') that the schema's terse 'substitui o card' does not, but the other parameters (env, confirm, managerMode, colleagueIds) are left entirely to the schema.

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 compound action (save + move) on a specific resource ('uma solicitação existente') and identifies the underlying API (saveAndSendTask SOAP), which implicitly separates it from the fluig_process_move_rest sibling. It stops short of explicitly naming that REST sibling or 'cancel', leaving the agent to infer the distinction.

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_process_take antes se a tarefa for de POOL' gives an explicit prerequisite with its triggering condition. No guidance is given on when NOT to use this tool (e.g., versus fluig_process_move_rest or fluig_process_cancel), so routing among siblings is only partially covered.

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