tiendanube_locations_deleteDeletes a specified Tiendanube/Nuvemshop location by ID, letting AI assistants remove obsolete or incorrect store locations through the API.
Delete a location. HTTP: DELETE /locations/{id} Required scope: write_locations API version: 2025-03
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Location ID |
Changes observed during successful MCP inspections.
v1.0.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds valuable technical context by providing the HTTP method and the required scope ('write_locations'), which complements the metadata in the annotations. However, since annotations already declare it destructive and idempotent, the added behavioral context is only moderate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The definition is highly efficient and front-loaded. It provides the verb, the resource, the API path, the required scope, and the version in a minimal, waste-free manner.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the tool is technically complete for invocation (it requires one ID), it lacks the 'why' of the operation. Without usage guidance, the agent relies entirely on external logic to decide if deletion is appropriate for the given context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Since the schema coverage is 100%, the parameter 'id' is fully defined in the structure. The description adds no semantic meaning beyond what is already captured in the schema's 'Location ID' description, meeting the baseline requirement.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the action ('Delete a location') and the resource, which, when combined with the specific name, distinguishes it from sibling tools like tiendanube_locations_create or tiendanube_locations_update.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when this tool should be used versus alternatives. It assumes the agent knows the correct state for deletion and does not mention preconditions or potential consequences beyond the implicit destructive nature.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.