fluig-mcp

fluig_process_history

Retrieves the full movement history of a Fluig process request, showing who moved it, when, from/to which activity, and comments.

Instructions

Histórico completo de movimentações da solicitação (getHistories -> quem moveu, quando, de/para qual atividade, comentários).

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

Input Schema

Name	Required	Description	Default
`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.
`processInstanceId`	Yes	iProcess

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedv1.3.0Nov 2, 2026

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 / processInstanceId / description
```
Previous value: -"Instance number."New value: +"iProcess"
```

changedInput schema / required

Previous value: -[
-  "processInstanceId"
-]New value: +[
+  "processInstanceId",
+  "env"
+]

First observedv0.1.0Jul 29, 2026

TDQS

B3.2/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 usefully discloses the return payload (mover, timestamp, from/to activity, comments), which is the main unknown given there is no output schema, but it does not state that the call is a read-only operation, nor anything about permissions, behavior on an invalid iProcess, or response size/pagination.

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 compact sentence, front-loaded with what the tool produces and parenthetically enumerating the fields, with no filler. It is efficient, though it leaves no room for the usage and safety context an agent would also need.

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 a 2-parameter, fully schema-documented read tool with no output schema, the description covers the essential purpose and return contents. It stops short on error behavior, whether all history is returned at once, and how it differs from sibling read tools.

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%, with env fully documented by enum and explicit warning and processInstanceId mapped to iProcess, so the baseline is 3. The description adds only the framing that the ID identifies a 'solicitação' whose history is retrieved; it gives no extra detail on ID format or env implications.

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?

The description states a specific resource and what it returns: the complete movement history of a request, via getHistories, including who moved it, when, source/target activity, and comments. That is far more concrete than the bare name, though it does not explicitly distinguish itself from related siblings such as fluig_process_actual_thread or fluig_workflow_events_get.

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

Usage Guidelines2/5

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

The description says only what the tool returns; it never states when to use it, when not to, or which sibling to prefer for a current-state versus historical view. Usage must be inferred entirely from the name and the list of returned fields.

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

Deploy Server