model_edit resolves bare block names to the built-in source, silently diverging from documented library defaults

[shafiul]

Bug Report

---

Summary

When model_edit's add_block op is given a bare internal type name (e.g. "UnitDelay"), the block is created from the built-in registry (built-in/); given a display name ("Unit Delay") or a full library path ("simulink/Discrete/Unit Delay"), it is created from the masked Simulink Library block. The two sources carry different defaults, so any parameter whose Library mask overrides the built-in default is silently produced with the built-in value when a bare type name is used. This is systematic across the library (not a per-block quirk); no warning is emitted and model_check reports the model healthy.

Expected Behavior

A block added by model_edit with unspecified params carries the same defaults as the corresponding Simulink Library block (add_block('simulink//', …)) — matching the Library Browser and the block-reference documentation — regardless of the name form used to reference it.

Actual Behavior

A bare internal type name produces the raw built-in/ defaults. Where the Library block's mask overrides a built-in default, the two diverge silently. Display name and full path produce the Library defaults. BlockType is identical for all forms, so the source is not visible on the placed block.

Reproduction Steps

Prerequisites: MATLAB/Simulink R2026a, SATK MCP server attached to an existing session, an agent with model_edit. Start from a clean session.

1. Add a Unit Delay with type + name only (no params) via model_edit:
   {"tool":"model_edit","model":"verify.slx","scope":"root","layout_mode":"full",
   "operations":[{"op":"add_block","type":"UnitDelay","name":"ud"}]}
2. Repeat into fresh models with type = "Unit Delay" and type = "simulink/Discrete/Unit Delay".
3. Read back each: get_param(blk,'BlockType'), get_param(blk,'SampleTime').
4. Observe — a single whitespace character flips SampleTime between built-in 1 (fixed-rate) and library -1 (inherited), with BlockType identical throughout:

• type = "UnitDelay" → BlockType UnitDelay, SampleTime 1
• type = "Unit Delay" → BlockType UnitDelay, SampleTime -1
• type = "simulink/Discrete/Unit Delay" → BlockType UnitDelay, SampleTime -1

A few more examples of the same mechanism

Same pattern on other blocks — bare type name gives the built-in default, full library path gives the documented Library default (block · parameter: built-in → Library):

• RelationalOperator · Operator: >= → <= (a logic inversion — this is model_edit adds Relational Operator with default Operator '>=', but Simulink library default is '<=' — silent semantic inversion #50)
• Switch · Criteria: u2 >= Threshold → u2 > Threshold (boundary flip)
• DataTypeConversion · SaturateOnIntegerOverflow: on → off

We ran a full-library sweep and confirmed the relationship holds for every deviating parameter (model_edit value == the built-in/ default). We can share the complete list and the census script on request — the point of this report is the single sourcing behavior, not the individual values.

Why this is a toolkit-introduced surface

Raw add_block rejects both bare forms; only the built-in/ prefix or a full path work natively, so the bare-name resolution model_edit performs does not exist in the native API:

add_block('UnitDelay', 't/b') % ERROR Simulink:Commands:InvBlockSpecifier
add_block('Unit Delay', 't/b') % ERROR Simulink:Commands:InvBlockSpecifier
add_block('built-in/UnitDelay', 't/b') % ok -> SampleTime '1'
add_block('simulink/Discrete/Unit Delay', 't/l') % ok -> SampleTime '-1'

Environment

Gathered live from the session (2026-07-20) via the filing-bug-reports workflow.

Toolkit & Agent

• SATK Version: simulink toolkit 2026.07.08 (VERSION file); MCP/SATK package v0.11.2, matlab toolkit 2026.07.02; source: release (config.json)
• Agent / Client: Claude Code CLI
• Agent Workspace Root: /Users/shafiulazam/maple
• MCP Server Mode: attach-to-existing (connector live on secure port 31516)
• Available MCP Tools: model_read, model_edit, model_check, model_overview, model_query_params, model_resolve_params, model_test

Skills · 4 ▶ 1

• model-based-design-core (SATK): ▶ filing-bug-reports (invoked to author this report)
• host built-in / project: maple-exp, update-config, loop
• ▶ invoked. Skill loading is not implicated in this bug — it reproduces purely via model_edit + get_param, with no skill body in the failure path.

Skill Conflict Analysis: N/A — no instruction conflict among invoked skills (only filing-bug-reports is in the authoring path).

MATLAB

• MATLAB Version: R2026a Update 3 (26.1.0.3276743)
• Simulink Version: 26.1 (R2026a)
• setup.m Status: ran successfully (which('model_read') → …/simulink/tools/model_read/model_read.p)
• Connector Port: 31516 (attach mode)

Platform

• OS: macOS 26.5.1 (Build 25F80)
• Architecture: maca64 (expected platform-independent)

Error Output

Silent — no error is raised. The observable evidence is the parameter-value mismatch, e.g.:

model_edit=1 builtin=1 library=-1

Visual Evidence

Confirmed in the block dialog: a model_edit-added Unit Delay (bare "UnitDelay") shows Sample time 1; the same block added by full library path shows -1.

Impact

• Scope: all agent/script workflows adding blocks via model_edit with a bare type name and implicit params — the toolkit's target population. GUI / add_block-from-Library users are unaffected.
• Silence: the divergence leaves no post-hoc signal — identical BlockType, empty ReferenceBlock on both sides (library block is a mask instance, not a link), and identical verbatim model_check status on a contaminated build vs its corrected counterpart.
• Blast radius: the SampleTime = 1 case silently corrupts discrete-block trajectories in any non-1 s / inherited-rate model and bites even a capable agent (no reasonable agent pins SampleTime explicitly). Fixed-point overflow/rounding/type flags change results on integer/fixed-point paths; the RelationalOperator/Switch cases invert a comparison.
• Workaround: reference blocks by full library path, or pass every affected param explicitly. Both require knowing which defaults diverge — undocumented.

Related Files

• tools/model_edit/model_edit.p (+patch package) — add_block reference resolution / default-assignment path
• tools/model_edit/+patch/block_config.json — declares the built-in type set

Additional Context

No response

[shafiul]

Following up on this with a systematic sweep, because one part of the original report turns out to be
too optimistic.

The report says display names and full library paths resolve to the library block, and only bare
type names resolve to built-in. That is not reliable for every display name. On release
2026.07.08 (MATLAB R2026a), passing a documented display name can yield the block type's generic
defaults rather than the defaults documented for the block that was named.

Two cases, both returning status: ok:

documented display name passed	parameter	you get	documented
Discrete Zero-Pole	SampleTime	1	-1
Integrator Limited	LimitOutput	off	on
	UpperSaturationLimit	inf	1
	LowerSaturationLimit	-inf	0

The Integrator Limited case is the clearer of the two, because nothing structural distinguishes the
result. The documentation states the block "is identical to the Integrator block with the exception
that the output of the block is limited based on the upper and lower saturation limits" — so the
delivered block has the same BlockType and, under default settings, the same single output
port as the correct one. There is no missing port, no wiring difference, and model_check reports
healthy on both.

The effect is not cosmetic. Integrating a constant input of 1 for 3 s:

model	result at t=3
built from Integrator Limited	3.0 — never saturates
built from simulink/Continuous/Integrator Limited	1.0 — saturates at the documented limit

The gap grows without bound as simulation time increases.

Both cases warn, and the warning does not lead to the correct block:

warning: Using 'Integrator' as best guess for 'Integrator Limited' (65% confidence).
Verify this is correct. Alternative matches: DiscreteIntegrator, SecondOrderIntegrator, RateLimiter

The block type named in the warning is correct — the documented block is a BlockType: Integrator.
The correct block is a configuration of that type rather than a distinct type, so it does not appear
among the type-name alternatives offered. A caller who follows the instruction to "verify this is
correct" by checking the block type will find that it is, and proceed.

Minimal reproduction:

m = 'repro'; new_system(m); load_system(m);
model_edit(m,'root','[{"op":"add_block","type":"Unit Delay","name":"a"}]','full');
model_edit(m,'root','[{"op":"add_block","type":"Discrete Zero-Pole","name":"b"}]','incremental');
model_edit(m,'root','[{"op":"add_block","type":"Integrator Limited","name":"c"}]','incremental');
get_param([m '/a'],'SampleTime')    % -1     library default, as the original report describes
get_param([m '/b'],'SampleTime')    %  1     built-in, despite being the documented display name
get_param([m '/c'],'LimitOutput')   % 'off'  documented default for this block is 'on'

So the display name is not a fully reliable way to obtain documented defaults. Method, since it
matters for a claim like this: we built each block twice, once via the display name through
model_edit and once via add_block with the full library path, and diffed every dialog parameter.

Two further observations from the same sweep, which may be useful when scoping a fix:

• For Integrator Limited we found no short form that works. Integrator Limited,
  IntegratorLimited, integrator limited, Integrator, Limited, IntegratorLimit,
  Integrator-Limited and LimitedIntegrator all yield limiting disabled; Limited Integrator yields
  a DiscreteIntegrator. The partial path Continuous/Integrator Limited is refused. Only the full
  simulink/Continuous/Integrator Limited returns the documented configuration. That is ten strings
  rather than an exhaustive search, but the pattern was consistent.
• Across the 203 declared types probed (122 by a distinct documented display name, 81 by the type name
  where no distinct display name exists), no input returned INVALID_TYPE; the six that were
  refused returned error_code: NOT_FOUND. Only 2 of those 6 were name-resolution failures — the
  other 4 failed because a library (vexv5lib) was not installed on this machine. Guidance that tells
  callers to fall back to a full library path when model_edit returns INVALID_TYPE did not
  trigger in either case. Separately, using NOT_FOUND for both "unknown name" and "known name,
  library not installed" means a caller cannot tell a typo from a missing toolbox.

Happy to share the full per-type table if that would help.

[derrick-mw]

Hey @shafiul

This issue was addressed in the latest SATK release. https://github.com/matlab/simulink-agentic-toolkit/releases/tag/2026.07.29

Please let us know if you still encounter this issue after installing the latest version.

Thanks,
Derrick