Skip to main content
Glama

Delete card

nextcloud_delete_card
DestructiveIdempotent

Delete a specific card from a Nextcloud Deck board and stack by providing board, stack, and card IDs; optional confirmation supports destructive-action safeguards.

Instructions

Delete one card.

DELETE /index.php/apps/deck/api/v1.0/boards/{board_id}/stacks/{stack_id}/cards/{card_id}

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": {
      "board_id": "<board_id>",
      "stack_id": "<stack_id>",
      "card_id": "<card_id>"
    },
    "name": "nextcloud_delete_card"
  }
}

Input Schema

NameRequiredDescriptionDefault
card_idYes
confirmNoExplicitly confirm this destructive operation. Needed only when the client cannot answer a confirmation prompt.
board_idYes
stack_idYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv3.0.0

TDQS

C2.7/5.0
Behavior2/5

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

Annotations already declare destructiveHint=true, idempotentHint=true, and openWorldHint=true, so the safety profile is covered. The description adds only the raw REST endpoint and says nothing about permanence, whether the deletion can be undone, or what happens to references to the card; against a lower bar set by annotations, this is minimal added value.

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 description is two lines, front-loaded with the action and free of filler. The raw endpoint line is terse but useful for resource hierarchy, though it is the only content beyond the first sentence.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For an irreversible destructive operation with no output schema and three undocumented parameters, the description should state permanence, confirmation expectations, and failure modes. It supplies none of these, so an agent must infer the consequences of calling it.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is only 25%: board_id, stack_id, and card_id are bare integers with no schema text. The endpoint template implies these are a path hierarchy, which gives partial meaning, but the description never states what a card_id refers to or how to obtain one, leaving most parameters unexplained.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

"Delete one card" is a specific verb and resource, and the endpoint path disambiguates it from sibling delete tools by showing it targets a card nested under a board and stack. It stops short of naming siblings like nextcloud_delete_stack or nextcloud_delete_item, but the hierarchy makes the target unambiguous.

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

Usage Guidelines2/5

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

There is no guidance on when to use this versus alternatives (e.g., deleting a stack, a board, or an item), and no stated preconditions such as required board/stack ownership or permissions. The only usage-adjacent information, the confirmation requirement, lives in the schema rather than the description.

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

Deploy Server

Other Tools