OpticStudioMCPServer Public Discussion and Usage Analysis
OpticStudioMCPServer Public Discussion and Usage Analysis
Updated for sharing • Revised on April 9, 2026 based on additional publicly accessible material
Bottom line: Public discussion volume around OpticStudioMCPServer still appears limited, but the strongest public evidence has become much more significant. In addition to earlier setup-and-usage validation, a newer LinkedIn post by Don Perrault now provides evidence of a full autonomous optimization cycle with diagnosis, rollback, strategy change, and successful re-optimization. That materially strengthens the case that the project is moving from “AI-assisted optical design” toward “partially autonomous optical-design iteration.”
1. Executive Summary
Javier Ruiz’s OpticStudioMCPServer is an MCP (Model Context Protocol) server that connects AI assistants to Zemax OpticStudio for optical design workflows. Based on the repository materials and publicly visible web content, the project is already more than a concept demo: it exposes a substantial set of design, analysis, and optimization operations to AI clients such as Claude Code, Claude Desktop, and local models via Ollama.
Public discussion remains niche rather than mainstream, but the quality of the evidence is high. Earlier public proof centered on a practical setup-and-usage write-up by Don Perrault of Aurora Photonics. Newly reviewed material goes further: it shows a multi-hour autonomous optimization workflow in which Claude not only ran OpticStudio tools, but also validated results, detected physically invalid outcomes, reloaded a backup, changed optimization strategy, and completed a cleaner design pass.
2. Project Overview
OpticStudioMCPServer is an open-source server layer that allows an AI assistant to interact with Zemax OpticStudio through a tool interface. Instead of limiting the AI to explanation or static recommendations, the server enables direct operational access to an optical design session.
- Primary domain: Optical engineering and lens design
- Main software target: Zemax OpticStudio
- Supported AI clients: Claude Desktop, Claude Code, Ollama-based local LLM workflows
- Platform constraints: Windows environment, .NET / ZOS-API dependencies, valid OpticStudio license
Public repository: https://github.com/jaruiz6363/OpticStudioMCPServer
3. What the Project Can Actually Do
Based on the README and tool reference, the MCP server is not limited to simple metadata reading. It exposes meaningful design operations across several categories.
3.1 System and session control
- Connect / disconnect / restart Zemax sessions
- Create new systems
- Open and save optical files
- Check connection state and session status
3.2 Lens and surface editing
- Read and modify surface properties
- Add surfaces
- Set aspheric coefficients
- Apply solve types and variable settings
- Adjust fields, wavelengths, and apertures
3.3 Analysis functions
- Spot diagrams
- FFT and geometric MTF
- Ray tracing
- RMS spot size
- Cardinal points
- Seidel coefficients
- Ray fan / OPD fan / field curvature / illumination analysis
3.4 Optimization functions
- Read and modify merit functions
- Add and remove operands
- Run local optimization
- Run hammer optimization
- Run global search
- Use optimization wizard flows
This makes the project especially notable: it is not merely an AI “viewer” for Zemax. It is closer to a real operational control plane for optical-design workflows.
4. Public Discussion Landscape
4.1 LinkedIn: still the strongest public evidence
The clearest public discussion identified so far remains a sequence of LinkedIn posts by Don Perrault (Aurora Photonics). The earlier post focused on practical deployment: prerequisites, installation flow, first-test commands, preferred connection mode, and common failure modes. The newly reviewed post raises the importance of that public signal substantially because it documents not just setup, but execution of a complete autonomous optimization cycle.
- He frames the work as a continuation of earlier Zemax + Claude experimentation.
- He reports a full autonomous run on a 100 mm f/1.6 Double Gauss design.
- He states that one prompt was pasted into Claude Code, with no human intervention afterward.
- He describes autonomous backup, baseline analysis, merit-function construction, optimization, validation, failure diagnosis, rollback, and retry.
4.2 Why the newer post matters even more
This is now the most important public evidence because it demonstrates several things at once:
- Actual adoption: someone outside the repository owner used the stack in a serious design experiment.
- Autonomous iteration: the AI did not just execute commands; it completed a diagnose-and-recover loop across multiple attempts.
- Validation awareness: numerical merit improvement was not treated as success when the physical result became invalid.
- Tool discovery and strategy shift: Claude reportedly discovered and adopted the Optimization Wizard on its own.
- Concrete engineering feedback: the post surfaces precise missing capabilities, such as hard variable bounds and better stop-surface handling.
4.3 GitHub: information-rich, but still not discussion-heavy
The repository itself remains the richest information source. The README is extensive and already functions as a strong technical orientation document. However, public GitHub Issues and Discussions visible through lightweight public access still do not show large discussion volume directly tied to the project name.
That does not mean discussion is absent. It may simply be happening through:
- LinkedIn posts and comments
- Direct user-maintainer exchanges
- Feature-branch iteration rather than issue-thread debate
- Private professional networks among optical engineers
4.4 Other social platforms
Searches across broader social and web channels still do not reveal large volumes of direct, project-specific discussion. There is plenty of public conversation about MCP in general, but much less specifically about OpticStudioMCPServer. The project remains early-stage in public visibility even as the practical signals become stronger.
5. Key Practical Usage Patterns
5.1 Claude as a collaborative optical-design operator
One major use pattern is to let Claude connect to a Zemax session and inspect the current optical system before making targeted changes or running analyses. This is more collaborative than generative: the user remains in the loop while the AI accelerates tedious design operations.
5.2 Analysis-first workflow
A likely real-world pattern is:
- Connect to a system
- Read current surfaces / fields / wavelengths
- Run spot, MTF, or aberration analysis
- Summarize weaknesses
- Apply targeted edits
- Re-run analysis or optimization
5.3 Local/private workflow via Ollama
The project’s Ollama bridge is strategically important. It means the workflow is not locked to a cloud-only assistant. For labs or companies with privacy concerns, local models become a practical route for AI-assisted optical design.
5.4 Emerging autonomous optimization workflow
The new LinkedIn post adds a distinct usage pattern: end-to-end autonomous optimization under supervision-by-prompt rather than live human steering. In that reported workflow, the AI did not stop after an initial failed optimization. It validated outputs, diagnosed the reason constraints failed, restored a backup, altered the optimization method, and continued toward a physically realizable result.
6. Most Important Lessons from the Earlier Don Perrault Setup Post
6.1 Standalone mode appears preferable in practice
Don explicitly recommends standalone mode rather than extension mode for at least some cases, especially where thickness optimization boundary constraints are involved. This is one of the most valuable practical findings because it goes beyond repository documentation and into observed behavior.
6.2 Setup difficulty is real
The installation path is not trivial. The practical barrier is not the MCP idea itself, but the engineering stack around it:
- Windows-only environment
- ZOS-API DLL path handling
- .NET and Node.js setup
- Claude Code / Claude Desktop integration
- PATH updates and shell restarts
- File lock conflicts during rebuilds
6.3 The project is already in a feedback-driven iteration phase
The explicit use of feature/thickness-variable-bounds in the earlier public discussion suggested real-world feedback and ongoing refinement. The newer autonomous-optimization report strengthens that interpretation further.
7. New Developments from the Autonomous Optimization Post
Compared with the earlier public signals that mainly proved the stack could be installed and operated, the newer LinkedIn update adds a much more important layer of evidence: OpticStudioMCPServer is not only usable for assisted interaction, but is already supporting a full autonomous optimization loop in a realistic optical-design task.
Perrault describes running a full autonomous optimization on a 100 mm f/1.6 Double Gauss design using Claude Code together with Javier Ruiz’s OpticStudioMCPServer. The most significant point is not simply that optimization was launched, but that the AI completed an end-to-end cycle with no human intervention after prompt submission: it connected to OpticStudio, saved a backup, ran baseline analysis, built a merit function, executed optimization, validated the result, diagnosed failures, reloaded the backup when needed, changed strategy, and tried again.
7.1 What the new post demonstrates technically
- Autonomous recovery is real: the process required three attempts before arriving at a physically realizable design.
- Validation matters as much as optimization: on the first attempt, the merit function improved dramatically, but the resulting design contained impossible thickness values. The AI caught this during validation instead of mistaking a low MF value for success.
- Strategy switching occurred without being explicitly scripted: after discovering that soft constraints were insufficient, the workflow changed methods entirely—switching to the Optimization Wizard, using RMS Wavefront, running DLS before Hammer, and limiting variation to 13 radii.
- Tool discovery behavior was observed: Perrault explicitly notes that Claude discovered and adopted the Optimization Wizard on its own.
7.2 Newly surfaced engineering lessons
- Soft merit-function penalties are not enough for Hammer optimization: even after boundary weights were increased by 100x, degenerate solutions still appeared.
- Hard variable bounds are becoming a priority requirement: the post specifically points to a need for true min/max bounds per surface variable.
- Optimization objective choice strongly affects outcome quality: shifting to RMS Wavefront and staging DLS before Hammer produced a more stable path.
- Autonomous lens design still needs encoded physical intent: the optimizer improved spot size and off-axis MTF, but allowed the design to drift from roughly f/1.65 to f/1.96, changing the effective design form rather than simply polishing the original one.
- Tooling gaps remain: stop surface handling in
zemax_set_surface, ENPD constraints to preserve target f/#, and non-blocking Hammer runs with merit-function polling all appear to be concrete next-step improvements.
7.3 Why this changes the strategic interpretation
This new evidence pushes the project beyond the category of “interesting MCP integration for a specialist desktop application.” It now looks more like an emerging autonomy substrate for optical engineering workflows. The important distinction is that the server is not just letting an LLM inspect lens data or run isolated analyses. It is enabling iterative control over a design loop where the AI can evaluate whether a numerical improvement is physically meaningful, recognize when the optimizer is exploiting weak constraints, alter optimization strategy, and continue toward a cleaner solution.
7.4 Newly Confirmed from Repository Materials: Constrained and Multistart Optimization
A fresh review of the repository materials adds an important technical finding that was not emphasized strongly enough in the earlier version of this report: the project now publicly documents a server-side constrained optimization workflow, not just ordinary merit-function editing and calls into Zemax’s built-in optimizers.
Specifically, the README now documents a dedicated set of constrained-optimization tools, including zemax_get_variables, zemax_set_variable_constraints, zemax_constrained_optimize, zemax_multistart_optimize, zemax_multistart_status, and zemax_multistart_stop. The documentation describes these as MCP-implemented optimization routines that run the optimization logic in the server itself while using ZOS-API for variable access and merit-function evaluation.
This is strategically important because it directly intersects with the problems surfaced in Don Perrault’s autonomous-optimization post. That post showed that soft merit-function penalties can fail under Hammer optimization, allowing physically invalid or degenerate results. The newly documented constrained tools suggest the codebase is already moving toward a more robust answer: explicit min/max variable bounds, bound-clamped optimization, and non-blocking multistart workflows.
If this functionality works in practice as described, then the project is not just an interface layer between an LLM and OpticStudio. It is beginning to grow its own optimization-control infrastructure designed to make AI-driven optical design workflows safer and more physically realistic.
7.5 Updated interpretation after the new research pass
- Public discussion remains sparse, especially on public GitHub discussion surfaces.
- Technical evidence is getting stronger, because the repository documentation now shows a richer workflow surface than a simple MCP demo.
- The code trajectory appears aligned with real field feedback, especially around constraints, multistart search, and optimization robustness.
- The most interesting gap now is not visibility but validation: public discussion does not yet show broad independent confirmation of how well these newer constrained tools perform in real design practice.
That changes the framing slightly. The public story is no longer only “a niche but serious MCP integration for Zemax.” It is increasingly “a niche but serious attempt to build autonomy-ready optical-design tooling on top of Zemax.”
8. Overall Assessment
- Public hype level: low to moderate
- Practical value: high
- Evidence of real use: yes
- Evidence of iteration: yes
- Evidence of autonomous diagnose-and-recover behavior: now yes
- Evidence of broad mainstream discussion: not yet
In short: the project still looks like a technically serious, early-stage, niche-but-real tool. But the newer public evidence is materially stronger than before. The most accurate summary now is not just “AI can talk to Zemax,” but “AI can already participate in nontrivial optical-design iteration with partial autonomy.”
9. Suggested Next Research Steps
- Trace Don Perrault’s earlier and later LinkedIn posts as a sequence rather than as isolated signals.
- Inspect repository and branch history for work related to hard bounds, optimization safety, and stop-surface handling.
- Look for comments, reposts, or follow-up discussion by Zemax users, optical engineers, or Aurora Photonics contacts.
- Monitor future posts under terms such as AI-assisted lens design, autonomous lens design, Claude + Zemax, and OpticStudio MCP.
10. Sources Reviewed
- GitHub repository homepage and README for jaruiz6363/OpticStudioMCPServer: https://github.com/jaruiz6363/OpticStudioMCPServer
- Public LinkedIn post by Don Perrault discussing setup and usage: https://www.linkedin.com/posts/don-perrault-0106165_github-jaruiz6363opticstudiomcpserver-share-7439640215465451520-26LK
- Public LinkedIn post by Don Perrault documenting a first complete autonomous optimization cycle with Claude Code + OpticStudioMCPServer: https://www.linkedin.com/posts/don-perrault-0106165_opticaldesign-ai-lensdesign-share-7438930044686626816-CIy1
- Public web-search results and lightweight fetches of related pages
Note: This report is based on publicly accessible information retrievable without authenticated platform access. Some platform-internal content, comment threads, and search results may not have been visible because of login walls or rate limits.