Skip to main content
Glama
Sign In

Ankra

by ai.ankra
OverviewDiscussionsAdmin

Delete project

delete_project
Destructive

Delete an empty project (the twin of ankra project delete). Needs projects.manage. Refused for the organisation's default project and while the project still holds anything: the refusal counts what is left per kind, to move with move_cluster_to_project or move_application_to_project or to make organisation-wide first. Deleting retires the role assignments scoped to the project, moves members whose current project it was to the default project, deletes its cost budgets and autopilot defaults, and makes tokens pinned to it fail authentication (pinned_tokens counts them). Not reversible. Always have the user confirm the project first.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "project_id": "<project_id>"
    },
    "name": "delete_project"
  }
}

Input Schema

NameRequiredDescriptionDefault
project_idYesUUID of the project (from list_projects).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.6/5.0
Behavior5/5

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

Annotations already flag destructiveHint=true and idempotentHint=false, but the description goes well beyond them: it names the required permission (projects.manage), enumerates the cascade of side effects (role assignments retired, members moved to the default project, cost budgets and autopilot defaults deleted, pinned tokens failing auth), and states irreversibility. This is exactly the context an agent needs before a destructive call.

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 critical constraint (empty project, refusal conditions) is front-loaded and every clause carries information. The single dense paragraph is somewhat run-on, and the side-effect list could be broken into a clearer sequence, but there is no filler.

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, non-idempotent single-parameter tool with no output schema, the description covers permissions, refusal conditions, remediation paths, cascade effects, and reversibility. Nothing an agent needs in order to call it safely is missing.

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?

There is a single parameter with 100% schema description coverage, so the schema already documents project_id as a UUID from list_projects. The description reinforces that the project must be confirmed first but adds no format or sourcing detail beyond the schema, so 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?

States a specific verb and resource ('Delete an empty project') and immediately narrows scope with the 'empty' qualifier plus the CLI twin reference. An agent can distinguish it from delete_application, delete_stack, or delete_cluster without opening any 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?

Explicitly names the conditions under which the call is refused (default project, project still holding resources) and routes the agent to concrete alternatives: move_cluster_to_project, move_application_to_project, or organisation-wide reassignment. It also adds a procedural precondition ('Always have the user confirm the project first').

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

All Ankra toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources