Notion MCP query-data-sources view mode as a Sume job ledger

The change

Notion's September 29 changelog entry says notion-query-database-view is being phased out and that you should call notion-query-data-sources with mode: "view" instead. If an agent reads a database view of your video jobs, update the call now.

A ledger is a simple pattern: one Notion row per Sume job, holding the job id, the status and the result URL. Your automation writes it; the agent only reads it.

Facts from Notion

Read from the MCP supported tools page and the changelog.

Ledger columns

Keep the schema small. A row needs the Sume job_id, a status that mirrors queued, processing, completed, failed or canceled, the media.sume.com URL once the job completes, and the idempotency key you sent. The webhook event is the right writer: Sume posts job.completed, job.failed or job.canceled, and the job_id is the idempotency key for the delivery, so an upsert by job id absorbs retries.

Delivery retries up to 10 times, 30 seconds apart, with 10 seconds allowed per attempt. Verify the signature before you write a row. The scheme is HMAC-SHA256 over the timestamp, a dot and the raw body, with a five minute replay window.

import hashlib, hmac, time

def verify(secret, ts, body, header):
    if not secret:
        raise ValueError('empty signing secret')
    if abs(time.time() - int(ts)) > 300:
        return False
    mac = hmac.new(secret.encode(), ts.encode() + b'.' + body, hashlib.sha256).hexdigest()
    return any(hmac.compare_digest(p.strip(), 'sume-v1=' + mac) for p in header.split(','))

Reading it back

Ask the agent to query the data source in view mode for rows where status is failed. At 20 queries per 10 seconds, a loop that polls once a second is fine, but one that fans out per row is not. Read the whole view with a limit of 100 and filter in memory.

The ledger is a record, not the source of truth: /v1/jobs/:id/status is. If a row and the API disagree, trust the API and fix the row. See jobs and results and webhooks.