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

1. 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 <field> 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.

2. 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.

3. 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