R3

Delete an R3 project

r3_project_delete

Destructive

Permanently delete an R3 project. With the project:delete:created right (on by default), only a project YOU created (this agent key or app connection) — use it to clean up your own abandoned attempts; the user's own projects and other agents' are refused. With project:delete:owned, any project the user owns, and only when the user asked for it: pass owned: true for a project you did not create (an app connection is then asked for that right). A published project (live, or with an open preview link) is refused: it must be taken offline first. If the refusal is for a preview link (temporary, 7 days), it may be removed without a separate request (r3_preview_remove) and the delete tried again; the user is then told it was removed. If the project is live, other people can open it: it goes offline only once the user has been asked and agreed, never as a step of the delete. This is irreversible: there is no trash and no undo.

Input Schema

Name	Required	Description	Default
`owned`	No	true when the project is one of the user's own, not one you created: it needs project:delete:owned. Only when the user asked to delete it. Leave out for a project you created.
`projectId`	Yes	The project id to delete: one you created, or (with project:delete:owned) any project the user owns.

Output Schema

Name	Required	Description
`answer`	Yes	This answer in words: what was done, what R3 measured, decided or refused, and what to do next. The same text as the result's text block. Read it: the fields beside it are the data, this is the guidance.
`deleted`	Yes
`projectId`	Yes
`environment`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 18, 2026

addedInput schema / properties / owned

Added value: +{
+  "description": "true when the project is one of the user's own, not one you created: it needs project:delete:owned. Only when the user asked to delete it. Leave out for a project you created.",
+  "type": "boolean"
+}

Changed1 schema field changedOct 17, 2026

changedInput schema / properties / projectId / description

Previous value: -"The project id to delete: one this key created, or (with project:delete:owned) any project the user owns."New value: +"The project id to delete: one you created, or (with project:delete:owned) any project the user owns."

Changed2 schema fields changedOct 15, 2026

addedOutput schema / properties / answer

Added value: +{
+  "description": "This answer in words: what was done, what R3 measured, decided or refused, and what to do next. The same text as the result's text block. Read it: the fields beside it are the data, this is the guidance.",
+  "type": "string"
+}

changedOutput schema / required

Previous value: -[
-  "projectId",
-  "deleted",
-  "environment"
-]New value: +[
+  "projectId",
+  "deleted",
+  "environment",
+  "answer"
+]

First observedOct 15, 2026

TDQS

A4.8/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations declare destructive=true, but the description goes far beyond them: it discloses the authorization model (project:delete:created vs project:delete:owned), the refusal conditions, the app-connection prompt, and that the operation is irreversible with no trash or undo. It also promises the tool never unpublishes a live project as part of the delete.

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?

Front-loaded with the core action and outcome, then proceeds in priority order through permission conditions, refusals, and irreversibility. The density is justified by the complexity, though a few clauses (preview-link explanation) could be tightened.

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?

For a destructive mutation with a complex permission model, every decision an agent must make is covered: which right applies, what the owned flag does, what gets refused, and recoverability. An output schema exists, so return values need not be described.

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?

Schema coverage is 100%, so baseline is 3, but the description adds context the schema does not: that owned:true carries an authorization consequence, is only valid when the user explicitly asked for the deletion, and triggers an app-connection prompt. This gives the flag semantic weight beyond its type definition.

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?

States a specific verb and resource ('Permanently delete an R3 project') and immediately scopes it against the siblings r3_project_create/rename and the preview tool. An agent can tell exactly what this does and does not remove, without opening another schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicit about when to use it (cleaning up your own abandoned attempts) versus when it will be refused (the user's own projects, other agents' projects, live or preview-linked projects). It names the prerequisite right, the alternative tool r3_preview_remove, and the ordering constraint (take offline first).

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All R3 tools Inspect

Try in Browser

Shareable, User-Owned Context BackendPeople, applications, and agents read, write, and coordinate together in one context lake. Reach it over MCP, a CLI, a Python SDK, or REST.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?