Skip to main content
Glama
Sign In
fluig-mcp

fluig-mcp

by alucardigo
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

fluig_process_event_set_xml

Updates a Fluig process event by exporting the process XML, replacing or creating its eventDescription, and reimporting it to generate a new reversible version.

Instructions

⚠️ ESCRITA. Grava um evento de PROCESSO pelo caminho SUPORTADO: exporta o XML da definição, troca (ou cria) o eventDescription e reimporta — gerando NOVA VERSÃO revertível. Substitui com segurança o fluig_process_event_set (UPDATE direto em event_proces). Use dryRun=true primeiro. Exige confirm=true.

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>",
      "eventId": "<eventId>",
      "code": "<code>",
      "env": "<env>"
    },
    "name": "fluig_process_event_set_xml"
  }
}

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.
codeYescódigo-fonte COMPLETO do evento (function nome(...){...})
dryRunNonão envia nada; só valida o patch e devolve o tamanho resultante
confirmNoobrigatório true para gravar de fato
eventIdYesnome do evento (ex: beforeStateEntry, afterTaskCreate, afterProcessFinish)
releaseNopublicar/liberar a nova versão na mesma chamada (padrão false)
versionNoversão de origem a exportar (opcional)
processIdYesid do processo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed9 schema fields changedv1.3.0
    • changedInput schema / properties / code / description
      Previous value: -"COMPLETE source of the event (function name(...) { ... })."New value: +"código-fonte COMPLETO do evento (function nome(...){...})"
    • changedInput schema / properties / confirm / description
      Previous value: -"Must be true to actually perform the operation."New value: +"obrigatório true para gravar de fato"
    • changedInput schema / properties / dryRun / description
      Previous value: -"Validate the patch without sending anything."New value: +"não envia nada; só valida o patch e devolve o tamanho resultante"
    • 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 / eventId / description
      Previous value: -"Event name, e.g. \"beforeStateEntry\", \"afterTaskCreate\", \"afterProcessFinish\"."New value: +"nome do evento (ex: beforeStateEntry, afterTaskCreate, afterProcessFinish)"
    • changedInput schema / properties / processId / description
      Previous value: -"Process id."New value: +"id do processo"
    • changedInput schema / properties / release / description
      Previous value: -"Publish the new version in the same call (default false)."New value: +"publicar/liberar a nova versão na mesma chamada (padrão false)"
    • changedInput schema / properties / version / description
      Previous value: -"Source version to export (optional)."New value: +"versão de origem a exportar (opcional)"
    • changedInput schema / required
      Previous value: -[
-  "processId",
-  "eventId",
-  "code"
-]New value: +[
+  "processId",
+  "eventId",
+  "code",
+  "env"
+]
  2. First observedv0.1.0

TDQS

A4.6/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 so well: it flags the tool as a write operation (⚠️ ESCRITA), discloses that it creates a new, revertible version rather than mutating in place, and requires both a dry-run phase and confirm=true. It stops short of describing failure modes, permissions needed, or what a real (non-dryRun) response contains.

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?

Roughly four short clauses, front-loaded with the write warning and the safe-path mechanism before the alternatives and preconditions. No filler; every sentence carries either safety or routing information.

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 mutating tool with no annotations and no output schema, the description supplies the critical missing context: it is a write, it is version-producing and revertible, and it has a mandatory dry-run/confirm protocol. The only gap is return-value shape for a real write, though dryRun's result is described as the resulting size.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so baseline is 3; however the description goes beyond the schema by establishing the operational ordering of dryRun and the hard gate on confirm=true, which is workflow semantics the schema alone states but does not sequence. Other parameters (env, release, version) are left entirely to the already-complete schema.

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 ("Grava um evento de PROCESSO") and explains the exact mechanism used (export XML -> swap/create eventDescription -> reimport). It explicitly names the sibling it replaces (fluig_process_event_set) and the kind of artifact produced (NOVA VERSÃO), so an agent can distinguish it from the direct-UPDATE sibling without opening any schema.

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

Usage Guidelines5/5

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

Gives an explicit ordered workflow ("Use dryRun=true primeiro. Exige confirm=true") and states which alternative it supersedes and why (safer than fluig_process_event_set's direct update on event_proces). The condition for choosing this tool over the sibling is unambiguous.

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