Skip to main content
Glama
Sign In
fluig-mcp

fluig-mcp

by alucardigo
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

fluig_workflow_events_get

Reads the workflow events of a Fluig process for a given process ID, version, and environment (test or prod). Run the workflow check first to validate the process before fetching its events.

Instructions

Lê os eventos de um processo (requer FluiggersWidget). Use fluig_workflow_check antes.

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>",
      "version": "<version>",
      "env": "<env>"
    },
    "name": "fluig_workflow_events_get"
  }
}

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.
versionYesversão do processo
processIdYesid do processo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changedv1.3.0
    • 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 / version / description
      Previous value: -"Process version."New value: +"versão do processo"
    • changedInput schema / required
      Previous value: -[
-  "processId",
-  "version"
-]New value: +[
+  "processId",
+  "version",
+  "env"
+]
  2. First observedv0.1.0

TDQS

A3.6/5.0
Behavior3/5

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

No annotations are provided, so the description carries the full burden. It does disclose a real operational prerequisite ('requer FluiggersWidget'), which is meaningful context an agent cannot get from the schema, but it never states that the operation is read-only/safe, nor what happens if the widget is absent.

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 short sentence with the action front-loaded and the dependency in parentheses; nothing is wasted. It is arguably too terse rather than padded, so it scores well on structure without being exemplary.

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?

Three required params are fully documented in the schema and the prerequisite is named, but with no output schema the description should say what 'eventos' actually returns (event scripts? BPM event configuration?) and in what form. The agent knows how to call it but not what it gets back.

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% and the env enum is documented in detail, including the test-vs-prod host distinction. The description adds no parameter-level meaning beyond that, so the 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: 'Lê os eventos de um processo' (reads the events of a process). It is distinguishable from the write-side sibling fluig_workflow_events_update, though it does not explicitly separate itself from fluig_process_event_get or fluig_process_events_xml, which sound adjacent.

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 prerequisite ordering: 'Use fluig_workflow_check antes', which tells the agent a precondition step exists. It does not state when NOT to use it or name the alternative for related event data, so it falls short of a full 5.

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