Skip to main content
Glama
FelipeDiazAimar

FlexSim MCP Server

by FelipeDiazAimar
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

flexsim_dashboard_create

Create a dashboard or chart window object in FlexSim with a unique name, type, and position. Supports overwriting existing objects.

Instructions

Create one dashboard/chart window object (window backend only).

Solo creacion + posicion (sin configuracion de series/datos: no hay
setProperty de charts verificado en el repo, asi que no se inventa API).

Clases creables via Object.create verificadas en AGENTE_FLEXSIM.md sec 4:
StatChart, GanttChart, Recorder. Dashboard se acepta por patron pero queda
pendiente de verificacion (si la clase no existe FlexSim devuelve FAIL:create).

Metodo (receta AGENTE_FLEXSIM.md sec 9): Model.find duplicado + destroyobject
si overwrite + Object.create(kind) + o.name + o.setLocation + return o.name.

Args:
    kind: StatChart (default), GanttChart, Recorder o Dashboard.
    name: nombre unico (solo letras, digitos, _).
    x, y, z: posicion en metros (default 0, 0, 0).
    overwrite: si True destruye el objeto previo con el mismo nombre.

Returns JSON {name, kind, created, note} (o {name, kind, created:false, error}).

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

A4.3/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 well: it discloses that overwrite destroys the prior object with the same name, that an unverified class returns 'FAIL:create', and outlines the underlying create/destroy recipe. It omits permission/auth needs and whether a window must already be open.

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

Conciseness4/5

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

The purpose is front-loaded and the following sections are logically ordered (scope, classes, method, args, return). It is somewhat verbose with repeated references to AGENTE_FLEXSIM.md and some implementation detail that an agent may not need for invocation.

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 mutation tool with no annotations, the description covers side effects, error modes, and creation limits, and an output schema exists so return values need not be fully spelled out. It is nearly complete, missing only prerequisites like model state and any auth requirements.

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%, so the description must compensate, and it largely does: it explains units for x/y/z (meters), the overwrite side effect, and the semantics of kind beyond the raw enum. Name constraints are left mostly to the schema pattern, so it stops short of fully replacing the missing schema docs.

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

Purpose5/5

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

The first sentence states a specific verb and resource ('Create one dashboard/chart window object') and immediately scopes it ('window backend only'). This clearly separates it from siblings like flexsim_dashboard_list, flexsim_chart_inspect, and flexsim_chart_bind_stat.

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?

It explicitly says this is creation + positioning only, with no series/data configuration, which tells the agent what this tool does not do. It does not, however, name alternatives (e.g. flexsim_chart_bind_stat) or state preconditions such as requiring an open model, so routing remains partly 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