Notion MCP 20 calls per 10 seconds: poll Sume jobs less

Notion's changelog entry of Sept 28, 2026 says Notion MCP now allows 20 search calls and 20 data source query calls per connection every 10 seconds. An agent that also polls Sume job status in a tight loop spends its turns on polling. Submit the Sume job with a webhook, so the agent only reads Notion when something has changed.

Notion's limit applies to Notion calls per connection; Sume's status reads are separate requests to Sume. They compete only for the agent's turns and your code's time. Sources: Notion's changelog, read 2026-10-01, and Sume's Jobs and results.

What does the Notion limit actually cover?

The entry names two call types: search and data source query, 20 each per connection per 10 seconds. The same changelog lists a separate per-connection ceiling over a 60-second window: 600 requests per minute on Business and Enterprise plans and 180 on all other plans. Read the changelog for the current text before sizing a loop.

How do async and webhook modes differ for an agent?

What should I do with the webhook?

Use job_id as the idempotency key on your side, since Sume delivers up to 10 attempts in total with a fixed delay. When the event arrives, write the result to Notion once. That is one write path instead of a poll loop beside a Notion search loop.

Do I still need status polling?

Yes, as a backup. The docs say to keep status_url polling available because a delivery can fail after ten refused attempts while the job still reaches its terminal state. Poll slowly, for example once when the webhook is late, and do not resubmit the paid request. For the Notion-to-Sume direction, see can Notion send webhooks to start an AI video job.