Feature/2754 add basic igor pro mcp server

[MichaelHuth]

Add a basic Igor Pro MCP server for Igor Pro 9+.

Igor Pro Bridge v2.3.2

A local MCP server that lets Claude control a running Igor Pro instance through the zeromq XOP.

Requirements

Igor Pro 9.00+

Installation

• run install.ps1 elevated. This installs the required python packages(mcp, pywin32, pyzmq)
• create a shortcut to ZMQ_BridgeHelpers.ipf in your Igor Procedures user folder
• add the ZeroMQ-64.xop to your Igor Pro by adding a shortcut to the Igor Extensions (64-bit) folder

The MCP communicated to Igor Pro through ZMQ port 5680 by default. However, it is possible to ask the agent to use a custom port as the MCP supports this. This allows the control of multiple parallel Igor Pro instances.

I strongly recommend to also use the SESSION_NOTES.md file in the client session as it includes important additional rules, like using ipt as well for parsing tasks. If used for other projects than MIES, as your client to strip of all MIES specifics.

[Copilot]

Pull request overview

Adds a Windows-only “Igor Pro Bridge” MCP server that connects to a running Igor Pro instance via COM Automation (ActiveX) to let local MCP clients execute commands, query environment state, manage Debugger settings, and read 1D wave data; plus a small Igor-side helper hook and documentation to support the workflow.

Changes:

• Introduces tools/igor-mcp-bridge/server.py, a FastMCP-based server using pywin32 to attach to IgorPro.Application and expose MCP tools (Execute2 wrapper, wave reads, compilation state, debugger control, environment summary).
• Adds Packages/MIES/MIES_ClaudeHelper.ipf (gated by IGOR_PRO_BRIDGE) providing an AfterCompiledHook counter to confirm successful compilation without polling races.
• Documents the bridge in Sphinx docs and links it from Packages/doc/index.rst.

Reviewed changes

Copilot reviewed 5 out of 6 changed files in this pull request and generated 6 comments.

Show a summary per file

File	Description
tools/igor-mcp-bridge/server.py	Implements the COM-based MCP server and tool surface for interacting with Igor Pro.
Packages/MIES/MIES_ClaudeHelper.ipf	Adds an optional AfterCompiledHook counter used by the bridge to confirm compile success.
Packages/MIES_Include.ipf	Includes the new Claude helper procedure file in the standard include list.
Packages/doc/index.rst	Adds the new “Igor Pro Bridge” documentation page to the docs TOC.
Packages/doc/igor-pro-bridge.rst	Documents architecture, requirements, installation, tools, and known caveats for the bridge.

[Copilot]

Pull request overview

Copilot reviewed 5 out of 7 changed files in this pull request and generated 1 comment.

Comments suppressed due to low confidence (2)

tools/igor-mcp-bridge/server.py:1348

• set_debugger_enabled() treats the optional debug_on_error/debug_on_abort/nvar_svar_wave_checking parameters as booleans via bool(...). When callers omit them (None), bool(None) becomes False, so enabling the debugger unintentionally forces all sub-settings off instead of leaving them unchanged.

    _apply_debugger_options(
        {
            "enable": enabled,
            "debug_on_error": bool(debug_on_error),
            "debug_on_abort": bool(debug_on_abort),

Packages/MIES/MIES_ClaudeHelper.ipf:21

• Typo: duplicated word in "Igor Pro Bridge bridge".

/// each time it fires. This gives the Igor Pro Bridge bridge a compile confirmation

[claude]

Claude Code Review

Claude Code Review is paused for this repository. To reconnect it, an admin of this repository's GitHub organization (or the account owner, for personal repositories) who can also manage your Claude organization's Code Review settings needs to re-link GitHub in Code Review settings. This is a one-time step.

_{Tip: disable this comment in your organization's Code Review settings.}

[Copilot]

Pull request overview

Copilot reviewed 5 out of 8 changed files in this pull request and generated 2 comments.

[Copilot]

Pull request overview

Copilot reviewed 5 out of 9 changed files in this pull request and generated 6 comments.

[Copilot]

Pull request overview

Copilot reviewed 4 out of 10 changed files in this pull request and generated 6 comments.

[Copilot]

Pull request overview

Copilot reviewed 5 out of 11 changed files in this pull request and generated 2 comments.

Comments suppressed due to low confidence (1)

Packages/doc/igor-pro-bridge.rst:394

• The AfterCompiledHook code snippet here no longer matches Packages/MIES/MIES_ClaudeHelper.ipf (the hook now preserves/restores ExperimentModified state to avoid marking the experiment as modified). Updating the snippet avoids misleading readers who may copy/paste from the docs.

   static Function AfterCompiledHook()

       Variable/G root:gClaudeHelperCompileCounter
       NVAR gClaudeHelperCompileCounter = root:gClaudeHelperCompileCounter

[Copilot]

Pull request overview

Copilot reviewed 5 out of 11 changed files in this pull request and generated 3 comments.

Comments suppressed due to low confidence (1)

Packages/doc/igor-pro-bridge.rst:394

• The documentation’s AfterCompiledHook code snippet is now out of sync with the actual implementation in Packages/MIES/MIES_ClaudeHelper.ipf: the real hook preserves/restores the experiment modified state (via ExperimentModified/V_flag) to avoid triggering a later "Save changes?" prompt. Update this snippet so readers don’t copy an unsafe version.

   static Function AfterCompiledHook()

       Variable/G root:gClaudeHelperCompileCounter
       NVAR gClaudeHelperCompileCounter = root:gClaudeHelperCompileCounter

[MichaelHuth]

@Garados007 I pushed a version with an install script.

[Copilot]

Pull request overview

Copilot reviewed 6 out of 9 changed files in this pull request and generated no new comments.

Suppressed comments (2)

tools/igor-mcp-bridge/requirements.txt:20

• The regeneration instructions reference requirements.in and pyproject.toml, but neither exists under tools/igor-mcp-bridge/ in this PR. As-is, a contributor cannot follow these steps to update hashes/versions without reverse-engineering the missing inputs.

# Regenerating this file (e.g. after deliberately bumping a version, or to add a newly
# released Python version): resolve the full dependency tree for the target platform/
# Python versions with `pip download --platform win_amd64 --python-version <NNN>
# --implementation cp --abi cp<NNN> --only-binary=:all: -d <dir> -r requirements.in`,
# where <NNN> is each Python minor version actually in use (currently 310/311/312/313/

Packages/doc/igor-pro-bridge.rst:86

• The documentation instructs building an .mcpb with mcpb pack tools/igor-mcp-bridge ..., but tools/igor-mcp-bridge/ in this PR does not include the usual MCPB source metadata (e.g., manifest.json / pyproject.toml / src/ layout). Without those, the documented build step is likely not reproducible from the repo checkout.

The bridge is distributed as a Claude Desktop Extension (``.mcpb``), not via manual
``claude_desktop_config.json`` editing (which does not work reliably for local MCP
servers in current Claude Desktop builds).

- Build: ``mcpb pack tools/igor-mcp-bridge tools/igor-mcp-bridge/igor-pro-bridge-X.Y.Z.mcpb``

[Copilot]

Pull request overview

Copilot reviewed 6 out of 9 changed files in this pull request and generated no new comments.

Suppressed comments (1)

Packages/doc/igor-pro-bridge.rst:189

• The get_bridge_version() example output hardcodes "version": "1.25.0", but server.py currently reports _BRIDGE_VERSION = "1.27.0". This will quickly confuse users who compare docs vs. the tool output.

        "version": "1.25.0",

[Copilot]

Pull request overview

Copilot reviewed 9 out of 11 changed files in this pull request and generated 2 comments.

Suppressed comments (6)

tools/igor-mcp-bridge/server.py:13

• server.py’s documentation and error messages refer to Packages/MIES/ZMQ_BridgeHelpers.ipf as the Igor-side helper file, but that path does not exist in this PR (the only ZMQ_BridgeHelpers.ipf is under tools/igor-mcp-bridge). As-is, the bridge won’t be able to reach ZBR#... functions unless the helper file is actually included/compiled and bound in the running experiment, so the setup instructions here appear inconsistent with the repository layout.

From 2.0.0 on, this bridge instead talks to Igor Pro's ZeroMQ-XOP
(https://github.com/AllenInstitute/ZeroMQ-XOP) over a plain TCP socket, sending
`CallFunction` JSON requests and calling into Igor-side helper functions in
`Packages/MIES/ZMQ_BridgeHelpers.ipf` (the `ZBR` independent module). See
SESSION_NOTES.md for the full COM-vs-ZeroMQ evaluation that led here, and

tools/igor-mcp-bridge/ZMQ_BridgeHelpers.ipf:301

• ZBR_SubmitCommandUnattended writes globals under root:Packages:ZBR:* before ensuring that data folder exists. If this is the first bridge call in a fresh experiment, that will raise a runtime error when creating those globals.

	DebuggerOptions
	Variable/G root:Packages:ZBR:savedDebugEnable      = V_enable
	Variable/G root:Packages:ZBR:savedDebugOnError     = V_debugOnError
	Variable/G root:Packages:ZBR:savedDebugOnAbort     = V_debugOnAbort
	Variable/G root:Packages:ZBR:savedDebugNvarCheck   = V_NVAR_SVAR_WAVE_Checking

tools/igor-mcp-bridge/ZMQ_BridgeHelpers.ipf:4

• This new procedure file is missing #pragma rtFunctionErrors = 1, which is required across MIES procedure files to enforce strict runtime error handling.

#pragma TextEncoding   = "UTF-8"
#pragma rtGlobals      = 3
#pragma IndependentModule = ZBR
#pragma version        = 1.00

Packages/doc/igor-pro-bridge.rst:31

• Packages/doc/igor-pro-bridge.rst states that Packages/MIES/ZMQ_BridgeHelpers.ipf is included from MIES_Include.ipf, but this PR adds the helper file under tools/igor-mcp-bridge/ and MIES_Include.ipf does not include it. The documentation and the actual repo layout/setup steps need to be made consistent, otherwise users will follow docs and end up with a non-working bridge.

The companion procedure file ``Packages/MIES/ZMQ_BridgeHelpers.ipf`` (included from
``MIES_Include.ipf``, independent module ``ZBR``) provides the Igor-side functions the
bridge calls into, including an ``AfterCompiledHook`` used to get a more reliable
compile-success signal and to (re)bind the ZeroMQ server socket on every compile; see
:ref:`igor_pro_bridge_zbr_helpers` below.

Packages/doc/igor-pro-bridge.rst:704

• This section claims MIES_ClaudeHelper.ipf “no longer exists as a separate file”, but the PR adds Packages/MIES/MIES_ClaudeHelper.ipf. Either the file should be removed/renamed as part of the migration, or this text should be updated to reflect the current repo state to avoid confusion when tracing where the compile counter comes from.

``ZMQ_BridgeHelpers.ipf`` defines a static ``AfterCompiledHook`` that increments
``root:gClaudeHelperCompileCounter`` (the global name, and the counter's role, carried
over unchanged from this repo's older ``MIES_ClaudeHelper.ipf``, which no longer
exists as a separate file):

tools/igor-mcp-bridge/server.py:10

• PR description says the bridge is “Based on the COM automation interface”, but server.py (and the added docs) describe a v2.0.0+ transport rewrite to ZeroMQ-XOP (no COM for command execution). This mismatch could confuse reviewers/users; either the PR description should be updated to reflect the ZeroMQ-based design, or the implementation/docs should be adjusted if COM is still the intended transport.

**v2.0.0: transport rewritten from COM to ZeroMQ.** Versions through 1.27.0 talked to
Igor Pro as a COM Automation *client* (win32com, `IgorPro.Application`, `Execute2`).
From 2.0.0 on, this bridge instead talks to Igor Pro's ZeroMQ-XOP
(https://github.com/AllenInstitute/ZeroMQ-XOP) over a plain TCP socket, sending

[Copilot]

Pull request overview

Copilot reviewed 9 out of 11 changed files in this pull request and generated no new comments.

Suppressed comments (5)

tools/igor-mcp-bridge/manifest.json:19

• manifest.json points the server entry point to src/server.py (and passes ${__dirname}/src/server.py), but this repo layout in the PR adds the server at tools/igor-mcp-bridge/server.py and there is no src/ directory. As-is, the packaged extension will fail to start because the entry point path won’t exist.

  "server": {
    "type": "python",
    "entry_point": "src/server.py",
    "mcp_config": {
      "command": "python",
      "args": [
        "${__dirname}/src/server.py"
      ],
      "env": {}

Packages/MIES_Include.ipf:200

• The bridge code and docs expect an Igor-side helper file at Packages/MIES/ZMQ_BridgeHelpers.ipf that is #include-d (see the module docstring and igor-pro-bridge.rst), but the only ZMQ_BridgeHelpers.ipf added by this PR is under tools/igor-mcp-bridge/. Also, MIES_Include.ipf includes MIES_ClaudeHelper instead of ZMQ_BridgeHelpers, so the ZBR functions will not be compiled into MIES experiments and nothing will bind to tcp://127.0.0.1:5680.

#include "MIES_Cache"
#include "MIES_CheckInstallation"
#include "MIES_ClaudeHelper"
#include "MIES_Configuration"

tools/igor-mcp-bridge/ZMQ_BridgeHelpers.ipf:4

• ZMQ_BridgeHelpers.ipf is intended to be included/compiled into Igor (and even says so in its header), but it’s missing #pragma rtFunctionErrors = 1, which is a consistent header requirement in this repo’s IPF files (see e.g. Packages/MIES/MIES_ClaudeHelper.ipf). Without it, runtime-error behavior may differ from the rest of MIES and from expectations in the bridge code/docs.

#pragma TextEncoding      = "UTF-8"
#pragma rtGlobals         = 3
#pragma IndependentModule = ZBR
#pragma version           = 1.00

Packages/doc/igor-pro-bridge.rst:31

• This section documents the companion helper file as Packages/MIES/ZMQ_BridgeHelpers.ipf included from MIES_Include.ipf, but in the actual PR contents there is no Packages/MIES/ZMQ_BridgeHelpers.ipf (only tools/igor-mcp-bridge/ZMQ_BridgeHelpers.ipf), and MIES_Include.ipf does not include ZMQ_BridgeHelpers. The documented setup steps therefore don’t match what will actually be compiled/available in Igor Pro.

The companion procedure file ``Packages/MIES/ZMQ_BridgeHelpers.ipf`` (included from
``MIES_Include.ipf``, independent module ``ZBR``) provides the Igor-side functions the
bridge calls into, including an ``AfterCompiledHook`` used to get a more reliable
compile-success signal and to (re)bind the ZeroMQ server socket on every compile; see
:ref:`igor_pro_bridge_zbr_helpers` below.

tools/igor-mcp-bridge/server.py:203

• server.py’s comments/docstring repeatedly refer to Packages/MIES/ZMQ_BridgeHelpers.ipf as the Igor-side helper module, but this PR adds that file under tools/igor-mcp-bridge/ZMQ_BridgeHelpers.ipf and (per MIES_Include.ipf) doesn’t currently include/compile it into the experiment. This mismatch will make troubleshooting much harder and suggests the bridge won’t connect unless the helper file is relocated/included as documented.

# --- ZeroMQ transport ----------------------------------------------------------------

# Matches ZBR_ZEROMQ_ENDPOINT in Packages/MIES/ZMQ_BridgeHelpers.ipf.
IGOR_ZMQ_ENDPOINT = "tcp://127.0.0.1:5680"
_ZMQ_DEFAULT_RECV_TIMEOUT_MS = 5000

[Copilot]

Pull request overview

Copilot reviewed 9 out of 11 changed files in this pull request and generated no new comments.

Suppressed comments (7)

tools/igor-mcp-bridge/manifest.json:17

• manifest.json points the MCP server entry point to "src/server.py", but this repo layout has server.py at tools/igor-mcp-bridge/server.py and there is no src/ directory. As-is, packaging/running the extension will fail with a missing entry point.

    "entry_point": "src/server.py",
    "mcp_config": {
      "command": "python",
      "args": [
        "${__dirname}/src/server.py"

Packages/doc/igor-pro-bridge.rst:768

• This sentence is now incorrect within this PR: it says MIES_ClaudeHelper.ipf "no longer exists as a separate file", but Packages/MIES/MIES_ClaudeHelper.ipf is added in this same change set. The wording should be updated to avoid confusing readers about where the compile counter used to live.

``ZMQ_BridgeHelpers.ipf`` defines a static ``AfterCompiledHook`` that increments
``root:gClaudeHelperCompileCounter`` (the global name, and the counter's role, carried
over unchanged from this repo's older ``MIES_ClaudeHelper.ipf``, which no longer
exists as a separate file):

Packages/MIES_Include.ipf:200

• Packages/doc/igor-pro-bridge.rst states that MIES_Include.ipf permanently includes ZMQ_BridgeHelpers.ipf, but the only related include added here is MIES_ClaudeHelper. If the intent is for the bridge to work out-of-the-box with MIES experiments, MIES_Include.ipf likely needs to include ZMQ_BridgeHelpers (and the file must live on the procedure search path under Packages/MIES).

#include "MIES_Cache"
#include "MIES_CheckInstallation"
#include "MIES_ClaudeHelper"
#include "MIES_Configuration"

tools/igor-mcp-bridge/ZMQ_BridgeHelpers.ipf:3

• ZMQ_BridgeHelpers.ipf does not follow the repository’s required IPF header pragma order (TextEncoding, rtGlobals, rtFunctionErrors). Keeping the standard order (and the rtGlobals comment) helps ensure consistent linting/formatting across procedure files.

#pragma rtFunctionErrors  = 1
#pragma TextEncoding      = "UTF-8"
#pragma rtGlobals         = 3

tools/igor-mcp-bridge/ZMQ_BridgeHelpers.ipf:403

• ZBR_PollCommand assumes root:Packages:ZBR storage waves already exist; calling poll before any submit (or after cleanup) will throw a runtime error when resolving dfr:done/dfr:resultText. It should defensively ensure storage exists, like the submit path does.

	variable idx

	DFREF  dfr        = root:Packages:ZBR
	WAVE   done       = dfr:done
	WAVE/T resultText = dfr:resultText

Packages/doc/igor-pro-bridge.rst:31

• The documentation claims the helper module is located at Packages/MIES/ZMQ_BridgeHelpers.ipf and included from MIES_Include.ipf, but this PR adds ZMQ_BridgeHelpers.ipf under tools/igor-mcp-bridge/ and MIES_Include.ipf does not include it. Please align docs and code (either move/include the file under Packages/MIES, or update the docs and setup steps to match the tools/ layout).

This issue also appears on line 765 of the same file.

The companion procedure file ``Packages/MIES/ZMQ_BridgeHelpers.ipf`` (included from
``MIES_Include.ipf``, independent module ``ZBR``) provides the Igor-side functions the
bridge calls into, including an ``AfterCompiledHook`` used to get a more reliable
compile-success signal and to (re)bind the ZeroMQ server socket on every compile; see
:ref:`igor_pro_bridge_zbr_helpers` below.

tools/igor-mcp-bridge/server.py:12

• server.py’s module docstring hardcodes the helper file path as Packages/MIES/ZMQ_BridgeHelpers.ipf, but this PR adds ZMQ_BridgeHelpers.ipf under tools/igor-mcp-bridge/. Consider making this path-agnostic (or update it to the actual location) so the docstring doesn’t mislead users following setup instructions.

`CallFunction` JSON requests and calling into Igor-side helper functions in
`Packages/MIES/ZMQ_BridgeHelpers.ipf` (the `ZBR` independent module). See

[Copilot]

Pull request overview

Copilot reviewed 10 out of 12 changed files in this pull request and generated no new comments.

Suppressed comments (10)

tools/igor-mcp-bridge/manifest.json:18

• manifest.json points the extension entry point at "src/server.py", but this repo has server.py at tools/igor-mcp-bridge/server.py and no src/ directory. Unless the pack step creates src/ implicitly, Claude Desktop will fail to launch the server.

  "server": {
    "type": "python",
    "entry_point": "src/server.py",
    "mcp_config": {
      "command": "python",
      "args": [
        "${__dirname}/src/server.py"
      ],

tools/igor-mcp-bridge/ZMQ_BridgeHelpers.ipf:10

• The header comment says this file is "#include-d from Packages/MIES_Include.ipf", but there is no Packages/MIES/ZMQ_BridgeHelpers.ipf in this PR and MIES_Include.ipf does not include it. This is likely to mislead users during setup.

// ZMQ_BridgeHelpers.ipf -- Igor Pro-side helper functions for the Igor Pro Bridge
// (tools/igor-mcp-bridge/), which talks to Igor over the ZeroMQ-XOP's CallFunction JSON
// protocol. #include-d from Packages/MIES_Include.ipf; see igor-pro-bridge.rst for setup
// in other experiments, and SESSION_NOTES.md for full design rationale/history.

Packages/doc/igor-pro-bridge.rst:779

• This paragraph says Packages/MIES/ZMQ_BridgeHelpers.ipf is included from MIES_Include.ipf, but there is no such file path in the repo and no include was added. This contradicts the actual file location (tools/igor-mcp-bridge/ZMQ_BridgeHelpers.ipf) and will misdirect users.

``Packages/MIES/ZMQ_BridgeHelpers.ipf``, included from ``MIES_Include.ipf``, is no
longer a throwaway prototype -- it is the permanent Igor-side dependency of this
bridge as of v2.0.0, providing every ``ZBR_*`` function ``server.py`` calls via
``CallFunction``. Its own header comment documents the manual, one-time ``#include``
delivery model (see :ref:`igor_pro_bridge_requirements`): this repo's own
``MIES_Include.ipf`` includes it permanently, but any other experiment needs its own
copy plus its own ``#include`` added by hand.

Packages/doc/igor-pro-bridge.rst:793

• This section says AfterCompiledHook also calls ZBR_EnsureZeroMQBound() and that the counter logic came from an older MIES_ClaudeHelper.ipf that "no longer exists". In this PR’s ZMQ_BridgeHelpers.ipf, AfterCompiledHook only bumps root:gClaudeHelperCompileCounter; binding happens via IgorStartOrNewHook, and MIES_ClaudeHelper.ipf does exist (new file).

Compile-confirmation counter, migrated from MIES_ClaudeHelper.ipf
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

``ZMQ_BridgeHelpers.ipf`` defines a static ``AfterCompiledHook`` that increments
``root:gClaudeHelperCompileCounter`` (the global name, and the counter's role, carried

Packages/doc/igor-pro-bridge.rst:843

• This subsection documents ZBR_EnsureZeroMQBound() being called from AfterCompiledHook and (re)binding on every compile, but in this PR’s ZMQ_BridgeHelpers.ipf binding is done from IgorStartOrNewHook (once per Igor process/new experiment) and recompiles only stop/restart the handler. The description should be updated to match the implemented hook flow.

The same hook also calls ``ZBR_EnsureZeroMQBound()``, which (re)binds the ZeroMQ-XOP's
server socket to ``ZBR_ZEROMQ_ENDPOINT`` (``tcp://127.0.0.1:5680``) and starts its
handler every time Igor finishes a successful compile:

.. code-block:: igorpro

tools/igor-mcp-bridge/server.py:33

• This docstring says Packages/MIES_Include.ipf already includes ZMQ_BridgeHelpers permanently, but MIES_Include.ipf does not include it in this PR. Either add the include (and place the .ipf on Igor’s procedure path) or adjust this paragraph so it doesn’t claim automatic inclusion.

**Setup requirement, new in v2.0.0**: unlike the COM transport (which worked against
a completely stock Igor Pro installation with zero custom procedure code), this
transport requires `Packages/MIES/ZMQ_BridgeHelpers.ipf` to be `#include`-d and
compiled into whatever Igor Pro experiment this bridge talks to -- there is no
bootstrap path over ZeroMQ itself (if that file isn't loaded, there is nothing
listening on the port at all). This repo's own `Packages/MIES_Include.ipf` already
does this permanently. Any OTHER Igor Pro experiment that wants to use this bridge
needs `ZMQ_BridgeHelpers.ipf` copied onto its own procedure search path with a
matching `#include` added by hand, then a recompile -- see

tools/igor-mcp-bridge/server.py:901

• These parameters default to None but are annotated as bool, which is an incorrect type contract and will confuse type checkers/readers. Use Optional[bool] (Optional is already imported) to match the actual accepted values.

def set_debugger_enabled(
    enabled: bool,
    debug_on_error: bool = None,
    debug_on_abort: bool = None,
    nvar_svar_wave_checking: bool = None,
) -> dict:

tools/igor-mcp-bridge/ZMQ_BridgeHelpers.ipf:5

• This new .ipf file does not follow the repository’s standard leading pragma order (TextEncoding, rtGlobals, rtFunctionErrors). Keeping the standard header order helps automated checks and consistency across procedure files.

This issue also appears on line 7 of the same file.

#pragma rtFunctionErrors  = 1
#pragma TextEncoding      = "UTF-8"
#pragma rtGlobals         = 3
#pragma IndependentModule = ZBR
#pragma version           = 1.00

Packages/doc/igor-pro-bridge.rst:31

• This section claims the companion procedure file is Packages/MIES/ZMQ_BridgeHelpers.ipf and included from MIES_Include.ipf, but this PR adds ZMQ_BridgeHelpers.ipf under tools/igor-mcp-bridge/ and there is no include in MIES_Include.ipf. The documented file location and inclusion mechanism should match the actual repo state.

This issue also appears in the following locations of the same file:

• line 773
• line 789
• line 839

The companion procedure file ``Packages/MIES/ZMQ_BridgeHelpers.ipf`` (included from
``MIES_Include.ipf``, independent module ``ZBR``) provides the Igor-side functions the
bridge calls into, including an ``AfterCompiledHook`` used to get a more reliable
compile-success signal and to (re)bind the ZeroMQ server socket on every compile; see
:ref:`igor_pro_bridge_zbr_helpers` below.

tools/igor-mcp-bridge/server.py:14

• The module docstring points to Packages/MIES/ZMQ_BridgeHelpers.ipf, but this PR adds that file under tools/igor-mcp-bridge/. The documented path should match the repo layout so users can find the Igor-side helper module.

This issue also appears on line 25 of the same file.

`CallFunction` JSON requests and calling into Igor-side helper functions in
`Packages/MIES/ZMQ_BridgeHelpers.ipf` (the `ZBR` independent module). See
SESSION_NOTES.md for the full COM-vs-ZeroMQ evaluation that led here, and
Packages/doc/igor-pro-bridge.rst for the up-to-date setup steps.