MCP server inside Ekos

[Thomas Nemer]

Hello there,

I fixed a few bugs in several tools, and ended up connecting claude to 
the mcp server with simulator devices, and recording a short video where 
the llm runs a demo procedure covering some tools, and a few free 
prompts. I put it here <https://vimeo.com/1198527232>. We can see there 
are still bugs to be handled but also that it globally works. If the 
feature looks interesting, I think the proper way to integrate it would 
be to split it in several parts. First the mcp server itself : ekos 
settings, transport layer, empty tool registry (or maybe with 1 tool) -> 
roughly 800 lines. And then single tools, or small groups of tools (e.g. 
slewing, tracking, focusing, capture, align, guiding, schedule...).

Best,
Thomas Nemer.

On 5/30/26 19:20, Thomas Nemer wrote:
>
> 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/20260604/f52d42ff/attachment.htm>