Using the latest version (4.4) and the built-in MCP server with Claude:
There’s an issue with long PDFs not returning the entire document.
Specifically on PDFs up to about 340 pages, extract_record_content works as documented. But on books larger than 500, it doesn’t. On a long document, asking for pages: "200" returns the cover and copyright page instead, and query never finds anything past roughly page 100, even for words I know are in chapter 30.
The text is there (word counts match page counts, and a native search_records for those same deep-chapter words returns the books as top hits). So DEVONthink’s index sees the whole book…the MCP extraction path stops early.
File size doesn’t explain it (the 744-page file is 53 MB, and 180 MB files work fine). Page count is the only thing that separates the failures from the successes.
Two smaller things from the same sessions: is_running returned false while everything else worked, and ocr_record on the 744-page book blew past Claude’s 4-minute call limit (the OCR kept running in-app, so probably just worth a note in the docs).
Anyone know if there is a page limit in the extraction path, and is there a way to read late pages of a long PDF over MCP in the meantime?
Welcome @wyrbw
What are you specifically doing with such a PDF and the MCP server?
And of course, page count is a factor, compared to file size. The context window also matters and is affected by this.
Also, a page range can be provided to tools-capable AI models…
Does the PDF actually have a useful text layer? Or what exactly should “word counts match page counts” mean? Most likely it’s a timeout issue if the PDF is not processed in chunks by Claude.
Yes, the text layer is there and usable. “Word counts match page counts” was shorthand for: DEVONthink reports 134,361 words over 500 pages, 198,379 over 628, and 292,710 over 744, which is 270 to 390 words per page, normal density for a book. And native search proves the deep pages are indexed: a search_records query for Austrian state names (Vorarlberg, Burgenland, Kärnten) that appear only in a chapter around page 85 returns the 500-page book as the top hit.
I don’t think it’s a timeout, because the calls come back promptly with content, just the wrong content. On the same record, extract_record_content with pages: "12" and max_token_count: 1500 returns page 12 correctly; pages: "100" with max_token_count: 400 comes back immediately with the cover, copyright page, and contents as a single unpaginated body. Same behavior for pages: "200" and pages: "243,244". The requests were already small; the page index just seems to stop being honored past some point. In query mode on the same records, hits never come from beyond roughly page 50 to 120.
The one call that did time out was different: after running ocr_record on a copy of the 744-page book (Compress PDF on, resolution As source), the output grew from 53 MB to 389 MB, and extract_record_content on that record hangs the server outright, reproducibly after a restart. The recognition itself improved, so I’d like to keep using OCR; is that size growth expected with those settings?
I have a few hundred historical books that I use Claude over the MCP server to help pull verbatim quotes. Most books are long, so the pages parameter is the feature I lean on most.
