Context
An agent (Codex) reading a note via a memory:// URL reported: "the note reader rejected its advertised paging parameter, so I'm retrying without paging." It then succeeded on the retry.
What's actually happening
read_note does not advertise or accept paging — its signature is identifier, project, project_id, output_format, include_frontmatter only (src/basic_memory/mcp/tools/read_note.py:64-77), and the docstring doesn't mention paging. So the agent's "advertised paging parameter" is a reasonable but mistaken inference: every sibling navigation tool supports pagination —
build_context → page / page_size (build_context.py:136-167)search_notes → page / page_size with AliasChoices (search.py:570+)recent_activity → same pattern
Because read_note is the lone exception, the agent passed page/page_size, FastMCP rejected them as unexpected kwargs (Pydantic validation), and the agent fell back to a no-paging retry.
Why it's a problem
- Inconsistent surface across the read/navigate tools invites exactly this failed first attempt (extra round-trip, agent confusion).
- No way to page a large note.
read_note returns the whole note or nothing; there's no chunked read, so very large notes can't be paged the way build_context/search_notes results can.
- Opaque error on the rejected params — the agent gets a schema-validation failure, not a hint that this tool doesn't page.
Suggested fix
Add page / page_size to read_note for parity with build_context / search_notes / recent_activity (same Annotated[... Field(validation_alias=AliasChoices(...))] pattern, documented in the docstring), paging the note content. read_note's existing search-fallback path already routes through search_notes, which computes pagination internally, so the plumbing is partly there.
Alternatively (minimal): explicitly document that read_note doesn't paginate and have it tolerate/ignore stray page/page_size rather than hard-rejecting — but parity is the better fix.
Context
An agent (Codex) reading a note via a
memory://URL reported: "the note reader rejected its advertised paging parameter, so I'm retrying without paging." It then succeeded on the retry.What's actually happening
read_notedoes not advertise or accept paging — its signature isidentifier,project,project_id,output_format,include_frontmatteronly (src/basic_memory/mcp/tools/read_note.py:64-77), and the docstring doesn't mention paging. So the agent's "advertised paging parameter" is a reasonable but mistaken inference: every sibling navigation tool supports pagination —build_context→page/page_size(build_context.py:136-167)search_notes→page/page_sizewithAliasChoices(search.py:570+)recent_activity→ same patternBecause
read_noteis the lone exception, the agent passedpage/page_size, FastMCP rejected them as unexpected kwargs (Pydantic validation), and the agent fell back to a no-paging retry.Why it's a problem
read_notereturns the whole note or nothing; there's no chunked read, so very large notes can't be paged the waybuild_context/search_notesresults can.Suggested fix
Add
page/page_sizetoread_notefor parity withbuild_context/search_notes/recent_activity(sameAnnotated[... Field(validation_alias=AliasChoices(...))]pattern, documented in the docstring), paging the note content.read_note's existing search-fallback path already routes throughsearch_notes, which computes pagination internally, so the plumbing is partly there.Alternatively (minimal): explicitly document that
read_notedoesn't paginate and have it tolerate/ignore straypage/page_sizerather than hard-rejecting — but parity is the better fix.