Expose an MCP server for AI-assisted editing in JOSM

[francians]

I’ve been doing some preliminary research on adding an MCP server interface to allow AI clients to interact with JOSM.

This may be premature to bring to the community, but I’d like to gather early feedback and understand whether this direction makes sense for JOSM. For that reason, I think it could be useful to start the discussion now.

First of all, I’d like to ask: what is the JOSM community’s general view on AI-assisted editing?

To better explain the idea, here are two example use cases:
Average mapper: a user wants to avoid studying large parts of the OSM wiki. They tell an AI to find an object, add opening hours they provide (possibly inferred from a photo), then open JOSM and find the data already filled in and ready for review before upload.
Advanced mapper: a user leverages AI to analyze complex editing plans, such as finding objects with shared characteristics and validating them against rules that are difficult to express in MapCSS or would otherwise require a dedicated advanced plugin.

The key point is that this approach explicitly does not involve automatic editing or uploading. Instead, it focuses on assisting the mapper during the editing process — what one might loosely call “vibe mapping”: expressing intent in natural language and letting JOSM (with AI assistance) prepare the edits, while the mapper remains fully responsible for reviewing and uploading the changes.

Anyway, at the moment I am far from implementing the second example, but with some additional work I believe the first scenario could be made functional.

I’d be very interested in hearing your thoughts on this approach and whether such an integration could be considered useful or appropriate for JOSM.
I’m working on this in my spare time, so please don’t expect a stable version anytime soon. The current experimental work is available here: ​https://github.com/fansanelli/JosmMCP

[stoecker]

Well, I cannot speak for the community, but I got a shit-storm for using AI generated images earlier this year (see #24067, #24124). Not because, they were ugly or crappy (OK, I overlooked one typo in an image), but because they were AI made. OTOH there were also people who liked that and most didn't care either way. Also as far as I know at least on plugin (MapWithAI) already uses AI.

So you will clearly step into a minefield.

Now my personal opinion: AI support will be the future and something I've been waiting for some decades. Essentially for OSM the final data quality is what counts. So when your AI functions help to produce good data that will be a step forward. If your AI functions only make it easy to push crap into the database it will be something which will (rightly) provoke resistance.

Your plugin seems to be a major extension for the idea of "remote control". That's a dangerous thing. JOSM has no real internal security architecture (plugins can do nearly anything). So your plugin MUST be extremely careful crafted to not be a security barn door - i.e. every input coming from the outside must pass filters which let only harmless content through.
No externally triggered (without user approval):

• file read/write
• no software execution (there are first AI tools where such actions are exploited)
• remote connections
• action causing remote side effects
• only send data which is in a positive list (instead of maintaining a blacklist of data - like username and password - not to send to AI helpers)
• ...

If you can handle (or ignore) the backlash of the AI haters then I suggest go forward with it. If it needs structural core changes (like making function public or add some helper stuff), then ask in JOSM tickets.

P.S. JOSM philosophy is to improve in small steps. I'd suggest to use the same for your plugin. Select one functionality. Get it working. Release. Find another one. Add It. Release. Don't go for the big goal and never reach release state.

[stoecker]

BTW: Thinking back what a lot of work it was to postprocess my images beginning of this year and what high quality stuff I can get today directly from the AI tools. It's only 1 year...

But you "can" get is not you "will" get. There will always be lazy people who simply take the AI results without verification and that can cause more overall work instead of reducing the workload of experienced mappers.

[gaben]

Well, I had a similar idea for my master's thesis, but it's no longer an original idea. I'm both happy and sad at the same time.

[francians]

@stoecker
Thanks a lot for the detailed and honest feedback, this is exactly the kind of input I was hoping for.
You are absolutely right about the security implications. The “remote control” aspect is the part I’m being most careful about. The current idea is to strictly limit what can be triggered externally and require explicit user approval for any meaningful action (for example, anything involving network access or changes to data). A strict allow-list approach is definitely the direction I want to follow.
I also agree with your suggestion about small steps. My plan is to start with a very narrow and well-defined feature set, focusing on simple, composable actions (following an “agentic” pattern) and avoiding large, high-level commands that could require structural changes or making additional APIs public in the JOSM core. If that ever becomes necessary, I’ll definitely bring the discussion to JOSM tickets first.

@gaben
I’m happy and sad for the same reasons 🙂
If you’re still interested in the topic, I’d be very happy to collaborate. There’s plenty of room to split the work into independent pieces, and some specific parts could fit very well as a master’s thesis on their own.
You could either work together on this project, or pick a well-defined sub-topic and develop it as part of your thesis, if that works better for your university.