Low Risk

notion-search

Perform a search over: - "internal": Semantic search over Notion workspace and connected sources (Slack, Google Drive, Github, Jira, Microsoft Teams, Sharepoint, OneDrive, Linear). Supports filtering by creation date and creator. - "user": Search for users by name or email. Auto-selects AI search...

Risk signalsAccepts freeform code/query input (query) · High parameter count (13 properties)

Part of the Notion server.

notion-search is read-only, but an agent in a loop can still rack up calls and cost. PolicyLayer caps every call before it runs. Live in minutes.

SECURE NOTION →

Free to start. No card required.

AI agents call notion-search to retrieve information from Notion without modifying any data. This is common in research, monitoring, and reporting workflows where the agent needs context before taking action. Because read operations don't change state, they are generally safe to allow without restrictions -- but you may still want rate limits to control API costs.

Even though notion-search only reads data, uncontrolled read access can leak sensitive information or rack up API costs. An agent caught in a retry loop could make thousands of calls per minute. A rate limit gives you a safety net without blocking legitimate use.

Read-only tools are safe to allow by default. No rate limit needed unless you want to control costs.

policy.json
{
  "version": "1",
  "default": "deny",
  "tools": {
    "notion-search": {}
  }
}

See the full Notion policy for all 26 tools.

Get this rule live on your own Notion server in minutes. PolicyLayer enforces it on every call, before it runs.

ENFORCE ON MY NOTION →

View all 26 tools →

These attack patterns abuse exactly the kind of access notion-search gives an agent. Each links to the full case and the policy that stops it:

Browse the full MCP Attack Database →

Every attack above starts with a tool call. PolicyLayer checks each one against your policy first, so notion-search only ever does what you allow.

SECURE NOTION →

Other read tools across the catalogue. The same approach applies to each: allow, with a rate cap to control cost.

What does the notion-search tool do? +

Perform a search over: - "internal": Semantic search over Notion workspace and connected sources (Slack, Google Drive, Github, Jira, Microsoft Teams, Sharepoint, OneDrive, Linear). Supports filtering by creation date and creator. - "user": Search for users by name or email. Auto-selects AI search (with connected sources) or workspace search (workspace-only, faster) based on user's access to Notion AI. Use content_search_mode to override. Use "fetch" tool for full page/database contents after getting search results. Each result's "url" field contains a page ID for Notion results (pass directly to fetch tool's "id" param) or a full URL for external connector results (Slack, Google Drive, etc.). Set page_size (default 10, max 25) and max_highlight_length (default 200, 0 to omit) as low as possible to minimize response size. To search within a database: First fetch the database to get the data source URL (collection://...) from <data-source url="..."> tags, then use that as data_source_url. For multi-source databases, match by view ID (?v=...) in URL or search all sources separately. Don't combine database URL/ID with collection:// prefix for data_source_url. Don't use database URL as page_url. <example description="Search with date range filter (only documents created in 2024)"> { "query": "quarterly revenue report", "query_type": "internal", "filters": { "created_date_range": { "start_date": "2024-01-01", "end_date": "2025-01-01" } } } </example> <example description="Teamspace + creator filter"> {"query": "project updates", "query_type": "internal", "teamspace_id": "f336d0bc-b841-465b-8045-024475c079dd", "filters": {"created_by_user_ids": ["a1b2c3d4-e5f6-7890-abcd-ef1234567890"]}} </example> <example description="Database with date + creator filters"> {"query": "design review", "data_source_url": "collection://f336d0bc-b841-465b-8045-024475c079dd", "filters": {"created_date_range": {"start_date": "2024-10-01"}, "created_by_user_ids": ["a1b2c3d4-e5f6-7890-abcd-ef1234567890", "b2c3d4e5-f6a7-8901-bcde-f12345678901"]}} </example> <example description="User search"> {"query": "john@example.com", "query_type": "user"} </example>. It is categorised as a Read tool in the Notion MCP Server, which means it retrieves data without modifying state.

How do I enforce a policy on notion-search? +

Register the Notion MCP server in PolicyLayer and add a rule for notion-search: allow, deny, rate-limit, or require approval. Point your MCP client at the PolicyLayer proxy URL and the rule is enforced on every call, before it reaches Notion. Nothing to install.

What risk level is notion-search? +

notion-search is a Read tool with low risk. Read-only tools are generally safe to allow by default.

Can I rate-limit notion-search? +

Yes. Add a rate_limit block to the notion-search rule in your PolicyLayer policy. For example, setting max: 10 and window: 60 limits the tool to 10 calls per minute. Rate limits are tracked per agent session and reset automatically.

How do I block notion-search completely? +

Set action: deny in the PolicyLayer policy for notion-search. The AI agent will receive a policy violation error and cannot call the tool. You can also include a reason field to explain why the tool is blocked.

What MCP server provides notion-search? +

notion-search is provided by the Notion MCP server (@notion-mcp-server). PolicyLayer sits as a proxy in front of this server to enforce policies before tool calls reach the server.

Enforce policy on every Notion tool call.

Deterministic rules across all 26 Notion tools. Per-identity grants. Full audit log. Live in minutes. Nothing to install.

Free to start. No card required.

4,600+ MCP servers and 31,000+ tools scanned and risk-classified.

// GET IN TOUCH

Have a question or want to learn more? Send us a message.

Message sent.

We'll get back to you soon.