DESTRUCTIVE

delete_requirement

Deletes a requirement after the person confirms; deprecating keeps it on the record instead.

Delete a requirement by requirement_id. Its reference is never reused and the links to it go. The removal goes through the same action the Requirements page runs and requirement.deleted goes out. The tool is destructive: a Heimdall turn pauses for the person's confirmation and an MCP client asks before sending. Prefer moving a requirement to deprecated with update_requirement, so the record keeps what was once asked. A staff token with requirement:delete on the project is needed.

Requires ability

The token behind the MCP session must hold it, or the call is refused with TOKEN_MISSING_ABILITY.

The REST endpoint and this tool share one action, so validation, permissions and events are identical.

Fires one event

Delivered to every endpoint subscribed to it once the change is made.

Annotations

Destructive

A client that honours annotations asks a person before running it.

Arguments

requirement_id*string

UUID of the requirement to delete.

What it returns

{  "data": {    "requirement_id": "a8b9c0d1-e2f3-4a4b-9c5d-6e7f8a9b0c13",    "deleted": true  }}

How it fails

RESOURCE_NOT_FOUND

unknown requirement_id, or a requirement outside the token's scope or the person's visibility.

FORBIDDEN

the token is a client guest's, or the holder's role on the project does not carry requirement:delete.

TOKEN_MISSING_ABILITY

token lacks requirement:delete.

How is this guide?

Last updated on