Skip to main content
Glama
stupidprogrammer4

digikala-mcp

Remove From Account Cart

remove_from_account_cart
DestructiveIdempotent

Remove a specific item from the account cart using an approved removal plan and explicit host approval.

Instructions

Trusted backend: DELETE the exact item using this account's approved remove plan.

Requires explicit host approval. No checkout or payment. Retries never resend mutations.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
plan_idYes
session_tokenYes

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
cartNo
stateYes
reasonNo
plan_idYes
limits_exceededNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

B3.2/5.0
Behavior4/5

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

Annotations already declare destructiveHint=true, idempotentHint=true, and readOnlyHint=false. The description usefully adds that host approval is required before execution, that no payment/checkout occurs, and that retries do not re-send mutations (reinforcing idempotency). This is meaningful context beyond the annotations, though it omits what specifically is destroyed or the effect on the cart state/limits.

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?

Four short sentences, front-loaded with the action and the key constraint (host approval), then two follow-up facts. Efficient, though sentence fragments ('Trusted backend: DELETE...') reduce readability slightly.

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?

An output schema exists, so return values need not be explained. But with a destructive, open-world mutation operating on an account cart, the description should clarify the prepare/execute plan workflow, session_token origin, and what removal affects (e.g., cart totals or limits). Key context is left to the sibling tools to convey.

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 coverage is 0%, and neither parameter is described in the description or schema. The description mentions an 'approved remove plan' which hints at plan_id's semantics, but session_token is entirely unexplained. For a mutation tool with two required undocumented parameters, the description does not compensate for the coverage gap.

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

Purpose3/5

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

The description implies a DELETE-style removal from a cart, but the tool name is remove_from_account_cart and the description never explicitly states 'removes an item from the account cart.' It uses vague phrasing ('DELETE the exact item using this account's approved remove plan'), requiring the agent to infer the resource and action from the name. Siblings like remove_from_cart exist, and the description does not distinguish account-cart scoping from the regular-cart variant.

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?

'Requires explicit host approval' implies a prerequisite gating usage, and 'No checkout or payment' rules out a related operation. However, the description never explains when to use this tool versus prepare_account_cart_change, prepare_cart_change, or remove_from_cart, nor does it explain the plan_id lifecycle (prepare → execute → reconcile) that the sibling names strongly suggest.

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