Skip to main content
Glama
FelipeDiazAimar

FlexSim MCP Server

by FelipeDiazAimar
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

flexsim_chart_bind_stat

Inspects candidate nodes for binding a FlexSim chart to a statistic and source object without writing changes, returning a node map and manual GUI steps since automatic binding is not implemented.

Instructions

Request a chart/statistic binding: inspect only, never writes (window or Python backend).

Camino honesto y reversible (ver bloque P3): grep del 2026-09-26 en repo y
Commands.xml (collector 0 hits, addcolumn 0, addrow solo Table.addRow
deprecated XML:9011, Chart 5 hits sin binding) NO hallo patron verificable
de binding por Statistics Collector, asi que NO escribe en ningun nodo del
chart (semantica desconocida; escribir titulo/nota seria decorativo y
confunde) y devuelve el mapa de nodos candidatos (misma inspeccion de R1)
+ guia de pasos manuales en GUI + "binding automático no implementado".

Args:
    chart: chart destino (Model.find debe resolverlo).
    statistic: Object.stats.<group>.<field>, debe estar en ALLOWED_STATS
        (p. ej. "content.value"; ver AGENTE_FLEXSIM.md sec 7).
    source_object: objeto que produce el dato (Model.find debe resolverlo).

Returns JSON {chart, statistic, source_object, bound:false, inspected:{kind,
subnodes, variables, data_nodes}, did:[...], did_not:[...], manual_steps,
limits, note} donde did/did_not dicen que hizo y que no. Si chart o
source_object no existen, o statistic es desconocido, devuelve error claro.

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

B3.1/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 so well: it states the tool never writes, that it returns bound:false, enumerates did/did_not actions, and specifies error behavior when chart/source_object are unresolved or statistic is unknown. It also discloses the manual-GUI-steps fallback and stated limits, which is exactly the kind of behavioral context 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 opening sentence is well front-loaded, but the middle is padded with internal audit reasoning (grep date, 'collector 0 hits, addcolumn 0', node-count tallies) that does not help an agent select or call the tool. The bilingual mixing and run-on structure add noise rather than value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/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-value explanation is technically redundant, though the description still restates it. It covers the three args and error cases adequately, but the central ambiguity (tool named 'bind' that does not bind) and the missing routing against sibling tools leave a gap for a tool whose name implies an action it never performs.

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 does: it defines chart and source_object as names that Model.find must resolve, and statistic as an Object.stats.<group>.<field> value that must appear in ALLOWED_STATS with a concrete example ('content.value'). This adds meaning the bare schema lacks.

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 first sentence does state a specific behavior ('inspect only, never writes'), but it frames the tool as 'Request a chart/statistic binding' even though the body concludes binding is not implemented and it only returns candidate nodes. The name 'chart_bind_stat' plus the 'binding' framing conflicts with the actual inspect-only behavior, making it harder to distinguish from the sibling flexsim_chart_inspect.

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

Usage Guidelines2/5

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

There is no explicit when-to-use / when-not-to-use guidance. The reference to 'misma inspeccion de R1' assumes external context, and it never contrasts itself against flexsim_chart_inspect or flexsim_collector_create, which an agent would need to route between these overlapping tools.

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