FlexSim MCP Server

Overview Schema Source Related Servers Discussions Admin

flexsim_agv_route

Dispatch an AGV route over multiple stops, with optional load/unload mission, to simulate material transport in FlexSim. Runs the model and confirms delivery via stats.

Instructions

Dispatch one AGV route: single TS with one TRAVEL per stop, or full mission with load/unload (window only). # AGV-mision

Receta mision completa (AGV-mision): 1) flexsim_add_agv_loop crea el loop
(CPs + StraightPath piloto sin conectar); 2) flexsim_agv_link_path /
flexsim_agv_connect une tramos y CPs con objectconnect verificado por
_flow_path (BFS de outObjects); 3) esta tool con solo stops mueve el
transporter en vacio por la red (un TRAVEL por stop, UNA sola TS); 4) con
load_item+load_from+unload_to anade en LA MISMA TS: TRAVEL stops... +
LOAD(item, load_from) + TRAVEL unload_to + UNLOAD(item, unload_to) con un
solo dispatch; 5) con confirm=true + run_after=true corre hasta run_to_time
y confirma por stats (delivered = stats.input de unload_to > before).

API (fuente, la misma ya usada en flexsim_run_transport y _dispatch_trip,
sin inventar task types: solo TRAVEL/LOAD/UNLOAD): createemptytasksequence
(dispatcher, priority, preempting) (Commands.xml:6854-6858, ej. XML:6858) +
inserttask(ts, type, involved1, involved2) (Commands.xml:7951-7955, ej.
XML:7955 "inserttask(ts, TASKTYPE_TRAVEL, current, NULL);") +
dispatchtasksequence(ts) (Commands.xml:7094-7099, ej. XML:7099);
TASKTYPE_TRAVEL=8 a objeto (FlexsimDefs.h:215; XML:7955/:6498),
TASKTYPE_LOAD (XML:7751), TASKTYPE_UNLOAD solo en headers locales
(FlexsimDefs.h:210 / allobjects.h:290), PREEMPT_NOT en FlexsimDefs.h:262.
Item por las 3 vias de flexsim_run_transport (tal cual, load_from/item,
scan de hijos por nombre); stats con `Object k = Model.find(..);
return k.stats.input.value;` (AGENTE_FLEXSIM.md sec 7); corrida con el
patron de flexsim_run_to_time (Run Speed slider
node("MAIN:/project/exec/step").value = 1000 + stoptime(t) +
applicationcommand("run") + espera getrunstate()==0 + return Model.time,
sin resetmodel porque borraria la TS en curso).

Args:
    transporter: TaskExecuter/AGV que ejecuta (dueno de la TS).
    stops: 2-6 objetos/ControlPoints en orden de visita.
    priority: prioridad de la TS (default 1).
    run_after: si True, corre el modelo hasta run_to_time tras despachar.
    run_to_time: segundos simulados para la corrida (default 120).
    load_item: flowitem a mover (None = ruta solo-stops; con mision los
        tres juntos son obligatorios).
    load_from: objeto/estacion donde se carga (involved2 del LOAD).
    unload_to: objeto/estacion donde se descarga (TRAVEL destino +
        involved2 del UNLOAD; se leen sus stats).
    confirm: si True (y run_after=true) confirma delivered por stats.
    confirm_timeout_s: presupuesto wall-clock para la espera getrunstate
        cuando confirm=true (default 600; el target simulado sigue siendo
        run_to_time).

Returns JSON {dispatched, transporter, stops, priority, flexsim_result,
console, delivery} (+ model_time y note="ruta ejecutada, verificar stats"
con run_after=true). delivery es null en ruta solo-stops; en mision es
{item, item_path, load_from, unload_to, confirm, delivered (bool|null),
input_before, input_after}.
Limites (AGV-mision): TRAVEL a objeto (inserttask(ts, TASKTYPE_TRAVEL,
destino, NULL), XML:7955) es el que usa la red AGV; TRAVELTOLOC=9 es a
coordenadas (no red) y FREETRAVEL/TRAVELTO no existen como TASKTYPE: no se
usan. Semantica LOAD/UNLOAD (involved1=item, involved2=estacion) no esta en
Commands.xml (remite al QuickReference): si FlexSim la rechaza se devuelve
su error real con dispatched:false. dispatched=true es TS aceptada, no ruta
completada ni entrega. delivered=true es input de unload_to incrementado
tras correr (evidencia, no trazabilidad del item); sin corrida (run_after
false) o sin confirm no se afirma nada (delivered null). Mision parcial
(alguno de load_item/load_from/unload_to sin los otros dos) es error sin
despacho.
Ejemplo multi-waypoint 3 CPs + mision con confirm (sintaxis exacta # T5):
    {"params": {"transporter": "AGV1", "stops": ["CP1", "CP2", "CP3"],
        "load_item": "Box1", "load_from": "Queue1", "unload_to": "Sink1",
        "confirm": true, "run_after": true, "run_to_time": 660}}

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

A4.2/5.0

Behavior5/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 thoroughly: dispatched=true means only that the TS was accepted (not route completion or delivery), delivered=true is an input-increment signal rather than item traceability, no resetmodel is called because it would erase the in-flight TS, and a rejected LOAD/UNLOAD returns the real FlexSim error with dispatched:false. These are exactly the behavioral traits an agent needs.

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 first sentence is well front-loaded, but the body is a very long wall of mixed Spanish/English text salted with API source citations (Commands.xml line numbers, FlexsimDefs.h, XML:7955, etc.) that do not help an agent select or invoke the tool. Much of the material is reference detail rather than decision-relevant guidance.

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 multi-mode AGV tool it covers the critical decision points, limits, error paths and return semantics, and it even restates return fields despite an output schema existing. The main remaining gap is not positioning itself against flexsim_agv_deliver, which appears semantically adjacent.

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

Parameters5/5

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

Schema coverage is 0% (only titles/defaults), so the description must compensate, and it does: the Args block explains each parameter's role beyond the schema, e.g. load_from is the involved2 of the LOAD, unload_to is the TRAVEL destination plus UNLOAD involved2 and the source of the delivery stats, and the three mission params are mutually required. This adds real semantics the structured schema lacks.

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 sentence gives a specific verb+resource+scope: dispatch one AGV route, either a stop-only TS or a full load/unload mission, window backend only. It also places itself in the AGV workflow relative to flexsim_add_agv_loop and flexsim_agv_link_path. It does not, however, differentiate itself from the close sibling flexsim_agv_deliver, so it falls short of full sibling disambiguation.

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

Usage Guidelines4/5

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

The numbered recipe states explicitly when to use which mode: steps 3 (stops only), 4 (adds load/unload), 5 (confirm + run), plus the rule that a partial mission (some of load_item/load_from/unload_to) is an error. Clear usage context is provided, but no when-not-to-use or alternative-selection guidance against sibling tools.

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

Deploy Server