Pingstack

Delete dashboard

delete_dashboard

DestructiveIdempotent

Permanently delete a private custom dashboard and its sections. The checks on it are kept and keep running. Overview can't be deleted, and a public dashboard returns forbidden until it's unpublished. Needs the dashboards:delete permission, which is off unless granted when the connection is approved. Counts toward the limit of 10 deletes a minute, and the account owner is emailed. Returns the deleted dashboard's id and name.

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": {
      "id": "<id>"
    },
    "name": "delete_dashboard"
  }
}

Input Schema

Name	Required	Description	Default
`id`	Yes	Dashboard id (dash_…).

Output Schema

Name	Required	Description	Default
`id`	Yes
`name`	Yes
`deleted`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 10, 2026

TDQS

A4.5/5.0

Behavior5/5

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

Goes well beyond the destructive/idempotent annotations: it discloses that attached checks survive and keep running, the exact permission needed and when it is granted, a rate limit of 10 deletes per minute, and an owner email side effect. These are non-obvious operational facts an agent cannot get from structured fields.

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?

Front-loads the destructive action first, then side effects, blockers, permission, rate limit, and return value in short declarative sentences. Every sentence carries distinct information with 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?

Covers everything needed to call a destructive one-parameter tool correctly: consequences, blockers, auth, throttling, and even the return payload despite an output schema existing. No meaningful gaps remain.

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?

Schema coverage is 100% for the single 'id' parameter, including the dash_ prefix convention, so the description adds no parameter meaning. Baseline 3 applies since the schema carries the burden.

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 a private custom dashboard and its sections') plus scope qualifiers that separate it from deletion of other resources. The notes that Overview is undeletable and that public dashboards are blocked until unpublished implicitly distinguish it from unpublish_dashboard and delete_check.

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

Usage Guidelines4/5

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

Gives concrete preconditions: private dashboards only, Overview rejected, public dashboards must be unpublished first, and the dashboards:delete permission is required. It stops short of naming the sibling to call for the unpublish step, so the agent must infer it from the catalog.

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

All Pingstack tools Inspect

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

Need Help?