$npx -y skills add matlab/matlab-agentic-toolkit --skill matlab-debuggingDiagnose MATLAB errors and unexpected behavior. Breakpoints, workspace inspection, try-catch diagnostics, and common error patterns. Use when debugging functions, tracing errors, inspecting variables, or diagnosing runtime failures.
| 1 | # Investigating and Debugging MATLAB Code with MCP Tools |
| 2 | |
| 3 | You have access to a live MATLAB session via MCP tools. Use them to actively |
| 4 | investigate code — whether debugging errors, understanding behavior, or answering |
| 5 | questions about how MATLAB code works. Don't just guess from code alone. |
| 6 | |
| 7 | ## When to Use |
| 8 | |
| 9 | - User encounters a MATLAB error message or unexpected result |
| 10 | - User wants to set breakpoints or inspect variable state |
| 11 | - Tracing why a function produces wrong output |
| 12 | - NaN/Inf values appearing unexpectedly |
| 13 | - A MATLAB MCP tool returns an error or exception — including runtime errors, syntax errors, undefined function/variable errors, or failed test results |
| 14 | - User asks "why is my MATLAB code not working", "help me debug", or shares a MATLAB stack trace |
| 15 | |
| 16 | ## When NOT to Use |
| 17 | |
| 18 | - Code quality review without a runtime problem — use `matlab-reviewing-code` instead |
| 19 | - Performance profiling — use performance optimization workflows |
| 20 | - Writing tests for correctness — use `matlab-testing` instead |
| 21 | - Understanding MATLAB APIs or language features without a specific bug |
| 22 | |
| 23 | ## Static Analysis vs Runtime Debugging |
| 24 | |
| 25 | Not every issue needs the live MATLAB session. Choose the right approach: |
| 26 | |
| 27 | - **Static analysis is enough** when: syntax errors, unused variables, obvious |
| 28 | logic mistakes, or issues visible from reading the source code alone. Use the |
| 29 | `Read` tool and `check_matlab_code`. |
| 30 | - **Runtime debugging is needed** when: |
| 31 | - The error depends on actual data values, types, or dimensions |
| 32 | - The output is wrong but the code looks correct |
| 33 | - The user says "it doesn't work" but the code looks fine — check actual data |
| 34 | - You need to know what variables contain at a specific point in execution |
| 35 | |
| 36 | When in doubt, start with static analysis. Escalate to runtime debugging when |
| 37 | you can't determine the root cause from source alone. |
| 38 | |
| 39 | ## Auto-Trigger on MATLAB Errors |
| 40 | |
| 41 | When a MATLAB MCP tool returns an error (runtime error, syntax error, undefined |
| 42 | function/variable, dimension mismatch, failed assertion, etc.), **do not silently |
| 43 | move on or guess at a fix**. Instead: |
| 44 | |
| 45 | 1. **Recognize the error** — Look for patterns like `Error using ...`, |
| 46 | `Undefined function or variable`, `Index exceeds ...`, `Error in ...`, |
| 47 | MATLAB stack traces, or failed test results in MCP tool output. |
| 48 | 2. **Ask the user for permission** — Before launching into investigation, offer: |
| 49 | > "I noticed a MATLAB error: `<brief error summary>`. I can use the |
| 50 | > matlab-debugging skill to dig into this — inspect variables, trace the |
| 51 | > call stack, and identify the root cause. Want me to investigate?" |
| 52 | 3. **Proceed only after confirmation** — Once the user agrees, follow the |
| 53 | investigation workflow below. |
| 54 | |
| 55 | This applies whether the error came from the user running code, or from you |
| 56 | running code on the user's behalf (e.g., verifying a fix, running tests). |
| 57 | |
| 58 | ## Available Tools |
| 59 | |
| 60 | | Tool | Use For | |
| 61 | |------|---------| |
| 62 | | `mcp__matlab__run_matlab_file` | **Run .m scripts** — prefer this for executing user scripts and verifying fixes | |
| 63 | | `mcp__matlab__evaluate_matlab_code` | Quick diagnostics: inspect variables, evaluate expressions, test small snippets | |
| 64 | | `mcp__matlab__check_matlab_code` | Static analysis of .m files (warnings, unused vars, potential issues) | |
| 65 | | `mcp__matlab__run_matlab_test_file` | Run a MATLAB test file | |
| 66 | | `mcp__matlab__detect_matlab_toolboxes` | List installed toolboxes — use when "Undefined function" may be a missing toolbox | |
| 67 | |
| 68 | **Prefer `run_matlab_file` over `evaluate_matlab_code` for running scripts.** Only |
| 69 | use `evaluate_matlab_code` for short diagnostic commands (checking a variable, |
| 70 | testing an expression, etc.) — not for re-running entire scripts inline. |
| 71 | |
| 72 | ## Workflow |
| 73 | |
| 74 | ### 1. Understand the Goal |
| 75 | |
| 76 | Determine what the user needs: |
| 77 | - **Debugging** — runtime error, wrong output, unexpected behavior |
| 78 | - **Understanding** — how does this code work, what does this function do |
| 79 | - **Investigating** — why does this variable have this value, where does this data come from |
| 80 | - **Exploring** — what functions are available, how is this codebase structured |
| 81 | |
| 82 | ### 2. Gather Information via MATLAB |
| 83 | |
| 84 | Use `mcp__matlab__evaluate_matlab_code` to run diagnostic commands. |
| 85 | |
| 86 | **Read source code:** Use the `Read` tool for .m files on disk — not MATLAB's |
| 87 | `type` or `dbtype`. Only use MATLAB's `which` to locate files you haven't |
| 88 | found yet, and `which -all` to check for shadowing. |
| 89 | |
| 90 | **Preview large data:** Use `varName(1:min(5,end),:)` or `head(T)` to preview |
| 91 | slices instead of dumping entire variables. |
| 92 | |
| 93 | **Runtime debugging — check desktop mode first:** |
| 94 | |
| 95 | Before using breakpoints, check if MATLAB has a desktop: |
| 96 | ```matlab |
| 97 | desktop('-inuse') % true = de |