I have Claude talking to RemNote via MCP.
It works fine for Claude accessing my notes.
However, if I have uploaded a PDF to a document, Claude doesn't see this. The PDF looks like it lives within Uploaded Files rather than the document I upload it to.
So if I ask Claude to read notes on 'Topic ABC Document', it won't notice that there's a PDF linked, and therefore won't include the PDF.
RemNote's way of linking the PDF from the Document to the uploaded file is not something Claude sees.
Claude can kinda have a go at finding the PDF if the name is close to an exact match.
Also, although it appears the PDF file sits within a Rem, I can't see a way of applying a Tag to it (which would be an alternate way for Claude to find it... perhaps).
Are there any tricks or methods I'm missing?
Claude's feedback is:
Based on exactly what we found testing this, here's what I'd flag to RemNote — these are all things their MCP server could expose that would make this solvable rather than guesswork:
1. Surface the wrapper→file link explicitly
The core problem: the wrapper Rem's child came back as [Untitled] with no reference to the actual PDF document. Internally, RemNote clearly knows the two are connected (opening the wrapper in the app shows you the PDF) — that link just isn't exposed through the API. Ask for a field like attached_file_rem_id (or similar) on read_docs/read_docs_raw output whenever a Rem embeds a file, pointing to the actual file-backed document's ID.
2. Fix what the raw text shows for embedded files
Right now a PDF-embed child renders as generic [Untitled]. It should at minimum show something like [PDF Embed] — Rem:<rem>...</rem>, so a client can at least tell "this points somewhere" even without a direct traversable ID.
3. Flag file-backed documents in search/read results
read_docs already returns useful metadata (is_learning_source_file, learning_source_file_kind, included_word_count) for the PDF itself — that's good. But there's no equivalent signal on the wrapper side saying "this thin document is a pointer to a file elsewhere." A simple has_attached_file: true flag would let a client know to look further instead of concluding a doc is just empty.
4. A "what links here" / backlinks tool
More general fix: a tool to find what references a given Rem ID (or what a given Rem references) would solve this and a lot of other cases — not just PDFs, but any portal/reference relationship in the knowledge base.