Skip to main content
Glama
FelipeDiazAimar

FlexSim MCP Server

by FelipeDiazAimar
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

flexsim_run_transport

Dispatch a loaded transporter trip from pickup to dropoff, loading and unloading an item, then optionally run the simulation to verify delivery via dropoff stats.

Instructions

Dispatch a loaded trip: TRAVEL pickup, LOAD item, TRAVEL dropoff, UNLOAD (window backend only).

API (fuente): createemptytasksequence(dispatcher, priority, preempting)
+ inserttask(ts, type, involved1, involved2) + dispatchtasksequence(ts),
firmas y ejemplos de Commands.xml:6854-6858, :7951-7955 y :7094-7099;
TASKTYPE_LOAD/TRAVEL vistos en XML:7751/:7955, UNLOAD solo en headers
locales FlexsimDefs.h:210 / allobjects.h:290. Stats del dropoff segun
AGENTE_FLEXSIM.md sec 7. Corrida opcional con el patron de
flexsim_run_to_time (Run Speed slider + stoptime + applicationcommand run
+ espera getrunstate==0). # DLV-delivery

Args:
    transporter: TaskExecuter/Transporter que ejecuta (dueno de la TS).
    item_from: flowitem a mover (Model.find debe resolverlo; para ver los
        items dentro de una estacion usar flexsim_list_tree sobre ella).
    pickup: objeto/estacion donde se carga.
    dropoff: objeto/estacion donde se descarga (se leen sus stats).
    priority: prioridad de la TS (default 1).
    run_after: si True, tras dispatch OK corre el modelo una duracion
        run_seconds y confirma por stats (default False).
    run_seconds: duracion simulada a correr tras despachar (default 600).
    run_speed: Run Speed slider para la corrida (default 1000).

Returns JSON {dispatched, delivered (bool|null si run_after=false),
    transporter, item_from, item_path, pickup, dropoff, priority,
    flexsim_result, dropoff_input_before, dropoff_input_after,
    model_time_end, flexsim_console, limits} o {dispatched:false, error,
    ...} con el error real de FlexSim, sin mentir.
Limits: semantica LOAD/UNLOAD (involved1=item, involved2=estacion) no esta
    en Commands.xml (remite al QuickReference); dispatched=true es TS
    aceptada, no entrega confirmada (requiere correr el modelo).
Receta de verificacion (humano): flexsim_reset + linea con items
    (Source>Queue>...) + flexsim_run_transport con run_after=true
    (run_seconds/run_speed) + flexsim_get_statistics sobre el dropoff
    (input.value debe incrementar; delivered refleja eso).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
paramsYes

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A3.7/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 largely meets it: it discloses the window-backend-only restriction and, critically, that 'dispatched=true es TS aceptada, no entrega confirmada' (accepted task sequence is not a confirmed delivery). It also documents the LOAD/UNLOAD semantic gap and honest error propagation. It omits any note on model-state mutation scope or permissions, keeping it below a 5.

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

Conciseness3/5

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

Purpose, Args, Returns and Limits are clearly sectioned and the key point is front-loaded, but the middle paragraph is a dense wall of source citations (Commands.xml:6854-6858, FlexsimDefs.h:210, allobjects.h:290) that offer little selection or invocation value to an agent. Mixed-language prose further hurts scannability.

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

Completeness4/5

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

For a complex, unannotated mutation tool the description covers purpose, all parameters, the return shape (including the error branch), a limits section, and a verification workflow. An output schema exists, so the return enumeration is somewhat redundant, but the behavioral caveats are the genuinely needed content and are present.

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

Parameters4/5

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

Schema coverage is 0% (properties carry only titles), so the description must compensate, and its Args block does: it defines all eight parameters including defaults, clarifies that item_from must be resolvable via Model.find, and notes that dropoff stats are read. This adds real meaning beyond the schema. The run_speed/run_seconds entries are terse but adequate.

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 opening line states a specific verb+resource and the exact operation sequence: 'Dispatch a loaded trip: TRAVEL pickup, LOAD item, TRAVEL dropoff, UNLOAD (window backend only).' An agent can immediately tell this is a task-sequence dispatch tool rather than a generic run/step tool. It does not explicitly differentiate itself from nearby siblings such as flexsim_agv_deliver, so it stops short of a 5.

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?

The description names flexsim_list_tree as the way to enumerate items inside a station, which is genuine alternative-routing, and the closing 'Receta de verificacion' sketches a workflow with flexsim_reset and flexsim_get_statistics. However, there is no explicit statement of when to use this tool versus flexsim_run, flexsim_run_to_time, or flexsim_agv_deliver, and no when-not conditions; usage must be inferred.

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

Deploy Server

Other Tools