MCP server inside Ekos

[Thomas Nemer]

Hello Jasem,

I read about Pavan's project a few weeks ago, this is very exciting, it 
will most probably improve guiding while an mcp server will only ever be 
a way to expose some internals in a structured way, I think these are 
complementary approaches.

I first used the mcp server to setup my guiding correctly, but since 
then I extended it a lot and intend to keep going as it provides a UX I 
like. For instance, last night I ran kstars, connected to my rig with 
ekos, then started a claude in my terminal and asked it to init the 
session. This triggers a skill that checks the ekos status is ok and 
that the mount is parked, then it unparks the mount, captures an image, 
solves it, syncs the mount. if this is successful, it slews the mount on 
an axis a few degrees, captures another image, solves again, syncs again 
and does that a few times for both axis until the system properly knows 
where it is, finally it notifies me the session is ready. During that 
time I was looking for the night's target (I don't have a structured 
enough usage to leverage the scheduler), and once it's ok I tell claude 
to point to my target and describe the capture sequence I would like. 
All this use various mcp tools I've integrated.

This is still a work in progress of course, and a lot is still missing, 
or in the making, or not tested yet : captured image data, focus 
results, polar align results, and more about features I can't test myself.

For now it lives in a branch on my Github fork here 
<https://github.com/thomasnemer/kstars/tree/feature/mcp-server> but I 
would be happy to push it somewhere else, what's you preferred place for 
this?

It would be a pain to review as a whole though (~ +6500 lines), a lot 
more manageable commit after commit 
<https://github.com/thomasnemer/kstars/compare/master...feature/mcp-server>.

Best,
Thomas

On 5/30/26 17:13, Jasem Mutlaq wrote:
> Hello Thomas,
>
> Thank you for your proposal. There is a whole project for this year 
> GSoC 2026 dedicated to AI-assisted guiding: 
> https://www.pavansg.me/blog/gsoc
>
> Nevertheless, the idea of MCP server integration is intriguing and we 
> can see if it benefits the overall ecosystem. Do you have the code 
> available somewhere so we can review it? Was this only used for 
> guiding or for other purposes?
>
> --
> Best Regards,
> Jasem Mutlaq
>
>
>
> On Sat, May 30, 2026 at 5:29 PM Thomas Nemer 
> <thomas.nemer at fortytwo.fr> wrote:
>
>     Hello,
>
>     I've been on this list quietly for several years but never posted
>     before.
>
>     Quick intro: backyard astrophotographer in France. For a long time
>     I picked targets that worked with "polar align well and track".
>     Recently I tried guiding for the first time and hit a tuning wall.
>
>     The Cloudy Nights folks pointed me in the right direction, and
>     once I had the basics I wanted to keep tuning, but the loop of
>     reading logs, change a setting and try again was painful. I fired
>     up an AI agent on the log files and it helped, but reading
>     after-the-fact text still was a very long feedback loop.
>
>     So I started building an MCP server inside Ekos, first exposing
>     the live state I needed for guiding diagnosis, then expanding as
>     it became useful, and even some more after only because some tools
>     looked like quick wins.
>
>     How it is today:
>
>       * ~40 tools across mount / capture / guide / focus / align /
>         scheduler / INDI, plus an SSE channel for typed events.
>       * Streamable-HTTP MCP transport on localhost, bearer-token auth,
>         rate limiting, optional read-only mode with a separate
>         read-only token.
>       * Per-tool 'readOnly' / 'destructive' / 'idempotent' annotations
>         so MCP clients can show users what they're authorizing.
>       * Settings UI integrated into the existing Ekos options panel.
>       * 25 headless QTest cases, all green on Qt6.
>
>     To be honest my C++ experience is very old, never with Qt, and
>     there are places I trusted the generative AI's proposed
>     implementations blindly. Also, my rig is very modest (EQ6 Pro +
>     200/800 Newton + ASI 294MC Pro + ASI 120MM mini), so there are
>     some tools I just can't test end to end.
>
>     Would that contribution be welcomed? I would be happy to share any
>     more details
>
>
>     Best regards,
>     Thomas Nemer
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kstars-devel/attachments/20260530/fe8cd0a7/attachment-0001.htm>