Allows interaction with a TOTVS Fluig environment, enabling management of datasets, forms, process definitions, requests, and SQL passthrough queries to Fluig and TOTVS RM databases.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@fluig-mcp list all datasets"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Opere um ambiente TOTVS Fluig por um agente de IA ou pelo terminal — datasets, formulários, eventos globais e definições de processo BPM — sem abrir o Fluig Studio.
Desenvolver no Fluig normalmente passa pelo Fluig Studio, uma distribuição do Eclipse. Ler um evento de formulário, descobrir qual dataset um workflow chama ou subir uma correção de uma linha num service task significa abrir a IDE, exportar um pacote, importar de volta e publicar na mão. Nada desse ciclo é automatizável, e nada dele é acessível a um agente.
Tudo o que o Fluig Studio faz, ele faz por HTTP. O fluig-mcp fala os mesmos três protocolos da
plataforma — o cookie de sessão do login.do, os serviços SOAP legados em /webdesk/* e a API
REST v2 — de dentro de um processo Node comum. Isso expõe a plataforma inteira como ferramentas
Model Context Protocol: o assistente lê o validateForm de um
formulário, rastreia por que uma tarefa caiu na pessoa errada ou publica uma versão corrigida de
processo na mesma conversa em que a pergunta apareceu.
Related MCP server: Operaton MCP
Datasets — listar, ler o código de um dataset custom, inspecionar a estrutura sem executar, executar, criar, atualizar e apagar.
Formulários — listar, ler todos os arquivos e eventos, e publicar nova versão.
Eventos globais — ler e gravar.
Definições de processo BPM — exportar o .ecm30.xml, ler e alterar o código dos eventos de
processo, publicar nova versão, retirar do ar para reverter e apagar versões.
Solicitações — iniciar, assumir, mover, cancelar; ler o card, o histórico, os anexos, os estados ativos e disponíveis, e quem pode receber a tarefa.
SQL passthrough — SELECT read-only no banco do Fluig e no TOTVS RM, direto ou pela
sentença registrada.
Escape hatches — GET/POST autenticado em qualquer caminho da API.
São 56 ferramentas. node server.js --list mostra todas — e não pede credencial nenhuma, para
você auditar a superfície antes de confiar alguma a ela.
O código dos eventos de processo vive dentro do XML da definição, em
<WorkflowProcessEvent><eventDescription>. O fluig-mcp lê de lá e grava de volta exportando a
definição, alterando só aquele evento e reimportando — o que faz de cada escrita uma nova
versão, revertível, que passou pela validação do servidor, num servidor sem nenhum add-on
instalado. O round-trip é byte a byte: acentos, aspas e o $ do jQuery sobrevivem intactos
(teste de regressão).
Node.js 20 ou superior.
Acesso de rede a um ambiente Fluig (testado contra Fluig 1.8.x).
Um usuário do Fluig. A maioria das ferramentas quer perfil administrativo; as de solicitação agem como esse usuário e precisam dos papéis correspondentes.
git clone https://github.com/alucardigo/fluig-mcp.git
cd fluig-mcp
npm installToda a configuração vem de variáveis de ambiente. Não existe default de host nem de credencial — variável faltando é erro explícito, nunca um fallback silencioso.
Variável | Obrigatória | Default | O que é |
| sim | — | URL base do portal, com esquema e porta |
| sim | — | Login do Fluig |
| sim | — | Senha desse login |
| não |
| Tenant; |
| não |
| Colleague id, quando difere do login |
| não |
|
|
| não | — | IPs de fallback (vírgula), sondados quando o DNS oscila |
| não |
| Datasource JNDI do banco do Fluig |
| não |
| Datasource JNDI do banco do TOTVS RM |
| não |
| Dataset que repassa sentenças SQL do RM |
| não |
| Prefixo dos datasets descartáveis criados aqui |
Veja .env.example.
claude mcp add fluig \
--env FLUIG_HOST=https://fluig.exemplo.com:8080 \
--env FLUIG_USER=seu.usuario \
--env FLUIG_PASS=sua-senha \
-- node /caminho/absoluto/para/fluig-mcp/server.js{
"mcpServers": {
"fluig": {
"command": "node",
"args": ["/caminho/absoluto/para/fluig-mcp/server.js"],
"env": {
"FLUIG_HOST": "https://fluig.exemplo.com:8080",
"FLUIG_USER": "seu.usuario",
"FLUIG_PASS": "sua-senha",
"FLUIG_READONLY": "1"
}
}
}
}Comece com FLUIG_READONLY=1. Tire quando já souber o que o agente faz com as ferramentas de
leitura.
A CLI usa o mesmo cliente, então é o caminho mais rápido para provar credencial e conectividade antes de envolver um agente:
export FLUIG_HOST=https://fluig.exemplo.com:8080
export FLUIG_USER=seu.usuario
export FLUIG_PASS=sua-senha
node bin/cli.js ping
node bin/cli.js dataset list colleague
node bin/cli.js form list
node bin/cli.js process events MeuProcessonode bin/cli.js --help lista todos os comandos. O que for baixado vai para ./out
(fora do git).
! marca ferramenta que altera o servidor. Essas desaparecem por completo com
FLUIG_READONLY=1, e cada uma exige confirm: true explícito.
Sessão
Ferramenta | O que faz |
| Valida autenticação e sessão |
Datasets
Ferramenta | O que faz |
| Lista datasets, com filtro opcional |
| Código-fonte de um dataset custom |
| Colunas e tipos, sem executar o dataset |
| Executa e devolve as linhas |
| Cria ou atualiza dataset custom (código ES5/Rhino) |
| Apaga dataset custom |
Formulários
Ferramenta | O que faz |
| Lista formulários |
| Eventos de customização com o código ( |
| Lista arquivos / lê um arquivo |
| Metadados, todos os arquivos e todos os eventos numa chamada |
| Publica nova versão do formulário |
Eventos globais
Ferramenta | O que faz |
| Lista eventos globais |
| Cria ou atualiza um |
SQL
Ferramenta | O que faz |
|
|
|
|
| Consulta ao RM pela sentença registrada (dataset ponte) |
|
|
Definições de processo
Ferramenta | O que faz |
| Baixa a definição como |
| Eventos de processo com o código, direto da definição |
| Versões / versão ativa |
| Formulário vinculado / diagrama |
| Busca / o que o usuário pode iniciar |
| Processos disponíveis para export |
| Código do evento na |
| Grava evento como nova versão (aceita |
| Deploy da definição pela REST v2 |
| Deploy da definição por SOAP |
| Retira a versão do ar — é como se reverte um deploy |
| Apaga uma versão |
| Substitui o SVG do diagrama da versão |
| Alteração in-place da |
Solicitações
Ferramenta | O que faz |
| Estados-destino disponíveis |
| Onde a solicitação está |
| Card inteiro / um campo |
| Histórico / anexos |
| Quem pode receber a tarefa |
| Quem responde por quem, e até quando |
| Inicia uma solicitação |
| Assume tarefa de pool |
| Salva o card e move a solicitação |
| Cancela a solicitação |
Add-on FluiggersWidget (opcional) — dispensável; as ferramentas _xml acima resolvem o mesmo
num servidor sem add-on.
Ferramenta | O que faz |
| O widget está instalado? |
| Lê eventos de processo pelo widget |
| Grava eventos de processo pelo widget |
Escape hatches
Ferramenta | O que faz |
|
|
|
|
Assunto | Mecanismo |
Autenticação |
|
Datasets | SOAP |
Formulários | SOAP |
Eventos globais | REST |
Definições de processo | REST v2 |
Solicitações | SOAP |
SQL | Um dataset custom descartável que abre o datasource JNDI no servidor e roda a instrução |
Resiliência de rede. Fluig quase sempre está atrás de DNS corporativo, e DNS corporativo
mente: zonas split-horizon devolvem endereço inalcançável de onde você está, e um lookup azarado
fica idêntico a uma queda de servidor. Então o cliente resolve o endereço ele mesmo — último IP
bom, dns.resolve4, dns.lookup, seeds do operador —, sonda os candidatos por TCP em paralelo,
fixa o primeiro que responde e preserva o Host original para o virtual host continuar
funcionando. O endereço bom fica em cache curto e é re-sondado em qualquer falha. Toda chamada
também tem retry com backoff, e só insiste em erro de fato transiente.
Este servidor entrega a um LLM a capacidade de rodar SQL, publicar formulários e apagar definições de processo. Trate com o cuidado correspondente.
FLUIG_READONLY=1 esconde as 18 ferramentas de escrita. Sobram 38, incluindo tudo o que é
necessário para ler e diagnosticar.
Toda operação destrutiva exige confirm: true explícito; não existe sim por omissão.
fluig_process_event_set_xml e fluig_process_import_xml criam nova versão em vez de
mexer na que está no ar, então fluig_process_version_withdraw reverte um deploy ruim.
As ferramentas de consulta aceitam só SELECT/WITH, validado antes de a instrução sair do
processo.
Para rodar SQL, o servidor grava um dataset descartável chamado ${FLUIG_SCRATCH_PREFIX}*
(por padrão ds_mcp_dbquery, ds_mcp_rmquery, …). Isso acontece em modo read-only também,
porque é assim que a leitura funciona. Tudo com esse prefixo no seu servidor foi criado aqui e
pode ser apagado com fluig_dataset_delete.
Aponte primeiro para um ambiente de teste ou homologação.
Veja SECURITY.md.
Formulário é orientado a leitura: fluig_form_save substitui todo o conjunto de arquivos e
eventos, então leia com fluig_form_full antes ou você perde o que não mandou.
O datasource do RM costuma estar configurado como read-only. Quando está, o caminho suportado
de escrita no RM é a API DataServer do RM, não o fluig_rm_db_exec.
O dataset ponte de sentenças (FLUIG_RM_BRIDGE_DATASET) é convenção de integração, não
garantia de plataforma — o nome e a existência variam por instalação.
Código de dataset roda em Rhino: só ES5, sem let/const, arrow function ou template string.
Verificado contra Fluig 1.8.x. Outras versões provavelmente funcionam, mas não foram testadas.
npm test # testes de unidade, não precisa de servidor
npm run check # checagem de sintaxe de todos os fontes
npm run list # imprime a superfície de ferramentasOs testes usam o runner nativo node:test e rodam offline — a camada de rede é stubada, então a
suíte roda em qualquer lugar. Veja CONTRIBUTING.md.
O protocolo de dataset e formulário foi originalmente mapeado pelo projeto comunitário
fluig-vscode-extension (Fluiggers), que
vale muito a pena se você escreve código Fluig no VS Code. As rotas de definição de processo,
ciclo de vida de solicitação e deploy aqui foram mapeadas de forma independente contra um
servidor real.
Projeto independente e não oficial. Sem vínculo, endosso ou suporte da TOTVS. TOTVS, Fluig e RM são marcas da TOTVS S.A. Alguns endpoints usados aqui são internos ou não documentados e podem mudar entre versões.
MIT © Rodrigo de Souza Faria
DESTRUCTIVE. Delete a CUSTOM dataset from the server. Also how this server cleans up its own throwaway datasets.
| Name | Required | Description | Default |
|---|---|---|---|
| confirm | Yes | Must be true to actually perform the operation. | |
| datasetId | Yes | Dataset id to delete. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full behavioral burden. It labels the action as destructive, which is good, but does not detail consequences (e.g., irreversible data loss, permission requirements, or server cleanup mechanism).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Short and front-loaded with 'DESTRUCTIVE', but the second sentence is confusing and not clearly related to the tool's function. Could be more concise by removing or clarifying that sentence.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Lacks details about what happens after deletion (e.g., success indication, side effects). The mention of server cleanup is vague and incomplete. No output schema exists, so description should provide more behavioral context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%; both parameters have descriptions in the schema. The tool description adds marginal value by specifying 'CUSTOM' dataset and implying confirm is mandatory, but does not provide new insight beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it deletes a CUSTOM dataset, distinguishing it from list, get, run, etc. The second sentence about server cleanup of throwaway datasets adds slight ambiguity but does not undermine the primary purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives (e.g., other dataset tools). The 'DESTRUCTIVE' prefix is a warning but not explicit usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return the source code of a CUSTOM dataset.
| Name | Required | Description | Default |
|---|---|---|---|
| datasetId | Yes | Id of the custom dataset. |
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 states the tool returns source code, but fails to disclose whether it is read-only, requires special permissions, or has side effects. 'Return' implies a read operation, but this is not explicitly confirmed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence of 9 words, no filler, front-loaded with the action verb 'Return'. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given low complexity (1 required param, no output schema, no annotations), the description is fairly complete for a simple retrieval tool. It lacks output format details, but these are implicitly understood for a source code fetch.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with one parameter described as 'Id of the custom dataset.' The description's use of 'CUSTOM' reinforces the parameter context, but adds no new meaning beyond the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Return' and the resource 'source code of a CUSTOM dataset', distinguishing it from siblings like fluig_dataset_list (list datasets) and fluig_dataset_structure (get structure).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or when-not-to-use guidance is provided. The description implies usage for retrieving custom dataset source code, but does not differentiate from alternatives like fluig_dataset_structure or fluig_dataset_save.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List datasets on the server (id + type). Optional substring filter over id and description.
| Name | Required | Description | Default |
|---|---|---|---|
| filter | No | Substring to filter by (optional). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It only states listing and optional filter, with no mention of side effects, read-only nature, or constraints. Minimal transparency for a tool that is likely a read operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no filler, front-loaded with main action. Every sentence earns its place. Highly concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple listing tool with one parameter and no output schema, description is nearly complete. Could mention if pagination exists or if it returns all datasets, but the context is sufficient for a basic list operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has one optional 'filter' parameter with simple description. Description adds meaningful context: filter applies to both id and description fields, which is not in the schema. Adds value beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool lists datasets with id and type, and optionally filters by substring over id and description. This distinguishes it from siblings like fluig_dataset_get (retrieves single dataset) and fluig_dataset_delete.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description implies usage (list datasets) but does not explicitly state when to use this tool versus alternatives like fluig_dataset_get, fluig_dataset_structure, or search-related tools. No when-not or explicit context provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run a dataset (form-backed or custom) and return its rows.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Dataset name. | |
| limit | No | Maximum rows to show (optional). | |
| fields | No | Columns to return (optional). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries full burden. It fails to disclose behavioral traits like side effects, permission requirements, or error behavior. The action 'run' could imply mutation, but no clarification is given.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, direct and free of fluff. Every word adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations, output schema, and the presence of many sibling tools, the description is insufficient for a complete understanding. Missing details on error scenarios, pagination, and data mutability.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%. The description adds 'form-backed or custom' context but does not enhance understanding of parameters beyond what the schema already provides. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('run'), the resource ('dataset'), and the result ('return its rows'). It also distinguishes between form-backed or custom datasets. Among sibling tools like fluig_dataset_list, get, structure, save, delete, this tool is uniquely for executing and obtaining data rows.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives such as fluig_dataset_get or fluig_dataset_structure. The description implies it is for retrieving rows, but does not state prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create or update a CUSTOM dataset. The code runs on the server under Rhino, so it must be ES5 (no let/const, arrow functions or template literals).
| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes | JavaScript source (a createDataset function), ES5/Rhino. | |
| datasetId | Yes | Dataset id. | |
| description | No | Description (optional). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must cover behavior. It discloses the Rhino/ES5 constraint and server-side execution, which is useful. However, it lacks details on destructive nature (overwrite behavior), required permissions, error states, or return value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with a clear front-loaded purpose statement. Every sentence adds value, but the structure could include a note on behavior like 'Overwrites existing dataset with same ID'.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema provided, but description does not explain return values or success indicators. For a tool executing arbitrary code, error handling and output format are omitted, making it incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 reiterates the ES5 constraint already in the schema, adding no new parameter meaning. It does not explain relationships or defaults.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the specific action 'Create or update' on a 'CUSTOM dataset'. This clearly distinguishes it from siblings like fluig_dataset_list or fluig_dataset_delete, providing a precise verb and resource.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. It does not specify prerequisites, exclusions, or mention sibling tools like fluig_dataset_list for read-only operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return a dataset's structure (columns and types) WITHOUT running it — useful to learn the schema before composing a query.
| Name | Required | Description | Default |
|---|---|---|---|
| datasetId | Yes | Dataset id. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses safe, read-only behavior ('WITHOUT running it'), which is critical for an AI agent. No annotations, so description carries full burden; it adequately covers the non-destructive nature.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single, front-loaded sentence with no unnecessary words. Every phrase earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (one parameter, no output schema), the description fully covers purpose, behavior, and usage context. No gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a basic description ('Dataset id.'). The tool description does not add further parameter semantics beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Explicit verb 'Return' and precise resource 'dataset's structure (columns and types)'. Distinguishes from sibling fluig_dataset_run by specifying 'WITHOUT running it' and states usefulness for composing queries.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Clearly indicates when to use (before composing a query to learn schema). Does not explicitly exclude alternatives like fluig_dataset_run, but context is strong enough for an agent to infer.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run a SELECT against the Fluig database through a throwaway dataset. Read-only (SELECT/WITH only). Reaches any table, including event_proces, DEF_PROCES and the FDN_* metadata.
| Name | Required | Description | Default |
|---|---|---|---|
| sql | Yes | SELECT ... (SELECT/WITH only). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It declares the tool is read-only (SELECT/WITH only) and mentions the result is temporary ('throwaway dataset'), but it does not disclose potential side effects, resource limits, or timeout behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences, front-loading the action and database, then clarifying scope. No extraneous words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a dynamic SQL query tool, the description lacks details about return format, error handling, pagination, or any limits. However, the read-only safety is noted, and the context of available tables is helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single parameter, which already repeats the constraint 'SELECT ... (SELECT/WITH only)'. The description adds minimal context (database scope, temporary dataset) but no additional format guidance or examples beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Run a SELECT') and resource ('Fluig database through a throwaway dataset'), and it distinguishes itself from other database query tools (e.g., fluig_rm_db_query) by specifying 'any table' and giving examples of Fluig-specific tables.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for read-only SQL queries on the Fluig database, but it does not explicitly state when to use this tool versus alternatives like fluig_rm_db_query or the dataset tools. No exclusions or prerequisites are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the processes available for export/deploy (SOAP WorkflowEngineService). Useful to validate a deploy with a round trip.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must cover behavioral traits. It indicates the tool is a read-only list operation (listing processes) and mentions the SOAP service, which hints at potential network requirements. However, it does not state that it is non-destructive or describe any authentication needs, rate limits, or side effects. For a simple list tool, this is adequate but not exceptional.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences: one defining the action and scope, the other providing a use case. Every sentence is valuable and there is no redundancy. It is appropriately front-loaded with the primary purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters and no output schema, the description is reasonably complete. It explains what the tool lists (processes available for export/deploy) and gives a practical use case. However, it does not describe the structure of the returned list (e.g., what fields are included), which might leave the agent uncertain about the output format.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no parameters, so schema coverage is trivially 100%. According to guidelines, baseline for 0 parameters is 4. The description does not add parameter meaning because there are none, but it confirms the tool requires no inputs, which is fine.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'List the processes available for export/deploy', which is a specific verb (list) and resource (processes for export/deploy). It also mentions the underlying SOAP service, adding technical context. However, it does not explicitly differentiate from other list tools in the sibling set, like 'fluig_globalevent_list', though the scope is clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a use case: 'Useful to validate a deploy with a round trip.' This gives some context for when to use it, but it does not offer explicit guidance on when not to use it or alternatives. For example, it does not mention that other tools like 'fluig_process_export_xml' or 'fluig_deploy_process' are for actual export/deploy, not listing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
WRITE, STRUCTURAL. Deploy a process definition over SOAP WorkflowEngineService (importProcess + releaseProcess). Alternative to fluig_process_import_xml for servers that do not expose the v2 REST route.
| Name | Required | Description | Default |
|---|---|---|---|
| xml | No | Inline .ecm30.xml content (alternative to xmlPath). | |
| isNew | No | true = new process; false (default) = new version of an existing one. | |
| confirm | Yes | Must be true to actually perform the operation. | |
| svgPath | No | Optional path to the .processimage.svg. | |
| xmlPath | No | Path to a .ecm30.xml file (alternative to xml). | |
| overWrite | No | Overwrite (default true). | |
| processId | No | Process id (optional; taken from the XML when omitted). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It labels the tool as 'WRITE, STRUCTURAL' and mentions SOAP protocol, but lacks details on side effects, permissions, error handling, or idempotency. This is insufficient for safe agent invocation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—two sentences that front-load the WRITE/STRUCTURAL category and deploy action. Every word earns its place, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (deploying a process via SOAP, 7 parameters, no output schema), the description omits important details such as return values, error scenarios, and confirmation procedure (beyond the confirm parameter). An agent needs more context to handle this safely.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, the baseline is 3. The description does not add parameter-specific meaning beyond what the schema already provides; therefore, it neither improves nor degrades parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: deploy a process definition over SOAP using importProcess and releaseProcess. It distinguishes itself from the sibling fluig_process_import_xml by targeting servers without v2 REST route, making the purpose specific and actionable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly identifies when to use this tool: as an alternative to fluig_process_import_xml when the v2 REST route is unavailable. This provides clear context, though it does not elaborate on when not to use it or other alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return a form's customisation events (displayFields, validateForm, enableFields, ...) with their source.
| Name | Required | Description | Default |
|---|---|---|---|
| documentId | Yes | Form documentId. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must disclose behavioral traits. It mentions returning events with source but does not state that it is read-only, whether it requires specific permissions, or any potential side effects. Minimal information beyond the basic function.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence that is clear and to the point. No wasted words; includes examples to clarify content. Perfectly concise for the information provided.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Simple tool with one parameter and no output schema. Description covers what it returns (events with source) and gives examples, which is adequate for basic understanding. However, lacks context about event source format, limits, or usage notes that could enhance completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only one parameter (documentId) with schema coverage 100%. Description adds no extra meaning beyond the schema's 'Form documentId.' Baseline score of 3 is appropriate as schema already fully describes the parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states verb 'Return', resource 'form's customisation events', and provides specific examples (displayFields, validateForm, enableFields). This distinguishes it from sibling tools like fluig_form_list or fluig_form_full which handle different aspects of forms.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. Does not mention prerequisites, context (e.g., form must exist), or cases where another tool would be more appropriate. Agent has to infer usage from name and description alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return the text content of one file of a form.
| Name | Required | Description | Default |
|---|---|---|---|
| version | Yes | Form version. | |
| fileName | Yes | File name. | |
| documentId | Yes | Form documentId. |
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 only states the tool returns text content but does not disclose behavioral traits such as required permissions, file size limits, encoding, error handling, or what happens if the file does not exist. For a file-reading operation, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of 11 words, which is concise. However, it could be slightly more informative without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description does not explain the return format (e.g., plain text string). For a simple file read, it partially covers the basics but lacks error context and result details. With many sibling tools, more context would help.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents each parameter. The description adds that the returned content is text but does not enhance parameter meaning beyond the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns the text content of one file from a form. It uses a specific verb ('Return') and resource ('text content of one file of a form'). It distinguishes from siblings like fluig_form_files, which likely lists files.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool vs alternatives like fluig_form_files (for listing). No prerequisites, exclusions, or context for usage are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the file names (HTML/JS/CSS/images) that make up a form.
| Name | Required | Description | Default |
|---|---|---|---|
| documentId | Yes | Form documentId. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description fully bears the burden of behavioral disclosure. The description states it 'list file names' but does not disclose potential failure modes (e.g., invalid documentId), whether the operation is read-only (likely but not explicit), or any side effects. It lacks depth for a tool with no annotation safety net.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no unnecessary words. It efficiently conveys the core purpose and file types. Every word earns its place, making it highly concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has one parameter, no output schema, and no annotations, the description is minimally adequate. It states the action and the resource types. However, it lacks details on the output format (e.g., list of strings, hierarchy), error scenarios, or any behavioral nuances, leaving some gaps for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with one parameter (documentId) having a basic description 'Form documentId.' The tool description adds no additional meaning beyond the schema, so the baseline score of 3 applies. The description does not clarify the format or constraints of documentId.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'list' and the resource 'file names that make up a form'. It specifies the types of files (HTML/JS/CSS/images), which adds specificity. However, it does not differentiate from sibling tools like fluig_form_file or fluig_form_full, which could also relate to form files.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided. There is no mention of when to use this tool vs alternatives (e.g., fluig_form_file for a single file), no prerequisites, and no exclusions. The agent must infer usage solely from the tool name and description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read a whole form: metadata, every file and every event. Do this before editing or publishing.
| Name | Required | Description | Default |
|---|---|---|---|
| version | Yes | Form version. | |
| documentId | Yes | Form documentId. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully communicates that this is a read-only operation ('Read a whole form'). It does not mention performance implications or any potential side effects, but the lack of contradictory annotations and clear read intention justifies a 4.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences that immediately convey the purpose and usage context. Every word is necessary and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While there is no output schema, the description explicitly states the return contents (metadata, files, events), which is sufficient for a read operation. It does not specify pagination or limits, but for a comprehensive read of a form, the description is largely complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters adequately. The description does not add extra meaning or context about the parameters beyond what is in the schema, earning the baseline score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Read', the resource 'a whole form', and specifies what is included: metadata, every file, and every event. This distinguishes it from sibling tools like fluig_form_events or fluig_form_files that handle specific subsets.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The instruction 'Do this before editing or publishing' provides clear context for when to use the tool. It implies that more targeted tools exist for specific parts, though it does not explicitly name alternatives or state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List forms (documentId, version, description, dataset). Optional substring filter.
| Name | Required | Description | Default |
|---|---|---|---|
| filter | No | Substring to filter by (optional). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. It mentions the filter capability and returned fields but lacks details on pagination, ordering, error handling, or the effect of no filter. For a list operation, such information is important for correct invocation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one sentence that concisely states the action, returned fields, and optional filter. There is no unnecessary text, and it is front-loaded with the essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one parameter and no output schema. The description covers the basic functionality but does not specify the response format (e.g., array of objects) or behavior when no filter is applied. For a list tool, additional completeness would be beneficial but is not severely lacking.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the single parameter. The description adds 'substring' context, which matches the schema description. No additional meaning beyond the schema is provided, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'List' and the resource 'forms', and specifies the returned fields (documentId, version, description, dataset). It also mentions the optional substring filter, which helps distinguish from other form-related tools like fluig_form_full (which likely retrieves a single form). However, it does not explicitly contrast with siblings, so a score of 4 is appropriate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives, such as fluig_form_full or fluig_dataset_list. It does not specify prerequisites, limits, or when not to use it. The description only states the basic function with minimal context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Publish a form as a new (revertible) version. The API REPLACES the whole set, so send ALL files and events — read it with fluig_form_full first and change only what you need.
| Name | Required | Description | Default |
|---|---|---|---|
| files | Yes | [{fileName, content}] — ALL files. | |
| events | No | [{eventId, eventDescription}] — ALL events. | |
| documentId | Yes | Form documentId. | |
| datasetName | Yes | Name of the form dataset. | |
| versionOption | No | 0 = keep version, 2 = new version (default 2). | |
| cardDescription | Yes | Form description. | |
| descriptionField | No | Descriptor field (may be empty). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It clearly discloses the destructive replace behavior and that it creates a revertible version. Missing details like authentication requirements or rate limits, but the behavioral core is well communicated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with no filler. The key action and critical constraint are front-loaded. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 7 parameters, no output schema, and no annotations, the description is largely complete: it explains the replace semantics, prereq read, and revertibility. Lacks error/return info, but for a mutation tool the essential behavior is covered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds essential meaning beyond the schema: it explains that files and events must include ALL (not just changes), and that versionOption default is 2. This is critical context that the schema does not provide.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool publishes a form as a new revertible version, with a specific verb and resource. It distinguishes from siblings like fluig_form_full by advising to read first.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use (publish new version) and provides critical guidance: the API replaces the whole set, so send all files/events, and read with fluig_form_full first. No alternatives are named but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the server's global events.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must fully disclose behavior. It only states that the tool lists events, but does not clarify scope (e.g., all events or filtered), potential side effects, or return structure. For a list tool, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no wasted words. It is front-loaded and clear, though it could be slightly more informative without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (no parameters, no output schema), but the description is too sparse. It does not mention what information is returned (e.g., event names, IDs, timestamps) or how the list is ordered. More context would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters and 100% coverage, so the description has no param details to add. The baseline score of 3 is appropriate; the description does not add or omit meaningful param information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'List' and explicitly identifies the resource as 'the server's global events'. It clearly distinguishes this tool from its sibling 'fluig_globalevent_save', which performs a write operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives, such as other event-related tools. The description does not include any conditions, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create or update a global event.
| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes | JavaScript source. | |
| eventId | Yes | Global event id. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries full burden for behavioral disclosure. It only states 'Create or update' without explaining side effects, idempotency, permissions, or error cases. Minimal transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no wasted words. It is appropriately sized for a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite low complexity, the description lacks essential context such as return value, error handling, or effect on existing events. Given no output schema, this is a gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The tool description adds no extra meaning beyond what the schema already provides for the two parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose ('Create or update a global event') with a specific verb and resource, distinguishing it from the listing tool fluig_globalevent_list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives (e.g., when to create vs update, or versus other save tools). The agent must infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check authentication and session against the configured Fluig server.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It mentions checking authentication and session, suggesting a network call, but it does not disclose what happens on failure, what the response looks like, or any side effects. Minimal behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that efficiently conveys the tool's purpose with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has low complexity (no parameters, no output schema), but the description is still slightly incomplete. It does not hint at the output format (e.g., success/failure, status) or error handling, which would help the agent interpret results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, so schema coverage is 100%. The description adds no param info as none are needed. Baseline 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it checks authentication and session, which is a specific verb-resource combination. It distinguishes from sibling tools that perform data operations on datasets, forms, processes, etc., making it unique as a connectivity and auth check.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used to verify authentication and session, but it does not explicitly state when to use it versus alternatives (e.g., before other operations), nor does it provide exclusions or alternative tool references.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the states an instance currently sits on.
| Name | Required | Description | Default |
|---|---|---|---|
| processInstanceId | Yes | Instance number. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description bears full burden. It implies a read operation but does not confirm read-only behavior, permissions, or side effects. No behavioral details beyond the basic action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded, no wasted words. However, it is extremely terse and could benefit from slight expansion.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description is incomplete. It does not explain return format, pagination, or what 'states' entails. Sibling tools hint at context but are not leveraged.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single parameter, and the description adds no extra meaning beyond 'Instance number.' Baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it lists the states an instance currently sits on, using a specific verb and resource. It distinguishes from siblings like fluig_process_states by specifying 'active' and 'currently'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool over alternatives such as fluig_process_states or fluig_process_states_detail. The description does not mention prerequisites or conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return the current thread of a given state sequence of an instance.
| Name | Required | Description | Default |
|---|---|---|---|
| stateSequence | Yes | State sequence. | |
| processInstanceId | Yes | Instance number. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description alone must disclose behavioral traits like read-only nature, side effects, or authentication requirements. It only states what the tool returns, with no such details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no wasted words. It is front-loaded and efficient, though it could be slightly expanded to add value without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of an output schema and moderate complexity, the description is incomplete. It does not explain what the 'current thread' is, what the return value looks like, or how this tool fits into the broader process workflow.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (both parameters have descriptions). The tool description adds no additional meaning beyond the schema, so it meets the baseline but does not enhance understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (Return) and the resource (current thread), with context (of a given state sequence of an instance). It is not a tautology and distinguishes the tool's focus on 'thread' from sibling process tools, though it could be more specific about what a thread represents.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like fluig_process_history or fluig_process_states. There is no mention of prerequisites or scenarios where the tool should or should not be used.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the attachments of an instance.
| Name | Required | Description | Default |
|---|---|---|---|
| processInstanceId | Yes | Instance number. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The verb 'List' implies a read-only operation, which is appropriate, but without annotations, the description should explicitly state that it is non-destructive. No mention of pagination, limits, or error handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence. Every word is necessary and contributes to the purpose. No redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one required parameter, no output schema), the description is minimally adequate. However, it does not indicate what the attachment list contains (e.g., file names, URLs) or any expected behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, the schema already describes the parameter adequately. The description adds no further meaning beyond what is in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List') and the resource ('attachments of an instance'). It is specific enough to distinguish from sibling tools like fluig_process_history, but could be more precise by specifying the instance type (e.g., 'process instance').
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as fluig_process_history or fluig_process_card_get. The description lacks context about prerequisites or scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the processes the logged-in user is allowed to start.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden but only states the basic purpose. It does not disclose any behavioral traits such as caching, scope restrictions, or return format. The simplicity of the tool (no parameters, likely read-only) makes this adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence starting with a verb, containing no unnecessary words. It conveys the core functionality efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given there is no output schema, the description should hint at what the returned data contains (e.g., process IDs, names). Without that, the agent may not know how to use the result. The description is minimally complete but lacks output details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, and the schema fully covers them (100% coverage). According to the rubric, zero parameters warrant a baseline of 4. The description adds no parameter info, but none is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (List) and resource (processes) with a specific scope (the logged-in user is allowed to start). This sharply distinguishes it from sibling tools like fluig_process_start (starts a process) and fluig_process_search (searches processes).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for checking which processes can be started before calling fluig_process_start, providing clear context. However, it does not explicitly state when not to use it or mention alternatives like fluig_process_available_users.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Users eligible to receive the task at a given state of a running instance.
| Name | Required | Description | Default |
|---|---|---|---|
| state | Yes | State number. | |
| threadSequence | No | threadSequence (optional, default 0). | |
| processInstanceId | Yes | Instance number. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries full burden. It does not mention read-only nature, authentication, pagination, or any side effects. The description is minimal and adds little beyond the name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single concise sentence with no wasted words. All information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description lacks details about return format, error conditions, or required permissions. It is functional but incomplete for an AI agent to use confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents all parameters. The description adds no extra meaning beyond what the schema provides, earning a baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly indicates the tool retrieves users eligible for a task at a specific state of a running instance. The verb is implicit but the resource and context are specific, distinguishing it from siblings like fluig_process_available_users_start.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives (e.g., fluig_process_available_users_start or other fluig_process_* tools). The description only states what it does, not when it is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Users eligible to receive the first task when starting a process.
| Name | Required | Description | Default |
|---|---|---|---|
| state | Yes | Initial state number. | |
| processId | Yes | Process id. | |
| threadSequence | No | threadSequence (optional, default 0). |
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 reveals the tool returns eligible users for the first task when starting a process, but does not disclose read-only nature, authentication needs, or output format. Minimal depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that is concise, front-loaded with the key purpose, and contains no waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
At 3 parameters, no output schema, and no annotations, the description is adequate for a simple tool but lacks details on output structure or any constraints. It meets the minimum viable standard.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description does not add extra meaning beyond the schema; the context of 'first task start' is already captured in the tool description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns 'Users eligible to receive the first task when starting a process', which is a specific verb+resource combination. It distinguishes from the sibling 'fluig_process_available_users' by specifying 'first task' and 'starting a process'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when starting a process to get the first task's eligible users, but provides no explicit guidance on when to use this vs alternatives like 'fluig_process_available_users' or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
WRITE. Cancel/close a running instance.
| Name | Required | Description | Default |
|---|---|---|---|
| confirm | Yes | Must be true to actually perform the operation. | |
| cancelText | Yes | Reason for cancelling. | |
| processInstanceId | Yes | Instance number. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It only says 'WRITE' indicating mutation, but lacks details on side effects, reversibility, permissions, or error conditions. The cancellation behavior is under-specified.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise with two short sentences, no wasted words. However, it could be slightly expanded to include more context without losing brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description lacks information about return values, success/failure indicators, and error conditions. Since there is no output schema, the description should compensate but does not. Given the low complexity, some additional detail is expected.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and each parameter has a clear description in the schema. The tool description does not add additional meaning beyond what the schema already provides, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool cancels/closes a running instance, using specific verb 'cancel/close' and resource 'running instance'. It distinguishes from sibling tools like process_start and process_move.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for cancellation but provides no explicit guidance on when to use versus alternatives or when not to use. Sibling tools exist but no comparison is made.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read the WHOLE card of a running instance as {field: value}. Do this before fluig_process_move, because moving REPLACES the card.
| Name | Required | Description | Default |
|---|---|---|---|
| processInstanceId | Yes | Instance number. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It states 'Read', implying no side effects, but does not explicitly confirm read-only behavior, auth needs, or error conditions. It adds minimal behavioral context beyond the verb itself, achieving only baseline transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, no redundancy. The first sentence states purpose, the second provides essential ordering guidance. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read tool with one parameter and no output schema, the description adequately covers purpose, usage context, and basic return format hint ('{field: value}'). It lacks details on pagination or field scope, but given the tool's simplicity, it is nearly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter processInstanceId has a schema description ('Instance number.') that is basic but present, achieving 100% schema coverage. The tool description does not add additional meaning to the parameter. Per guidelines, with high schema coverage, baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool reads the whole card of a running instance as field-value pairs. It uses a specific verb ('Read') and resource ('whole card'), and distinguishes from a potential sibling (fluig_process_card_value) by emphasizing 'WHOLE'. The ordering hint with fluig_process_move further clarifies its specific role.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises to use this tool before fluig_process_move because moving replaces the card. This provides a specific when-to-use scenario, though it doesn't discuss other alternatives or when not to use it. The guidance is clear and contextually relevant.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read a single card field of a running instance.
| Name | Required | Description | Default |
|---|---|---|---|
| cardFieldName | Yes | Form field name. | |
| processInstanceId | Yes | Instance number. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It indicates a read operation (safe), but lacks details about side-effects, authorization, or return behavior beyond the implied reading.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence with no extraneous information. Every word adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with 2 parameters and no nested objects or output schema. However, the description does not clarify return format or behavior for missing fields, leaving some ambiguity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with both parameters having descriptions. The description adds no extra meaning beyond the schema, meeting but not exceeding the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (Read), the resource (a single card field), and the context (of a running instance). It effectively distinguishes this tool from the sibling fluig_process_card_get, which likely reads multiple fields.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool over alternatives like fluig_process_card_get, nor does it mention prerequisites or typical use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
WRITE. Replace the SVG diagram of a process version. Required after changing the topology in the XML, otherwise the published drawing no longer matches the flow.
| Name | Required | Description | Default |
|---|---|---|---|
| svg | Yes | SVG content of the diagram. | |
| confirm | No | Must be true to actually perform the operation. | |
| processId | Yes | Process id. | |
| processVersion | Yes | Process version. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It labels the operation as 'WRITE' (mutation) but does not mention side effects, reversibility, or that the confirm parameter must be true. The description is minimal beyond purpose.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise: one sentence plus a brief note. It is front-loaded with 'WRITE' and immediately states the purpose. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 4 parameters, no annotations, and no output schema, the description provides the key usage context but omits important behavioral details like the need for confirm=true or what happens on success/failure. It is partially complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds no additional information about parameters; it does not explain the confirm parameter's role or the format of svg, processId, or processVersion.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'Replace the SVG diagram of a process version' with a clear verb and resource, and provides context about when it is required (after XML topology change), distinguishing it from sibling process tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives a clear precondition: 'Required after changing the topology in the XML, otherwise the published drawing no longer matches the flow.' It implies when to use but does not explicitly state when not to or mention alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read the source of a process event from the event_proces table. Legacy path — prefer fluig_process_events_xml, which reads the authoritative definition.
| Name | Required | Description | Default |
|---|---|---|---|
| version | Yes | NUM_VERS. | |
| eventName | Yes | Event name, e.g. "beforeTaskSave" or "servicetask71". | |
| processCode | Yes | Fragment of COD_DEF_PROCES. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the source table and that the tool reads non-authoritative data. However, it does not describe the return format or pagination, but for a simple legacy read tool, the behavior is reasonably transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with no redundant wording. The first sentence states the purpose, the second adds usage guidance, making it efficient and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read tool with no output schema, the description adequately covers what it does, its legacy status, and the preferred alternative. It does not explain error conditions or result format, but given the context and sibling guidance, it is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the description does not add extra meaning beyond the schema. The parameter descriptions in the schema are already informative, so the description meets the baseline expectation without needing to elaborate further.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Read'), the resource ('source of a process event from the event_proces table'), and distinguishes from the sibling tool fluig_process_events_xml by labeling this as legacy and directing to the preferred alternative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly guides when to use ('legacy path') and specifies the preferred alternative (fluig_process_events_xml) for the authoritative definition, making the usage decision unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
DEPRECATED, WRITE. Patch a process event in place in the event_proces table, keeping a backup of the previous source. Bypasses server-side validation and does not create a new version — prefer fluig_process_event_set_xml.
| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes | New source. | |
| confirm | Yes | Must be true to actually perform the operation. | |
| version | Yes | NUM_VERS. | |
| eventName | Yes | Event name. | |
| processCode | Yes | COD_DEF_PROCES. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses key behaviors: it bypasses server-side validation, does not create a new version, keeps a backup of the previous source, and requires confirm to be true. No annotations provided, so description carries full burden and does so well.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise: one sentence with three clear statements, front-loaded with deprecation and purpose. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers deprecation, alternative, key behavioral traits. However, does not describe return values or error conditions, which would be helpful especially with no output schema. Still fairly complete for a deprecated tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description does not add any additional semantics beyond the schema descriptions, which are brief but present.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it patches a process event in the event_proces table, specifying it is a write operation. It distinguishes from the alternative fluig_process_event_set_xml by noting it bypasses validation and does not create a new version.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly marks as deprecated and recommends fluig_process_event_set_xml as the preferred alternative, giving clear when-not-to-use guidance. This is sufficient for a deprecated tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
WRITE. Set the source of a process event through the supported path: export the definition XML, patch the event, re-import. Produces a NEW, revertible version and passes server-side validation. Try dryRun=true first.
| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes | COMPLETE source of the event (function name(...) { ... }). | |
| dryRun | No | Validate the patch without sending anything. | |
| confirm | No | Must be true to actually perform the operation. | |
| eventId | Yes | Event name, e.g. "beforeStateEntry", "afterTaskCreate", "afterProcessFinish". | |
| release | No | Publish the new version in the same call (default false). | |
| version | No | Source version to export (optional). | |
| processId | Yes | Process id. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses key behaviors: produces a new revertible version, passes server-side validation, and is a write operation (WRITE). Since no annotations are provided, the description carries the full burden. It adds context about the export-patch-reimport lifecycle but could mention permissions or error handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two succinct sentences with no wasted words. Front-loaded with 'WRITE' for immediate clarity. Every sentence earns its place, providing core action, workflow, and a usage tip.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 7 parameters, no output schema, and no annotations, the description covers the main workflow and validation but misses expected output/response format and what happens on failure. The agent lacks information on return values or error handling. Could be more complete for a complex write tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 100% coverage with descriptions for all 7 parameters. The description adds value by explaining the overall workflow (export-patch-reimport), which gives context to parameters like version (source version to export) and code (complete source). This helps the agent understand how parameters relate. Still, the description could elaborate on confirm's role.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Starts with 'WRITE' and clearly states the verb (set) and resource (process event source). Describes the exact workflow (export-patch-reimport), distinguishing it from siblings like fluig_process_event_set. The title also includes '_xml' hinting at XML-based operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly recommends trying dryRun=true first, which is a strong usage guideline. However, it does not compare with alternative tools (e.g., fluig_process_event_set) or specify when not to use this tool. Lacks explicit when-to-use vs. alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read process events (beforeStateEntry, afterTaskCreate, afterProcessFinish, ...) with their source, straight from the definition XML. This is the authoritative copy — no add-on widget and no database access needed.
| Name | Required | Description | Default |
|---|---|---|---|
| version | No | Specific version (optional). | |
| processId | Yes | Process id. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must carry behavioral info. It states it's a read operation from XML without database access, implying non-destructive behavior. However, lacks details on authentication, rate limits, or exact return format.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with purpose, no redundant or unnecessary information. Highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool is simple (2 params, no output schema). Description explains what it does and its source. Could be slightly more explicit about return format, but still adequate given context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with both parameters described. The description does not add extra parameter semantics beyond what the schema already provides, so baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the verb 'Read' and the resource 'process events', and specifies it reads from the definition XML. It distinguishes from siblings by noting it's the 'authoritative copy' and doesn't use add-on widgets or database.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool (when authoritative XML source is needed) and highlights advantages over alternatives, but does not explicitly state when not to use or name alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Download a process definition as .ecm30.xml. It contains everything: activities (ProcessState), transitions (ProcessLink), fields and the source of every process event.
| Name | Required | Description | Default |
|---|---|---|---|
| version | No | Specific version (optional; defaults to the current one). | |
| processId | Yes | Process id. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral traits. It only describes the output content but omits important details such as whether the operation is read-only, if authentication is required, rate limits, or error handling for invalid process IDs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences; the first states the action and output format, the second details content. Every sentence adds value, and the key information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 parameters, no output schema, no annotations), the description adequately explains what the exported file contains. However, it lacks guidance on how the download is delivered (e.g., binary response) and error scenarios, which would make it slightly more complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with both parameters described. The description adds no additional semantics beyond what the schema provides (version and processId). Baseline 3 is appropriate since the schema is comprehensive.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool downloads a process definition as a specific file format (.ecm30.xml) and lists the contained elements (activities, transitions, fields, event sources). This clearly communicates the verb and resource, and the detail helps distinguish it from sibling tools like fluig_process_import_xml.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide explicit guidance on when to use this tool versus alternatives (e.g., import, version management). The purpose is clear but no when-not-to-use or exclusion criteria are given, so the agent must infer usage context from the tool name and siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return the documentId of the form bound to a process.
| Name | Required | Description | Default |
|---|---|---|---|
| processId | Yes | Process id. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It does not disclose whether the operation is read-only, requires authentication, or has side effects. The description is minimal and fails to add behavioral context beyond the return value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that directly states the tool's purpose with no unnecessary words or information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (one parameter, no output schema), the description provides basic functionality. However, it lacks details on return type, error conditions, or usage scenarios, making it only minimally complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a description for processId ('Process id.'). The tool description does not add any additional meaning or clarification beyond what the schema already provides, so it meets the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns the documentId of the form bound to a process, using a specific verb and resource. However, it does not differentiate from sibling tools like fluig_process_card_get, which may have overlapping functionality.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. The description lacks context about prerequisites or exclusions, leaving the agent to infer usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Full movement history of an instance: who moved it, when, from and to which activity, with comments.
| Name | Required | Description | Default |
|---|---|---|---|
| processInstanceId | Yes | Instance number. |
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 describes the output (movement history with specific fields) but does not disclose whether it is read-only, requires authentication, or has rate limits. The description is adequate but could be more transparent about behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that efficiently communicates the tool's purpose, front-loading the key information. Every word is necessary, and no waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the single required parameter and no output schema, the description is adequate but incomplete. It does not specify whether the history is returned as a list, or if there are pagination or sorting options. Missing details on response structure reduce completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with the parameter processInstanceId described as 'Instance number.' The description adds no additional meaning beyond this, so baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool provides the full movement history of a process instance, specifying details such as who moved it, when, from which activity to which, and comments. This verb+resource+scope effectively distinguishes it from sibling tools like fluig_process_start or fluig_process_move.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for retrieving historical movements of an instance, but it does not explicitly state when to use it versus alternatives or when not to use it. Among many process-related siblings, no exclusions or alternatives are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return the flow diagram of a process (URL or base64, depending on the server).
| Name | Required | Description | Default |
|---|---|---|---|
| processId | Yes | Process id. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the burden. It discloses the conditional output format (URL or base64) but lacks details on authentication, side effects, or what the flow diagram entails.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded with the verb and resource, no extraneous words. Efficient and clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool with no output schema, the description covers the basic function and output format but omits usage context and behavioral details, leaving some gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the single parameter processId, which has a basic description. The tool description adds no further meaning beyond that, meeting the baseline expectation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns the flow diagram of a process, specifying the output format (URL or base64) which distinguishes it from sibling tools that handle other process data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like fluig_process_card_get or fluig_process_history. The description simply states what it does without usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
WRITE, STRUCTURAL. Deploy a process definition (.ecm30.xml) over the v2 REST API. One call replaces the SOAP sequence createWorkFlowProcessVersion -> importProcess -> releaseProcess. Validate with a round trip (export, then import unchanged) before trusting it.
| Name | Required | Description | Default |
|---|---|---|---|
| xml | Yes | Contents of the .ecm30.xml (root <list><ProcessDefinition>). | |
| isNew | No | true creates a new process; false (default) adds a version to an existing one. | |
| formId | No | documentId of the form to bind (optional). | |
| confirm | No | Must be true to actually perform the operation. | |
| release | No | Publish the version in the same call. | |
| processId | Yes | Process id. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It labels the tool as WRITE and STRUCTURAL, mentions replacing a SOAP sequence, and warns about trusting after validation. This adequately discloses the operational nature and potential pitfalls.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with 'WRITE, STRUCTURAL.' No extraneous information; every word is efficient and purposeful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 6 parameters and no output schema, the description covers the core purpose, file type, API replacement, and validation tip. It is sufficiently complete, though it could elaborate on success/failure outcomes.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so each parameter has a description in the schema. The description adds context like 'Contents of the .ecm30.xml' and the confirm flag requirement, but does not significantly expand beyond the schema. Baseline is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as deploying a process definition XML file, specifying the file type (.ecm30.xml) and the API (v2 REST). It distinguishes from the SOAP sequence and sibling tools like fluig_process_export_xml.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It states that one call replaces the SOAP sequence, indicating when to use this tool over alternatives. It also advises validating with a round trip before trusting, providing practical guidance. However, it does not explicitly exclude cases or compare to other deploy tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
WRITE. Save and move an existing instance. cardData REPLACES the card — send every field that must survive or it is wiped. Call fluig_process_take first if the task belongs to a pool.
| Name | Required | Description | Default |
|---|---|---|---|
| cardData | No | {field: value} — ALL fields (replaces the card). | |
| comments | No | Comment (optional). | |
| managerMode | No | Move as process manager (requires the manager role). | |
| choosedState | Yes | Target state (number of the next node or gateway). | |
| colleagueIds | No | Next assignees (optional). | |
| processInstanceId | Yes | Instance number. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility for disclosing behavior. It correctly labels the tool as a WRITE operation and highlights the destructive card replacement behavior. However, it does not mention other side effects (e.g., triggers events, permission requirements) or whether the operation can be undone. The transparency is adequate but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long and front-loaded with the critical 'WRITE' tag. Every word serves a purpose—no fluff, no redundancy. It is maximally concise while still conveying essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the key danger (card replacement) and a prerequisite (call take first). The schema handles parameter details, and there is no output schema, so return format is not expected. While it explains 'save and move', it could briefly describe the outcome (e.g., instance transitions to next state) but overall it provides sufficient context for a tool with this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so parameters are already described. The description adds significant value for 'cardData' by emphasizing it replaces the entire card and must include all surviving fields. For other parameters, the description adds nothing beyond the schema. Baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it is a WRITE operation that saves and moves an existing instance. It uses specific verbs ('save', 'move') and resource ('existing instance'), effectively distinguishing it from siblings like fluig_process_take (taking a task) and fluig_process_start (starting a new instance).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes explicit guidance: 'Call fluig_process_take first if the task belongs to a pool.' It also warns that cardData replaces the card entirely, instructing to send every field that must survive. This helps the agent decide when and how to use the tool, though alternatives are not exhaustively listed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search processes by text. Set favorite=true to return only the user's favourites.
| Name | Required | Description | Default |
|---|---|---|---|
| content | Yes | Search text. | |
| favorite | No | Favourites only (optional). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully convey behavioral traits but only states that it searches and supports a favorite filter. It omits details like whether results are paginated, sorted, or limited, and does not confirm read-only behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two clear sentences with no extraneous words. Every part earns its place: the action and the parameter hint.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of output schema, the description should explain what is returned (e.g., list of process IDs, full objects). It does not address output format, sorting, or limits, leaving the agent underinformed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema coverage is 100%, baseline 3. The description adds value by explaining the favorite parameter's effect ('return only the user's favourites'), which is beyond the schema's 'Favourites only (optional)'. The content parameter is sufficiently described.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action ('Search processes by text') and resource ('processes'). It distinguishes from siblings like fluig_process_get or fluig_process_move, as this is a text-based search tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus other process-related siblings (e.g., fluig_process_available, fluig_process_start). It only hints at the favorite parameter within the tool, not alternatives or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
WRITE. Start a process instance. cardData holds the form fields; choosedState is the target state when the start activity completes. The configured user needs the start role.
| Name | Required | Description | Default |
|---|---|---|---|
| cardData | No | {field: value} — send ALL fields; the API replaces the card, it does not merge. | |
| comments | No | Comment (optional). | |
| processId | Yes | Process id. | |
| choosedState | Yes | Target state (number of the next node or gateway). | |
| colleagueIds | No | Next assignees (optional). | |
| completeTask | No | true (default) completes and moves; false parks on the start activity. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It includes upfront 'WRITE' to denote mutation, and provides critical behavioral details: cardData replaces (not merges) and completeTask behavior (true moves, false parks). It could additionally describe error handling or async behavior, but the given details are substantial.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, each earning its place: verb+resource, key parameter explanations, and a prerequisite role requirement. It is front-loaded with the action type and purpose, with no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 6 parameters and no output schema, the description covers core functional aspects (write operation, replacement behavior, state targeting, completion mode). It lacks return value or error details but is adequate for invocation given good schema documentation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 adds value beyond the schema by clarifying that cardData must send all fields (no merge) and explaining completeTask's default and effect. This enhances understanding of parameter behavior.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Start a process instance' with a specific verb and resource. It also explains key parameters cardData and choosedState, distinguishing this tool from siblings like move, take, or cancel which handle different lifecycle actions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions the prerequisite that 'The configured user needs the start role,' but does not provide explicit guidance on when to use this tool versus alternative process tools. Usage context is implied by the naming and verb, but no exclusions or alternatives are listed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the valid target states (choosedState) from an instance's current state.
| Name | Required | Description | Default |
|---|---|---|---|
| processId | Yes | Process id. | |
| processInstanceId | Yes | Instance number. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only states the read operation; it does not clarify side effects, authentication requirements, or any constraints. The description adds minimal behavioral context beyond the obvious.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of 14 words, very concise and to the point. No unnecessary information is present.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of an output schema, the description should explain the return format (e.g., list of state identifiers). It omits this crucial context, making it incomplete for a tool that merely lists states.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers 100% of parameters with basic descriptions. The tool description adds no additional meaning beyond what the schema already provides. Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool lists valid target states ('choosedState') from an instance's current state. It uses a specific verb and resource, and hints at its purpose relative to siblings like 'fluig_process_active_states'. However, it does not fully differentiate from related tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives such as 'fluig_process_active_states' or 'fluig_process_states_detail'. The description does not mention any prerequisites or context for use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Target states with name and type from the current state — richer than fluig_process_states.
| Name | Required | Description | Default |
|---|---|---|---|
| processId | Yes | Process id. | |
| threadSequence | No | threadSequence (optional, default 0). | |
| processInstanceId | Yes | Instance number. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must cover behavioral traits. It states the output includes name and type from current state, suggesting a read operation, but does not disclose any side effects, permissions, or error conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence that conveys purpose and differentiation with no wasted words. Highly concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description is adequate but lacks detail on what 'richer' entails beyond name and type. Could mention output format or additional fields.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so parameters are already documented. The description adds no extra meaning beyond the schema, thus baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly indicates the tool provides target states with name and type from current state, and explicitly distinguishes it from sibling 'fluig_process_states'. However, missing an explicit verb like 'get' or 'retrieve'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly compares to sibling tool by stating 'richer than fluig_process_states', implying this tool should be used when more detailed state information is needed. No explicit when-not-to-use, but sufficient for differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
WRITE. Take ownership of a task — required for pool/role tasks before moving them.
| Name | Required | Description | Default |
|---|---|---|---|
| processInstanceId | Yes | Instance number. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the burden. It discloses the WRITE nature and precondition, but lacks details on error conditions, idempotency, or permission requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the operation type (WRITE) and conveys purpose and usage in a compact manner with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (1 param, no output schema, no annotations), the description covers the essential information: what it does and when to use it. Slightly incomplete in not mentioning return values or error outcomes, but adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the parameter description 'Instance number' is sufficient. The tool description adds no extra meaning beyond what the schema provides, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (take ownership) and the resource (task), and distinguishes from sibling tools like fluig_process_move and fluig_process_cancel by specifying it's a prerequisite for moving pool/role tasks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states 'required for pool/role tasks before moving them', providing clear context on when to use. However, it doesn't mention when not to use or alternatives for task types that aren't pool/role.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Active version of a process (SOAP).
| Name | Required | Description | Default |
|---|---|---|---|
| processId | Yes | Process id. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description does not disclose side effects, authentication requirements, or any behavioral traits beyond mentioning 'SOAP', which is a protocol detail rather than behavioral transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
At 4 words, it is too terse. Clarity is sacrificed for brevity. No structure or front-loading of critical information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one parameter and no annotations or output schema, the description is insufficient. It does not clarify return value, behavior, or how the 'active version' concept is used.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with one parameter (processId) described as 'Process id.' The description adds no extra meaning beyond the schema, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description states 'Active version of a process (SOAP)', which indicates it deals with the active version but does not specify whether it retrieves, sets, or manages it. The verb is implicit. While not a tautology, it lacks specificity and does not differentiate from sibling tools like fluig_process_versions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. Siblings such as fluig_process_versions or fluig_process_version_withdraw exist, but the description provides no context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
DESTRUCTIVE. Delete a process version (withdraw it first if released). Deleting the LAST version removes the entire process definition.
| Name | Required | Description | Default |
|---|---|---|---|
| confirm | No | Must be true to actually perform the operation. | |
| version | No | Version (optional; omitted means latest). | |
| processId | Yes | Process id. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully bears the burden of behavioral disclosure. It clearly labels the operation as 'DESTRUCTIVE', warns about the need to withdraw first, and explains the side effect of deleting the last version. This provides excellent transparency for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, using two short sentences that front-load the critical warning ('DESTRUCTIVE') and cover the essential usage constraints. Every word adds value with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's destructive nature and lack of output schema, the description adequately covers preconditions (withdraw first), full behavior (delete version, remove process definition if last), and the required 'confirm' parameter. However, it does not describe return values or error scenarios, which would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage; each parameter's purpose is already explained. The description does not add new parameter-level meaning beyond what the schema provides, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (delete a process version) and specifies the resource. It distinguishes from sibling tools like 'fluig_process_version_withdraw' by noting the prerequisite to withdraw if released, and highlights an exceptional case (deleting the last version removes the entire process definition).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context: the tool is for deleting a process version after withdrawing if released. It implies when to use (after withdraw) but does not explicitly state when not to use or name alternative tools (e.g., 'fluig_process_version_withdraw' for withdrawal only). The guidance is helpful but limited.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the versions of a process (number, bound form, whether it is still in edition). Use before withdrawing or deleting a version.
| Name | Required | Description | Default |
|---|---|---|---|
| processId | Yes | Process id. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description indicates a read-only listing operation, but with no annotations, additional behavioral details (e.g., permissions, return format, pagination) are missing. The mention of 'whether it is still in edition' adds some context, but overall transparency is adequate but not thorough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with purpose and return fields, followed by usage guidance. No wasted words, excellent conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given low complexity (one parameter, no output schema), the description is nearly complete. It explains what is listed and when to use it, though a bit more detail on the return format would make it perfect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (one parameter well described). The description does not add extra meaning beyond 'process id', so it meets the baseline without adding value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists versions of a process and specifies the returned information (number, bound form, edition status). It distinguishes itself from sibling tools like fluig_process_version, fluig_process_version_withdraw, etc., which deal with single versions or actions on versions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises to use the tool before withdrawing or deleting a version, providing clear guidance on when to invoke it. However, it does not mention alternatives or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
WRITE. Withdraw a process version — the inverse of release, and how a bad deploy is rolled back. Also mandatory before deleting a released version.
| Name | Required | Description | Default |
|---|---|---|---|
| confirm | No | Must be true to actually perform the operation. | |
| version | No | Version (optional; omitted means latest). | |
| processId | Yes | Process id. |
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 discloses the operation is a write ('WRITE') and is mandatory before deletion, but does not detail side effects, reversibility, permissions, or error conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, starts with 'WRITE' for immediate intent, and every sentence adds value. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 3 parameters and no output schema. The description covers purpose and usage context but lacks details about return values, possible errors, or specific version resolution behavior. It is adequate but could be more comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 not add meaning beyond what the schema already provides for parameters like 'confirm' and 'version'. No additional clarity is given.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('withdraw') and resource ('process version'), clearly stating the action. It distinguishes from siblings by noting it is the inverse of release and a rollback mechanism, mandatory before deletion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool: to roll back a bad deploy and as a prerequisite before deleting a released version. It implies alternatives ('inverse of release') but lacks explicit when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Escape hatch: authenticated GET against any path of the Fluig API.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Path, e.g. /ecm/api/rest/ecm/dataset/loadDataset?datasetId=x |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It states 'authenticated GET,' indicating a read operation, but lacks details on response format, error handling, permission requirements for different paths, or any potential side effects. The description is minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single focused sentence that efficiently communicates the core purpose. It is not overly verbose, but could be slightly more structured without becoming lengthy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema or annotations, the description should provide context on response expectations and error handling. It omits these, leaving the agent without a clear understanding of what to expect from the call.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a single 'path' parameter and an example. The description does not add additional parameter semantics beyond what the schema provides, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool as an 'escape hatch' for authenticated GET requests against any Fluig API path. It uses specific verb (GET) and resource (any path), and explicitly distinguishes from sibling tools by framing it as a generic fallback.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The term 'escape hatch' implies usage when other specific tools (e.g., fluig_dataset_list) are insufficient, but no explicit when to use or when not to use is given. With many sibling tools, more explicit guidance on alternatives would be beneficial.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Escape hatch: authenticated POST against any path. body is a JSON string; set form=true for x-www-form-urlencoded.
| Name | Required | Description | Default |
|---|---|---|---|
| body | No | Body (JSON string). | |
| form | No | Send as x-www-form-urlencoded. | |
| path | Yes | Path. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description mentions authentication and request format but does not cover response details, error handling, or what happens on invalid paths. Given no annotations, it carries the full burden but leaves gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core purpose, and every word adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For an escape hatch tool with no output schema or annotations, the description gives minimal but functional guidance. It lacks details on return values, error scenarios, and rate limits, leaving some uncertainty.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so schema already documents all parameters. The description adds some context: body is a JSON string and form=true sets x-www-form-urlencoded. This is useful but not extensive.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Escape hatch: authenticated POST against any path', which is a specific verb-resource pair. It distinguishes itself from sibling tools by being a generic POST endpoint, while siblings are specific for datasets, forms, processes, etc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The term 'escape hatch' implies it is for cases where no specific tool exists. It also provides guidance on using form=true for x-www-form-urlencoded. However, it does not explicitly state when not to use it or compare to the related get tool (fluig_rest_get).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
WRITE. Run INSERT/UPDATE/DELETE against the TOTVS RM database. Note that the RM datasource is often configured read-only, in which case the supported write path is the RM DataServer API instead.
| Name | Required | Description | Default |
|---|---|---|---|
| sql | Yes | INSERT/UPDATE/DELETE statement. | |
| confirm | Yes | Must be true to actually perform the operation. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It labels the tool as 'WRITE' and mentions potential read-only constraints, but lacks details on destructive side effects, authentication requirements, or rate limits. Information is adequate but not thorough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no wasted words: the first states the core purpose, the second adds a crucial usage caveat. Information is front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with only two parameters, no output schema, and no nested objects, the description covers the essential behavior and edge case (read-only datasource). Minor omission: return value not described, but not critical.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the description adds little beyond the schema's parameter descriptions. It reiterates that sql is for INSERT/UPDATE/DELETE and confirms the confirm flag, but no additional semantics or format details are provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'WRITE. Run INSERT/UPDATE/DELETE against the TOTVS RM database.', specifying both the verb (write operations) and the resource (TOTVS RM database). This distinguishes it from sibling read tools like fluig_rm_db_query.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly advises when not to use this tool ('RM datasource is often configured read-only') and directs to an alternative ('RM DataServer API instead'), providing clear context for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run a SELECT directly against the TOTVS RM database, when Fluig has a datasource for it. Read-only (SELECT/WITH only).
| Name | Required | Description | Default |
|---|---|---|---|
| sql | Yes | SELECT ... (SELECT/WITH only). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It correctly declares read-only behavior ('Read-only (SELECT/WITH only)'), which is critical. However, it fails to disclose potential behaviors such as error handling, connection requirements, or what happens with invalid SQL, which would be beneficial for an AI agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no filler. The description is front-loaded with the core function and constraints. Every word serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the key aspects (what, where, read-only) but lacks information about return format or output behavior. Given there is no output schema, the description should at least indicate what the tool returns (e.g., rows, error messages) to be fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with one parameter (sql). The description echoes the schema's description ('SELECT ... (SELECT/WITH only)'), adding no new semantic details beyond confirming allowed SQL types. The baseline of 3 is appropriate as schema already documents the parameter adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it runs SELECT queries against the TOTVS RM database, distinguishing it from write tools like fluig_rm_db_exec and generic queries like fluig_db_query. The verb 'Run a SELECT directly' and specification 'Read-only (SELECT/WITH only)' provide precise purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions a prerequisite ('when Fluig has a datasource for it') but does not provide explicit guidance on when to use this tool versus alternatives like fluig_db_query or when not to use it. The read-only constraint is clear, but no exclusions or alternatives are named.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Query TOTVS RM through the stored-SQL bridge dataset: a registered statement code plus branch (CODCOLIGADA) and application (CODAPLICACAO). Read-only. The columns the statement returns must be declared.
| Name | Required | Description | Default |
|---|---|---|---|
| branch | No | CODCOLIGADA (default "0"). | |
| fields | Yes | Columns the statement returns. | |
| params | No | Extra statement parameters as {NAME: value}. | |
| application | No | CODAPLICACAO (default "G"). | |
| statementCode | Yes | RM statement code, e.g. "WS.247". |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description declares read-only behavior, but lacks details on potential side effects, error modes, rate limits, or return format. With no annotations, it partially meets the transparency burden.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences front-load the purpose and add a constraint on column declaration. No redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the explanation of parameters and the read-only nature covers the core usage. However, the 'params' object could be more detailed, and error handling or defaults are omitted.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 adds value by explaining branch as CODCOLIGADA, application as CODAPLICACAO, and specifying that fields are required columns. This goes beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool queries TOTVS RM via stored-SQL bridge, requiring a statement code, branch, and application. It specifies the resource and action effectively, distinguishing it from sibling tools like fluig_db_query.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions 'Read-only' but does not provide explicit guidance on when to use this tool versus alternatives (e.g., fluig_db_query, fluig_rest_get). Usage context is implied but not detailed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List configured user replacements — who answers for whom, and for how long. Explains why a task landed on someone else.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum records (optional). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It states the tool 'lists' (read behavior) and 'explains' (adds context), which is helpful but does not disclose potential side effects, authorization requirements, or whether data is real-time or cached. Given the simplicity, it's adequate but not thorough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, each conveying essential information. It is front-loaded with the main action ('List configured user replacements') and immediately provides what the user gets (who, how long, why). No redundant words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with one optional parameter and no output schema, the description covers the conceptual output well. It could be enhanced by mentioning whether the list is paginated or sorted, but overall it sets accurate expectations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with the single optional 'limit' parameter described. The description adds no extra meaning beyond the schema, so baseline score of 3 applies. No parameter details in the description itself.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it lists configured user replacements, explaining who answers for whom and for how long, and why a task landed on someone else. It uses a specific verb ('List') and resource ('user replacements'), distinguishing it from all sibling tools, as no other tool focuses on this functionality.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or when-not-to-use guidance is given. However, the purpose is specialized enough that usage is implied: you would use it to understand user replacements or task delegation. No alternatives are mentioned, but no sibling tool duplicates this function, so the lack of explicit guidelines is a minor gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check whether the optional FluiggersWidget add-on is installed. Not required: the fluig_process_*_xml tools cover process events on a stock server.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but description clearly indicates a read-only check operation. It could mention idempotency or safety, but the current text is sufficiently transparent for a simple check tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no fluff. First sentence states purpose, second gives usage guidance. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters, no output schema, and no annotations, the description is fully adequate. It covers what the tool checks and provides usage alternatives.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters in schema, so description adds no parameter details. Baseline 4 applies, and the description appropriately adds context about the add-on being optional.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description explicitly states the tool checks for an optional add-on, using verb 'check' and resource 'FluiggersWidget add-on'. It distinguishes from siblings by noting that fluig_process_*_xml tools cover process events on a stock server, making the purpose unique and clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description explicitly states when this tool is not required and directs to alternative tools (fluig_process_*_xml). This provides clear guidance on usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read a process's events through the FluiggersWidget add-on. Requires the widget; fluig_process_events_xml does not.
| Name | Required | Description | Default |
|---|---|---|---|
| version | Yes | Process version. | |
| processId | Yes | Process id. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the read nature and the dependency on a specific widget. However, it could mention potential error scenarios if the widget is missing, but given no annotations, this is acceptable for a read tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences that front-load the purpose and key differentiator. No unnecessary words or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the description covers purpose and usage, it lacks any information about the return value or structure of the events. With no output schema, the agent would benefit from knowing what the response contains.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for both parameters. The tool description does not add any extra information about parameters beyond what the schema provides, so baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Read' and the resource 'process events', distinguishing it from the sibling tool 'fluig_process_events_xml' by mentioning the widget requirement.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly provides when to use this tool (if the FluiggersWidget add-on is available) and when to use the alternative (fluig_process_events_xml if not), making the selection decision clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
WRITE. Set a process's events through the FluiggersWidget add-on. Requires the widget; fluig_process_event_set_xml does not and is versioned.
| Name | Required | Description | Default |
|---|---|---|---|
| events | Yes | [{name, contents}] | |
| version | Yes | Process version. | |
| processId | Yes | Process id. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility for behavioral disclosure. It only indicates the operation is a write and mentions a dependency, but lacks details on side effects, idempotency, permissions, return behavior, or error conditions. This is insufficient for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loading the key information ('WRITE') and stating the action and dependency. Every sentence adds value, with no redundant or vague language.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (updates process events via a widget), the description lacks critical context such as whether events are replaced or merged, return values (no output schema exists), and consequences of missing the widget. The contrast with the sibling is helpful but incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with each parameter having a basic description. The description adds that events are '[{name, contents}]', providing slight structural hint. However, it does not compensate further, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with 'WRITE' indicating mutation, states 'Set a process's events through the FluiggersWidget add-on,' clearly specifying verb, resource, and scope. It also distinguishes itself from sibling 'fluig_process_event_set_xml' by noting it does not require the widget and is versioned.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions a prerequisite ('Requires the widget') and contrasts with an alternative tool that does not need the widget and is versioned. This provides clear context for when to use this tool, though it does not explicitly state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.1.0fluig_dataset_deletefluig_dataset_getfluig_dataset_listfluig_dataset_runfluig_dataset_savefluig_dataset_structurefluig_db_queryfluig_deploy_listfluig_deploy_processfluig_form_eventsfluig_form_filefluig_form_filesfluig_form_fullfluig_form_listfluig_form_savefluig_globalevent_listfluig_globalevent_savefluig_pingfluig_process_active_statesfluig_process_actual_threadfluig_process_attachmentsfluig_process_availablefluig_process_available_usersfluig_process_available_users_startfluig_process_cancelfluig_process_card_getfluig_process_card_valuefluig_process_diagram_setfluig_process_event_getfluig_process_event_setfluig_process_event_set_xmlfluig_process_events_xmlfluig_process_export_xmlfluig_process_formidfluig_process_historyfluig_process_imagefluig_process_import_xmlfluig_process_movefluig_process_searchfluig_process_startfluig_process_statesfluig_process_states_detailfluig_process_takefluig_process_versionfluig_process_version_deletefluig_process_version_withdrawfluig_process_versionsfluig_rest_getfluig_rest_postfluig_rm_db_execfluig_rm_db_queryfluig_rm_queryfluig_user_replacementsfluig_workflow_checkfluig_workflow_events_getfluig_workflow_events_updateTools are grouped by domain (dataset, form, process, etc.) and actions are distinct. Some overlap exists between process event reading tools (fluig_process_events_xml vs fluig_workflow_events_get, fluig_process_event_get) but descriptions clarify differences. Overall, agents can reliably distinguish tools.
All tools follow a strict 'fluig_domain_action' snake_case pattern. Domain and action naming is consistent (list, get, save, delete, etc.). No mixing of styles or unexpected verbs.
56 tools is relatively high for an MCP server. While each tool has a distinct purpose, the breadth may overwhelm agents. The scope justifies many tools but the count borders on excessive.
The tool set provides comprehensive coverage of Fluig's core domains: datasets (CRUD + schema), forms (read, save, metadata), processes (start, move, cancel, history, attachments, versions, export/import, event management), and RM integration. No obvious gaps for typical workflows.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Connect, monitor, and control AI agents — tasks, approvals, schedules, and governance.
Give your AI agents the tools to build, manage, and run automation workflows.
Build, validate, deploy — HTTP APIs, cron jobs, webhooks and MCP tools — from your AI client.
Build, validate, and deploy multi-agent AI solutions from any AI environment.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/alucardigo/fluig-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
