delete_project
Delete a project (irreversible).
Args: project_id: Project ID (e.g., PR-123-456-789).
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| project_id | Yes |
Output Schema
| Name | Required | Description | Default |
|---|---|---|---|
| result | Yes |
Delete a project (irreversible).
Args: project_id: Project ID (e.g., PR-123-456-789).
| Name | Required | Description | Default |
|---|---|---|---|
| project_id | Yes |
| Name | Required | Description | Default |
|---|---|---|---|
| result | Yes |
Changes observed during successful MCP inspections. Dates show when Glama detected each change.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true, so the destructive nature is known. The description adds the crucial context that deletion is 'irreversible,' going beyond the annotation's generic destructiveness. It does not disclose secondary effects like cascading deletion of associated resources, but the 'irreversible' note plus the annotation covers the core behavioral risk.
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 two sentences: the first states the purpose and irreversibility, the second documents the parameter. It is front-loaded, contains no redundant filler, and every sentence contributes useful information. Ideal conciseness.
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?
For a simple delete tool with one parameter, the description is largely complete, especially given the presence of an output schema and annotations. The main gap is the lack of information about what happens to associated resources (e.g., nodes) upon project deletion, but given the tool's simplicity and the openWorldHint annotation, this is a minor omission rather than a fatal flaw.
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 provides only a string type with no description, so the description's parameter documentation is essential. It explains 'project_id' and gives a concrete example format ('e.g., PR-123-456-789'), which is valuable for correct invocation. This compensates well for the 0% schema description coverage.
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 a project') and explicitly notes irreversibility, which distinguishes it from sibling tools like delete_node and update_project. The verb 'Delete' plus the specific resource 'project' makes 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The use case is implied by the tool name and description—use when you need to delete a project. However, there is no explicit guidance on when not to use it (e.g., if nodes depend on the project) or mention of alternative tools like delete_node. The description lacks any contextual prerequisites or side-effect warnings beyond irreversibility.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Each tool targets a distinct resource and action: nodes, projects, docs, pricing, status, org, faucet, and contact. There is no overlap between list/get, create/update/delete, or the doc search vs fetch tools.
All tool names follow a consistent verb_noun pattern (create_node, get_project, list_nodes, update_node, delete_project). Underscore separator and lowercase are used throughout with no mixed conventions.
At 18 tools, the set is slightly above the typical 3-15 range but each tool serves a distinct purpose within the platform's domain. The count is appropriate for a platform with project, node, documentation, pricing, status, and faucet features.
The tool set provides full CRUD for both projects and nodes, plus deployment options, pricing, docs search/retrieval, platform status, organization info, testnet faucet, and a contact channel. There are no obvious dead ends for the workflows the server advertises.