FlexSim MCP Server

Overview Schema Source Related Servers Discussions Admin

flexsim_pf_connect

Connect two FlexSim ProcessFlow activities with a token line by resolving source and target names and verifying the resulting outObjects link.

Instructions

Connect two ProcessFlow activities with a token line (window backend only).

Los paths de actividades dentro del flow son inciertos, asi que primero
RESUELVE ambos (solo lectura, sin escribir): Model.find("flow/src"),
Model.find("src") (nivel modelo, donde flexsim_pf_add_activity crea) y
scan de subnodos del flow por nombre. Si alguno no resuelve, devuelve error
con los candidatos probados y no escribe nada.

Si resuelve: contextdragconnection(Model.find(from), Model.find(to), "A")
(forma no obsoleta de flujo, como flexsim_connect_objects) y verificacion
outObjects via _last_link (guard length==0, mismo helper de
flexsim_connect_objects).

Args:
    flow: ProcessFlow contenedor (para candidatos "flow/actividad").
    source: actividad origen (nombre corto).
    target: actividad destino (nombre corto).
    verify: comprobar outObjects (default True).

Returns JSON {resolved_from, resolved_to, verified} (+ last_out / error).
Limite: la semantica token de ProcessFlow no esta verificada end-to-end
(sin corrida de tokens de prueba); solo se verifica el enlace outObjects.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`params`	Yes

Output Schema

TableJSON Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Oct 5, 2026

TDQS

A3.7/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 discloses the read-only resolution step first, that it writes nothing on failure, the verification via _last_link with length==0 guard, and candidly flags that ProcessFlow token semantics are NOT verified end-to-end. That limitation disclosure is exactly the kind of behavioral context that adds value. It could still note permission/auth needs or reversibility.

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?

The action is front-loaded, but the description is long, dense, and bilingual, mixing English and Spanish mid-sentence. Several clauses (Model.find candidate probing, _last_link helper) are implementation detail an agent invoking the tool does not need, diluting the signal.

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 an output schema, the description covers resolution strategy, failure behavior, verification, args, return shape, and a known limitation. An output schema exists so return-value explanation is not strictly required. What remains missing is guidance on required permissions or environment prerequisites.

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: an Args section defines flow as the container for 'flow/actividad' candidates, source/target as short names, and verify as the outObjects check defaulting to True. This meaningfully exceeds the bare string/boolean schema, though it does not restate the regex/length constraints.

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?

States a specific verb+resource: 'Connect two ProcessFlow activities with a token line', which an agent can distinguish from object-level siblings. It even names flexsim_connect_objects as the analogue whose behavior it mirrors. It stops short of explicitly differentiating from the closest siblings like flexsim_pf_add_activity or flexsim_pf_attach, so not a full 5.

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?

Usage context is implied: it is for linking ProcessFlow activities and only works on the 'window backend'. There is no explicit when-to-use vs when-not, nor a stated alternative for connecting activities in other backends. The routing guidance is present but must be inferred.

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

Deploy Server