Skip to main content
Glama

notion_pages_retrieve

Read-onlyIdempotent

Retrieve a Notion page's properties by ID to inspect metadata such as status, owner, or dates, with optional filtering by property IDs. Does not return page content.

Instructions

Get a page's properties. This does not return the page's content — the blocks are read with blocks_children_list, or all at once as Markdown with pages_retrieve_markdown. A property holding more than 25 entries comes back truncated; read it in full with pages_retrieve_property_item.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
pageIdYesThe ID of the page.
filterPropertiesNoProperty IDs to return, instead of all of them. A page that does not have a listed property simply omits it.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.5/5.0
Behavior4/5

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

Annotations already cover safety (readOnlyHint, idempotentHint, openWorldHint), so the description is free to add the traits the annotations cannot: that properties are truncated past 25 entries and where to read the full value. It does not cover anything about rate limits or auth scope, but the truncation disclosure is a genuinely useful behavioral detail.

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

Conciseness5/5

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

Three sentences, zero filler, front-loaded with the core statement of scope followed by the exclusions and the truncation caveat. Every sentence earns its place by preventing a specific misuse.

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?

No output schema exists, yet the description tells the agent what the response does and does not contain, and what to do when it comes back incomplete. For a two-parameter read tool this covers everything needed to call it correctly and interpret the result.

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

Parameters3/5

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

Schema description coverage is 100%, so pageId and filterProperties (including the omit-on-missing-property behavior) are already documented in the schema. The description adds nothing about parameter formatting or the filterProperties include-list. Baseline 3 is appropriate when the schema does the heavy lifting.

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?

States a specific verb and resource ('Get a page's properties') and immediately draws the boundary against the nearby concept of page content, so an agent can distinguish it from notion_pages_update, pages_retrieve_markdown and blocks_children_list.

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?

Explicitly names when NOT to use it ('This does not return the page's content') and routes to the correct alternatives by name (blocks_children_list, pages_retrieve_markdown, pages_retrieve_property_item). The condition that selects the alternative (truncation over 25 entries) is given, not left to inference.

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