Skip to main content
Glama
Sign In
notion-mcp

notion-mcp

by snickery
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

notion_create_database

Create a Notion database under a parent page by defining a property schema or using a typed tasks, projects, or skills database.

Instructions

Create a new Notion database under a page.

parent_page_id: page to create the database under. title: database title (optional for a typed database, which is otherwise named after its type). schema_json: JSON object mapping property names to their type config in Notion API format. A title property is required. Example: { "Name": {"title": {}}, "Status": {"select": {"options": [ {"name": "To Do", "color": "red"}, {"name": "Done", "color": "green"} ]}}, "Due Date": {"date": {}}, "Priority": {"number": {"format": "number"}}, "Tags": {"multi_select": {"options": [ {"name": "bug"}, {"name": "feature"} ]}}, "Assignee": {"people": {}}, "Done": {"checkbox": {}}, "Notes": {"rich_text": {}}, "Link": {"url": {}} } database_type: "tasks", "projects" or "skills" creates one of Notion's typed databases with its built-in schema INSTEAD of schema_json (they cannot be combined). Run notion_describe_database afterwards for the exact property names. inline: True shows the database inline on the parent page; default is a full-page database.

Input Schema

NameRequiredDescriptionDefault
titleNo
inlineNo
schema_jsonNo
database_typeNo
parent_page_idYes

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed5 schema fields changedv0.2.2
    • addedInput schema / properties / database_type
      Added value: +{
+  "default": "",
+  "title": "Database Type",
+  "type": "string"
+}
    • addedInput schema / properties / inline
      Added value: +{
+  "default": false,
+  "title": "Inline",
+  "type": "boolean"
+}
    • addedInput schema / properties / schema_json / default
      Added value: +""
    • addedInput schema / properties / title / default
      Added value: +""
    • changedInput schema / required
      Previous value: -[
-  "parent_page_id",
-  "title",
-  "schema_json"
-]New value: +[
+  "parent_page_id"
+]
  2. First observedv0.1.0

TDQS

A4/5.0
Behavior3/5

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

With no annotations, the description carries the full behavioral burden. It does disclose meaningful defaults (inline=False means a full-page database; title is optional for typed databases since they are named after their type) and that a title property is required. It is silent on permissions/integration access to the parent page, failure modes (name collisions, invalid schema), and whether the operation is reversible — significant gaps for a mutation tool with zero annotation coverage.

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?

The one-line summary is front-loaded and each parameter block is clearly labeled. The 9-property schema_json example is long for a description, but it substitutes for absent schema documentation and illustrates several property types, so most of it earns its place; some pruning (e.g., Notes/Link/Assignee) would tighten it.

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

Completeness4/5

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

An output schema exists, so return values need no explanation, and the description fully covers the non-trivial input surface including the typed-vs-custom fork and the required follow-up call. What's missing is authority/error context — whether the integration must already have access to the target page and what happens if schema_json is malformed.

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

Parameters5/5

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

Schema description coverage is 0%, so the description must carry all five parameters — and it does. It explains parent_page_id, title's conditional optionality, inline's True/False effect, database_type's three values and exclusivity with schema_json, and shows the full Notion API schema_json shape with a worked example plus the 'title property is required' constraint.

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

Purpose4/5

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

Opens with a specific verb + resource + placement: 'Create a new Notion database under a page.' That distinguishes it from notion_update_database and notion_query_database by scope. It stops short of naming a sibling or stating when to prefer notion_create_page with a database, so it isn't a full 5.

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

Usage Guidelines4/5

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

Gives concrete routing rules: database_type ('tasks', 'projects', 'skills') creates a typed database INSTEAD of schema_json, and the two 'cannot be combined'; plus a follow-up instruction to run notion_describe_database for exact property names. That is real when/when-not guidance, though it never addresses the create_database vs create_page/add_data_source boundary.

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

Deploy Server

Other Tools