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

With no annotations, the description carries the full burden and largely meets it: it discloses the window-backend restriction, that the StraightPath is created unconnected, the physical-connection uncertainty, the overwrite-destroys-previous behavior, and verification via return o.name. Only remaining gap is any permission/rate context, which is minor here.

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

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

The English opener is well front-loaded, but the full Spanish restatement duplicates the same content, roughly doubling length without adding information. Appropriately sized for a complex tool, but the bilingual redundancy is waste.

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

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 detail is not required, yet the description still names the JSON keys and states the verification limit. Combined with the disclosed constraints and next-step guidance, an agent has enough to call it correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so the description must compensate, and it does: it documents name_prefix, n_points (2-10), spacing in meters, x/y/z as origin corner, and overwrite's destructive semantics with its default. This adds meaning beyond the bare schema defaults and ranges.

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

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

States a specific verb and resource: creates N ControlPoints in a rectangle plus one StraightPath, scoped as 'window backend only'. That is concrete and separable from siblings, though the sibling differentiation comes via the 'Siguiente paso' section rather than the opening line.

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

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

Names the follow-on tools (flexsim_agv_link_path, flexsim_agv_route) and clarifies what this tool does not do ('NO crea Dispatcher/TE'), giving clear workflow context. It lacks an explicit negative condition, but the sequencing and scope are adequately conveyed.

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

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 that o.size is written but the visual geometry stays ~10 m because Conveyor.length is readonly, that objectconnect alone leaves belt.in at 0, that the transfer chain uses contextdragconnection plus selective port deletion, and how verification walks the outObjects chain via EntryTransfer/ExitTransfer. These are genuine side effects and limitations an agent could not infer. It is docked a point for being noisy and self-repeating rather than a clean behavioral contract.

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

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

The text is long, mixes English and Spanish mid-sentence, and repeats the same ~10 m visual-length caveat three separate times. The critical constraint is buried rather than front-loaded, and parenthetical verification notes ('verificado con screenshots 2026-09-27') add bulk without helping an agent call the tool.

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

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 definition covers what is created, the flow-wiring behavior, the auto-layout rule, and the known limitation. An output schema exists, so return values need not be explained. What is missing is permission/authorization context and a clear statement of prerequisites for the referenced from_object/to_object nodes.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

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: name, length, x, y, z, from_object and to_object are each given meaning, defaults, and the auto-layout derivation (midpoint position, length = dist-1, min 2). It adds real semantics beyond the bare JSON types. It stops short of a 5 because the prose is tangled and the ~10 m caveat is repeated instead of stated once.

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

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

The opening line states a specific verb+resource: 'Add one Conveyor::StraightConveyor leg (window backend only)'. It also clarifies that with from_object/to_object it additionally builds a transfer chain, which is a second responsibility made explicit. It does not, however, differentiate itself from likely-overlapping siblings like flexsim_create_objects or flexsim_connect_objects.

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

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

It gives useful conditional guidance (auto-layout applies only when x/y/length are None and from_object+to_object are supplied) and flags 'window backend only'. But it never states when to reach for this tool versus flexsim_create_objects or flexsim_connect_objects, so the routing decision is left to inference.

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

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

It discloses important behavioral context: 'window backend only', the objectconnect mechanism, the fact that intermediate objects created by FlexSim are reported via the full path, and the verification behavior. It also states limits ('red AGV completa/tasksequences no verificadas'). With no annotations provided, the description must carry the full burden, and while it adds meaningful behavioral details, it does not cover permissions, error conditions, or what happens if the connection fails.

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

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

The description is front-loaded with the core purpose, but it mixes English and Spanish, repeats concepts, and includes parenthetical commentary that interrupts flow. Several sentences are dense and could be tightened without losing meaning. It is adequately sized but not maximally efficient.

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

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given a single-parameter input object (wrapped as params) and an existing output schema, the description need not reiterate return values, yet it still summarizes the JSON return shape. It covers backend constraints, neighbor relationships, and limitations. It misses error-handling behavior and any explicit statement about prerequisite state, so it is not fully complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

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. It does explain path_from, path_to, and verify ('caminar outObjects con BFS buscando path_to'), which adds real meaning beyond bare names. However, it does not fully specify value formats, valid object types, or the meaning of the output fields relative to each parameter, leaving meaningful gaps.

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

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

The description states a specific verb ('Connect') and resource ('two AGV segments'), and explicitly names its siblings/neighbors ('flexsim_add_agv_loop creates ControlPoints + a pilot StraightPath unconnected; this tool closes that gap'). It is much more specific than a generic 'connect objects' tool. However, the bilingual structure and parenthetical qualifiers dilute immediate clarity, keeping it from a 5.

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

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

It clearly positions itself relative to flexsim_add_agv_loop as the step that closes the gap between unconnected segments, and it explicitly excludes Dispatcher/TE and tasksequence creation. However, it does not say when NOT to use this tool versus flexsim_connect_objects or flexsim_agv_link_path, which are close siblings.

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

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

No annotations are supplied, so the description carries the full burden, and it discloses a lot: 'dispatched=true is TS accepted, not delivery', 'delivered=true is input increment evidence, not item traceability', that the run avoids resetmodel because it would erase the TS, and that network_checked only reports. These are exactly the non-obvious behaviors an agent needs. It loses a point for burying them in dense prose rather than making the operational caveats prominent.

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

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

The core purpose is front-loaded, but the body is bloated with source-code citations (Commands.xml line numbers, FlexsimDefs.h references) and implementation boilerplate that do not help an agent select or invoke the tool. Much of the 'Fuente' paragraph should be stripped; it dilutes the actionable Args/Limits content and mixes languages.

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

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a complex orchestration tool with no annotations and an output schema present (so return values needn't be re-explained, though the description redundantly lists them), the coverage is strong: params, limits, error semantics, and run behavior are all addressed. It is essentially complete for correct invocation, only hampered by presentation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0% (only titles and constraints), so the description must compensate, and its Args block documents all eight sub-parameters with meaning — including non-obvious ones like control_points verification via _flow_path and the run_seconds TE budget heuristic. This adds genuine value beyond the bare schema. It is not a 5 because a few entries (e.g. priority) are defined minimally.

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

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

The opening sentence names a specific verb and resource ('Deliver one item on the AGV network') and enumerates the exact task sequence (TRAVEL pickup, LOAD, TRAVEL dropoff, UNLOAD + run), which clearly separates it from lower-level siblings like flexsim_run_transport or flexsim_agv_route. The '(window only)' qualifier further scopes it. It stops just short of 5 because it never explicitly contrasts itself with those siblings by name in a selection-oriented way.

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

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

Usage is implied rather than stated: it notes the window-backend constraint and points to flexsim_list_tree for discovering items, which helps an agent get set up. However, there is no explicit 'use this instead of X when…' routing or when-not guidance against the many AGV/transport siblings, so the agent must infer the choice.

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

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

With no annotations, the description carries the full behavioral burden and does disclose key context: the window-backend-only restriction, the honest caveat that objectconnect's effect on AGV objects is not pre-verified, and the internal BFS verification via _flow_path that reports the real chain even through intermediate nodes. It stops short of stating whether the operation is destructive/reversible or what permissions it needs, but the disclosure is well above average for an unannotated tool.

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

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

The core action and constraints are front-loaded, which is good, but the text is bilingual and includes a lengthy 'Fuente / honestidad' paragraph and a redundant 'Args' section duplicating schema-level detail. It is informative yet more sprawling than it needs to be, weakening scannability.

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

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists ({from, to, linked, path | last_out, note}), so return values need not be explained, yet the description still briefly covers them. Combined with the backend constraint, verification behavior, and parameter resolution rules, an agent has enough to invoke it correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

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: point_a/point_b are explained as either an AGV::StraightPath/CurvedPath or an AGV::ControlPoint that Model.find must resolve, and verify is defined as walking outObjects with BFS looking for point_b. This meaningfully exceeds what the bare schema titles ('Point A', 'Verify') convey.

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

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

The opening sentence gives a specific verb (Link), resource (two AGV endpoints), implementation method (objectconnect), and an environment constraint (window backend only). It further anchors the tool against a sibling by naming the flexsim_add_agv_loop loop-closing case, though it does not distinguish itself from other link-type siblings like flexsim_agv_connect or flexsim_link_transporter.

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

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

The description offers concrete usage scenarios ('cerrar el loop de flexsim_add_agv_loop', 'atar un ControlPoint a su path') and a routing hint for a related need ('tasksequences sobre la red: flexsim_run_transport'), which implies when to reach for this tool. It never states when NOT to use it versus the nearby agv_connect/link_transporter alternatives, so guidance stays at an implied level.

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

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 thoroughly: dispatched=true means only that the TS was accepted (not route completion or delivery), delivered=true is an input-increment signal rather than item traceability, no resetmodel is called because it would erase the in-flight TS, and a rejected LOAD/UNLOAD returns the real FlexSim error with dispatched:false. These are exactly the behavioral traits 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.

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

The first sentence is well front-loaded, but the body is a very long wall of mixed Spanish/English text salted with API source citations (Commands.xml line numbers, FlexsimDefs.h, XML:7955, etc.) that do not help an agent select or invoke the tool. Much of the material is reference detail rather than decision-relevant guidance.

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

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a complex multi-mode AGV tool it covers the critical decision points, limits, error paths and return semantics, and it even restates return fields despite an output schema existing. The main remaining gap is not positioning itself against flexsim_agv_deliver, which appears semantically adjacent.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0% (only titles/defaults), so the description must compensate, and it does: the Args block explains each parameter's role beyond the schema, e.g. load_from is the involved2 of the LOAD, unload_to is the TRAVEL destination plus UNLOAD involved2 and the source of the delivery stats, and the three mission params are mutually required. This adds real semantics the structured schema lacks.

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

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

The opening sentence gives a specific verb+resource+scope: dispatch one AGV route, either a stop-only TS or a full load/unload mission, window backend only. It also places itself in the AGV workflow relative to flexsim_add_agv_loop and flexsim_agv_link_path. It does not, however, differentiate itself from the close sibling flexsim_agv_deliver, so it falls short of full sibling disambiguation.

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

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

The numbered recipe states explicitly when to use which mode: steps 3 (stops only), 4 (adds load/unload), 5 (confirm + run), plus the rule that a partial mission (some of load_item/load_from/unload_to) is an error. Clear usage context is provided, but no when-not-to-use or alternative-selection guidance against sibling tools.

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

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

With no annotations, the description carries the full behavioral burden. It discloses that the tool works only on the window backend, that assignments are per-session and revert on save+reopen, and that the manifest is a versioning mechanism. It also outlines the return JSON shape (applied/errors). It does not state whether existing shape assignments are overwritten or what permissions are required, leaving some safety-related behavior unspecified.

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

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

The description is front-loaded with the core purpose, but it mixes English and Spanish and contains redundancy: the manifest format is given both in the introductory notes and again in the Args section. Every sentence is relevant, but the duplication and language switching reduce clarity and efficiency for an agent parsing it.

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

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given one required parameter, no annotations, and an output schema, the description is nearly complete. It explains the manifest format, session persistence, backend restriction, and return structure. The output schema means return values need not be detailed, and the description only briefly touches on them, which is appropriate. Some edge cases (e.g., what happens on partial failure) are left to the errors array.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

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 explains that manifest_path is a JSON file with a 'shapes' key containing a list of {object, file, shape_name?}, and that file paths can be absolute or relative to the manifest. This adds substantial meaning beyond the bare string parameter in the schema. It does not detail error conditions or validation constraints, but the core semantics are well covered.

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

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

The description states a specific verb and resource: 'Apply every entry of a shapes manifest JSON.' It distinguishes itself from sibling flexsim_import_shape by operating on a manifest (bulk) rather than a single shape, and it scopes the tool with '(window backend only).' An agent can identify exactly what this tool does without inspecting the schema.

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

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

The description provides clear context: the tool is for applying a versioned shapes manifest after opening a model, and it notes that script assignments are per-session (reverting on save+reopen). This explains when to use it. However, it does not explicitly name alternatives (e.g., flexsim_import_shape for single imports) or state when NOT to use it, so it falls just short of full usage guidance.

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

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

With no annotations, the description carries the full burden and delivers real behavioral context: it names the underlying call (contextdragconnection), the centerObjects verification, the backend precondition, and the important caveat that in shared mode exclusivity is 'not enforced, only reported'. It omits error behavior and any permission/state prerequisites, keeping it short of a 5.

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

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

Front-loads purpose in the first sentence, then a compact behavioral paragraph and a clean Args block. The implementation detail about contextdragconnection/centerObjects is borderline but earns its place by explaining the verify behavior.

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

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return values need not be explained, and the description covers preconditions, all parameters, and key behavioral caveats for a mutation tool with no annotations. It stops short of a 5 only because error/state requirements (e.g. a loaded model) are not stated.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

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 documents all four parameters (requester, resource, mode, verify), supplies example object names (Processor1, Operator1), states the default for mode, and clarifies what verify checks. Minor gap: mode's full semantics (exclusive vs shared effect) is only partially explained in the Args section versus the body.

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

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

States a specific verb+resource ('Attach a resource to a requester') and adds a scope qualifier ('window backend only'), making the intent concrete. It does not, however, explicitly contrast with closely related siblings such as flexsim_connect_objects or flexsim_link_transporter, so sibling differentiation is left to inference.

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

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

Implies usage through the 'window backend only' precondition and the shared-mode semantics, but gives no explicit when-to-use / when-not-to-use guidance and names no alternative sibling for the same task. Adequate context, but selection logic is left implicit.

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

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

With no annotations, the description carries the full burden. 'Check ... and answering' implies a non-destructive read that reports a connectivity/configuration state, which is useful, but it says nothing about failure modes, timeout behavior, or what 'configured' means. An output schema exists, so return details are reasonably delegated.

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

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

A single front-loaded sentence with no wasted words; the object of the check and the two conditions are stated immediately.

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

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a parameterless health-check tool with an output schema and no annotations, this covers what the agent needs to invoke it correctly. It could be more complete by naming the adjacent status tools or indicating what action should follow a negative result.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool takes zero parameters, so there is no parameter semantics to add and the baseline is 4. The description neither misleads nor needs to compensate for schema coverage.

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

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

States a specific verb ('check') and a specific resource ('the FlexScript bridge node') plus the two conditions tested (configured, answering). It does not, however, distinguish itself from closely related status siblings such as flexsim_gui_status, flexsim_experimenter_status, or flexsim_processflow_ping.

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

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

The description gives no explicit when-to-use guidance, prerequisites, or alternatives. An agent must infer that this is a pre-flight connectivity check, and it gets no help choosing between this and the several other '*_status'/'ping' tools in the sibling list.

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

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.

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.

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.

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.

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.

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.

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

With no annotations, the description carries the full behavioral burden and does so well: it declares read-only behavior, says 'No escribe nada', describes dual backends (window or Python), details the return JSON shape, specifies error behavior for missing charts, and openly states a limitation about unverifiable subnode semantics.

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

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

The description is structured with sections for siblings, args, returns, and limits, and the purpose is front-loaded. However, it has clear waste: read-only is stated three times ('read-only', 'Solo lectura', 'No escribe nada'), and the mixed English/Spanish phrasing adds length without added precision.

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

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity, absent annotations, and 0% schema description coverage, the definition covers the necessary ground: what it inspects, when to use it, argument meaning, return structure, error behavior, and known limits. An output schema exists, but the description still adds useful completeness without being redundant.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, but the description compensates by defining the sole parameter: 'name: nombre del chart (Model.find debe resolverlo).' It adds meaning and a resolution constraint beyond the schema's type/pattern fields, though it does not repeat the pattern/length constraints.

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

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

The first line states a specific verb and resource: 'Inspect a chart's internal tree structure, read-only.' It also distinguishes this tool from siblings by naming flexsim_dashboard_create, flexsim_dashboard_list, and flexsim_chart_bind_stat, so an agent can tell it apart without opening schemas.

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

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

The 'Vecinas' section explicitly names alternatives and gives the condition for using this tool: 'descubre de donde lee antes de bindear (ver flexsim_chart_bind_stat).' It provides clear context but does not state explicit when-not-to-use exclusions.

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

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

With no annotations this description carries the full burden and does disclose significant behavior: it runs the model (reset + run_to_time), samples at N=5 fixed instants, leaves the GUI chart untouched, and returns a clear JSON error 'sin escribir ni correr nada' on validation failure. The major side effect (model reset/run) is surfaced. Gaps remain: reversibility of reset and any state destruction of the current model are not stated, and internal references obscure some meaning.

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

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

Structure is reasonable (purpose first, then mechanics, Args, Returns, Limite), but the body is verbose and references internal artifacts (DB-bind, AGENTE_FLEXSIM.md) that an agent cannot act on, plus repeated defaults. It could be halved without losing actionable content.

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

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a complex model-mutating sampling tool it covers purpose, mechanics, args, the JSON return shape, error behavior and the external-chart limit; an output schema exists so return explanation is bonus depth. The reset-reversibility question and the reliance on undocumented internal references keep it from being fully self-contained.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so the description must compensate and it does: it specifies the statistic format (Object.stats.<group>.<field>, validated against ALLOWED_STATS), the 1-8 / 1-10 cardinalities, that chart is an output label only, and that objects must resolve via Model.find. Defaults for run_to_time/run_speed merely repeat the schema, but the format/constraint detail is genuinely value-adding.

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

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 ('Sample real time series to feed a chart outside') and the body clarifies the crucial distinction that it does NOT touch the GUI chart, naming flexsim_chart_bind_stat as the contrast. This lets an agent separate it from the chart-binding siblings. The Spanish prose and internal-doc jargon (AGENTE_FLEXSIM.md sec 7) add friction, keeping it below a clean 5.

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

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

It states the '(window backend only)' constraint and notes the GUI chart 'se alimenta a mano', which implies when this tool is appropriate. However, it never explicitly routes the agent (e.g. 'use this instead of flexsim_chart_bind_stat when the target chart is external'), and the 'Vecinas' list reads as implementation-reuse notes rather than usage alternatives.

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

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 the copy semantics, that the window is saved when connected, that dest_path must not exist and can never be the template, and that open_in_gui opens the copy in FlexSim. It stops short of stating permission/auth requirements or what happens to an existing file, but the mutation side effects are clearly conveyed.

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

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

The purpose is front-loaded in the first sentence, followed by mode-specific detail and an Args block. It is appropriately sized, though the flexsim_prepare_gui_model comparison is repeated in two places, a minor redundancy.

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

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given an output schema exists, return values need not be explained, and the description covers modes, all parameters, and file/GUI side effects adequately. It omits auth/prerequisite context, but for a clone/clear operation the coverage is close to complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

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: each of the four sub-parameters (dest_path, source_path, mode, open_in_gui) gets an explicit meaning plus constraints and defaults. This is materially more than the bare schema provides. It lacks format examples for paths, keeping it from a 5.

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

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

The first sentence gives a specific verb+resource ('Clone the current model file or clear back to the GUI template') and immediately distinguishes the two modes. It names the related sibling flexsim_prepare_gui_model, so an agent can separate it from other model tools. Slightly tangled by the branching modes, but the core purpose is unambiguous.

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

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

It states the condition that selects each mode (clone vs clear) and clarifies when source_path applies ('only when no known origin'). It references flexsim_prepare_gui_model for the open_in_gui behavior, giving a comparison point. However, it does not explicitly contrast with flexsim_new_model or flexsim_save_model_as, so the routing is not fully closed.

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

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

No annotations are provided, so the description carries the full burden and does so well: it discloses that no verified close command exists, that it kills only the current model's window via powershell Stop-Process filtered by MainWindowTitle, that it cleans up _gui_model_path, and that save runs applicationcommand('save') first. It stops short of explicitly warning that unsaved work is lost if save=False.

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

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

The purpose is front-loaded, but the remainder is dense implementation detail in mixed English/Spanish, including a justification aside about grep results. Some of this earns its place (it explains why no native close command is used), but the prose is heavier than needed.

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

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given a single optional parameter, an output schema (so return values need not be described) and the fact that 'Devuelve OK' is mentioned anyway, the description is complete for calling the tool correctly; only an explicit destructive-warning is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0% and the only parameter is undocumented in the schema, so the description must compensate. It does: 'save' is defined as running applicationcommand('save') before closing, with default False stated, adding real meaning beyond the bare boolean.

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

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

The first sentence states a clear verb+resource (close the window model) and a scope constraint (window backend only), with an option to save first. It doesn't explicitly name a sibling alternative, but 'window model' and 'close' distinguish it from save_model/open_model/reset/stop reasonably well.

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

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

The 'window backend only' qualifier gives implicit usage scoping, and the save option hints at the branch condition, but there is no explicit statement of when to use this versus flexsim_save_model or flexsim_stop, nor any stated exclusions.

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

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

With no annotations, the description fully carries the behavioral burden: it discloses Object.create + unique name + setLocation, that overwrite destroys the previous object, that failures return the real FlexSim error without inventing classes, and that collector_class is unverified. This is unusually thorough for a tool with no annotation coverage.

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

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

The purpose is front-loaded and the Args/Returns/Limite structure is helpful. However, the 'Camino SEGURO y honesto' and internal doc references add meta-commentary that does not help an agent invoke the tool correctly, making it longer than necessary.

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

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite an output schema existing, the description still clearly explains success/failure returns and the unverified-class limitation. With no annotations and 0% schema coverage, it supplies enough behavioral, parameter, and error-handling context to call the tool correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

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: name is unique and limited to letters/digits/underscore, collector_class is free-form with an unverified default, x/y/z are positions in meters, and overwrite destroys the prior object. It adds meaning well beyond the schema's type/default constraints.

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

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

States a specific verb and resource: 'Create one Statistics Collector object (window backend only)'. It points to flexsim_collector_record for internal configuration, distinguishing related tasks, but does not explicitly distinguish itself from the generic flexsim_create_objects sibling.

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

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

Provides clear context: window backend only, creation+position verified, internal configuration not verified and referred to flexsim_collector_record. This gives an exclusion and a related alternative, though it never says when to prefer this over flexsim_create_objects.

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

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: read-only, never writes, never samples, error behavior (recorded:false plus a clear error when collector/source_object are unresolved), and an explicit limitation about what can't be verified. It omits any permission/auth considerations, keeping it from a 5.

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

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

The Args/Returns structure is helpful and the read-only constraint is front-loaded, but the text is bilingual and repetitive ('no escribe nada', 'recorded siempre false' restated), and it leaks internal implementation details (_chart_inspect_map, AGENTE_FLEXSIM.md sec 7) that waste space for an agent.

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

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so explaining the return shape is not strictly required, yet the description still fully characterizes behavior, error cases, and known limitations. For a diagnostic tool with no annotations it is complete enough to invoke correctly, with only minor gaps around permissions.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0% (property-level descriptions are absent), so the description must compensate — and it does, defining collector and source_object as Model.find-resolvable names, statistic as Object.stats.<group>.<field> validated against ALLOWED_STATS, and event as nominal/informative only with a default. This adds substantial semantics beyond the schema's patterns and length limits.

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

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

States a specific verb+resource — 'Diagnose a collector's structure, read-only' — and immediately disambiguates from the name's misleading 'record' (it neither samples nor writes). This lets an agent separate it from flexsim_collector_create, though it does not explicitly contrast itself with sibling inspection tools like 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.

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

It implies usage (structural diagnosis of a collector, no writes, no sampling) and hints at reuse of an existing inspect helper, but never explicitly says when to pick this over flexsim_collector_create, flexsim_chart_inspect, or flexsim_chart_bind_stat. No clear when-not guidance or named alternative is given.

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

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

With no annotations, the description carries the full burden and largely meets it: it discloses that connections ACCUMULATE (1-2-3...), that flexsim_disconnect_objects must precede reconnecting to avoid duplicate links, and what verify actually inspects (outObjects/inObjects vs centerObjects). It omits mutation/error/permission behavior, keeping it out of the top band.

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

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

Front-loaded purpose, then kind-specific usage, then a NOTE on accumulation, then Args — a sensible order with no filler. The contextdragconnection('A'/'S') internals are implementation trivia an agent does not need, a minor waste.

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

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists so return values need not be explained, and the description covers the mode switch, the accumulation hazard, and the verification option. The 'window backend only' constraint is surfaced. What is still absent is failure behavior (e.g. invalid source/target, duplicate rejection) and any permission requirement.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the Args block does the work: source is 'origin (or requester for resource)', target is 'destination (or resource for resource)', kind is flow/resource, verify toggles structural verification. Crucially it clarifies that source/target semantics shift based on kind, which the schema's generic string types do not convey.

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

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

States a specific verb+resource (connect two objects) and immediately constrains the surface with '(window backend only)'. It also distinguishes the two invocation modes (flow vs resource) with examples. It stops short of differentiating itself from connect-capable siblings such as flexsim_pf_connect, flexsim_agv_connect, flexsim_link_transporter, or flexsim_attach_resource.

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

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

It explains when each kind applies (flow = item flow, resource = e.g. Processor asks Operator) and gives the important 'disconnect before reconnecting' precondition, which is real usage guidance. However, it never tells the agent when to pick this tool over the many connect-adjacent siblings, so routing remains inferred.

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

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 richly: it discloses duplicate handling (SKIP without overwrite, destroy with overwrite), blocked properties (ArrivalStyle/FlowItemClass), the ordered attempt loop with real errors ('sin mentir'), the require_gui constraint, and both success and failure return shapes. This is well beyond what the schema exposes.

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

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

The content is padded with bilingual duplication (e.g., 'Solo ventana (require_gui)' restated as 'window backend only'), an internal '# LIB-people' heading, file/version references, and a 'Vecina leida' digression. It is not front-loaded cleanly and the Spanish/English interleaving hurts scannability, even though most sentences carry some information.

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

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a multi-parameter creation tool with no annotations, coverage is close to complete: it explains fallback, duplicates, property roundtrip, error surfacing, and points to library_list for valid classes. An output schema exists, so its return-value explanation is bonus rather than necessary. The only gap is what happens when the GUI backend is unavailable, which is implied rather than stated.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is negligible, but the description documents every parameter: candidates (1-8, non-empty, attempt order), name (unique, letters/digits/underscore), x/y/z (meters, default 0,0,0), properties (setProperty roundtrip with blocked keys), and overwrite (destroys prior object of same name). The blocked-key detail is not derivable from the schema, so it adds genuine value.

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

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

States a specific verb and resource with a distinctive strategy: 'Create one object trying candidate classes in order (window backend only).' It explicitly contrasts against siblings flexsim_create_objects and flexsim_person_create, so an agent can tell it apart. It falls short of a 5 only because the mixed-language, rambling framing makes the core purpose slightly harder to extract than a crisp one-liner would.

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

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

Gives explicit when-to-use context ('Solo ventana (require_gui)'), the ordered-fallback workflow, and names alternatives: flexsim_create_objects for roundtrip/SKIP semantics and flexsim_person_create for the single-class case, noting the recommended path is now library_list + create_any. It even states the failure route ('ver clases con flexsim_library_list').

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

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

With no annotations, the description carries the full behavioral burden and does it well: atomic failure ('devuelve error SIN crear nada'), a soft warning threshold at 85, a hard cap at 100, per-object verification, and the fact that overwrite destroys the existing object first. It omits permission/auth requirements and return-format details, and the garbled '# CNT-limite' scaffolding hurts legibility, keeping it from a 5.

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

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

The first sentence is well front-loaded, but the middle Spanish block is duplicated ('Solo ventana' repeats the window-backend constraint) and littered with '# CNT-limite' template markers, making the rules harder to parse than they need to be.

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

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return values need no explanation, and for a batch mutation tool with zero annotations the description still covers atomicity, thresholds, uniqueness, and destructive overwrite. The unresolved 50-vs-100 item discrepancy and absent permission notes are the remaining gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Despite 0% reported schema description coverage at the top level, the description explains the parameter shape directly: the objects list fields (cls, name, x, y, z, properties), concrete class examples, and the semantics of overwrite. This adds meaningful value beyond the schema, though it never reconciles the described 100-object cap with the schema's maxItems: 50.

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

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

States a specific verb+resource ('Create objects in the FlexSim window in batch') and scopes it to the window backend, which separates it from other creation tools. It never names a sibling tool to route against (e.g. flexsim_create_any or flexsim_person_create), so sibling differentiation is left to inference.

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

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

Gives real usage conditions: window backend only, use overwrite=True when the name already exists, and the object-count thresholds that govern whether creation proceeds. However it offers no explicit exclusions or named alternatives among the many create_* siblings, so the agent must still infer when this tool is preferred.

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

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.

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.

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.

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.

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.

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.

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

With no annotations, the description carries the full behavioral burden. It usefully discloses read-only semantics and that no results yields an empty list rather than an error, plus the internal filtering logic. It omits permission/auth requirements, performance/scale characteristics, and pagination expectations.

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

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

Front-loaded purpose is good, but the middle sentence dumps implementation internals (model().subnodes, getname(classobject(o))) that an agent does not need to select or call the tool, and the text mixes Spanish and English awkwardly. Trimmed, it would be tighter.

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

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a single-parameter read-only list tool with an output schema present, the description covers purpose, filtering behavior, and the empty-result edge case adequately. The remaining gap is only the missing sibling routing, which is minor here.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so the description must compensate. It explains that 'pattern' is an optional substring that filters against both name and class, with default '' meaning no filter — meaning beyond the bare schema's 'Pattern'/'maxLength' metadata, though it notes no syntax examples.

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

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

States a specific verb ('List') and resource ('chart/dashboard/recorder objects') and specifies the output form ('as JSON'). It is clear about scope, though it does not explicitly distinguish itself from nearby siblings like flexsim_chart_inspect or flexsim_list_tree.

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

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

'Solo lectura (dual via run_script)' frames it as a read operation and hints at the inspect_model pattern, implying usage context. However, it never states when to prefer this over flexsim_chart_inspect, flexsim_list_tree, or flexsim_library_list, leaving alternative selection to inference.

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

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 reasonably: it declares read-only behavior and explicitly states 'never runs write scripts', a meaningful safety guarantee. It also discloses the implementation dependency (utility/doctor.py) and the scope of checks, though it says nothing about failure modes or what happens when a check cannot complete.

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

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

Two tight sentences with the read-only guarantee front-loaded and the check list following. Nothing is wasted and the most decision-relevant fact leads.

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

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 not required, and the description covers scope, safety, and the checks performed. The minor gaps are default parameter behavior and the relationship to the overlapping bridge_status tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The single 'checks' array parameter has 0% schema description coverage, so the description must compensate. Enumerating the available checks (port, window/poll age, bridge ping, FlexSimPy import, template) effectively reveals the accepted values. It does not state the default (presumably all checks) when the array is omitted.

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

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

States a specific verb+resource ('environment diagnosis') and enumerates the exact checks performed, so an agent knows precisely what it gets back. It does not explicitly differentiate itself from the closely related flexsim_bridge_status sibling, which covers overlapping ground.

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

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

The use case (pre-flight/environment troubleshooting) is implied by 'diagnosis' and the check list, but there is no explicit when-to-use guidance and no mention of when to prefer flexsim_bridge_status or another status tool instead.

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

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 underlying command path, keyed behavior per port type ('Q' flow, 'W' resource), the accumulation caveat for connects, and the OK/FAIL outcome. Missing only permission/auth requirements, but behavioral disclosure is otherwise strong.

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

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

Front-loaded and informative, but oversized: the mechanism history and the Spanish sentence partially duplicate the English verify explanation, and the language switches mid-description. Sentences mostly earn their place but trimming and language consistency would help.

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

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 detail is optional, yet the description still notes the OK/FAIL post-state. Combined with the mechanism, port-type keys, and caveats, it is complete enough for an agent to call a window-backend disconnect correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

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: the Args block defines source, target, kind (flow/resource), and verify (check outObjects for flow, centerObjects for resource). It adds real meaning beyond the schema's bare property names and pattern.

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

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

States a specific verb+resource ('Disconnect two objects') and pins down the mechanism ('window backend only', contextdragconnection). It is clearly distinguishable from the inverse flexsim_connect_objects, though it never names that sibling explicitly. Purpose is unambiguous.

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

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

Gives useful context (no objectdisconnect command exists in FlexSim 2026; use DISCONNECT keys) and a caveat-driven instruction ('disconnect all matches before reconnecting'). However it never states an explicit when-to-use vs alternative or a clean set of conditions/exclusions, so guidance is implied rather than stated.

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

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 the create-vs-update branching (Model.parameters.names() check), the returned JSON shape, type/rectangular validation, and the limit that string cells with '|' or ';' are stored verbatim. It omits permission/auth needs and reversibility, but is otherwise unusually thorough.

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

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

Purpose is front-loaded, but the implementation-detail sentence ('Replicates the VERIFIED pattern of AGENTE_FLEXSIM.md sec 3c ... Table addRow + cell(k,1).value=name ...') is largely internal mechanics that doesn't help an agent select or invoke the tool, adding bloat.

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

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Covers backend restriction, prerequisite node, validation, and the PerformanceMeasureTables exclusion, which is sufficient for correct invocation. An output schema exists so return-value detail is a bonus rather than a requirement, and the description supplies it anyway.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

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 via an Args block: name charset, value as number|string that 'must match type', and type defaulting to number. This adds a meaningful cross-field constraint ('must match type') the schema does not express.

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

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

States a specific verb+resource with scope: 'Ensure a model parameter exists, creating it when missing (window backend only).' The create-or-update semantics distinguish it from the read/write siblings flexsim_get_parameter and flexsim_set_parameter without opening either schema.

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

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

Gives clear context: window backend only, requires the Toolbox ParameterTables node, and updates value when the parameter already exists. However, it never explicitly routes the agent away from flexsim_set_parameter or states a 'when not to use' condition.

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

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 only existing nodes are evaluated, that unknown paths return None without raising an error, and that arbitrary script execution is out of scope. It omits any note on side effects of node code or permissions, keeping it short of a 5.

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

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

Front-loaded purpose, then a scope exclusion, then args, then an example. Slightly redundant that the example path repeats the one already shown inline in the Args section, but overall tight and well-structured.

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

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return values need not be explained, and the description covers the key behaviors an agent needs (existing-node evaluation, None on unknown path, script alternative). It could be richer about what kinds of node values are returned, but nothing critical is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

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. It supplies a concrete path format for node_path and explains args as 'Optional parameters passed to the node's code', which the schema's bare 'array' type does not convey.

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

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

States a specific verb+resource ('Evaluate an EXISTING node by tree path') and its return ('return its value'). It explicitly distinguishes itself from flexsim_execute_script, so an agent can separate it from the most confusable sibling without opening either schema.

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

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

Clearly names the alternative ('This does not run arbitrary FlexScript - use flexsim_execute_script for that'), giving a usable when/when-not boundary. It does not, however, contrast with flexsim_get_node_value, the other obvious sibling for reading node state.

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

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 names the bridge-node dependency and enumerates the specific blocked operations (ArrivalStyle/FlowItemClass writes, PerformanceMeasureTables.addRow, overwriting bridge/mcp_template.fsm) with the reason they are blocked (they hung or corrupted FlexSim). It stops short of describing general side effects or state mutation semantics.

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

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

Front-loaded with the purpose, then prerequisites, safety, args and examples in clearly delineated sections. Information-dense with little waste, though the section labels make it slightly longer than strictly needed.

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

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return values need not be explained, and the description still covers the bridge prerequisite, the blocked-operation safety envelope, the parameter, and worked examples. Complete enough for an agent to invoke it correctly, with the only gap being routing versus similar evaluation tools.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so the description must compensate, and it does: it documents the single `script` parameter as FlexScript code, states the `return <value>;` convention for retrieving output, and provides two concrete example scripts. That adds real meaning beyond the bare schema.

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

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

States a specific verb and resource: execute FlexScript inside the open model and return its result. This is inherently distinct from node-focused siblings like flexsim_get_node_value or flexsim_evaluate_node, but the description never explicitly differentiates itself from those alternatives.

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

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

Points to a prerequisite (needs the bridge node, see flexsim_bridge_status) and notes how to get a value back, which is implicit usage guidance. However, it never says when to prefer this tool over siblings such as flexsim_evaluate_node or flexsim_get_node_value.

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

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

With no annotations, the description carries the burden well: it is explicit about SOLO LECTURA, that it never calls resetexperiment/endreplication, touches no Experimenter nodes in write mode, and returns started:false. It explains the reason for the no-launch behavior (no verified starter).

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

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

The description is lengthy and mixes Spanish rationale with line-referenced justification (XML:5633-5636) that is noise for an agent. The essential fact (does not launch) is buried after several sentences.

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

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return values needn't be explained, though the description lists the exact JSON keys. It is honest about its limitations and suggests a workaround when the Experimenter does not exist, making it complete enough for an agent.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, and the description covers both params: name (default Experimenter1) and timeout_s (60-3600, default 600, accepted by signature but not used for polling). It adds meaning, but the 0% coverage baseline would suggest more, and timeout_s is essentially vestigial.

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

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

The name and first sentence suggest launching a scenario runner, but the body immediately negates this: it only reports scenarios and never launches. The true purpose (read-only reporting) only emerges from reading the full text, which is confusing given the name.

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

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

It recommends a prior step (flexsim_experiment_plan) and points to flexsim_experimenter_status as a pattern, and mentions the honest alternative path. But there is no explicit when-to-use-this vs when-to-use-run_experiments guidance.

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

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

With no annotations, the description carries the full behavioral burden and does so thoroughly: it states the tool is strictly read-only, explains the detection mechanism (Model.find and/or class scan of subnodes), and details the job-counting rule (jobs=0 unless a visible subnode contains 'job'). It also explicitly guarantees no creation, connection, or launching occurs.

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

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

The core purpose is front-loaded, but the text is padded with bilingual duplication ('read-only'/'SOLO LECTURA') and repeats the non-mutation guarantee several times ('nunca escribe', 'NUNCA crea, conecta ni lanza nada'). The repetition dilutes rather than strengthens the definition.

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

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists so return values need not be re-explained, yet the description still documents the JSON shape {exists, name, scenarios, jobs, note} plus the not-found hint, which is useful for anticipation. Combined with the thorough behavioral detail and parameter meaning, it is complete enough for an agent to call correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

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 for the single parameter, and it does: 'name' is defined as the Experimenter's name with a stated default of Experimenter1. This matches the schema default and adds clear meaning beyond the bare property definition.

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

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

The opening line names a specific verb and resource: report the Experimenter's existence, scenarios and jobs in read-only fashion. It implicitly contrasts with the sibling flexsim_experimenter_run by insisting it never creates/connects/launches. The purpose is unambiguous, though the bilingual restatement adds clutter rather than clarity.

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

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

Usage is only implied: an agent infers this is a pre-flight status/inventory check before running experiments, and the description does give a concrete next step for the not-found case ('crearlo a mano en Toolbox'). But it never explicitly says when to prefer this over flexsim_experimenter_run or flexsim_experiment_plan, leaving routing to inference.

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

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

No annotations, so description carries full burden. Thoroughly discloses: detection method, reading up to 20 subnodes, parsing logic (variable=number into params, others into unreadable), dual run_script, and return structure with hint when missing. No contradictions.

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

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

Front-loaded purpose is clear, but the description is verbose with implementation details (Model.find, subnodes[i].name expressions, run_script dual) that may exceed what an agent needs, slightly reducing conciseness.

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

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Output schema exists, so return values needn't be detailed, but the description omits the required 'params' wrapper, creating a completeness gap for correct invocation. Otherwise behavior and usage are well-covered.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage 0% and the top-level parameter is a nested 'params' object, but description lists name, default_seeds, etc. as direct args without mentioning the wrapper. This structural mismatch could lead to incorrect invocation; meaning of each param is given but not the required nesting.

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

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

States a specific verb and resource: 'Plan read-only de escenarios del Experimenter (pre-vuelo, sin lanzar).' Clearly distinguishes from siblings by referencing flexsim_experimenter_status and providing defaults for flexsim_run_experiments, so an agent can tell it apart.

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

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

Provides clear context: pre-flight planning, read-only, never launches jobs. Implies when to use (before running experiments) but does not explicitly contrast alternatives like flexsim_experimenter_status or flexsim_run_experiments beyond mentioning them.

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

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

With no annotations, the description carries the full load. It usefully discloses one side effect (artifact_dir is created when missing) and a scope boundary (never touches PerformanceMeasures), but leaves out overwrite behavior for existing files, permission requirements, and rate/volume limits.

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

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

Front-loaded with the core action, then a tight args block. The internal '_collect_statistics' detail is slightly obscure but earns its place as a scope boundary; overall no wasted sentences.

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

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return values need not be explained. But this is a write operation with zero annotations and a nested params object, and the description does not address overwrite semantics or error conditions, leaving meaningful gaps for correct invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

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 cover all four params with defaults (artifact_dir, format csv/json, filename snapshot.csv, statistics content/input/output basics). However it omits include_time and doesn't explain the objects/metrics structure, so a gap remains.

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

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

States a specific verb (export) and resource (statistics snapshot), plus the output formats (CSV/JSON). The reference to reusing _collect_statistics and not touching PerformanceMeasures helps distinguish it from related statistics tools, though it never names the closest sibling flexsim_get_statistics directly.

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

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

Usage is implied by 'export ... snapshot' and the note that it never touches PerformanceMeasures, which implicitly routes away from the performance-measure path. But it gives no explicit when-to-use vs flexsim_get_statistics or flexsim_chart_snapshot, and no prerequisites.

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

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

With no annotations provided, the description carries the full behavioral burden and does so well: it states 'nunca escribe' (never writes), specifies a fallback read order, forbids a particular incorrect formula, documents a verified roundtrip behavior, and describes error handling with 'tried' values and no invented zeros.

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

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

The description is front-loaded with the core purpose, but it is lengthy and repeats the same information in English and Spanish. The bilingual duplication and nested procedural details make it less concise than necessary, though the technical content is mostly relevant.

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

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no annotations, an output schema, and a single-parameter read operation, the description is nearly complete: it covers read-only behavior, backend context, fallback attempts, and error semantics. Minor gaps remain around when to prefer this over sibling tools, but the core call is well specified.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema gives no description for the single 'name' parameter (0% coverage), but the prose adds meaningful semantics: 'name: tanque a leer (Model.find debe resolverlo)'. This tells the agent what the parameter represents and how it must be resolved, compensating for the schema gap.

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

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

The description opens with a specific verb and resource: 'Read a FluidTank level, read-only'. It clearly separates this from write operations and mentions the dual backend, but it does not directly compare with the sibling flexsim_fluid_tank tool, so sibling differentiation is incomplete.

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

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

It provides procedural guidance for reading the level (try k.stats.content.value then average, never invent formulas) and says it works via window or Python backend. However, it does not state when to choose this tool over alternatives such as flexsim_get_statistics or flexsim_fluid_tank, leaving usage context implied rather than explicit.

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

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.

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.

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.

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.

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.

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.

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

With no annotations, the description carries the full behavioral burden. It usefully discloses the bridge prerequisite and 'get' implies a read-only operation, but it says nothing about error behavior, permissions, or what happens for an invalid path — significant gaps for a bridge-dependent call.

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

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

Efficient and front-loaded: the core action comes first and the path example is a compact single line. The 'Args:' scaffolding is mild overhead but not wasteful.

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

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool is single-parameter and has an output schema, so return values needn't be explained, and the bridge dependency is noted. The unexplained 'value' field and absence of any failure-mode detail keep it short of complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0% and the schema only declares node_path as a non-empty string, so the description's path example ('Model/Queue1/stats/input') genuinely adds format meaning. However, the optional 'value' parameter present in the schema is not mentioned at all, leaving part of the contract undocumented.

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

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

States a specific verb+resource ('Get value from a FlexSim tree node'), which is clear on its own and implicitly differentiated from the write counterpart flexsim_set_node_value. It doesn't explicitly name or contrast with siblings, keeping it below a 5.

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

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

The parenthetical '(needs the bridge)' hints at a prerequisite, but there is no guidance on when to use this versus alternatives like flexsim_list_tree, flexsim_inspect_model, or flexsim_evaluate_node. Usage is left to inference.

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

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 the dual backend (FlexSim window vs controller.getParameter), the failure mode for missing parameters, and the non-creating guarantee. It does not mention permissions or any side effects, but for a read operation this is solid disclosure.

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

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

Front-loads the purpose, then backend behavior, then the arg. The description is appropriately short, though the hard line breaks and the redundant 'Args:' block add minor noise.

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

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 details are not needed. The description covers the backend duality, the error case, and the create-vs-read boundary; only permission/context nuance is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0% and the schema only declares a minLength-1 string, so the description must compensate. It clarifies that 'name' refers to a parameter as defined in the model's Parameter Tables, which is useful but minimal for a single low-complexity parameter.

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

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

States a specific verb (Read) and resource (a model parameter defined in the model's Parameter Tables), which distinguishes it cleanly from flexsim_set_parameter and flexsim_ensure_parameter. An agent can identify 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.

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

Explicitly routes the agent: a missing window parameter is an error and should be created with flexsim_ensure_parameter, which also clarifies this tool never creates. It gives clear context but no explicit 'do not use this when...' exclusions.

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

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 dual-backend behavior (window vs controller), the inline discovery fallback that lists available measures, and explicitly that it never creates nor modifies rows (citing a prior OnReset breakage). It stops short of stating permissions or read-only guarantees in annotation terms, but the behavioral picture is clear.

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

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

Purpose is front-loaded, the Args section is separated, and the backend/path detail earns its place as behavioral transparency. The treenode path is dense but justified by the discovery fallback explanation.

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

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return values need not be described, and the description still covers backend routing, the discovery fallback, and mutation safety. The main gap is the absence of any routing to or contrast with flexsim_get_statistics.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0% (the 'name' property has only type/title/minLength), so the description must compensate. It adds 'as defined in the model', hinting the value must reference an existing measure, but provides no format, casing, or lookup guidance beyond that. Minimal added value for a single required param.

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

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

States a specific verb and resource: 'Read a performance measure defined in the model', and clarifies it is the native statistics-retrieval path. It does not, however, explicitly differentiate itself from the sibling flexsim_get_statistics, which appears to overlap in purpose.

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

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

'This is the native way to get statistics out of a model' implies a usage context but never says when to choose this over flexsim_get_statistics or other read tools. No exclusions or alternatives are named, leaving selection to inference.

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

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

With no annotations, the description carries the full burden; it does disclose useful traits such as the JSON return type, the two backend modes (window vs Python), and the default inclusion of Model.time. It does not state permission/auth requirements, whether the call has side effects beyond reading, or any cost/rate considerations, leaving notable behavioral gaps.

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

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

Front-loaded with purpose, then a structured Args block. Sentences are tight and every line adds information; sizing is appropriate for a tool with a nontrivial metrics grammar.

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

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return-format details are not required, and the description covers the key parameter semantics and the metrics grammar. It is broadly complete for calling the tool correctly, though it omits the objects cap and says nothing about how multiple backends affect results.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

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: objects defaults to all model objects, include_time defaults to True and adds Model.time, and metrics is documented via a grammar (<group>.<field>) plus concrete examples. Only minor gaps remain (e.g., the 50-item cap on objects is not mentioned).

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

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

States a specific verb+resource: 'Read TrackedVariable statistics as JSON'. It also clarifies the retrieval mechanism ('window or Python backend') and that it supersedes manual `k.stats.input.value` reads, which makes the function recognizable. It does not explicitly contrast itself with nearby siblings like flexsim_get_performance_measure or flexsim_get_node_value, so it falls short of a 5.

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

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

'Replaces hand-written k.stats.input.value reads' implies the intended use case (fetching tracked-variable metrics instead of scripting them). However, there is no explicit guidance on when to prefer this over flexsim_get_performance_measure, flexsim_get_time, or direct node reads, so usage is only implied.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It states what the tool does but doesn't describe how it behaves—e.g., whether it returns a timestamp format, if it requires an active simulation, error conditions, or performance implications. For a tool with zero annotation coverage, this is a significant gap in transparency.

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

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

The description is a single, clear sentence with zero waste—'Get current simulation time' is front-loaded and perfectly concise. Every word earns its place, making it easy for an agent to parse quickly without fluff.

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

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (0 parameters, no annotations, but with an output schema), the description is minimally adequate. It states the purpose but lacks context on usage, behavior, or output format. The output schema existence means the description doesn't need to explain return values, but it should still cover more behavioral aspects for a tool in a simulation environment.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has 0 parameters, and schema description coverage is 100%, so there's no need for parameter documentation in the description. The baseline for 0 parameters is 4, as the description appropriately avoids unnecessary parameter details. It doesn't add or detract from parameter understanding.

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

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

The description 'Get current simulation time' clearly states the verb ('Get') and resource ('current simulation time'), making the purpose immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'flexsim_get_statistics' or 'flexsim_get_node_value' beyond the obvious time focus, so it doesn't reach the highest tier of sibling differentiation.

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

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

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., requires a running simulation), exclusions, or comparisons to similar tools like 'flexsim_step' or 'flexsim_run_to_time' for time-related operations. The agent must infer usage from the name alone.

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

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

With no annotations, the description must carry the behavioral load and largely does: it discloses that connection is automatic on model open and, importantly, that a connected GUI reroutes other tools away from the Python backend — a non-obvious side effect an agent needs. It omits the disconnected-state behavior and any failure/error semantics, which keeps it below 5.

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

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

Three sentences, front-loaded with the answer this tool produces, then the how-to-connect note, then the routing implication. The parenthetical about the Student license and mcp_start() is slightly dense but each sentence earns its place. No filler.

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

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return values need no prose. Given a zero-parameter status tool, the description covers state meaning, the license constraint, the connection path, and the behavioral impact on sibling tools — enough for correct invocation. Only the disconnected/false case and any diagnostic guidance are left implicit.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool takes zero parameters, so there is nothing for the description to disambiguate; baseline of 4 applies. No parameter text is expected or missing.

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

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

States a specific verb and resource: reports whether a FlexSim GUI window is connected, plus the license context (Student, can create objects). An agent can tell what it returns at a glance. It does not, however, distinguish itself from the near-identical sibling flexsim_bridge_status, so it stops short of a 5.

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

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

It names the concrete prerequisite path (flexsim_prepare_gui_model opens the template copy and self-connects via mcp_start()) and explains the downstream consequence of a connected state — script/node/run tools act on that window instead of the Python backend. That is genuinely actionable context, though it never states when *not* to call this tool or how it relates to the other status/ping siblings.

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

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

With no annotations provided, the description carries the full behavioral burden and does so thoroughly: it documents session-only script assignments, the plain-text error format, the success JSON contract, copy behavior, verification steps, and known limitations. It also warns that set_size_xyz is intentionally ignored and why.

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

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

The purpose is front-loaded, but the description is heavily overloaded with internal verification notes, command snippets, XML examples, and mixed-language commentary that do not all help an agent select or invoke the tool. Much of the implementation detail could be moved out or summarized without losing decision-relevant information.

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

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity, lack of annotations, and the existence of an output schema, the description is complete enough: it covers prerequisites, flow, error modes, return contract, persistence caveats, and known gaps. An agent has what it needs to call the tool correctly and interpret outcomes.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

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 explains file_path extensions, object existence requirements, shape_name sanitization default, copy_next_to_model default, and the intentionally ignored set_size_xyz argument. This adds meaning well beyond the bare schema types and defaults.

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

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

The first sentence gives a specific verb and resource: importing a 3D shape file onto an existing object, with the window-backend scope stated up front. The description also implies the relationship to flexsim_apply_shapes for persistence, so an agent can distinguish this import action from later reapplication.

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

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

It gives a clear usage context (window backend only) and an explicit flow for when and how to use the tool, including the copy-next-to-model and verification steps. It also names flexsim_apply_shapes for reopening a model, but does not systematically compare all alternative shape-related siblings or state when not to use this tool.

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

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

No annotations are provided, so the description carries the full burden and it does add real behavioral context: the per-object payload shape, which classes carry `stats`, that simulation time is returned, and especially the Student-license count thresholds (85+/100) that trigger a `license_hint`. It omits safety/profile traits (read-only, prerequisites), keeping it short of a 5.

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

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

The core purpose is front-loaded and the field list is useful, but the Student-license block is cluttered with inline '# CNT-limite' markers and mixed-language commentary that add noise without much clarity.

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

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return values need not be spelled out, and the description still covers payload shape, the license behavior, and the returned simulation time. Nothing critical for calling a zero-parameter read tool is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool takes zero parameters, so the baseline of 4 applies; the description correctly adds no parameter guidance because none is needed.

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

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

States a specific verb and resource ('List every object of the model... as JSON') and the window-backend scope. It is distinguishable from read-oriented siblings like flexsim_list_tree or flexsim_get_statistics by its whole-model object dump, but it never names those alternatives explicitly.

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

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

The parenthetical '(window backend)' implies the operating context but gives no explicit when-to-use or when-not-to-use guidance relative to siblings such as flexsim_list_tree or flexsim_get_statistics. Usage is only loosely implied.

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

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

With no annotations, the description carries the full behavioral burden. It discloses the backend restriction, the origin behavior of new objects, and the default spacing, but it does not state whether existing object positions are overwritten, whether the operation is reversible, or what happens if a named object is missing.

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

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

The description is short, front-loaded, and uses a compact Args list. Every sentence contributes useful information: the core action, backend constraint, origin behavior, default spacing, and parameter meanings.

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

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return values need not be explained. The description covers the critical backend constraint and all parameters, but with no annotations it could say more about mutation side effects and failure modes for a tool that repositions existing objects.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must define the fields, which it does: names in line order, start_x/y/z as the first position, spacing in meters, and axis as x or y. It adds substantial meaning beyond the bare schema, though it omits schema constraints such as the minimum of 2 names, maximum of 50, and coordinate ranges.

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

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

The first sentence gives a specific verb and resource: 'Place existing objects along X or Y.' It also adds a backend constraint, but it does not differentiate this tool from sibling layout/mutation tools such as flexsim_create_objects or flexsim_set_node_value, so it falls short of 5.

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

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

Usage is implied by 'Place existing objects along X or Y' and the 'window backend only' note, which gives context for when the tool applies. However, there is no explicit guidance on when to choose this over alternatives like flexsim_apply_shapes or flexsim_set_view, and no when-not conditions are stated.

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

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

With no annotations, the description carries the full burden and does disclose useful behavior: it is read-only, works on a dual backend, and returns a clear error listing known groups when the group is invalid. It does not mention permissions or latency, but the safety profile and error path are covered.

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

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

The purpose is front-loaded in the first line, but the body is bloated with implementation notes (a FlexScript snippet, 'Vecinas leidas antes de escribir', a full known-groups list) that serve the author more than an agent choosing a tool. Content is useful but not tight.

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

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a two-parameter read tool with an output schema present, the description need not explain return values, and it still covers parameters, error behavior, and valid group names. An agent has enough to call it correctly, though permissions and backend selection could be clearer.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

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 explains the group default ('people'), its regex validation and injection protection, and the pattern substring semantics (optional, Python `in`, not a regex, never sent to FlexScript). This meaningfully exceeds the bare schema.

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

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

The opening sentence states a specific verb and resource: 'List library class names in a group as JSON', so an agent knows exactly what it returns. It also references siblings (flexsim_dashboard_list, flexsim_person_create) to situate itself, though the distinction is by analogy rather than by explicit contrast.

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

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

It signals read-only use and cites a documented pattern ('Solo lectura (dual via run_script...)' referencing AGENTE_FLEXSIM.md sec 4), but never states explicitly when to reach for this tool versus the many other list/introspection siblings. Usage is implied rather than directed.

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

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

With no annotations provided, the description carries the full behavioral burden. It usefully discloses the window-backend-only restriction, the centerObjects verification behavior, and an important warning about unverified mobile Dispatcher topology, but it does not state permissions, side effects, reversibility, or what happens to existing links.

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

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

The purpose is front-loaded, and the Args/Returns structure is useful. However, the description mixes English and Spanish, includes a code-like implementation chain, and repeats the mobile-Dispatcher warning, which adds redundancy rather than clarity.

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

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the operation's complexity, the nested input schema, and the existence of an output schema, the description is largely complete: it explains the link target, optional processor behavior, verification, and an important topology warning. The main gap is that it does not route the agent away from sibling linking/connection tools.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

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. Its Args section documents all four inner parameters: dispatcher, transporter with examples, optional processor, and verify with its default and centerObjects meaning.

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

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

The description states a specific verb and resource: linking a transporter to a dispatcher via resource (S) connections, with a window-backend-only constraint. It is clear enough to distinguish the operation from generic model manipulation, but it does not explicitly name or differentiate itself from sibling tools such as flexsim_connect_objects or flexsim_attach_resource.

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

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

The description explains mechanics and optional behavior but does not say when to use this tool versus alternatives like flexsim_connect_objects, flexsim_attach_resource, or flexsim_agv_connect. No prerequisites, exclusions, or routing guidance are provided.

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

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

With no annotations, the description carries the full burden. It usefully discloses the return shape, the depth>1 iteration behavior, and the injection-validation rules on path. However, it never states the operation is read-only/non-mutating, nor any error or permission behavior, and is cluttered with implementation internals rather than agent-relevant traits.

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

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

The text is bilingual and mixes agent-facing purpose with implementer internals (run_script, node(), classobject(), subnodes loop). The key purpose is front-loaded in one line, but the body is bloated and hard to parse, with no clean separation of usage, behavior, and arguments.

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

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 not strictly required, and the description still provides it. The Args section covers all three parameters, giving an agent enough to call the tool. But the muddled bilingual phrasing and implementation noise leave the definition only adequate, not complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

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. The Args block does add some meaning beyond the schema: 'depth: 0 returns no children' and 'max_nodes: cap for returned nodes' clarify semantics the schema does not. But path is only described tautologically as 'tree path', and the rest largely restates defaults/ranges already present in the schema.

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

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

The opening states a specific verb+resource: 'List tree subnodes as JSON'. That is clear enough for an agent to know what the tool does. It stops short of a crisp sibling differentiation, since the routing hints (run_script vs evaluate_node) concern internal mechanics rather than why an agent would pick this over flexsim_inspect_model or flexsim_get_node_value.

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

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

The description tells the implementer which backend to use ('Usa run_script ... NO evaluate_node'), but that is not agent-facing when-to-use guidance. There is no statement of when to call flexsim_list_tree versus flexsim_inspect_model, flexsim_get_node_value, or other read tools in the family.

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

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

No annotations are provided, so the description carries the full burden and does so reasonably: it discloses the write side effect (a new .fsm file is created on disk), that the model is opened, and the precondition that model_path 'must not exist yet.' It omits error behavior (e.g., missing directory, existing file) and any 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.

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

Front-loads the action in the first sentence, then explains rationale and args in clearly separated blocks. The config.toml parenthetical is a touch verbose but earns its place by explaining the template source.

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

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a single-parameter creation tool with an output schema, the description covers purpose, mechanism, the parameter constraint, and returns are handled by the output schema. Only edge-case/error behavior is left unstated, which is a minor gap.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

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. It identifies model_path as the path of the new .fsm file and adds a critical constraint ('must not exist yet') not present in the schema, plus a concrete example value. This meaningfully exceeds the bare schema.

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

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

States a specific verb and resource ('Create a new model from the bridge template') and discloses the mechanism (copies the template to a new .fsm and opens it). An agent can tell this creates-from-template rather than opening (flexsim_open_model) or cloning (flexsim_clone_model), 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.

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

Usage is implied through the constraint that 'FlexSim has no script command to create a blank model,' which explains why this tool exists. However, it never states when to prefer it over flexsim_open_model or flexsim_clone_model, nor any explicit when-not guidance.

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

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

No annotations are provided, so the description carries the full burden. It states the action ('Open a FlexSim model file') but lacks behavioral details: it doesn't specify if this loads the model into memory, requires specific permissions, affects other operations (e.g., closing previous models), or has side effects like initialization. The example adds minimal context but is insufficient for a mutation tool.

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

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

The description is front-loaded with the core purpose in the first sentence, followed by a clear Args section and a practical example. Every sentence earns its place: no fluff, and the structure (purpose, parameters, example) is logical and efficient for quick understanding.

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

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 1 parameter with low schema coverage and an output schema (which reduces need to explain returns), the description is minimally adequate. It covers the parameter semantics well but lacks behavioral context (e.g., what 'opening' entails, error handling). For a tool that likely mutates state (opening a model), more detail on effects and usage context would improve completeness.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema description coverage, the description must compensate, which it does effectively. It explains 'model_path' as 'Path to .fsm or .fsx file' and provides an example with a concrete path, adding meaning beyond the schema's generic 'Model Path' title. However, it doesn't detail path format constraints (e.g., absolute vs. relative, network paths).

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

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

The description clearly states the verb ('Open') and resource ('FlexSim model file'), making the purpose immediately understandable. It distinguishes from siblings like 'flexsim_new_model' (creates new) and 'flexsim_save_model' (saves existing), though not explicitly. However, it doesn't fully differentiate from all siblings (e.g., 'flexsim_compile' might also involve opening).

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

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

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., if a model must be opened before running or evaluating), nor does it specify when not to use it (e.g., for new models vs. existing ones). The example shows usage but lacks contextual rules.

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

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

No annotations are provided, so the description carries the full burden and does so well: it discloses the session-persistence limitation of shapes in the .fsm, states that shape_name loading is idempotent, and specifies the timing constraint (after each reset+run). It omits auth/permission and error-handling behavior, but for a local FlexSim media operation this is strong disclosure.

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

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

Purpose is front-loaded in the first line, followed by the scope condition, timing requirement, and Args/Returns blocks. Most sentences earn their place, though the verified-date note and repeated full STL path are minor excess.

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

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists so return values need not be explained, yet the description still summarizes the JSON return shape. Combined with defaults, timing, and persistence caveats, an agent has enough to call it correctly; only auth/error semantics are unaddressed.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

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 each of the four params (from_objects as source stations with default DesT1/T2/L3, file_path as the STL, shape_name as the media name, color_rgb as 0-1 channels). It even supplies a default for from_objects that the schema lacks, though it could state the exact color channel order.

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

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

States a precise verb+resource ('Pinta como carne los items') and narrows scope to items already output from the named stations, distinguishing it from generic shape tools like flexsim_apply_shapes or flexsim_import_shape by specifying post-unboxing items in transit toward the picadora.

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

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

Explicitly gives a when-to-use condition ('Correr tras cada reset+run') because the shape does not persist across sessions, and identifies the target population (post-desencajado items in Pie*/BeltDT*/picadora queues). It does not, however, name sibling alternatives or when NOT to use it.

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

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.

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.

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.

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.

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.

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.

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 substantively: it discloses that the object is NOT parented to the flow, that attached is always false, the exact command sequence used, and which steps remain unverified. This is unusually candid about side effects and uncertainty, though it stops short of covering auth/permissions or error behavior.

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

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

The content is useful but heavily bloated and bilingual, with repeated hedging about verification status and an embedded script snippet. The purpose is front-loaded, but the middle sprawls across uncertainty notes that could be compressed substantially.

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

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists so return values need not be explained, yet the description supplies them anyway. Combined with the limitation disclosure (attach pending, attached:false) and full parameter coverage, an agent has enough to call this correctly; only error/permission behavior is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0% – the individual properties (flow, name, x, y, activity_class) have no descriptions. The prose compensates: it explains flow must exist via Model.find, that name must be unique, that x/y are position with z=0, and gives the default and candidate values for activity_class. That is a meaningful lift over the bare schema.

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

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

The description opens with a specific verb+resource+scope: 'Add one ProcessFlow activity object at model level (window backend only)'. It also names and characterizes the neighboring tools (flexsim_processflow_ping, flexsim_processflow_inventory), though these are not true alternatives to this operation, so sibling differentiation is partial rather than clean.

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

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

It states a key constraint ('window backend only', activity always created at model level) and routes the agent to execute_script for discovering valid classes. However, it never says explicitly when to choose this tool over the other pf_* siblings (pf_attach, pf_connect, pf_run_tokens); usage is implied rather than stated.

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

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

With no annotations, the description carries the full load and does well: it discloses the underlying operation (moveobject), a post-condition verification (Model.find('flow/activity') != NULL), the return keys, error behavior when attached=false ('sin mentir'), and an honest limitation about unverified token semantics. It omits any permission/auth requirements or side effects on existing connections.

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

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

Purpose is front-loaded and the sections (neighbors, method, args, returns, limit) are organized, but the text is verbose and mixes Spanish and English, including meta-commentary about which tools were 'read before writing' and a manual quote. Some of this is redundant overhead that dilutes an otherwise serviceable structure.

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

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a single-parameter mutation tool with an output schema, the description covers the operation, prerequisite workflow, return shape, and an explicit limitation. The output schema makes explaining return values optional (it explains them anyway), and the only real gap is the absence of failure/permission guidance.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

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 largely does: 'flow' is defined as the ProcessFlow container that must exist via Model.find, and 'activity' as a short-name activity created at model level. The pattern/length constraints live only in the schema, but the semantic meaning of each parameter is added.

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

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

The opening line gives a precise verb+resource+destination ('Move a model-level activity INSIDE its ProcessFlow') and scopes it ('window backend only'). It explicitly distinguishes itself from siblings by naming flexsim_pf_add_activity as the tool that creates at model level with attached:false, so an agent can route correctly without opening either schema.

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

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

It names the prerequisite/related tools to consult first (pf_add_activity, pf_connect, processflow_inventory) and the implicit workflow of create-at-model-level then attach, plus the 'window backend only' constraint. It stops short of stating explicit when-not-to-use conditions or what to do if the activity is already attached.

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

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.

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.

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.

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.

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.

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.

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

With no annotations, the description carries the full burden and does substantial work: it discloses the reset+run side effect, sets run speed to 1000, applies stoptime(60)+applicationcommand('run'), and waits for getrunstate==0 under a deadline. It also flags a behavioral caveat ('tokens runtime no siempre cambian subnodes', arrivals_observed can be 0). It stops short of explicitly warning that the reset discards current simulation state.

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

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

The purpose sentence is front-loaded, but the body is dense, bilingual, and repetitive (the 'no construye/inyecta' point recurs; the reset/run sequence is described twice). Implementation minutiae (node(...).value) crowd out signal. It is serviceable but not tight.

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

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a reset+run observation tool with no annotations, the description covers the mechanism, arguments, side effects, and result caveats adequately. An output schema already exists, so the explicit 'Returns JSON {...}' explanation is bonus rather than necessity, and the overall picture is complete enough to call correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

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 largely does: 'flow' is defined as an existing ProcessFlow (clear error if missing), and 'arrivals' is clarified as a non-injected reference with default 5 and range 1-100. This adds real meaning the bare schema lacks, though it omits how/why the reference value matters.

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

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

Opens with a specific verb+resource: 'Observe ProcessFlow state across a short reset+run.' It distinguishes itself from the builder siblings by stating 'no construye nada (no crea actividades ni inyecta tokens).' It is clear on what it does, though the mixed-language and implementation-heavy body dilutes the focus somewhat.

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

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

It gives a key precondition ('window backend only') and names the read neighbors (flexsim_processflow_inventory, flexsim_run_to_time), implying when this fits. However it never states explicitly when to use this tool instead of flexsim_run_to_time or flexsim_processflow_inventory, nor when not to use it. Usage is implied rather than spelled out.

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

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 auto-connect via the On Model Open trigger, the ~20 s delay, the status-check step, and the manual `mcp_start();` fallback. The 'must not exist yet' constraint also flags a creation-safety behavior not visible in the schema.

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

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

Front-loaded with the core action, followed by operational notes and then the args block. Each sentence earns its place; nothing is redundant padding.

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

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return values need not be explained, and the description fully covers the operational workflow, precondition, and recovery step for this single-parameter tool. Nothing an agent needs to invoke it correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0% (the property is only typed as a string with minLength 1), so the description must compensate. It does: model_path is 'Path of the new .fsm file (must not exist yet)', adding format and precondition semantics the schema lacks.

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

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

The description uses a specific verb and resource: 'Copy the GUI template to a new .fsm and open that copy in the FlexSim window.' This clearly distinguishes it from siblings like flexsim_new_model (creates fresh), flexsim_open_model (opens existing), and flexsim_clone_model (clones). An agent can tell exactly what this does 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.

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

It gives explicit operating guidance ('Work on the copy, never on the template') and the post-copy connection workflow including the fallback if mcp_start() doesn't fire. What's missing is an explicit statement of when to choose this over flexsim_new_model or flexsim_open_model, but the workflow context is strong.

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