mcp-server

delete_ad

DestructiveIdempotent

Delete an ad. DESTRUCTIVE and NOT reversible from this surface: it stops syncing, is removed from the list, and ALSO hard-deletes the ad's feeds (channel profiles) — there is no restore tool here, so warn the user that deletion cannot be undone. Use this when the user explicitly asks to delete an ad. Ads are product-listing channels (Google Shopping, Meta catalog, Microsoft, price comparison) for the merchant's physical products, not marketplaces: they publish products to the channel and have no order sync. Confirm with the user first, then call with confirm:true. Without confirm:true the call returns error 'confirm_required' (HTTP 400) and nothing is deleted. Returns {integrationId, action:'delete', status:'deleted', kind:'ads'}. ad_id is from list_ads. project_id is OPTIONAL (inferred for a single-project customer; project_id_required otherwise — then call list_projects).

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": {
      "ad_id": "<ad_id>"
    },
    "name": "delete_ad"
  }
}

Input Schema

Name	Required	Description	Default
`ad_id`	Yes
`confirm`	No
`project_id`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedSep 1, 2026

TDQS

A4.9/5.0

Behavior5/5

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

Annotations already declare destructiveHint=true and idempotentHint=true, but the description goes well beyond them: it names the collateral damage (feeds/channel profiles are hard-deleted), states there is no restore tool on this surface, and specifies the exact failure mode (error 'confirm_required', HTTP 400, nothing deleted). It even documents the success payload. No contradiction with the destructive/idempotent hints.

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?

Destructive warning is front-loaded before any mechanics, which is the right ordering. It is dense rather than padded, though the irreversibility point is made twice ("NOT reversible from this surface" and "deletion cannot be undone") — defensible emphasis, but slightly redundant.

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?

Despite having no output schema, the description supplies the return shape, the error contract, the entity definition, the confirmation prerequisite, and parameter provenance. An agent can call this correctly and warn the user appropriately on the first attempt.

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 description coverage is 0%, so the description must carry the load and does: ad_id's provenance (from list_ads), project_id's optionality with the inference rule and the project_id_required fallback to list_projects, and confirm's gating semantics including the resulting error. All three parameters gain meaning unavailable in the bare schema.

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 ad") and then defines what an ad actually is — a product-listing channel (Google Shopping, Meta catalog, Microsoft) for physical products, explicitly not a marketplace. That definition is what separates it from siblings like delete_marketplace and delete_feed, which an agent could otherwise confuse.

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?

Gives an explicit trigger ("Use this when the user explicitly asks to delete an ad") plus a mandatory confirmation protocol: warn the user, then call with confirm:true. It also routes to alternatives for the ambiguous parameter — list_ads for ad_id, list_projects when project_id_required is returned.

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

All mcp-server 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?