notion-ops-mcp
Related Servers
Alternatives to notion-ops-mcp
No user-submitted related servers found.
Related Servers
- FlicenseNot gradedqualityBmaintenanceRemote MCP server that exposes Notion as tools (search, get, create pages, append blocks, query databases) via Streamable HTTP with bearer auth, designed for deployment on Railway.-
- FlicenseNot gradedqualityDmaintenanceA Python server that integrates MCP with Notion to automate documentation workflows and manage Notion pages via LLMs, supporting operations like creating, updating, and searching Notion content.1-
- AlicenseNot gradedqualityCmaintenanceStateless MCP server exposing the full Notion API as 33 tools, enabling users to manage pages, databases, blocks, comments, users, and file uploads using their own integration token.Apache 2.0
- AlicenseBqualityDmaintenanceMCP server for common Notion page workflows: search pages, inspect content, create structured pages, append rich blocks, and start documents from reusable templates.10MIT
- AlicenseAqualityCmaintenanceUnofficial Notion MCP server built on Notion's private API (token_v2 cookie). Gives LLM agents full read/write access to the entire workspace — no integration token and no per-page sharing.119 npm4MIT
- FlicenseAqualityBmaintenanceAn MCP server exposing eight narrow Notion tools for reading pages and databases and writing additively, without deleting, archiving, or overwriting content.8-
TDQS
Scored across 2 tools
The two tools have clearly distinct purposes: one reads/fetches documents, the other creates or updates them. There is no overlap or ambiguity in their intended use.
Both tool names follow the exact same pattern: a 'notion_' prefix, a verb ('read' or 'publish'), and an object ('document'). The naming is perfectly consistent and predictable.
With only two tools, the server feels thin for the 'notion-ops' scope. However, each tool is broad and capable (bulk reads, conflict-safe writes), so it is borderline rather than severely underdeveloped.
The read and publish tools together cover searching/resolving, reading, creating, and updating documents, which covers most core workflows. The main gap is the lack of an explicit delete operation, but this is a minor omission given the server's apparent focus on content operations.