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 does not say what happens to error when reference is a step target, how saturation_limit affects the metrics, whether empty/mismatched time and signal arrays are handled, or any sampling-rate expectations. Only the word 'optional' hints at the role of control.

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 filler, and the metric list is the most useful part placed first. It is efficient, though arguably too terse for a five-parameter analysis 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?

An output schema exists, so return values need not be explained. But with no annotations and zero documented parameters, the description leaves key invocation details (units, array alignment, reference semantics, saturation behavior) unaddressed, which is inadequate for a five-parameter 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?

Schema description coverage is 0% across five parameters. The description implies 'control' is optional (via 'optional control-effort metrics') but never explains time, signal, reference, or saturation_limit, all of which are non-obvious in the control-analysis domain. It does not compensate for the coverage 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 gives a specific verb ('Calculate') and resource (step-response metrics) and enumerates the exact metrics produced (rise, settling, overshoot, error, control-effort), which is enough to distinguish it from the simulate_* siblings that run models rather than analyze captured data. However, it never explicitly names those siblings or states that it operates on pre-recorded time/signal series.

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 statement of when to use this tool versus simulate_xcos_model or simulate_first_order_model, no prerequisites (e.g. data must come from a completed run), and no mention of the reference value's role in selecting the invocation. Usage must be inferred entirely from the domain.

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. 'Ask real Xcos to export' hints that an external Xcos process is invoked (implying latency and process spawn), but nothing states side effects, file writes, permission needs, or that the default 120s timeout reflects a slow operation.

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 filler. It is appropriately terse, though the brevity borders on under-specification for a tool that spawns a process.

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 with zero annotation coverage, zero parameter documentation, and an external-process behavior left unstated, the description is too thin for an agent to call this confidently.

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% for two parameters, and the description mentions neither 'name' (is it the block name? the template name?) nor 'timeout_seconds'. It adds no meaning at all beyond the bare schema titles.

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 action (export a one-block diagram) and a concrete output (its XML), which distinguishes it from siblings like list_xcos_blocks or get_xcos_block_source. However, it never reconciles the 'block template' naming with the 'one-block diagram export' phrasing, leaving mild ambiguity about what a template actually is.

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 guidance on when to use this versus get_xcos_block_source, list_xcos_blocks, or inspect_xcos_model. The agent must infer from context that this generates a template rather than reading an existing block.

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 implies a read-only lookup but says nothing about whether the block must already be installed/loaded, what happens for an unknown name, or the shape of the returned source text.

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?

One short sentence with the action and target front-loaded and no wasted words. It is efficient, though the brevity is also the source of its gaps.

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. However, with zero annotation coverage and zero parameter description coverage, the description leaves the single required parameter and the block-installed precondition unspecified, which is only minimally adequate.

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% for the single required 'name' parameter. The description only obliquely references 'an installed block's ... source' and never states that the parameter is the block name or what form it takes (e.g., path vs. bare name).

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 (an installed block's Scilab interface source), which distinguishes it from siblings like list_xcos_blocks and inspect_xcos_model. It does not explicitly name which sibling to use under which condition, 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?

The phrase 'for accurate configuration' hints at intent but gives no explicit when-to-use guidance, prerequisites, or alternatives to consider. Nothing tells the agent when this should be preferred over inspect_xcos_model or list_xcos_blocks.

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 is implicitly a read-only environment probe, but it does not disclose failure behavior (e.g., what is reported if no Scilab/Xcos install is found) or any side effects, leaving some behavioral gaps for a diagnostic 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?

A single front-loaded sentence with zero filler, listing exactly the three things reported. Nothing is wasted or buried.

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?

With an output schema present, the description need not enumerate return fields, and its high-level enumeration (CLI, GUI, version) plus zero params makes it nearly self-sufficient. Minor gap: no mention of environment-prerequisite context.

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 schema has nothing to explain and the baseline is 4. The description appropriately does not invent parameter discussion.

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 (Report) and concrete resources (Scilab CLI, Xcos-capable GUI, exact version), which makes the tool's output clear. It is naturally distinct from the block/model/simulation siblings, but the description never explicitly positions itself against them.

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 guidance on when to call this versus the siblings (e.g., as a prerequisite check before simulate_xcos_model). The word 'discovered' faintly implies environment probing, but no condition, trigger, or alternative is 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?

No annotations are provided, so the description carries the full burden. It does not say whether the read is side-effect-free, whether a missing path errors or returns empty, or what the inspection output looks like beyond a rough field list.

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 focused sentence with no waste, front-loading the resource and enumerating outputs. Appropriate length for a one-parameter read 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?

An output schema exists, so return values need not be explained, and there is only one parameter. But with no annotations and no usage routing, an agent gets little help deciding when this beats its many siblings.

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%, but there is only one parameter and its name (model_path) is self-explanatory. The description adds no format or sourcing detail, so this lands at the low-coverage baseline rather than above it.

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?

Specific verb 'Inspect' plus resource 'saved Xcos diagram,' and it enumerates what inspection returns (blocks, links, recorded outputs). It is clear but does not differentiate itself from siblings like list_xcos_blocks or get_xcos_block_source.

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?

No indication of when to use this tool versus list_xcos_blocks, get_xcos_block_source, or validate_xcos_model. It mentions 'saved' models but never states a precondition or selection 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?

No annotations are provided, so the description carries the full disclosure burden. It hints the list comes from installed macros, but says nothing about side effects, pagination, ordering, caching, or what happens when query/limit are omitted.

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 filler. It is appropriately sized, though the brevity leaves no room for the guidance the tool otherwise lacks.

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 the two input parameters are undocumented and no usage context is supplied. For a discovery tool with a query/limit interface this leaves meaningful 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?

Schema description coverage is 0%, so the description should compensate, yet neither the limit nor the query parameter is mentioned. The parameter names are intuitive, but the description adds no filtering semantics or default behavior.

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 ("List") and resource ("block interfaces discovered from the installed Xcos macros"), which clearly separates it from siblings like get_xcos_block_source or inspect_xcos_model. It is clear on its own but never explicitly contrasts itself with those siblings.

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 indication of when to call this versus alternatives such as get_xcos_block_source (single block source) or inspect_xcos_model. No prerequisites, no context about the discovery step in a workflow are 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?

No annotations are provided, so the description carries the full burden. It implicitly discloses that this is a non-mutating liveness check, but says nothing about timeout, latency, failure semantics, or whether it is idempotent. For a trivial ping this is only a minor gap.

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 filler. Every word earns its place for a tool of this scope.

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 the description need not explain return values. For a zero-parameter liveness check, the description is nearly complete, though it could mention how responsiveness failure manifests.

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. There is nothing for the description to clarify about arguments.

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 resource ('the MCP process is responsive'), making the health-check purpose unambiguous. It does not explicitly contrast with the Xcos-model siblings, but those tools are so different in function that confusion is unlikely.

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 phrase 'Check that the MCP process is responsive' implies the usage context (liveness/health verification), but there is no explicit when-to-use, when-not-to-use, or named alternative. Usage is inferred 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 disclose meaningful traits: it validates structure before writing, the write is atomic, and the destination is confined to an allowed root (a sandbox constraint). It stops short of stating what happens on validation failure, whether errors roll back, or how 'basic structure' is scoped.

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 filler; the scope constraint and atomicity come through quickly. It is efficient, though the brevity borders on under-specification given the entirely undocumented parameter set.

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 output schema covers return values, so the description need not explain them. But for a mutating tool with no annotations and 0% parameter documentation, key facts are missing: overwrite semantics, failure/rollback behavior, and any usage routing versus validate_xcos_model.

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, but it only hints at output_path via 'inside an allowed root'. The meaning of xml_content and the overwrite flag (default false, existing-file behavior) are undocumented in both schema and description, leaving two of three parameters semantically opaque.

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: validate and save Xcos XML. It is distinguishable from the read-only siblings (inspect_xcos_model, validate_xcos_model) by its persist-to-disk purpose, though it does not explicitly say how it differs from validate_xcos_model, which also performs validation.

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 when-to-use or when-not-to-use guidance and never names an alternative. An agent must infer that this is the persistence step after inspect/validate, and nothing explains why one would call this rather than validate_xcos_model 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?

No annotations are provided, so the description carries the full disclosure burden. "In real Xcos" usefully signals genuine execution rather than an analytical shortcut, but nothing is said about side effects (does it create/persist a model?), timeout behavior, or failure modes, which matter for a tool that runs a simulation.

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 filler that names the model and the output. It is efficient, though it slightly underspecifies rather than being padded.

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, but with no annotations and 0% parameter coverage the definition leaves the agent guessing about invocation semantics, runtime limits, and how it relates to its simulation siblings.

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% for three parameters, so the description must compensate and does not. It never explains that duration_seconds sets the simulated time window, what max_samples caps, or how timeout_seconds interacts with the run — all of which are essential to calling it sensibly.

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 pair ("Build and simulate") and a specific resource (the fixed transfer function G(s)=1/(s+1)) executed in real Xcos. It is clear what the tool does, though it never explicitly contrasts itself with the sibling simulate_xcos_model, which simulates arbitrary models.

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 guidance on when to pick this over simulate_xcos_model or analyze_step_response. An agent cannot tell from the text whether this is a convenience shortcut for a canned first-order system or the preferred entry point, and no prerequisites or exclusions are 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 provided, the description carries the full disclosure burden and does not meet it. It does not say that this executes a simulation (implying compute cost and latency), does not mention the default 120s timeout or 10000-sample cap, and does not indicate whether the run has side effects on the model file or workspace.

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?

It is a single tight sentence with no padding, which is structurally fine. However, brevity here comes at the cost of missing information, and the cryptic "TOWS_c" phrasing means the few words used are not maximally informative.

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-shape explanation is not strictly needed, but for a 5-parameter simulation tool with 0% schema coverage and no annotations, the description is far too thin. An agent would have to guess at model_path format, sampling behavior, and timeout implications before calling 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% across 5 parameters, so the description must compensate and largely does not. It hints at duration_seconds ("any positive duration") and outputs ("requested TOWS_c series"), but says nothing about model_path, max_samples, or timeout_seconds, leaving three parameters undefined anywhere in the contract.

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?

"Run a real diagram" gestures at executing a model, but "diagram" and "TOWS_c series" are opaque jargon that an agent cannot map to a concrete action or output. It also fails to distinguish itself from the sibling simulate_first_order_model, which performs a superficially similar job on a specific model type.

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 only guidance is the inline constraint "for any positive duration," which is a parameter rule rather than a when-to-use statement. Nothing says when to pick this over simulate_first_order_model or the inspect/validate siblings, nor are any prerequisites (e.g., model must be loaded or validated first) 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?

No annotations are provided, so the description carries the full behavioral burden. It hints at a runtime dependency (a real Scilab/Xcos engine is invoked) and the 120-second default timeout implies a long-running operation, but it never says whether the import has side effects on the model or workspace, what failures look like, or whether permission/runtime availability is required.

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 filler — the action and the engine are packed in tight. It is arguably too terse for the tool's complexity, but every word earns its place.

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. However, for a tool that spins up a real Scilab/Xcos process, the definition omits timeout semantics, import side effects, and routing against the four sibling inspection/simulation tools — the essentials an agent needs to call it correctly are absent.

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 neither model_path nor timeout_seconds is documented anywhere. The description mentions neither parameter, so it does not compensate for the coverage gap — an agent gets no clue about accepted path formats or what happens when the timeout is exceeded.

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 concrete verb pair (perform structural checks, import the diagram) against a specific resource (an Xcos model) and even names the engine used ('real Scilab/Xcos'). It is clear what the tool does, but it offers no differentiation from the closely named sibling inspect_xcos_model, leaving the agent to guess which one diagnoses vs validates.

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 guidance on when to reach for validate_xcos_model versus inspect_xcos_model, simulate_xcos_model, or get_xcos_runtime. The phrase 'import the diagram with real Scilab/Xcos' hints at a heavyweight validation path but never states prerequisites or the conditions that select this tool.

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