Feature Requests

Allow date formats to be changed to suite locale/preference. E.g. I'm British and prefer to read d m Y / d-m-Y / d of m, Y / etc.

I work with Europeans and North Americans - sending either of them materials with dates in DD/MM/YYYY format or MM/DD/YYYY format leads to confusion. YYYY-MM-DD dates are unambiguous for both groups.

The MCP server currently exposes whichever graph is active in the desktop app. Switch graphs, and the AI sees different data. Fine as a first version – honestly, I get why it works this way. What I'd actually want: access to more than one graph at a time. I have three, and the moment I'm doing anything interesting, context is scattered across at least two of them. Right now, I have to manually switch in the UI and hope Claude picks up the change, which it does, but only one graph at a time. The local server at 127.0.0.1:7676 could expose separate endpoints per graph – something like /mcp/personal, /mcp/whatnot – and let users configure each as its own MCP server in Claude Code, Cursor, etc. Small change on Reflect's side, meaningful difference in practice.

create_note is idempotent – if a note with the same subject exists, it returns that note without any indication that's what happened. The caller has no way to tell whether a new note was created or an existing one was returned, short of inspecting the content by hand. A boolean created field in the response would be enough. This matters whenever the intent is a fresh note – right now, you only discover you got an existing one when the content looks wrong.

replace_text_in_block is the most ergonomic edit tool the MCP has – no position math, just find-and-replace. But it's limited to text within a single paragraph. The moment the target spans a line break, you're back to get_note_outline + replace_range, which is five times the work for what should be a small edit. Extending it to work across adjacent blocks – or at least adjacent list items – would cover most real-world editing cases without changing the simple API surface.

delete_tag removes a tag from the graph-level tag list but leaves it on every note that already uses it. The tag still exists in the graph; it's just orphaned from the UI. The name implies full deletion. Either rename it to something like remove_tag_from_index to be honest about the scope, or add a parameter to cascade the removal to all notes. As it stands, calling it leaves things in a state that's worse than before – notes carrying a tag that no longer shows up in any tag filter.

get_note_outline returns block positions as raw integers. Any write invalidates them – silently, until a follow-up call errors with INVALID_POSITION. By then, you've lost track of what you were doing and have to fetch the outline again from scratch. A revision token attached to both the outline response and write calls would let clients detect staleness before making the call, not after. Even a lastModified timestamp would help. Right now, the API just asks you to guess.

With the focus on living in daily notes, it’d be helpful to be able to see other backlinks to a given subject. Right now you can hover over a reference and it provides a mini-note summary, but if all context lives in backlinks this becomes less useful. Here’s a few options we posted in Discord… Option 1: Perhaps updating the right-sidebar where the “Outgoing links & Tags” are listed to embed other backlinks to same note would help? Option 2: If my daily note has a top-level bullet of "Call with [[person]] of [[company]] re [[project]]" then as long as my cursor is focused on that line, or any sub-bullets of it, bring up a panel at the bottom of the screen with backlink references for each of the Notes mentioned that has back references. That way I can stay on the Daily Note, take notes, but have all the context of the related notes on screen at the same time. Basically just copy the split-pane UI you have on an individual Note, and have it dynamically update (and allow showing multiple of them) on the Daily.

to have a my tasks sort in order by date and a weekly or monthly view of them. Maybe also an integration with Zapier to load them in Google caldendar for example.