The set is close to symmetric: database, page and block can each be read and changed, and archiving stands in for deletion on pages and blocks. Reach is decided outside the server, so whatever the integration has been granted is exactly what search and list-databases will see. Paging is explicit on the query, children and search calls, which means large collections arrive a cursor at a time.
A Notion server covering the database, page and block layers of the API, with workspace search on top.
- Database work: list what the integration can reach, query one by ID with filters, sorts and cursor paging, create a database under a parent page, and change an existing one's title, description or property schema.
- Page work: create a page in a database with its properties and initial children, fetch a page by ID, and update its properties or archive it.
- Block work: read a block, list a block's children with paging, append children to a block, and change a block's content or archive status.
- Search across pages and databases with a filter, a sort and paging.
A Notion integration with the databases and pages you want reachable shared with it — list-databases returns only what that integration has been granted.
One command plus a key — npx -y @sjotie/notion-mcp-server, then supply credentials
