FlexSim MCP Server

Overview Schema Source Related Servers Discussions Admin

flexsim_fluid_tank

Create a FluidTank in a FlexSim model, specifying a unique name, 3D position, and optional initial/max content. Overwrite existing tanks if needed.

Instructions

Create one FluidTank in the FlexSim window (window backend only).

Clase verificada: Object.create("FluidTank") (AGENTE_FLEXSIM.md sec 4;
crea ademas FluidTicker). Con prefijo ("Fluid::FluidTank") NO existe
(misma seccion). Otras clases de fluidos existen en la biblioteca pero
no estan probadas: listarlas a mano por flexsim_execute_script con
library().find("?fluid") (patron AGENTE_FLEXSIM.md sec 4 para
"?fixedresources"; grupo "fluid" listable segun sec 4).

Metodo (receta AGENTE_FLEXSIM.md sec 9): Object.create + name unico +
setLocation + return o.name verificado.

Propiedades: MaxContent esta verificado SOLO para Processor/Queue
(AGENTE_FLEXSIM.md sec 6); para tanques NO se asume. Si se pasan
initial_content/max_content se intenta o.setProperty + o.getProperty
roundtrip ("MaxContent" para max_content, "InitialContent" para
initial_content, ambos NO verificados en FluidTank) y si el valor leido
no coincide se devuelve warning "propiedad no efectiva en FluidTank"
SIN fallar la creacion. Propiedades verificadas en el repo (sec 6):
InterArrivalTime/ProcessTime/SetupTime/MaxContent/BatchSize; cualquier
otra solo via roundtrip con aviso.

Args:
    name: nombre unico (solo letras, digitos, _).
    x, y, z: posicion en metros (default 0, 0, 0).
    initial_content: contenido inicial deseado (opcional, roundtrip).
    max_content: capacidad deseada (opcional, roundtrip).
    overwrite: si True destruye el objeto previo con el mismo nombre.

Returns JSON {name, created, level, note} (+ warnings/error). level es
{initial_content, max_content} con los valores roundtrip que resolvieron
a numero (None cuando no se pidieron o no fueron efectivos); level es
null cuando no se pidio ninguno.

Input Schema

Name	Required	Description	Default
`params`	Yes

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Oct 5, 2026

TDQS

A4.1/5.0

Behavior4/5

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

No annotations, so the description carries the full burden and does well: overwrite destroys the prior same-named object, property application uses a set/get roundtrip that never fails creation but emits a "propiedad no efectiva en FluidTank" warning, and MaxContent/InitialContent are explicitly unverified for tanks. It omits duplicate-name-without-overwrite behavior and 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.

Conciseness3/5

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

Purpose is front-loaded, but the body is bloated with repeated references to AGENTE_FLEXSIM.md sections, mixed Spanish/English, and meta-commentary about verification provenance that could be compressed. The Args/Returns blocks are efficient, but the middle prose is not.

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?

Covers creation recipe, property roundtrip behavior, warning semantics, and the return JSON shape {name, created, level, note} including when level is null. With an output schema present, return documentation is more than sufficient; minor gaps remain around error/duplicate handling.

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 description coverage is 0%, yet the description documents every arg: name uniqueness and character rules, x/y/z in meters with default 0, initial_content/max_content as optional roundtrip values, and overwrite semantics. This adds substantial meaning the bare 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?

Opens with a specific verb+resource: "Create one FluidTank in the FlexSim window", plus a scoping caveat (window backend only). The resource is unique enough that an agent can tell it apart from generic creators like flexsim_create_objects or flexsim_create_any, though no sibling is named explicitly.

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?

Gives real context: verified class Object.create("FluidTank"), the non-existent prefixed variant, and the fallback of listing other fluid classes via flexsim_execute_script with library().find("?fluid"). It clarifies scope but does not state when-not-to-use this tool versus the generic creation tools.

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

Deploy Server