Permanently delete a project and ALL its data (records, resources, snapshots, custom routes, webhooks, request log). Irreversible. Good practice for short-lived test projects: clean up when your session is done. Requires the adminKey.
| Name | Required | Description | Default |
|---|---|---|---|
| project | Yes | Project id. | |
| adminKey | Yes | The project's adminKey. |
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 explicitly states the operation is permanent, irreversible, and deletes all listed data. It also discloses the requirement for adminKey, which is a crucial prerequisite. This is strong transparency for a destructive action, though it does not cover error cases or success details.
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 consists of two concise sentences with zero filler. The most critical fact (permanence and irreversibility) is front-loaded, followed by a clear usage recommendation and requirement. Every clause adds value, making it highly efficient.
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 destructive tool with no output schema, the description covers the action, scope, irreversibility, usage context, and the required adminKey. It does not mention possible error scenarios or a successful-return message, but these are minor omissions given the tool's simplicity. Overall, it provides sufficient information for an agent to call it correctly.
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 provides full descriptions for both parameters (project id and adminKey), giving 100% schema coverage. The description adds no extra parameter semantics beyond redundantly mentioning that adminKey is required. The baseline of 3 applies because the schema does the heavy lifting and the description contributes nothing additional.
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 states a specific verb ('permanently delete') and resource ('project and ALL its data'), listing the data categories (records, resources, snapshots, custom routes, webhooks, request log). This clearly differentiates it from sibling tools like create_project or query_records, none of which are delete operations.
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 description explicitly recommends using this tool for cleanup of short-lived test projects ('clean up when your session is done'). It implies when not to use it by emphasizing the irreversible nature, but it does not name alternative tools because no other delete tool exists among siblings. The guidance is adequate for selection.
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 maps to a distinct resource/operation: project lifecycle, resource seeding, artifact import, record CRUD, custom routes, snapshots, request inspection, and external API status. Even the data-population tools are clearly separated by existing project (add_resource) versus new project (import_data/create_project).
Most tools follow a clear verb_noun pattern (add_resource, create_project, query_records, write_record, delete_project, etc.). A few noun-style names (custom_route, project_info, snapshots) break the pattern, but all names are snake_case and readable.
Eleven tools is a well-scoped set for a mock API server: project creation/deletion, data population/import, record operations, snapshots, custom routes, inspection, and API status all have dedicated tools without redundancy.
The core workflow is well covered: create/delete projects, add/import resources, CRUD records, snapshot state, define routes, and inspect requests. The main gaps are the lack of explicit resource deletion and custom-route update/delete, but these are workaroundable rather than blocking.