QuestionPunk

Notion Survey Create Database

notion_survey_create_database

Destructive

Create a Notion database built from a survey's questions (typed columns: choices as selects, ratings as numbers, dates, emails and so on) and send every new completed response to it as a page. With backfill (the default) the responses collected so far are sent too, on the server. The database goes inside parentPageId (a page from notion_list_pages; Notion lets QuestionPunk create databases only inside a shared page, so if notion_list_pages returns none, ask the user to share a page with QuestionPunk in Notion). Not idempotent: each call creates another database and points the survey at it, and a survey that already syncs stops sending to its old database, so check notion_survey_sync_get first and confirm with the user before replacing a sync. Sends respondents' answers to Notion. Returns the survey's sync as notion_survey_sync_get does; give the user its databaseUrl.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "surveyId": "<surveyId>",
      "connectionId": "<connectionId>",
      "parentPageId": "<parentPageId>"
    },
    "name": "notion_survey_create_database"
  }
}

Input Schema

Name	Required	Description
`backfill`	No	Also send the responses collected before now, on the server (default true)
`surveyId`	Yes	The survey ID (from survey_list)
`connectionId`	Yes	A connected workspace's id (connections[].id from notion_status)
`parentPageId`	Yes	The page to create the database in (pageId from notion_list_pages)
`includeSummary`	No	Put the AI summary of each response in its page (default true)
`includeTranscript`	No	Put interview transcripts in each page (default true)

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 7, 2026

TDQS

A4.8/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare destructiveHint=true, idempotentHint=false and openWorldHint=true, but the description goes further: it explains exactly what a repeat call does (creates another database, repoints the survey, the old database stops receiving responses), that backfill runs server-side, and that respondents' answers leave the platform for Notion. It also tells the agent to surface databaseUrl from the returned sync object.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the core action and dense with useful detail — nothing is padding. It is one long run-on paragraph, though; splitting the prerequisites, idempotency warning, and privacy note into distinct sentences would improve scanability.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Covers everything an agent needs before a destructive, non-idempotent, cross-system write: prerequisite discovery, permission constraint, irreversibility/replacement warning, confirmation step, data-privacy disclosure, and the user-facing follow-up (databaseUrl). Return values are further covered by an existing output schema.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3, but the description adds real meaning: parentPageId is constrained to a page from notion_list_pages and, more importantly, that Notion only permits database creation inside a shared page. Backfill is clarified as server-side. It adds less to includeSummary/includeTranscript, which are left to the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Specific verb and resource: creates a Notion database from a survey's questions with typed columns (selects, numbers, dates, emails) and streams responses into it as pages. It is clearly distinguishable from notion_survey_link_database and notion_survey_sync_start because it names the database-creation and survey-repointing behavior explicitly.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives explicit when-to-use and when-not-to-use: check notion_survey_sync_get first, confirm with the user before replacing an existing sync, and use notion_list_pages to find a valid parent page. It even handles the failure path — if no pages are returned, ask the user to share a page with QuestionPunk in Notion.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All QuestionPunk tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?