RetailHardHat

Update Purchase Item

update_purchase_item

Destructive

Use this when working with RetailHardHat purchase_lists records in the connected organization. Update a purchase item. No change occurs until a human approves the exact request in Settings > MCP and execute_approved_action is called. MCP approval requirements are configurable by the organization administrator; business workflow approvals always apply.

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": {
      "siteId": "<siteId>",
      "purchaseItemId": "<purchaseItemId>",
      "data": "<data>"
    },
    "name": "update_purchase_item"
  }
}

Input Schema

Name	Required	Description	Default
`data`	Yes
`siteId`	Yes
`purchaseItemId`	Yes

Output Schema

Name	Required	Description	Default
`data`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 27, 2026

TDQS

A3.5/5.0

Behavior4/5

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

Annotations already flag destructiveHint=true and idempotentHint=false, so the safety profile is known. The description adds substantive context the annotations cannot convey: the two-step approval gate, that approval policy is admin-configurable, and that business workflow approvals still apply regardless. It does not say what a partial update does to omitted fields, which is the main remaining behavioral gap.

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 sentences, front-loaded with the scope statement and followed immediately by the approval gate, which is the highest-value information. The opening "Use this when working with..." clause is slightly boilerplate but not wasteful.

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

Completeness2/5

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

The governance model is covered thoroughly, and an output schema exists so return values need no explanation. However, for a destructive mutation over an undocumented nested payload, the description never states update semantics (merge vs overwrite) or which fields are editable, leaving the core operation underspecified.

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 description coverage is 0% and there are three parameters, including a nested `data` object with roughly two dozen fields that carry no per-field documentation. The description contributes nothing about siteId, purchaseItemId, or whether `data` is a patch or a full replacement. It cannot compensate for the coverage gap.

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 specific verb and resource ("Update a purchase item") and names the record family ("RetailHardHat purchase_lists records"). It does not distinguish this from near siblings such as update_purchase_template_item or update_purchase_template, so an agent must infer which purchase entity this targets.

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

Usage Guidelines4/5

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

It states the operating context (connected organization, purchase_lists records) and a hard prerequisite: the call is a no-op until a human approves in Settings > MCP and execute_approved_action is invoked. That is a real routing/sequencing rule. It stops short of naming when to prefer a sibling tool instead.

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

All RetailHardHat 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?