Comprehensive CLI Support for MLO

[Miguel Barquet]

Hi,

I’ve been a dedicated MLO user for many years, and the app remains a cornerstone of my productivity system. However, I want to raise a concern that feels increasingly urgent: the lack of a fully supported command‑line interface.

After reviewing past discussions in this group, it’s clear that many users have been asking for programmatic access for years, whether through a REST API, a documented file format, or a robust CLI. The most recent comments confirm that there is still no official API or dev documentation, and while some users have found partial workarounds—like the undocumented mlo.exe batch commands or reverse‑engineering the WiFi sync DLL—these approaches are fragile and not sustainable for real automation workflows.

The landscape has changed dramatically since those earlier threads. With the rise of AI‑driven automation tools, a powerful CLI is no longer a “nice to have”—it’s essential. Tools like Claude Code, GitHub Copilot, and other agentic systems thrive when they can interact with applications programmatically. If MLO had comprehensive CLI support, I could integrate it directly into my workflows and build automations that would take MLO to an entirely new level of usefulness.

Right now, though, I’m limited to interacting with MLO through the UI, which prevents me from building the kind of intelligent, automated workflows that are becoming standard in modern productivity ecosystems. Competing tools are moving quickly in this direction, and I worry that MLO—despite its strengths—may fall behind if it doesn’t embrace this shift.

I’m sharing this not as criticism, but as someone who genuinely loves the product and wants to keep using it. I hope you can share whether there are any plans for:

• A documented and supported CLI

• A public API (REST, local, or otherwise)

• Any roadmap updates regarding automation or AI integration

I’d appreciate any insight you can provide. Without some form of programmatic access, I may eventually have to migrate to another tool—something I really want to avoid.

Thanks for listening, and I hope we can get clarity on this soon.

[Alexander W.]

Hi,

 if you do not want to have the direct interaction with the MLO app and do some manual exporting, then there are a lot of options that I could and would suggest. 

For example if you export the XML structure and leave out not needed stuff  like the encoding of the flags or something like that so that they can just get the raw data in XML; then it perfectly works with Claude Code CoWork. That's what I'm doing.

Then you can talk with your MLO structures and even use it as a reference for tasks that you give Claude to follow your goals and even help you execute on your goals.
Obviously in that state, writing back is manual stuff but if you have a stable structure for life management or this kind of stuff, then this can be really useful.  

So the suggested cycle that could really work is to do the strategic planning in MLO and do the execution of your goals in Claude Code CoWork and only write back the needed updates and then you go if you iterate.
And what you get is a digital assistant that perfectly knows your goals and can execute on them.

Just a thought.
Obviously any feedback appreciated about what others are doing to work with their personal AI ;). 

[Hugo González Castro]

Thank you for the information, Alexander. I already use the XML export. The problem with that approach is: the bigger the size and number of tasks, the more difficult for the AI to keep the consistency of the file and keep all the context...

I suppose a more useful approach could be providing a MCP server, so the AI could make direct calls to the MLO API. Also, it would be great if there were connectors to Zapier, n8n, and other automation services or AI agents. That way the AI could work with individual tasks without dealing with the full XML files.

Just sharing my ideas...

--
You received this message because you are subscribed to a topic in the Google Groups "MyLifeOrganized" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/mylifeorganized/624lia56C58/unsubscribe.
To unsubscribe from this group and all its topics, send an email to mylifeorganiz...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/mylifeorganized/dd7cbefd-5483-44f1-89f2-3cbb2ef3c508n%40googlegroups.com.

[Alexander W.]

Hi Hugo,

That is interesting. How do you make an MCP server a better thing to create the right context? That's not totally clear to me because in my observation it is the case that you need to provide the file, which is then part of the overall context. Obviously you can build a specific extract.

For example I have in my XML export specific tags for tasks or metrics or something and then I have the AI to extract specific portions from it, but from the total because otherwise the context is totally lost.
So the AI decides which parts of the file to take and how to construct the proper context for the proper task. 

So in my mind MCP server does not help to really build the right context but it would be interesting to see what strategies you see and how an MCP server would be helpful to create the right context.
That is something that I am currently investigating myself to build basically a dynamic context building memory system for an AI. I mean everybody is working on it. Nobody has a proper solution yet, I think.  

-a

[Hugo González Castro]

Hi Alexander,

I think I didn’t explain clearly what I meant earlier, so let me clarify.

The main issue with letting the AI directly modify the XML is that there’s no guarantee it will only change the intended sections. When the file becomes large, the LLM can lose context and unintentionally modify unrelated parts of the XML. In my case, for example, I have multiple projects with subprojects, which makes the file too large for the AI to reliably process and preserve its full structure.

The advantage of an MCP server is that the AI does not directly manipulate the XML. Instead, it proposes actions, and those actions are executed by predefined, deterministic functions on the server side.

For example, an `add_task` function would receive the task data from the AI, but the actual insertion into the XML would be handled by a properly implemented function. This guarantees that the file structure remains intact and that no unintended parts are modified. The same applies to actions like adding subtasks, deleting tasks, etc.

Another risk with direct AI editing is that, when handling large XML files, the model may attempt to restructure, simplify, or reformat parts of the file (e.g., removing comments or adjusting formatting), which can easily corrupt it. Using an MCP server avoids this entirely.

Additionally, exposing an API and integrating with tools like Zapier or n8n enables powerful automation workflows. For example:

- When a YouTube video is uploaded, an event could automatically create a task in MLO.

- Or when a task is created in a specific project, it could trigger actions in other platforms (e.g., social media posting).

These tools essentially allow event-driven inputs and action-based outputs, enabling bidirectional integrations between MLO and other systems.

Regarding context: an MCP server can also expose query functions so the AI can retrieve the necessary information before acting. For instance, if asked to create a subtask, the AI could first query the relevant project data to ensure proper context before executing the action.

So overall, the idea is:

- The AI proposes actions

- The MCP server executes them safely

- The XML/database is handled deterministically

- And context can be dynamically retrieved when needed

This approach significantly reduces the risks associated with large XML manipulation while enabling more robust automation.

To view this discussion visit https://groups.google.com/d/msgid/mylifeorganized/1a7eab3c-eeee-4976-9b4f-1e9465749d6en%40googlegroups.com.