Read and write attachments (PDFs, images) via bearcli / MCP server

Bear feedback Feature Request
1

Hi Bear team,

Thanks for bearcli and the Claude Connector. They’ve changed how I use my notes, and I really appreciate that you built an official, safe path rather than leaving it to third-party tools.

There’s one gap that matters a lot for my use. The CLI and MCP server can’t read attachments. list_attachments shows filenames and sizes, but there’s no way to get at the content. My library has thousands of notes with attached PDFs, such as scanned letters, invoices, manuals and articles. For many of those notes, the attachment is the actual knowledge and the note text is just a title. So when I ask Claude about these notes, it sees almost nothing.

What would help, roughly in order of priority:

  1. Attachment text via CLI/MCP. Bear already OCRs PDFs and images for search. Exposing that text, for example through bearcli attachment text <note> <filename> and an equivalent MCP tool, would already solve most cases.
  2. Raw attachment export. Something like bearcli attachment export <note> <filename> --to <path>, so tools can read the original file, including layout, tables and images.
  3. An MCP tool that returns the attachment itself, e.g. a PDF or image as an MCP resource, so AI clients can read it natively.

Related, but lower priority: an optional HTTP transport for the MCP server, which others in the 2.8 thread have also asked for. Combined with the new workspaces for scoping, it would let people reach their notes from Claude on the phone or web while the Mac is at home.

Bear’s “your notes, your tools” philosophy is exactly why I’d love to stay. Attachments are currently the one part of my data the tools can’t reach.

Thanks!

1 Like
2

The CLI already have bearcli attachments save .... See bearcli help attachments save for details. As the CLI is sandboxed, it can’t write itself to disk, so you have to pipe it.

It isn’t feasible. AIs can’t handle binary data as part of context and anything you communicate over MCP goes into its context.

This is something we could consider, but the context size is a problem also in this case, at least for MCP. I will take a note about it.

Not sure how we would do it. We don’t run any servers so it would depend on your computer being the server. And it would need to handle authentication. Not sure we want to go in that direction.