Skip to main content
Glama
FelipeDiazAimar

FlexSim MCP Server

by FelipeDiazAimar
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

flexsim_experimenter_run

Reports Experimenter scenarios without launching a run, returning a read-only workaround and planning guidance when no verified starter exists.

Instructions

Report Experimenter scenarios without launching (no verified starter).

SOLO LECTURA (nunca escribe): R1 no hallo comando de arranque en
Commands.xml (solo resetexperiment XML:5633-5636 y endreplication
XML:9572-9576, ninguno lanza), asi que esta tool NO ejecuta
resetexperiment/endreplication ni toca nodos del Experimenter en
escritura. Reutiliza el patron de la vecina flexsim_experimenter_status
(Model.find + scan por clase conteniendo "experiment" + subnodos) para
listar escenarios y devolver el camino honesto alternativo. Paso previo
recomendado: flexsim_experiment_plan (lee variables por escenario para
flexsim_run_experiments).

Args:
    name: nombre del Experimenter (default Experimenter1).
    timeout_s: deadline aceptado por firma (60-3600, default 600); sin
        arranque verificado no hay poll que esperar, se devuelve tal cual.

Returns JSON {started:false, reason, name, exists, scenarios, workaround,
    timeout_s, note} (y hint cuando no existe: crearlo a mano en Toolbox).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
paramsNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

B3.2/5.0
Behavior4/5

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

With no annotations, the description carries the burden well: it is explicit about SOLO LECTURA, that it never calls resetexperiment/endreplication, touches no Experimenter nodes in write mode, and returns started:false. It explains the reason for the no-launch behavior (no verified starter).

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 description is lengthy and mixes Spanish rationale with line-referenced justification (XML:5633-5636) that is noise for an agent. The essential fact (does not launch) is buried after several sentences.

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 needn't be explained, though the description lists the exact JSON keys. It is honest about its limitations and suggests a workaround when the Experimenter does not exist, making it complete enough for an agent.

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

Parameters3/5

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

Schema description coverage is 0%, and the description covers both params: name (default Experimenter1) and timeout_s (60-3600, default 600, accepted by signature but not used for polling). It adds meaning, but the 0% coverage baseline would suggest more, and timeout_s is essentially vestigial.

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

Purpose3/5

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

The name and first sentence suggest launching a scenario runner, but the body immediately negates this: it only reports scenarios and never launches. The true purpose (read-only reporting) only emerges from reading the full text, which is confusing given the name.

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 recommends a prior step (flexsim_experiment_plan) and points to flexsim_experimenter_status as a pattern, and mentions the honest alternative path. But there is no explicit when-to-use-this vs when-to-use-run_experiments guidance.

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