FlexSim MCP Server

Overview Schema Source Related Servers Discussions Admin

flexsim_pf_add_activity

Adds a ProcessFlow activity object at model level for FlexSim models and returns its name and attachment status; it does not attach it to the flow.

Instructions

Add one ProcessFlow activity object at model level (window backend only).

Vecinas: flexsim_processflow_ping (crea ProcessFlow::ProcessFlow + inventario)
y flexsim_processflow_inventory (solo lectura: clase + in/out counts).

Catalogo minimo (NO verificado: construir actividades no se probo,
AGENTE_FLEXSIM.md sec 3c): solo Object.create("ProcessFlow::ProcessFlow")
esta verificado (sin prefijo "ProcessFlow" da `is not a valid class name`).
Por eso activity_class es LIBRE (default "ProcessFlow::Delay") y estos
candidatos llevan prefijo "ProcessFlow::" por analogia, pendiente de
verificacion: "ProcessFlow::Delay", "ProcessFlow::Source",
"ProcessFlow::Sink", "ProcessFlow::Process" (o sin prefijo? incierto).

La lista exacta sale de la biblioteca via:
  execute_script: treenode g = library().find("?processflow"); string s = "";
    for (int i = 1; i <= g.subnodes.length; i++) s = s + g.subnodes[i].name + ","; return s;
(patron AGENTE_FLEXSIM.md sec 4 para "?fixedresources"; grupos verificados
incluyen "processflow"). flexsim_list_tree lista el arbol del modelo
(path="Model"), no la biblioteca, asi que para clases use execute_script.

Metodo (solo comandos verificados): Object.create(activity_class) +
o.name + o.setLocation(x, y, 0) + return o.name (receta AGENTE_FLEXSIM.md
sec 9). NO parenta al flow: en este repo no hay forma verificada de mover
un objeto como subnodo del ProcessFlow (grep: solo Tools.create,
createcopy bajo Tools/GlobalTables y Object.create; ningun movetomodel/
parent verificado), asi que se crea a nivel modelo y se devuelve
attached:false.

Args:
    flow: ProcessFlow existente (debe existir via Model.find).
    activity_class: clase libre (default "ProcessFlow::Delay").
    name: nombre unico de la actividad.
    x, y: posicion (z=0).

Returns JSON {activity, flow, activity_class, attached:false,
    note:"attach al flow pendiente de verificacion"}.
Limite: attached siempre false; el attach al flow queda pendiente.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`params`	Yes

Output Schema

TableJSON Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Oct 5, 2026

TDQS

A3.6/5.0

Behavior4/5

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

With no annotations, the description carries the full burden and does so substantively: it discloses that the object is NOT parented to the flow, that attached is always false, the exact command sequence used, and which steps remain unverified. This is unusually candid about side effects and uncertainty, though it stops short of covering auth/permissions or error behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness2/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The content is useful but heavily bloated and bilingual, with repeated hedging about verification status and an embedded script snippet. The purpose is front-loaded, but the middle sprawls across uncertainty notes that could be compressed substantially.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists so return values need not be explained, yet the description supplies them anyway. Combined with the limitation disclosure (attach pending, attached:false) and full parameter coverage, an agent has enough to call this correctly; only error/permission behavior is missing.

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

Parameters4/5

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

Schema description coverage is 0% – the individual properties (flow, name, x, y, activity_class) have no descriptions. The prose compensates: it explains flow must exist via Model.find, that name must be unique, that x/y are position with z=0, and gives the default and candidate values for activity_class. That is a meaningful lift over the bare schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb+resource+scope: 'Add one ProcessFlow activity object at model level (window backend only)'. It also names and characterizes the neighboring tools (flexsim_processflow_ping, flexsim_processflow_inventory), though these are not true alternatives to this operation, so sibling differentiation is partial rather than clean.

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

Usage Guidelines3/5

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

It states a key constraint ('window backend only', activity always created at model level) and routes the agent to execute_script for discovering valid classes. However, it never says explicitly when to choose this tool over the other pf_* siblings (pf_attach, pf_connect, pf_run_tokens); usage is implied rather than stated.

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

Deploy Server