Skip to main content
Glama

flexsim_person_create

Create one people object in the FlexSim window at a chosen position, with optional class and overwrite, returning verified success or the real error.

Instructions

Create one people object in the FlexSim window (window backend only).

Via recomendada ahora (# LIB-people): flexsim_library_list +
flexsim_create_any; esta tool queda como caso simple de una sola clase.

OJO: "Person" NO esta verificado como clase creable. El grupo ?people
es listable (AGENTE_FLEXSIM.md sec 4) pero sin prueba de creacion en el
repo. Por eso person_class es LIBRE (default "Person"): se intenta
Object.create(person_class) + name + setLocation + return verificado
(receta AGENTE_FLEXSIM.md sec 9) y si FlexSim responde error/nombre
distinto se devuelve created:false con el error real, sin mentir exito.

Clases candidatas: grep 2026-09-26 de people/Person/Staff/Patient en
AGENTE_FLEXSIM.md y mcp_server/flexsim_mcp.py solo hallo el grupo
`people` listable (sec 4), sin clases candidatas verificadas; por eso
NO se sugieren 2-3 clases aqui (no hay de donde sacarlas sin inventar).

Para listar candidatas reales hacerlo a mano por flexsim_execute_script
con: treenode g = library().find("?people"); string s = ""; for (int i
= 1; i <= g.subnodes.length; i++) s = s + g.subnodes[i].name + ", ";
return s; (patron AGENTE_FLEXSIM.md sec 4 para "?fixedresources").

Args:
    person_class: clase libre del grupo people (default "Person",
        no verificado).
    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, class, created} o {name, class, created:false,
error, hint} con hint "listar grupo ?people con
library().find(\"?people\") por execute_script". Nunca miente exito.

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
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: it discloses that 'Person' is unverified as a creatable class, that failure returns created:false with the real error and never fakes success, and that overwrite 'destruye el objeto previo con el mismo nombre' (destructive semantics). It also reveals the internal create recipe and the window-only backend constraint.

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 purpose is front-loaded, but the body is bloated with process meta-commentary: grep history dated 2026-09-26, repeated AGENTE_FLEXSIM.md section citations, and an inline execute_script code snippet for manually listing candidates. These do not earn their place in a tool definition an agent must parse at selection time, and the Spanish/English mix adds friction.

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?

Given no annotations and a nested schema with 0% property descriptions, the description is thorough about behavior, failure modes, and arguments. An output schema exists, yet it still restates the return shape, which is redundant but harmless. The main completeness gap is that no verified candidate class is offered, which the description honestly explains rather than inventing.

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 describes every argument: person_class (free/unverified, default 'Person'), name (letters/digits/_ only), x/y/z (position in meters, default 0,0,0), and overwrite (destroys any prior object with the same name). It adds units and destructive meaning beyond the bare schema, though x/y/z are treated only briefly.

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 opening line states a specific verb and resource ('Create one people object in the FlexSim window') and immediately scopes it ('window backend only'). It also explicitly names the sibling alternative (flexsim_library_list + flexsim_create_any) that this tool competes with, so an agent can distinguish it without opening the schema.

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 gives a clear recommended path ('Via recomendada ahora (# LIB-people): flexsim_library_list + flexsim_create_any') and positions this tool as 'caso simple de una sola clase'. That is explicit alternative-routing guidance, though the condition for choosing this tool is stated obliquely rather than as a crisp when/when-not rule.

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