Skip to main content
Glama

query_database

Search Notion database entries using keyword text, filters, or sorts. Pass advanced Notion filter syntax for precise queries, or resolve a page's inline database.

Instructions

Query a database with optional filters, sorts, or text search. Use text for simple keyword search across title, rich_text, url, email, and phone fields. For advanced filters, pass Notion filter syntax and call get_database first to see property names and valid options.

Response shape: { results: Array, warnings?: Array }. Multi-value properties are capped by max_property_items and can emit truncated_properties; read resources easy-notion://docs/property-pagination and easy-notion://docs/warnings for details.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
textNoSearch text — matches across all text fields (title, rich_text, url, email, phone)
sortsNoOptional Notion sorts array
filterNoOptional Notion filter object
page_idNoAlias accepted when database_id is absent. If the ID is a page containing exactly one inline database, it resolves to that database. Providing both database_id and page_id with different values is an error.
database_idNoDatabase ID
max_property_itemsNoMax items returned per multi-value property (title, rich_text, relation, people). Default 75. Set to 0 for unlimited. Negative values rejected. When the cap is hit, the response includes a truncated_properties warning with a how_to_fetch_all hint.
Install Server

TDQS

A4.1/5.0
Behavior4/5

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

With no annotations, the description carries the behavioral burden. It discloses the response shape, warning behavior, max_property_items cap, truncated_properties emission, and links to relevant docs. It stops short of explicitly stating read-only behavior or error handling, but overall it is transparent for a query tool.

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?

The description is front-loaded with a concise purpose, followed by usage guidance and a compact response-shape explanation. Each sentence earns its place, including the links to edge-case documentation.

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?

For a 6-parameter query tool with no output schema, the description covers the response format, parameter usage, and important edge-case behavior. It could optionally explain top-level result pagination, but the linked docs and warning details make it sufficiently complete for an agent to invoke correctly.

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 covers 100% of parameters, so baseline is 3. The description adds value by explaining text search fields, advising get_database for advanced filter options, and detailing max_property_items behavior beyond the schema.

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?

The description clearly states the tool queries a database and lists the available operations: filters, sorts, and text search. It differentiates from siblings like query_view by specifying the resource as a database, though it does not explicitly name the sibling alternative.

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?

Provides practical guidance on when to use text search versus advanced filters, and instructs the agent to call get_database first for valid property names. It does not explicitly contrast with query_view or state exclusion criteria, but the in-tool routing is clear and actionable.

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

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/Grey-Iris/easy-notion-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server