Skip to main content
Glama
Sign In

Brix Digital Signage

by com.brixsignage
OverviewDiscussionsAdmin

Delete items

delete_items
DestructiveIdempotent

Delete items of one kind into the 30-day recycle bin.

When to use:

  • The person has confirmed what should go (show it with list_items or get_items first).

When NOT to use:

  • Taking a screen out of a group: use update_items removeScreenIds.

  • Stopping a takeover: use end_takeover.

What to know:

  • restore_items undoes a delete within 30 days. A deleted playlist or schedule stops on every screen playing it; a deleted screen's device returns to pairing; a deleted location hands its content to its parent.

  • Refused: the root, a location with child locations, items shared to another workspace. Each id reports ok or its error. Needs the kind's delete permission.

Parameters:

  • kind and ids: every id must be of that kind.

  • permanent: true erases for good instead (recycle-bin kinds only). The first call deletes nothing and returns wouldErase and a confirmCode.

  • confirmCode: only with permanent:true; send the code from the first call, after the person says yes, with the same kind and ids. It lasts 10 minutes and fits only those ids; without permanent it is an error.

  • Example: {kind:"playlists", ids:["pl_8f2c"]}.

Input Schema

NameRequiredDescriptionDefault
idsYesItem ids.
kindYesKind of the ids.
permanentNoErase for good.
confirmCodeNoCode from the first call.

Output Schema

NameRequiredDescriptionDefault
kindNoThe kind that was acted on.
nextNoPreview call: what to do next.
erasedNoHow many items were erased for good (0 on the first, preview call).
failedNoHow many failed; the rest still ran.
resultsNoOne row per id or item, in the order given.
permanentNotrue for a permanent delete.
succeededNoHow many ids or items succeeded.
wouldEraseNoPreview call: the items that would be erased.
confirmCodeNoPreview call: send this on the second call, after the person says yes.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changed
    • changedInput schema / properties / confirmCode / description
      Previous value: -"permanent:true only: the code the first call returned, sent after the person said yes."New value: +"Code from the first call."
    • changedInput schema / properties / ids / description
      Previous value: -"Item ids to delete, 1 to 50, from list_items (or kind recycle_bin for a permanent delete)."New value: +"Item ids."
    • changedInput schema / properties / kind / description
      Previous value: -"The kind of every id."New value: +"Kind of the ids."
    • changedInput schema / properties / permanent / description
      Previous value: -"true erases for good instead of the recycle bin. Recycle-bin kinds only (not locations, screen groups or emergency templates). Needs confirmCode on a second call."New value: +"Erase for good."
  2. Added

TDQS

A5/5.0
Behavior5/5

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

Annotations already mark this as destructive and not read-only, but the description adds critical behavior: recycle-bin recovery, permanent deletion with a two-step confirmation flow, refused deletion cases, and permission requirements. It also describes side effects for deleted playlists, schedules, screens, and locations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with purpose, then organized into when to use, when not to use, behavior, and parameter notes. Every section adds actionable information without repetition or 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?

Given that this is a destructive mutation tool with complex permanent-delete confirmation behavior, the description covers prerequisites, alternatives, side effects, refusals, permissions, and parameter interaction. An output schema exists, and the description appropriately includes key response elements such as wouldErase, confirmCode, ok, and error without duplicating full return documentation.

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

Parameters5/5

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

Schema coverage is 100%, but the description still adds meaningful semantics beyond the schema: all ids must be of the specified kind, permanent deletion requires a first call and a confirmCode, and the confirmCode is time-limited and tied to the same kind and ids. The example further clarifies invocation.

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: deleting items into the 30-day recycle bin. It also clarifies scope and distinguishes the operation from adjacent actions by naming alternatives in the When NOT section.

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 says when to use the tool, including confirming the target first, and when not to use it. It names concrete alternatives such as update_items removeScreenIds and end_takeover for cases that should not use delete_items.

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

All Brix Digital Signage 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