Add optional Notion API fallback for MCP functionality gaps

[0xble]

I’m still running into a few high-impact gaps where MCP can’t currently do the operation, and those are painful for real workflows (especially automation).

Most impactful to least impactful from what I’m seeing:

1. archive/delete pagees
2. change page icon
3. uploading local files/images (for example ./image.png) breaks unless files are hosted first
4. reading very large page properties (eg big relations/people lists) can be incomplete and REST has better endpoints for full/accurate reads

Btw I completely agree with the notion-cli MCP-first where possible over API. That should stay the default. Curious what you would think tho about MCP-first + REST-fallback model

On my fork I have implemented:

• Official API primitives/foundation (typed API client + config + CLI wiring, no feature-specific behavior): feat(api): add core API client primitives 0xble/notion-cli#14
• Auth setup + wizard UX for API (auth api setup/status/verify/unset): feat(auth): add official API token setup flow 0xble/notion-cli#10
• Set/claer icon support (page edit --icon): feat(page): add api-backed --icon support 0xble/notion-cli#15
• Adds page archive support: feat(page): add api fallback for archive command 0xble/notion-cli#11
• Adds page property get command with paginated reads for complete large property values: feat(page): add api command for full property reads 0xble/notion-cli#13
• Local markdown image fallback: detect local paths, upload via API, append uploaded image blocks: feat(page): add api fallback for local markdown images 0xble/notion-cli#12

[lox]

Triage update after v0.5.0:

• Property updates are now available via page edit -P/--prop (feat(page): add --prop and --allow-deleting-content #24), so that part is done.
• Local image handling remains open and is tracked in page upload/sync drops local markdown image embeds #13.
• Keeping this issue open as the umbrella request for optional API fallback support (archive/delete, icon updates, and full large-property reads where MCP is limited).

If you want to upstream your fork work incrementally, the easiest path is small scoped PRs per capability.