Skip to main content
Glama

Cookies/Delete Cookies

cookies_delete_cookies
Destructive

Delete specific cookies by providing their names as URL parameters, returning a JSON list of remaining cookies.

Instructions

One or more cookies that has been set for this domain can be deleted by providing the cookie names as part of the URL parameter. The response of this request is a JSON containing the list of currently set cookies.

(Postman request: Cookies/Delete Cookies | GET https://postman-echo.com/cookies/delete)

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "cookies_delete_cookies"
  }
}

Input Schema

NameRequiredDescriptionDefault
foo1NoQuery parameter 'foo1'
foo2NoQuery parameter 'foo2'

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

B3.4/5.0
Behavior3/5

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

Annotations already declare destructiveHint=true, readOnlyHint=false and openWorldHint=true, so the destructive nature is covered. The description usefully discloses the return value (JSON listing currently set cookies), which matters since there is no output schema, but it says nothing about partial-deletion results, behavior for non-existent cookies, or whether the effect is reversible.

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 core action and its mechanism are stated in the first clause, and the response format follows immediately. The trailing parenthetical Postman/HTTP metadata is low-value for an agent but small enough not to undermine an otherwise tight description.

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

Completeness3/5

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

For a destructive cookie-mutation tool with no output schema, the description covers the action and the return payload, but it omits the important edge case that zero parameters are required — an agent could call it with no cookie names and the description gives no clue what that does.

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%, so the baseline is 3. The description does add that the parameters represent cookie names to delete, which is more than the schema's placeholder "Query parameter 'foo1'", but it never explains which name maps to foo1 vs foo2 or that both are optional, leaving the semantics ambiguous.

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?

The description names a specific verb and resource (delete cookies for this domain) and states the mechanism (cookie names as URL parameters), so it is clearly distinguishable from cookies_set_cookies and cookies_get_cookies in the sibling list. It stops short of explicitly naming those siblings as alternatives, so it lands at 4 rather than 5.

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

Usage Guidelines3/5

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

"One or more cookies ... can be deleted by providing the cookie names" implies the usage condition, but there is no explicit statement of when to prefer this over cookies_set_cookies/cookies_get_cookies, and no mention of what happens if no cookie names are supplied. Usage is inferable but not guided.

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