notion-mpm

Server Quality Checklist

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

Latest release: v0.1.1
Disambiguation5/5
Each tool maps to a distinct Notion resource and action. get_page_property targets a specific property vs get_page's full page, and append_block_children vs get_block_children are clearly read vs write. No two tools have overlapping purposes.
Naming Consistency5/5
All tools follow a verb_noun pattern with snake_case, e.g., get_page, create_database, update_block. The only deviation is 'search', but it is a clear imperative verb that fits the style. No mixed conventions.
Tool Count4/5
21 tools is above the typical 3-15 sweet spot, but the breadth of Notion's API (pages, blocks, databases, users, comments) justifies the count. Each tool serves a specific operation, so it doesn't feel bloated.
Completeness4/5
Core CRUD and lifecycle operations are covered for pages, blocks, and databases, plus search, comments, and user retrieval. A notable minor gap is lack of database archive/restore operations, but this does not severely hinder common workflows.
Average 3.6/5 across 21 of 21 tools scored. Lowest: 2.9/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- Last stable release on March 10, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure, but it does not mention whether updates are full replacements or merges, whether write permissions are required, what happens if the block does not exist, or any return value. It only implies mutation via 'update'.
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 efficient sentence with a clear subject-verb-object structure and no filler. It is concise, though perhaps too sparse given the need for additional usage and behavioral details.
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 mutation tool with no annotations and no output schema, the description is disproportionately thin. It lacks context about update semantics, failure modes, permissions, and how it relates to sibling tools, even though parameters are well covered by the schema.
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%, with block_id and block_data both described including an example. The tool description adds no parameter-level meaning beyond the schema, so the baseline score of 3 applies.
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 verb 'Update' and the resource 'existing block', distinguishing it from sibling tools like get_block, delete_block, append_block_children, and update_page. It is specific enough about the action, though it does not elaborate on what 'content' encompasses.
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 append_block_children or update_page. There are no explicit exclusions, prerequisites, or contextual hints beyond the action itself.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It shares one useful behavioral trait: 'Only returns content the integration has access to.' However, it does not mention what fields are searched (e.g., title vs. content), the return structure, or limitations like pagination behavior. This is insufficient for a search tool with no other source of behavioral context.
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 concise sentences, front-loaded with the action and resource. Every word contributes meaning, with no redundant or filler content. It is appropriately sized for the tool's complexity.
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 5 parameters and no output schema or annotations, yet the description is quite brief. It conveys the core purpose and one access limitation, but does not explain what the response contains or how results are structured. The schema covers parameters, but the lack of return-value context leaves a gap. This is adequate but not thorough.
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 input schema provides 100% coverage with clear descriptions for all five parameters, so the description need not elaborate. The description itself adds no extra parameter semantics beyond what the schema already offers. Baseline of 3 applies due to full schema coverage.
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's function: 'Search for pages and databases in the Notion workspace.' The verb 'search' and the resources 'pages and databases' are specific, distinguishing it from direct fetch tools like get_page or get_database. However, it does not explicitly contrast with sibling tools like query_database, so it stops short of full 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?
No guidance is provided on when to use this tool versus alternatives such as query_database or get_page. The description only states what the tool does, not the context or conditions under which it should be chosen. It lacks any 'when to use' or 'when not to use' advice.
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?
With no annotations, the description carries the full burden of behavioral disclosure. It discloses the required permission but omits mutation effects, response behavior, and how page_id and discussion_id interact. This is inadequate for a write operation.
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?
Two short sentences with no filler. The prerequisite statement is useful, and the description is appropriately compact.
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 3 parameters, no output schema, and no annotations, the description oversimplifies. It does not explain the relationship between page_id and discussion_id, nor what the API returns. This is incomplete for safe autonomous use.
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 covers 100% of parameters with clear descriptions, including text, page_id, and discussion_id. The description adds no additional parameter context, so the baseline score of 3 is appropriate.
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 ('Add a comment') and the target ('to a Notion page'), making the tool's function unambiguous. It inherently distinguishes from the read-only sibling get_comments through the verb 'Add'.
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 a prerequisite (insert comments capability) but offers no guidance on when to use this tool versus alternatives like get_comments or create_page. No exclusions or alternative references are given.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only says 'retrieve' without mentioning pagination behavior (despite page_size being a parameter), return format, permissions, or error conditions. The description adds no behavioral context beyond the basic action.
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, well-structured sentence that is front-loaded with the action and resource. It is concise without unnecessary words, making it easy for an agent to parse quickly.
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 tool has no output schema and no annotations, so the description should compensate by explaining the return value, pagination behavior, or usage context. It does none of these, leaving the agent with incomplete information about how to correctly invoke and interpret the tool.
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 input schema provides 100% coverage with descriptions for all three parameters (page_id, page_size, property_id), so the baseline is 3. The description does not add any additional meaning or nuance beyond what the schema already provides.
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 ('Retrieve') and the specific resource ('a specific property value from a Notion page'). This distinguishes it from siblings like get_page, which retrieves the whole page, and other property-related operations.
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, no context about prerequisites, and no exclusions. It simply states what it does without any comparative or situational information.
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?
No annotations are provided, so the description carries the full burden. It claims to list 'all' users but does not disclose that results are paginated (max 100 per page via page_size), nor does it mention authentication needs or response format, creating potential for misinterpretation.
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, front-loaded sentence with zero wasted words. It immediately communicates the core action.
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?
For a simple list tool with a well-documented schema, the description is minimally viable. However, without an output schema or annotations, it could provide more context about pagination to truly retrieve 'all' users, as the current wording may imply a single unfiltered list.
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 input schema provides complete descriptions for both parameters (page_size with max 100, start_cursor as a pagination token). Since schema coverage is 100%, the description does not need to add parameter details, and the baseline of 3 applies.
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 'list' and resource 'users' within the 'Notion workspace', providing a specific and unambiguous purpose. It naturally distinguishes itself from singular tools like get_user and get_bot_user.
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_user or search. While the function is obvious from the name, there is no explicit mention of selection criteria or exclusions.
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?
The description states the core action but fails to disclose side effects such as permanence, whether child blocks are deleted, or permission requirements. With no annotations, the description carries the burden and does not address these.
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 clear sentence with no extraneous information, achieving maximum conciseness while conveying the essential action.
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 no annotations, no output schema, and a minimal description, important details such as what the tool returns (e.g., deleted block object or empty response) and any cascading effects are missing. The description is too sparse for complete understanding.
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 input schema includes 'Block UUID to delete' providing 100% coverage for the only parameter. The description adds no new meaning beyond 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?
The description uses a specific verb 'Delete' and resource 'block' with context 'from a Notion page', clearly distinguishing it from sibling tools like update_block or get_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?
Usage is implied by the name and description; there is no explicit guidance on when to use vs alternatives, but no competing block deletion tool exists among siblings.
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?
There are no annotations, so the description carries the full burden. 'Retrieve' implies a read operation but does not disclose potential errors, permission requirements, or return format. Minimal behavioral context is added beyond the tool name.
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 with no filler. It front-loads the action and resource, making it easy to parse quickly.
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 single-parameter retrieval tool, the description, combined with the clear schema, is mostly complete. It lacks details on return format or error behavior, but the simplicity of the operation makes it adequate for selection and invocation.
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 already documents block_id as 'Block UUID' with 100% coverage, and the description adds no extra meaning. Since schema coverage is high, a baseline score of 3 is appropriate.
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', the resource 'a specific block', and the criteria 'by its ID'. This distinguishes it from sibling tools like get_block_children, which retrieves children, or update_block, which modifies a block.
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. It doesn't mention that this is for fetching a single block while get_block_children is for fetching children, or any prerequisites or exclusions.
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?
With no annotations provided, the description must fully disclose behavior; it only lists supported features (filtering, sorting, pagination) without explaining pagination cursor handling, result size limits, or read-only semantics. It adds little beyond what the schema already reveals.
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 sentence that communicates the core function efficiently with no filler. It is appropriately sized.
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 tool has no output schema, so the description must explain return values and pagination behavior. It only says 'retrieve pages' without describing the response structure, next_cursor, or how page_size interacts. This is insufficient for a tool with nested objects and 5 parameters.
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 100% coverage with examples for filter and sorts. The description merely restates these features ('Supports filtering, sorting, and pagination') and provides no additional semantic context for the parameters.
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 precisely states 'Query a Notion database to retrieve pages matching filter criteria,' identifying the verb (query), resource (Notion database), and outcome (retrieve pages). This distinguishes it from sibling tools like get_page (single page) and search (workspace-wide search).
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 the use case of retrieving filtered pages from a specific database but does not explicitly mention when to choose it over alternatives like search or get_database. No prerequisites or exclusions are stated.
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?
No annotations are provided, so the description carries the full behavioral disclosure burden. It simply says 'Update' without mentioning side effects, partial update behavior, idempotency, permissions, or error cases. The schema's mention of 'partial update supported' is not echoed in the description.
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 front-loads the primary action and resource. Every word contributes to clarity, and there is no redundant or filler 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?
With no annotations, no output schema, and a mutation tool, the description is too sparse. It does not explain partial updates, what happens to unspecified properties, required permissions, or how to construct nested icon/cover objects. The context is insufficient for reliable tool selection and invocation, despite the schema covering parameters.
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 the baseline is 3. The description lists the parameter groups ('properties, icon, or cover') but does not add meaning beyond the schema. It neither clarifies types nor provides additional usage context for these parameters.
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 'update' with a clear resource 'Notion page' and enumerates the scope ('properties, icon, or cover image'). This distinguishes it from sibling tools like update_block and update_database, which target different resources.
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 the action, but provides no explicit guidance on when to use this tool versus alternatives like archive_page, restore_page, or create_page. There are no exclusions or alternative tool references, leaving the decision to the agent's inference.
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?
No annotations are provided, so the description must fully disclose behavioral traits. It implies a read-only operation but does not mention pagination behavior, rate limits, or authentication requirements. The claim to retrieve 'all' comments is misleading given the page_size and start_cursor parameters, which indicate paginated results.
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 with no wasted words. It is appropriately front-loaded and easy to parse.
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?
Given the tool's low complexity and complete schema, the description suffices for basic understanding but omits return format and pagination behavior. For a list-returning tool without an output schema, the lack of return value details leaves a gap.
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 provides full descriptions for all three parameters, including block_id, page_size, and start_cursor with 100% coverage. The description adds no additional parameter semantics beyond what the schema already specifies.
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 'Retrieve all comments on a Notion page or block' uses a specific verb and resource, clearly distinguishing this from sibling tools like create_comment or get_page. It clearly states the operation and target.
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 provides no explicit guidance on when to use this tool versus alternatives, such as create_comment for writing or get_block for block details. The intended usage is implied by the name and simple description, but there is no mention of pagination or exclusions.
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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only says 'Retrieve information' without specifying what fields are returned, authorization requirements, rate limits, or any error behavior. This is minimal and lacks detail expected for a tool invocation.
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, clear sentence that is front-loaded with the verb and resource. Every word earns its place, with no redundancy or irrelevant detail.
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 is simple with only one parameter and no output schema, but the description is still vague about what 'information' means (e.g., user name, email, type). Given the lack of annotations and output schema, the description could be more complete by outlining the return value or typical use case, but it is minimally adequate for a basic retrieval tool.
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 input schema has 100% coverage: user_id is described as 'User UUID' in the schema. The description does not add any additional meaning or context beyond the schema, so it meets the baseline for good schema coverage but provides no extra value.
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' with a specific resource 'a specific Notion user', clearly distinguishing it from sibling tools like list_users (all users) and get_bot_user (the bot's own user). It fully states what the tool does without ambiguity.
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 that this tool is for retrieving a single user by ID, but it does not explicitly say when to use it versus list_users or get_bot_user. There is no mention of exclusions or alternative tools, so usage guidance is implied rather than stated.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only lists what can be updated but does not reveal side effects, permission requirements, whether updates are additive or replacing, or how partial updates behave. For a mutation tool, this lack of detail leaves significant unknowns.
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 is direct and front-loaded with the action and resource. It covers the essential scope without any filler or redundancy.
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?
Given the tool's complexity (nested 'properties' object, partial updates) and lack of annotations and output schema, the description is too sparse. It does not explain the structure of property updates, potential impacts on existing data, or any prerequisites. This leaves the agent under-informed for correct invocation.
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 a baseline of 3 is appropriate. The description summarizes the key parameters ('title, description, or property schema') but does not add meaning beyond what the schema already provides. The schema gives per-parameter descriptions, so the description's contribution is minimal.
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 'Update' and a clear resource 'Notion database' with explicit attributes (title, description, property schema). This clearly distinguishes it from sibling tools like update_page, which updates page content, and create_database, which creates new databases.
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 clearly sets the context: this tool is for updating database-level metadata and schema. It does not explicitly mention alternatives or when-not-to-use, but the scope is evident from the resource focus (database vs. page). Sibling names (update_page, create_database) further imply the boundaries, though no direct exclusions are stated.
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?
No annotations are provided, so the description alone must disclose behavioral traits. It states the append action, implying non-destructive addition, but does not mention required permissions, error conditions, or the effect on existing children. This is a mutation tool, and the description lacks details that would help an agent understand side effects beyond the name.
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 efficiently conveys the tool's purpose. Every phrase adds value without redundant detail.
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 3 parameters and no output schema, so the description should compensate by explaining return behavior or edge cases, but it does not. The description is sufficient for basic understanding, but lacks information on what the tool returns or how it handles invalid inputs, leaving it incomplete for full autonomous use.
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 input schema covers all three parameters with descriptions, providing 100% coverage. The description adds no specific parameter semantics beyond the schema, which already explains 'after' as an optional insertion point and 'children' as a list of block objects. Therefore baseline score of 3 applies.
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 'Append' and identifies the resource as 'a page or block', clearly distinguishing from sibling tools like create_page or delete_block. It also enumerates content types ('paragraphs, headings, lists, code blocks'), making the purpose concrete.
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 states 'Use this to add paragraphs, headings, lists, code blocks, and more,' which provides clear positive context for when to invoke the tool. It does not mention alternatives or scenarios where this tool should be avoided, such as using create_page for new pages, so it lacks exclusions but the context is sufficient.
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?
No annotations are provided, so the description carries full responsibility for disclosing behavioral traits. It mentions the database is a child of a page and that schema is set at creation time, but omits important details such as permission requirements, potential side effects, failure modes, or whether the operation is destructive. This is a significant gap for a write operation.
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 sentences with no redundant information. It front-loads the primary action and then adds a second clause about schema definition. Every word earns its place.
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 moderate complexity with 4 parameters and nested objects, and no output schema. The description covers the core purpose but does not mention return values, prerequisites (e.g., parent page must exist), or error behavior. With no annotations, the description is somewhat minimal, but the schema fills in parameter details. Overall, it is adequate but leaves gaps.
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 input schema provides 100% coverage of all parameters with descriptions. The description adds minimal extra meaning beyond the schema, such as the 'creation time' context for the schema and the 'child of page' relationship for parent_page_id. Baseline of 3 is appropriate since 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?
The description clearly states the specific action: creating a new Notion database as a child of an existing page. It also highlights the key operation of defining the property schema at creation time, which distinguishes it from sibling tools like create_page (which creates pages) and update_database (which modifies existing databases).
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 provides clear context for when to use the tool: when you need to create a database under an existing page. It does not explicitly mention alternatives or exclusions, but the context is sufficient to differentiate it from sibling tools. Slight gap: no explicit 'use this instead of X' guidance.
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?
With no annotations provided, the description carries the full burden. The verb 'Retrieve' implies a read-only operation, and it specifies what is returned (schema and metadata), but it does not disclose potential side effects, permissions, error behavior, or response format beyond that. The description is adequate 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, concise sentence that front-loads the verb and resource. Every word contributes value, with no redundancy or extraneous detail.
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 tool with one parameter, no annotations, and no output schema, the description provides sufficient context: it explains the resource type and that the return is schema/metadata. It does not detail the return structure or error conditions, but these are not critical for such a straightforward retrieval operation. The description is complete enough for this low-complexity tool.
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 100% coverage with the parameter description 'Database UUID'. The tool description says 'by its ID', which echoes the schema without adding new meaning. Since schema coverage is high, the baseline is 3, and the description does not materially enhance parameter understanding.
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 resource ('Notion database schema and metadata') with a clear parameter ('by its ID'). This distinguishes it from siblings like get_page (for pages) and query_database (for database contents), making the 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when you need the schema or metadata of a database, but does not explicitly mention when not to use it or point to alternatives like query_database for querying contents. The context is clear but lacks exclusions or alternative guidance.
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?
With no annotations, the description carries the full burden of behavioral disclosure. It adds that the tool returns all properties, which is useful context, but does not disclose potential errors, authentication requirements, or response structure. The behavior is simple and mostly self-explanatory, so a mid-range score is appropriate.
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 well-structured sentence that is front-loaded with the action and resource. Every word earns its place, 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 retrieval tool with no output schema, the description adequately explains the core function. It mentions that all properties are included, giving the agent a sense of the response. It lacks explicit detail about page object structure, but this is not critical for such a straightforward operation.
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 already provides 100% description coverage for the single parameter (page_id). The description adds no additional information about the parameter beyond what the schema states, so the baseline score of 3 applies.
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 retrieves a Notion page by ID and includes all properties, which distinguishes it from sibling tools like get_page_property. The verb 'retrieve' and resource 'Notion page' are specific 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?
The description implies when to use this tool (when you need a full page with all properties) but does not explicitly mention alternatives or exclusion criteria. The phrase 'including all properties' is a subtle differentiator but not an explicit usage guideline.
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?
No annotations are provided, so the description must disclose behavioral traits on its own. It only states the action with no details about side effects, required permissions, error cases (e.g., page not archived), or whether the operation is reversible. This lack of transparency is a significant gap for a mutation 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 with zero redundancy. Every word is meaningful and directly communicates the tool's purpose.
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 without an output schema, the description sufficiently conveys the operation and when it applies. It could be more complete by mentioning expected outcomes or permissions, but the low complexity makes this description adequate for correct invocation.
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 describes page_id as 'Page UUID to restore' with 100% coverage, so the baseline is 3. The tool description does not add any additional meaning about the parameter beyond what the schema already provides, so it stays at the baseline.
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 'Restore a previously archived Notion page' clearly states the action (restore) and the resource (previously archived Notion page). It distinctively differentiates from sibling tools like archive_page, create_page, and delete_block by specifying the exact operation and target.
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 phrase 'previously archived' gives clear context that this tool should be used for pages that are currently archived, not for other states. However, it does not explicitly name alternatives or state when not to use it, so it misses full exclusionary guidance.
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?
No annotations are provided, so the description must indicate safety and behavior. It implies a read-only operation via 'list' and 'read', but does not disclose pagination details, rate limits, or the response format. This is adequate for a simple listing but lacks depth.
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?
Two short sentences deliver the essential information without any filler or redundancy. Every word earns its place.
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?
With no output schema and no annotations, the description should clarify return behavior. It states the tool lists direct children but does not mention that the response is an array of block objects or that pagination is supported. This is adequate for a simple read operation but leaves some gaps.
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 coverage is 100% with clear parameter descriptions. The tool description adds no additional parameter semantics beyond what the schema already provides, so the baseline score of 3 is appropriate.
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 (list), the target (direct children of a block or page), and the intent (read the content of a Notion page). This distinguishes it from siblings like get_block (fetches a single block) and get_page (fetches page metadata).
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 explicit use-case guidance: 'Use this to read the content of a Notion page.' This implies the tool is for reading page content rather than retrieving block metadata. However, it does not explicitly mention alternatives or when not to use it.
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?
With no annotations provided, the description carries the full burden. It discloses two key behavioral traits: the operation is a soft-delete and the page can be restored later. This goes beyond a generic 'archives a page' and provides meaningful context about reversibility, though it does not elaborate on side effects or permissions.
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 concise sentences, with the primary action front-loaded. Every word adds value: 'Archive', 'soft-delete', and 'can be restored later' are all meaningful and non-redundant.
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 no output schema, the description covers the essential purpose and the critical behavioral nuance of reversibility. It does not explain return values, but that is less critical given the operation's simplicity. The sibling context (restore_page) further clarifies the workflow.
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 provides 100% coverage for the single parameter page_id with a clear description ('Page UUID to archive'). The tool description does not add extra semantic detail beyond referencing the page, so the baseline of 3 is appropriate given the schema already handles parameter meaning.
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 states a specific verb ('Archive') and resource ('Notion page'), with the clarification '(soft-delete)' and 'can be restored later' distinguishing it from destructive deletion tools like delete_block and complementing restore_page. This clearly differentiates from siblings.
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 reversible deletion by stating it's a soft-delete and restorable, but it does not explicitly mention when to use this over delete_block or reference restore_page as an alternative. Context is present but no explicit exclusions or alternative guidance.
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?
With no annotations provided, the description carries the burden of behavioral disclosure. It mentions the schema-matching requirement, which is a useful constraint, but does not detail other behaviors such as what happens with invalid parents, required fields for sub-pages, or the response format. This is adequate but not rich in transparency.
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 concise sentences. It is front-loaded with the core purpose and includes a key constraint without any redundant words or repetition of schema information.
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 creation tool with 5 parameters and no output schema, the description covers the primary purpose and the critical database-schema constraint. It is complete enough for an agent to understand when to use it and what to provide. A minor gap is not describing the return value or error scenarios, but those are often not required for basic creation tools.
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 input schema describes each parameter with 100% coverage, so the baseline is 3. The description adds a small semantic layer by noting that properties must match the database schema, which reinforces the properties parameter's meaning beyond the schema. However, it does not elaborate on icon, cover, or children beyond what the schema already says.
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 creates a new Notion page and specifies two distinct parent contexts (database or sub-page). This distinguishes it from sibling tools like update_page or archive_page, which operate on existing pages.
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 provides clear context on when to use the tool (creating a new page) and gives a specific constraint (properties must match the database schema for database pages). It does not explicitly mention alternatives or exclusions, but the context is sufficient for a creation tool.
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?
No annotations are provided, so the description carries the full burden. It indicates a read-only operation via 'Retrieve information' and adds specific behavior by listing 'workspace name and owner details' in the response. However, it does not disclose potential caveats such as authentication needs, error responses, or whether the bot user might be absent. For a simple getter, this is adequate but not overly 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, compact sentence front-loaded with the action and resource. It contains no filler and effectively communicates the tool's purpose and key return fields.
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 zero-parameter tool with no output schema, the description provides sufficient context: it explains what is retrieved and highlights key fields. While it does not cover edge cases or error behavior, these are not critical given the simplicity of the operation. The description is complete enough for its complexity.
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, so the schema is trivially covered. The description adds helpful context about the return payload (workspace name, owner details), which compensates for the lack of an output schema. A baseline of 4 is appropriate for zero-parameter tools.
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 retrieves the bot user for the integration, using the specific verb 'Retrieve' and the resource 'bot user'. It also mentions 'including workspace name and owner details', which distinguishes it from sibling tools like get_user and list_users by specifying the integration-specific scope.
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 obtaining the bot user's own details ('associated with this integration'), but does not explicitly state when to use this tool versus alternatives like get_user or list_users. No exclusions or alternative conditions are provided, so guidance is only implied by the wording.
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:

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

Score Badge

Copy to your README.md:

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

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/bobmatnyc/notion-mpm'

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