The first failure mode in a Notion MCP integration is rarely a missing tool. It is assuming that a visible tool name implies access to the whole workspace. makenotion/notion-mcp-server exposes the official entry point npx @notionhq/notion-mcp-server, while the independent Doramagic capability pack puts page access checks, workspace boundaries, and tool verification before any serious workflow.
I would treat the first run as a permission-routing test, not as a successful plugin installation. Start with a temporary workspace or test page. Confirm that the host points at the intended MCP server, confirm that the Notion integration has access to that page, and prove the access with a read-only call. A page visible in the Notion UI is not evidence that the integration token can read it.
The source map gives a useful debugging route. src/init-server.ts and scripts/start-server.ts describe startup; src/openapi-mcp-server/mcp/proxy.ts maps the OpenAPI description into MCP tools; src/openapi-mcp-server/openapi/parser.ts handles tool parsing; and src/openapi-mcp-server/auth/ plus client/http-client.ts define authentication and request boundaries. When a tool appears but a call fails, inspect the layer: host configuration, auth, OpenAPI translation, or the Notion API's permission response.
My first verification sequence would be deliberately small: run npx @notionhq/notion-mcp-server only through the documented entry path, read one test page, compare the returned page id with the expected id, then try one minimal update. Record the actual response and the page permission state after every step. Do not use a team knowledge base, private pages, or a production integration token as the first test fixture.
There is an important evidence boundary here. The pack does not prove that Notion MCP has been installed, run, or successfully called on this machine. Its quick start, Human Manual, and eval files are routes for validation, not runtime output. The pack also flags configuration, installation, runtime, and permission risks, so the official quickstart should be reproduced in an isolated environment. A process that starts is not proof that the target page is readable, and readable is not proof that an agent can safely write.
My operator rule is simple: give the agent one test page first, then expand the grant. Put the page id, workspace, integration permission, and exact error response into the acceptance record. Only connect a working knowledge base after read, minimal write, and revoked-permission failure are all observable.
This is an independent Doramagic capability pack, not official Notion documentation or an endorsement. Project page: https://doramagic.ai/en/projects/notion-mcp-server/; upstream: https://github.com/makenotion/notion-mcp-server.
Top comments (0)