Feedback
Roadmap

Have something to say?

Tell us how we could make the product more useful to you.

MCP & MORE!

I'm building a community MCP server (github.com/lorecraft-io/morgen-mcp, currently at v0.1.9 on npm) plus an n8n-based 3-way sync (Obsidian ↔ Notion ↔ Morgen) on top of the v3 API. Morgen is the only tool I've found that unifies calendar and tasks the way my daily workflow needs, and the API has gotten me ~95% of the way there. This request consolidates three concrete API gaps. A developer at Morgen confirmed in an email reply on 2026-04-15 that all three are real and would be strong candidates when the API is next revisited (and mentioned a hackathon coming up where MCP work is being considered). Filing publicly so other v3 users can share context and upvote. I'm fully on board with the direction of deprecating task lists in favor of tags in the upcoming app release — I've already migrated my sync pipeline to use /v3/tags as the primary organization primitive. "Inbox" is now a tag, Lorecraft/Parzvl/WAGMI/etc. are Area tags, and Urgent is a flag tag that can coexist with an Area tag (something single-valued task lists couldn't express). Working great. Three asks, in priority order Task → calendar slot, exposed as an API call Current state: the web app lets you drag a task from the sidebar onto a time slot, which creates a calendar event with morgen.so:metadata.taskId set and renders the checkbox-in-calendar UI. This is the single most powerful Morgen-exclusive UX — it's why I keep coming back instead of using calendar-only or task-only tools. What's blocked: the public API rejects every way I've found to reproduce this. Specifically verified: POST /v3/tasks/update whitelist-rejects start, scheduledStart, calendarId, accountId ("property should not exist") POST /v3/events/create with morgen.so:metadata.taskId in the body rejects with "An event with canBeCompleted cannot have a taskId" or "Invalid event id" POST /v3/events/update with top-level taskId rejects: "property taskId should not exist" No endpoint exists at /v3/tasks/schedule, /v3/tasks/plan, /v3/tasks/block, /v3/tasks/timeblock, /v3/events/fromTask, /v3/events/createFromTask, /v3/events/linkTask, /v3/tasks/scheduleOn, /v3/tasks/planAt, /v3/calendars/block-task, or /v3/tasks/scheduleInCalendar (all return 404) morgen.so:metadata on an event is documented as read-only What would unblock me: a single endpoint — something like POST /v3/tasks/:id/schedule with { calendarId, accountId, start } that creates the linked event the same way the drag UX does. Even without any server-side auto-placement logic, the ability to script "put this task on this slot at this time" removes the last manual step from my sync pipeline. Why this is the biggest ask: today my pipeline pushes tasks into Morgen correctly and tags them correctly, but I still have to open the app and drag each one onto a time slot by hand to get the checkbox-in-calendar render. Every other operation (create, update, complete, delete, tag) is fully automated. Server-side reflow / auto-flow Current state: my MCP ships a client-side reflow_day tool that fetches events once (list_events, 10 pts), then issues one POST /v3/events/update per reflowable step to compress them back-to-back from an anchor time. It works for the common case (4-5 focus blocks on one calendar) but is partial-failure-prone (state can diverge mid-loop) and capped at 50 event moves per call to stay under the rate budget. Design considerations flagged by Morgen: Non-movable meetings — should reflow split time before and after the block, or skip it entirely? Preserving existing breaks/gaps — don't compress through a lunch window Multi-calendar awareness — most users (me included) have personal + work + ops calendars that need to reflow together, not one at a time What would unblock me: a server-side endpoint like POST /v3/calendars/reflow (or /v3/tasks/autoflow) that takes: An anchor window (start/end) A list of calendars to include A list of event IDs to treat as fixed (non-movable) Optional gap preservation rules A dry_run flag so the caller can preview the moves before committing Returns the computed event updates atomically so partial-failure state is impossible. Why this matters even if #1 ships first: once tasks are on the calendar grid (via #1), I need to be able to reshuffle them around a late-afternoon meeting that landed after the initial plan. Today I do this by hand. Multi-calendar task scheduling Current state: I run 4 Morgen-connected accounts (personal, two work contexts, ops). The MCP's create_event has a smart-account router that figures out which calendar to write to based on hints in the event payload. Since #1 is blocked, there's no equivalent path for scheduling a task onto the "right" calendar automatically. What would unblock me: tie this into #1's endpoint. POST /v3/tasks/:id/schedule should accept either an explicit calendarId + accountId pair, OR a strategy: "auto" option that uses the same multi-calendar heuristics the web app uses when dragging a task without pre-selecting a target slot. Small side note: undocumented tag endpoint response shapes While migrating to tags I hit a subtle bug that would be worth documenting. /v3/tags/list returns a bare array at the top level ([{id, name, ...}, ...]), and /v3/tags/create returns {id, name, color, position} with a top-level id — not {data: {tags: [...]}} and {data: {id}} like the task and event endpoints. Both my MCP and my n8n sync code had parsers that assumed the nested shapes (matching the documented task/event responses), which silently returned empty tag lookups for 4 release cycles and sent tags: [] on every task update. It only surfaced when I deliberately looked at a Morgen task and saw no tags attached. Not a request to change the shapes — totally fine as-is — just a note that documenting the response shapes on the tags endpoints alongside the task/event docs would save future integrators the same debugging trip. What the community MCP can cover vs. what needs first-party support The MCP layer itself (natural-language date parsing via chrono-node, smart-account routing for multi-calendar users, local rate-limit ledger, tag label→UUID resolver) is mostly ergonomic glue that makes the existing v3 API accessible to LLM callers. The three gaps above are the ones I can't paper over in client code — they need server-side primitives. If a first-party Morgen MCP is on the hackathon roadmap, I'd love for it to absorb ideas freely from the community project. Happy to review preview/beta endpoints, answer questions about real-world sync patterns, and contribute test cases if useful. Thanks for building Morgen — it's the best unified calendar+tasks tool I've found, and it's become load-bearing in my daily workflow. — Nathan nate@lorecraft.io

Nate Davidovich 2 days ago

Make filter options list searchable, alphabetically sorted and fully readable (no more 200 px truncation)

The filter configuration and management in Morgen.so is very cumbersome and time-consuming to use, especially when you have many tags. Specifically: Currently the filter options must be found in a non-searchable, non-alphabetically sorted list. The list is truncated at approximately 200 px and is therefore poorly readable. With the Obsidian integration, I first have to scroll past all listed notes (1200+) before the tags are finally displayed. The configured filters themselves are also truncated at about 200 px, making the names hard to read. This makes working with Saved Filters and tags extremely time-consuming, especially with large note collections from Obsidian or with lots of tagged content from other integrations. Suggestions for improvement: The filter options selection list must be searchable (search field directly at the top of the list). The list should be automatically sorted alphabetically (or optionally, let me choose how it’s sorted: by name / usage frequency / color). I believe there is already a request for this here https://feedback.morgen.so/en/p/enable-sorting-of-tags-alphabetically. If I can search, I probably don’t need sorting. Significantly wider display of the entire filter options list (at least 400–500 px or fully adjustable so that longer names are no longer truncated). The displayed filter names themselves must also be shown in full width and clearly readable (no more 200 px limitation). Optional: Hover preview or tooltip with the full filter name and description directly in the selection list. This would greatly improve daily usage of filters and tags and make Morgen.so much more user-friendly for power users with lots of tags. Thanks a lot and keep up the amazing work. Morgen has already allowed me to stay on top of everything better and faster than anything before. You rock.

Lukas 3 days ago

1

Closed

Inconsistant task data between web app and Mac app

this is super frustrating and almost makes it unusable I am seeing issues with inconsistent data between web app and mac. I cant deal with this, I will end up missing things. I need to be able to trust that when I add a task I will see the task. Also on the mac app, I had to add a task 3 times before it actually showed up. I am on good fibre internet so that should not be the issue.

Mike O'Meara 9 days ago

1

In Review

Task List CRUD endpoints in the API (create, rename, delete, list)

The Morgen API currently has no endpoints for managing task lists. You can create tasks in a list (taskListId), but you cannot create, list, rename, or delete the lists themselves via the API. Current workaround: Create lists manually in the webapp Create a dummy task in each list to discover the list ID via /tasks/list Cannot delete lists programmatically at all Requested endpoints: GET /task-lists/list — List all task lists with their IDs and names POST /task-lists/create — Create a new task list (name, color) PATCH /task-lists/update — Rename or change color POST /task-lists/delete — Delete a task list Use case: I'm building an open-source migration tool from Akiflow to Morgen (https://github.com/ezwep/akiflow-morgen-migration). The biggest friction point is task list discovery — empty lists are invisible to the API, forcing users through a manual workaround. Full CRUD would make migrations and integrations seamless. This would also benefit anyone building Todoist/Notion/Linear-style integrations that need to map external projects to Morgen lists.

ezwep 22 days ago

In Review

When "Week start" is set to Sunday in Preferences, the "Mon - Fri" view option should dynamically update to "Sun - Thu" to reflect the actual workweek.

Currently, the "Mon - Fri" view is hardcoded regardless of the user's week start preference. For users in regions where the standard workweek runs Sunday through Thursday (e.g., Israel), this creates a mismatch: the Week Start setting correctly shifts the calendar grid to begin on Sunday, but the workweek view still displays Monday through Friday - missing the actual first workday (Sunday) and including a day off (Friday). Expected behavior: The workweek view should respect the "Week start" setting and shift accordingly. If Week Start is set to Sunday, the 5-day workweek view should display Sun - Thu instead of Mon - Fri. Current behavior: The "Mon - Fri" view label and the days it displays remain fixed at Monday through Friday, even when Week Start is set to Sunday.

Fade Rudman 23 days ago

Closed

Time to invest in Task Management and Smartphone APP

I think Morgen is the best app on the market when it comes to calendar management, but its task management feels too basic and confusing. I’d suggest using the app TickTick as a reference point. In my opinion, it’s very similar to Morgen, but clearly better when it comes to task management. This is not meant to be polemical, but rather a genuine suggestion from a user who has been using Morgen Premium for more than 2+ years. Morgen has some great features, such as AI and the web app, but I think it’s time to focus on what really matters: task management and the smartphone app. I think you should take inspiration from TickTick, which is truly excellent at being both a good task manager and a good calendar at the same time. This is especially relevant considering that Morgen costs €180 per year, while TickTick costs €35 per year and is growing so well that it now has almost the same calendar management features as Morgen. However, it has a better smartphone app, more advanced task management, and even Wear OS integration, which allows your smartwatch to notify you about upcoming tasks. I will continue using Morgen because I love it and my whole life is organized there, but objectively, Morgen seems to be pushing secondary things like AI (or I saw some people suggesting focusing on “Dashboard Analytics,” which, seriously, what added value does that bring?), while the competition has stronger fundamentals: better task management features and a better smartphone app. Thank you for reading!

Francesco 29 days ago

5