Skip to main content
Glama

Delete customer item mapping (dangerous)

delete_customer_product

Deletes a customer product mapping by customer number and item number; requires confirm:true and AIOTIC_MCP_ALLOW_DANGEROUS=true.

Instructions

DELETE /customer-product/{customer_number}/{customer_item_number}. Requires AIOTIC_MCP_ALLOW_DANGEROUS=true and confirm:true.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
confirmNo
customer_numberYes
customer_item_numberYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.2.1

TDQS

A3.5/5.0
Behavior3/5

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

With no annotations, the description carries the full behavioral burden. It does disclose that this is a destructive DELETE gated behind an environment flag and confirmation, which is genuinely useful. It does not describe irreversibility, side effects on related records, or error behavior when the gate is off.

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?

Two short sentences, zero filler, with the operation and its safety gate front-loaded. Every clause earns its place.

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?

There is no output schema, so the description would ideally note the return/confirmation behavior, and it doesn't. It covers the operation and its gating prerequisites adequately, but a destructive tool with three undocumented parameters and no annotations should say more about consequences.

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 description coverage is 0%, so the description must compensate. It adds real meaning for confirm (must be true to proceed, matching the schema default of false) and implies the two path parameters via the URL template. It does not explain the customer_number/customer_item_number format or pattern constraints.

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 gives a concrete verb+resource through the HTTP route DELETE /customer-product/{...}, so an agent can tell it removes a customer-item mapping. It is clear but does not explicitly distinguish itself from siblings like upsert_customer_product or delete_customer beyond the route name.

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?

It states a prerequisite (AIOTIC_MCP_ALLOW_DANGEROUS=true and confirm:true), which implies 'only use in a danger-enabled session'. However, it never says when to choose this over alternatives such as upsert_customer_product, nor any exclusion conditions.

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