plane-page-delete
Delete a page from a project by providing the project and page UUIDs.
Instructions
Delete a page from a project.
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| page_id | Yes | Page UUID | |
| project_id | Yes | Project UUID |
Delete a page from a project by providing the project and page UUIDs.
Delete a page from a project.
| Name | Required | Description | Default |
|---|---|---|---|
| page_id | Yes | Page UUID | |
| project_id | Yes | Project UUID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for disclosing side effects. It only states 'Delete' without indicating if the operation is irreversible, whether it cascades to related data, or if it requires special permissions. This leaves the agent uninformed about potential risks.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, making it very concise. However, it could be more informative without becoming verbose. It is front-loaded with the action and resource, but lacks any supplementary details that would justify a 5.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the minimal description and no output schema, the tool definition is incomplete. It does not explain the effect on the project or page list, nor does it mention that the page ID must exist. Sibling tools like plane-page-detail or plane-page-list are not referenced for context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already contains descriptions for both parameters (Page UUID, Project UUID) with 100% coverage. The tool description adds no additional meaning or context beyond the schema, so baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (Delete) and the resource (a page from a project), making the primary purpose evident. However, it lacks specificity about whether the deletion is soft or permanent, and does not distinguish from other delete tools like plane-label-delete.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives (e.g., page update, or deleting associated content). There is no mention of prerequisites, such as ensuring the page exists or that the user has proper permissions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/philipvanlewis/plane-mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server