mcp-notion-fast

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.0
Disambiguation5/5
Each tool targets a distinct resource and action: status, search, page CRUD, database retrieval/query, and block operations. There is no ambiguity between tools like get_database and query_data_source, as they serve different purposes (schema discovery vs. data querying).
Naming Consistency4/5
Most tools follow a consistent verb_noun pattern (search_notion, get_page, create_page, update_page, get_database, query_data_source, list_block_children, append_block_children, get_block, update_block, delete_block). The exception is notion_status, which uses a noun phrase instead of a verb-first convention, creating a minor but noticeable deviation.
Tool Count5/5
With 12 tools, the set is well-scoped for the Notion API domain, covering pages, databases, blocks, and search without redundancy or excessive specialization. The count falls comfortably within the ideal range for a focused MCP server.
Completeness4/5
The tool surface comprehensively covers core Notion operations: search, page lifecycle (create, read, update including trash via update_page), database retrieval/query, and block management (list, append, get, update, delete). A dedicated delete_page is missing, but update_page's trash capability makes it workable, so the gap is minor rather than blocking.
Average 3.4/5 across 12 of 12 tools scored. Lowest: 2.4/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 5 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate a non-read, non-idempotent, non-destructive operation. The description adds no additional behavioral context, such as effects on the parent, required permissions, atomicity, or response behavior. It only repeats the basic create action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely brief ('Create a Notion page under a page or data source parent.'). While concise, it is under-specified for a tool with 5 parameters and nested objects, crossing from conciseness into incompleteness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description lacks essential context for correct usage, such as how to structure properties for database parents, valid parent types, or that children blocks can be included. Given the tool's complexity and 0% schema coverage, this is a substantial gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 5 parameters with 0% description coverage. The description mentions only 'parent' context and fails to explain properties, children, icon, cover, or their relationships. It does not compensate for the missing schema documentation.
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 a specific action ('Create a Notion page') with a constrained parent context ('under a page or data source parent'). It distinguishes from sibling tools like update_page or delete_block. However, it doesn't fully differentiate from hypothetical create tools in other contexts and uses the slightly technical term 'data source parent'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives. The description gives context ('under a page or data source parent') but doesn't mention exclusions or alternatives. Siblings like append_block_children or update_page are not referenced.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate a non-read-only, non-idempotent mutation, but the description adds no behavioral context such as authentication requirements, side effects on existing children, or ordering behavior. 'Append' implies modification, but no specifics are disclosed beyond what annotations already state.
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 description is a single sentence, front-loaded with the action, and contains no excessive wording. However, the closing clause 'using the current Notion position object API' is somewhat unclear and adds limited value, slightly detracting from overall structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With nested object parameters and an output schema, the tool is moderately complex, yet the description provides only the basic operation. It does not explain the children array format, the position object, or any constraints, making it insufficient for an AI agent to reliably invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and the description provides no explanation for blockId, children, or position. While parameter names are partially self-explanatory, the description fails to clarify the structure of the children objects or the optional position parameter, especially given the reference to the 'current position object API'.
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 uses the specific verb 'Append' with the resource 'block children', clearly distinguishing it from sibling tools like list_block_children and get_block. The phrase 'current Notion position object API' is vague but does not obscure the core purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as update_block or create_page. There are no mentions of prerequisites, exclusions, or scenarios where this tool is preferred, leaving the agent to infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false and destructiveHint=false, and the description does not contradict them. The phrase 'validated JSON object payload' adds a small bit of behavioral context beyond the schema, but it does not disclose side effects, permissions, or error handling. Since annotations cover the safety profile, this is acceptable but not rich.
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 a single, front-loaded sentence with no filler. Every word contributes to stating the operation and the payload requirement, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While an output schema exists, the description lacks contextual details such as what kind of updates are supported (partial vs. full), how the patch should be structured for different block types, and when to use this tool over update_page. Given the tool's moderate complexity with a nested object parameter, this description is incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/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 compensate by explaining parameters. It mentions 'JSON object payload' which refers to the 'patch' parameter, but it does not explain the structure or accepted fields, nor does it mention 'blockId'. The minimal hint is insufficient for the patch object's arbitrary 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 action ('Update') and the resource ('Notion block'), making the tool's purpose understandable. However, it does not explicitly distinguish this tool from its sibling tools like update_page or delete_block, so it lacks sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as update_page or get_block. There is no mention of prerequisites, scenarios, or when not to use it, leaving the agent without any usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already indicate readOnly and idempotent behavior, so the description doesn't contradict them. However, it adds no additional behavioral context beyond the annotations and schema, such as explaining the meaning of compound filters or the pagination cursor mechanics. It doesn't mention any side effects, rate limits, or authentication requirements, but those are less critical for a read-only 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 a single, front-loaded sentence that wastes no words. It communicates the core action and capabilities efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite the presence of annotations and an output schema, the description is too sparse for a tool of this complexity. It does not explain how to construct compound filters, what sort objects look like, how pagination cursors work, or what 'filterProperties' refers to. An agent would have difficulty invoking this tool correctly based on this description alone, especially given the complete lack of parameter documentation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has zero documentation coverage for its six parameters. The description mentions 'compound filters, sorts, and pagination,' which maps loosely to filter, sorts, pageSize, and startCursor, but it never names these parameters or explains their structure. The 'filterProperties' parameter is completely unaddressed, and the formats for filters/sorts are not described. This provides only vague hints beyond the raw property names.
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 identifies the action ('Query'), the target resource ('a Notion data source'), and key capabilities ('compound filters, sorts, and pagination'). It distinguishes from sibling tools that operate on pages/blocks, but it doesn't explicitly contrast with search_notion or get_database, so it's clear but lacks explicit differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for querying with complex filters, sorts, and pagination, but it gives no explicit guidance on when to choose this over alternative tools such as search_notion, get_database, or get_page. There are no exclusion criteria or when-not-to-use statements.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, covering the safety profile. The description adds useful scope context ('shared with the Notion integration') but does not disclose pagination, sorting, or result behavior. This meets the lower bar expected when annotations are present.
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 a single, front-loaded sentence with no filler. Every word contributes to communicating the core action and scope, making it appropriately concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 5 optional parameters and an output schema, the description provides only a high-level object scope. It omits guidance on how to leverage query, pagination, or sorting, making it incomplete for an agent to invoke the tool effectively in varied scenarios.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/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 compensate for parameter explanations. It only hints at the 'object' parameter via 'pages or data sources' and ignores query, pageSize, startCursor, and sortDirection, leaving the agent without adequate parameter-level guidance.
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?
Description uses active verb 'Search' and specifies resource 'pages or data sources shared with the Notion integration.' It clearly differentiates from sibling tools like get_page/get_database by indicating a cross-resource search operation, though it doesn't explicitly contrast with query_data_source.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by stating what is searched, but it provides no explicit when-to-use guidance, no exclusions, and no mention of alternative tools. It is not misleading, just minimal.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint and idempotentHint, so the safety profile is clear. However, the description adds little beyond the core behavior; it does not mention pagination (startCursor, pageSize) or whether it returns only direct children, which are important behavioral traits for correct usage.
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 a single sentence that directly states the purpose without any fluff. It is well-structured and front-loaded with the action verb, making it highly concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has pagination parameters and an output schema, but the description is minimal and does not cover pagination behavior or whether children are direct only. This is a clear gap for an agent needing to correctly handle large or nested structures, though the core purpose is clear.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/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 compensate, but it does not. It only implies blockId refers to a page or block, and does not explain pageSize or startCursor, leaving their semantics to be inferred from names and types.
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?
The description uses the specific verb 'List' with the resource 'child blocks beneath a page or block', making the action and scope unambiguous. It clearly distinguishes from siblings like get_block (single block) and append_block_children (mutating children).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as get_block or query_data_source. It lacks any explicit context about scenarios or exclusions, leaving the agent to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, which cover safety. The description adds the behavioral detail that the tool discovers child data source IDs, but it does not disclose any side effects, permissions, or potential limitations. The output schema further reduces the need to explain return values, so a score of 3 reflects the marginal added context beyond annotations.
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 a single, focused sentence that conveys the essential function without any unnecessary words. It front-loads the verb and resource, achieving high conciseness.
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 simple one-parameter tool with read-only annotations and an output schema, the description sufficiently covers the purpose and key outputs. It lacks explicit usage guidance relative to siblings, but given the tool's straightforward scope, the description is mostly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not elaborate on the databaseId parameter's format or semantics beyond the implicit implication from the tool name. It offers no additional parameter-level meaning, leaving the schema to stand alone without compensation.
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?
The description uses the specific verb 'Retrieve' and identifies the resource as 'database container' while adding the unique discovery aspect of 'child data source IDs'. This clearly distinguishes it from sibling tools like get_page or query_data_source, making its purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives. It does not mention any alternatives, exclusions, or preconditions, making it purely descriptive without contextual direction for an AI agent deciding between tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=false, idempotentHint=true, and destructiveHint=false, providing a baseline. The description adds which aspects can be updated but does not disclose side effects, permission requirements, or nuances of setting trash/lock state.
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?
A single, front-loaded sentence that efficiently lists all key update dimensions with no extraneous content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 6 parameters and nested objects, this description is minimal. It lacks parameter structure details, usage prerequisites, and behavior nuances. Although an output schema exists, the description does not sufficiently compensate for the low schema coverage.
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 0%, so the description must compensate. It maps 'properties', 'icon', 'cover', 'lock state', and 'trash state' to the parameters, but it does not explain the required pageId, nor the structure of icon/cover/properties objects.
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?
The description clearly states the tool updates page-related entities (properties, icon, cover, lock state, trash state) using the specific verb 'Update', distinguishing it from sibling tools like create_page, get_page, and update_block.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The intended use for updating a page is implied by the name and description, but there is no explicit guidance on when to use this tool over alternatives like update_block, nor any mention of exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, and the description's 'Retrieve' aligns with these. It adds no extra behavioral context like error handling or authentication needs, but the annotation coverage lowers the burden.
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 one short, front-loaded sentence with no filler. Every word earns its place, providing maximum clarity in minimal space.
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 simple read-only tool with an output schema and annotations, the description is largely sufficient. It could mention not-found behavior or related tools, but these are not essential given the structured data available.
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?
The schema has one parameter, blockId, with 0% description coverage. The phrase 'by ID' confirms the parameter's role but adds no format or example. For a single-parameter tool this is minimally sufficient but lacks enrichment.
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?
The description uses a specific verb ('Retrieve') and identifies the exact resource ('one Notion block by ID'), distinguishing it from sibling tools like list_block_children and update_block. The scope is precise and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or when-not-to-use guidance is provided. The description implies usage when a single block ID is known, but it does not reference alternatives or exclusions, leaving the decision to the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, covering safety and idempotency. The description adds that it returns property values, a small behavioral detail. It doesn't mention potential errors like page-not-found or permission issues, but for a simple read operation with annotations, this is acceptable.
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 a single, front-loaded sentence with no redundant words. It conveys the essential action and target without unnecessary elaboration.
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?
Given the tool's low complexity (one parameter, read-only, output schema present), the description is largely sufficient. It lacks explicit error-case context or permission notes, but these are typical for such operations and are not critical. The presence of an output schema reduces the need to describe return values.
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?
The only parameter pageId is self-explanatory and the description references 'by page ID', which adds minimal meaning beyond the schema. The schema itself provides no description, but the parameter's purpose is clear from its name and context. No additional format or constraint details are provided.
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?
The description clearly states the verb 'Retrieve' and the resource 'Notion page', and specifies that it returns property values by page ID. This distinguishes it from sibling tools like get_database and get_block, which target different Notion objects.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving a specific page by its ID, but does not explicitly state when to use it versus alternatives, nor does it mention any exclusions such as 'use get_block for block-level retrieval'. It is adequate but lacks explicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true and readOnlyHint=false. The description adds the specific behavior of moving to trash (soft delete) rather than permanent deletion, which goes beyond the bare 'destructive' annotation and provides useful context about reversibility.
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 two short sentences, front-loaded with the action and immediately followed by a critical warning. Every word contributes to understanding, with no redundancy or filler.
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 simple one-parameter deletion tool with annotations and an output schema, the description covers the core behavior (move to trash) and destructive nature. It lacks explicit prerequisites or edge-case behavior, but overall it is sufficiently complete for an AI agent to select and invoke it correctly.
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?
With 0% schema description coverage, the description should compensate, but it does not mention the blockId parameter. However, the single parameter's name is self-explanatory, and the schema requires only a string blockId, so the meaning is inferable. The description adds no explicit parameter detail.
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?
The description clearly states the action ('Move a Notion block to trash') with a specific verb and resource, distinguishing it from sibling tools like get_block, update_block, and append_block_children. It unambiguously identifies this as the deletion operation.
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?
The description implies usage for deleting a block and warns that it is destructive, providing clear context. It does not explicitly name alternatives or state when not to use it, but the verb 'Move to trash' makes the intended scenario obvious.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint and idempotentHint, and the description adds the key behavioral detail that the tool does not call Notion and reports only non-secret configuration. This goes beyond the annotations and provides useful context without contradiction.
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 a single, concise sentence that front-loads the purpose ('Report non-secret server configuration') and adds the important distinguishing trait ('without calling Notion'). No unnecessary words.
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?
This is a simple tool with no parameters, read-only and idempotent annotations, and an output schema. The description adequately explains its function and its distinction from sibling tools, making it complete for an agent to select and 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?
The tool has zero parameters, and the input schema covers parameter definitions completely. With 0 parameters, the baseline is 4, and there is no need for the description to add parameter details.
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?
The description clearly states the tool reports non-secret server configuration, using a specific verb and resource. The phrase 'without calling Notion' distinguishes it from all sibling tools that interact with Notion, and it aligns with the title 'Notion connection status'.
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?
The description implies when to use this tool by noting it does not call Notion, which sets it apart from siblings and suggests it is for checking configuration/status without API interaction. However, it does not explicitly mention alternatives or exclusions, though the context is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![mcp-notion-fast MCP server](https://glama.ai/mcp/servers/TTaoGaming/mcp-notion-fast/badges/card.svg)](https://glama.ai/mcp/servers/TTaoGaming/mcp-notion-fast)

Score Badge

Copy to your README.md:

[![mcp-notion-fast MCP server](https://glama.ai/mcp/servers/TTaoGaming/mcp-notion-fast/badges/score.svg)](https://glama.ai/mcp/servers/TTaoGaming/mcp-notion-fast)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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/TTaoGaming/mcp-notion-fast'

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