Skip to main content
Glama

bill-of-sale

by io.github.theluckystrike
OverviewDiscussionsAdmin

Record a sale

sale_create

Record a sale and generate the bill of sale: who sold, who bought, what item (with VIN, serial or IMEI where it has one), the price in minor units and the date. Returns the BOS-YYYY-NNNN number of the draft. The draft can still be changed with sale_update; sale_finalize freezes it into the signing copy and sale_render prints it. Free tier: 10 drafts.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
vinNoVehicle Identification Number, 17 characters, for a vehicle sale
dateNoThe date of the sale, YYYY-MM-DD. Default today
imeiNoIMEI, 15 digits, for a phone or tablet
as_isNoInclude the as-is clause: sold with all faults, no warranties except any written here. Default true, the norm for second-hand sales; pass false to leave it out
notesNoAnything else the document should say, e.g. payment method or what is included in the sale
serialNoSerial number, for equipment and electronics
currencyYesISO code the price is in
quantityNoHow many units this document covers. Default 1
warrantyNoA warranty the seller does give, in their own words, e.g. The seller warrants the engine for 30 days from the sale date
conditionNoThe condition at handover, e.g. used, good working order, or new, sealed
buyer_nameYesWho is buying, e.g. Jane Kowalska or Northwind Sp. z o.o.
buyer_emailNoThe buyer's email
buyer_phoneNoThe buyer's phone number
price_minorYesThe sale price in whole minor units (integer cents). 120000 is USD 1,200.00
seller_nameNoWho is selling. Defaults to the shared business profile's name when the profile has one
duplicate_okNoRecord it even though an identical sale to the same buyer exists, for a genuinely repeated sale. Default false
seller_emailNoThe seller's email
seller_phoneNoThe seller's phone number
buyer_addressNoThe buyer's postal address, one string
item_categoryNoWhat kind of item, e.g. vehicle, equipment, electronics, stock
seller_addressNoThe seller's postal address, one string
identifier_otherNoAny other identifying number, e.g. a hull number or an asset tag
item_descriptionYesWhat was sold, specific enough to identify it, e.g. 2019 Honda Civic 1.5 petrol, grey, or MacBook Pro 14-inch 2021

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.4/5.0
Behavior4/5

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

No annotations are provided, so the description carries the full behavioral burden. It discloses the return value (BOS-YYYY-NNNN), the mutable-draft state, and the free-tier quota, but says nothing about permissions, duplicate-detection errors (only the duplicate_ok param implies it), or what happens when the quota is exhausted.

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?

Three sentences, front-loaded with the core action and output, then the sibling workflow, then the quota. No filler; every clause carries information an agent needs.

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

Completeness4/5

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

For a 23-parameter creation tool with no annotations and no output schema, the description supplies the return identifier, the lifecycle context, and the quota. It stops just short of describing failure modes such as duplicate rejection, though the schema's duplicate_ok parameter partly covers that.

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 100% with 23 well-documented properties, so the schema already does the heavy lifting. The description recaps the required concepts (who sold, who bought, item with VIN/serial/IMEI, price in minor units, date) but adds no syntax or format detail beyond the schema.

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?

States a specific verb and resource ('record a sale'), then immediately scopes it as generating the bill of sale draft. It is clearly distinguishable from the sibling lifecycle tools it names.

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

Usage Guidelines5/5

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

Explicitly routes the agent through the workflow: the draft created here can be changed with sale_update, frozen by sale_finalize, printed by sale_render. It also flags the free-tier limit of 10 drafts, which is a concrete when-to-call constraint.

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

All bill-of-sale toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources