FastBound MCP

Update acquisition item

update_acquisition_item

Idempotent

Correct firearm data in a pending acquisition by replacing an item with full updated details. Dry-run by default; pass confirm:true to execute the write.

Instructions

Replace an item within a pending acquisition with corrected firearm data. Supply the full item (PUT replaces it). Dry-run by default; pass confirm:true. Write.

Input Schema

TableJSON Schema

Name	Required	Description
`id`	Yes	GUID of the acquisition.
`mpn`	No
`sku`	No
`upc`	No
`cost`	No
`note`	No
`type`	Yes	Required. See list_smartlists ItemType.
`model`	Yes	Required.
`price`	No
`serial`	Yes	Required. The serial marked on the firearm.
`account`	No	Which configured FastBound account to use for this one call — an alias or account number (see list_accounts). Omit to use the active account.
`caliber`	Yes	Required. See list_smartlists Caliber.
`confirm`	No	Set true to actually execute. Omit or false returns a DRY RUN preview that sends nothing.
`importer`	No	Required for imported firearms.
`location`	No	See list_smartlists Location.
`auditUser`	No	Email recorded as X-AuditUser for the ATF audit trail. Overrides FASTBOUND_AUDIT_USER for this call. Must be an active user on the account.
`condition`	No	See list_smartlists Condition.
`externalId`	No
`itemNumber`	No
`totalLength`	No
`barrelLength`	No
`manufacturer`	Yes	Required. See list_smartlists Manufacturer.
`acquisitionItemId`	Yes	GUID of the acquisition item to replace.
`countryOfManufacture`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv0.2.0Aug 28, 2026

addedInput schema / properties / account

Added value: +{
+  "description": "Which configured FastBound account to use for this one call — an alias or account number (see list_accounts). Omit to use the active account.",
+  "type": "string"
+}

First observedv0.1.0Jul 31, 2026

TDQS

A4.3/5.0

Behavior4/5

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

The description adds meaningful behavioral context beyond the annotations: 'Supply the full item (PUT replaces it)' warns that omitted fields may be overwritten, and 'Dry-run by default; pass confirm:true' explains the two-step execution safety gate. These details are valuable beyond the idempotentHint and destructiveHint annotations. It does not contradict the annotations.

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?

The description is compact and front-loaded: the core purpose comes first, followed by the PUT behavior and the dry-run/confirm gate. Every sentence carries actionable information, and the 'Write' tag reinforces the mutation intent without wordiness.

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?

Given the tool's complexity—24 parameters, no output schema, and a destructive-ish replacement operation—the description covers the key behavioral essentials but omits return-value expectations and does not explicitly state constraints like 'only works while the acquisition is still pending.' It is adequate but leaves an agent to infer some operational boundaries from sibling tool names and the schema.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is only 54%, so the description partially compensates by explaining that the full item must be supplied because PUT replaces the entire record. This is important semantic guidance not present in the schema. It does not enumerate the undocumented optional fields, but the replacement model plus schema descriptions provide enough for an agent to construct a correct payload.

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

Purpose5/5

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

The description states a specific verb and resource: 'Replace an item within a pending acquisition with corrected firearm data.' This clearly distinguishes the tool from siblings like update_item, update_acquisition, or add_acquisition_items by scoping it to replacing an existing item in a pending acquisition. The PUT semantics further clarify the operation.

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?

The description gives clear context on when to use the tool: when replacing an item within a pending acquisition. It also explains the full-PUT replacement model and the dry-run/confirm flow. However, it does not explicitly mention any alternatives or when not to use it, such as pointing to update_item for bound-book items outside acquisitions.

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

Deploy Server

Update acquisition item

Instructions

Input Schema

Schema Changelog

TDQS

Other Tools