Skip to main content
Glama
Sign In

Hundo

by finance.hundo
OverviewDiscussionsAdmin

propose_collectibles_add

Propose adding trading cards to the user's collection: cards bought as singles, pulled from a booster box or packs, received as a gift, or received in a trade. Find each card's variantId with search_cards first. Returns a proposal id and a preview with each card's market value and what it will cost; to record it, call the confirm_proposal tool with the returned proposalId after the user approves (there is no UI button or proposal card to click in this context). Show the user the cards, their conditions and the money before they approve. Copies of a print the user already holds in the same condition join that card.

MCP note: this tool only CREATES a pending proposal; nothing is recorded until confirm_proposal is called.

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": {
      "date": "<date>",
      "cards": "<cards>"
    },
    "name": "propose_collectibles_add"
  }
}

Input Schema

NameRequiredDescriptionDefault
boxNosource 'opening' only: the box or packs. Give boxId, or exactly one of payments, newPayment and price.
dateYesYYYY-MM-DD: the day the cards came in.
cardsYesThe cards that came in, one line per print and condition.
givenNosource 'trade' only: the cards the user gave away.
sourceNoWhere the cards came from. 'singles': bought one by one, each line with its own optional price. 'opening': pulled from a booster box or packs; one price in `box` is split over the cards by market value. 'gift': no cost. 'trade': traded for cards the user gave (list them in `given`); their cost moves to the cards received.singles
currencyNosource 'singles': the 3-letter currency of every `paid`. Required when a card has `paid`; with accountId it must be the account's currency.
accountIdNosource 'singles' only: the account the cards were paid from (from get_accounts). Each card with `paid` is then recorded as a buy from this account, so its balance goes down. Leave it out when the payment is already recorded or the user does not want it recorded: the cards then carry their cost and no money moves.
editsProposalIdNoId of a pending collectibles_add proposal to replace with this one, when the user asks to change it. Omit for a new one.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.4/5.0
Behavior4/5

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

Annotations already declare non-readonly, non-destructive, non-idempotent, closed-world; the description adds real context beyond them: the deferred-commit model (nothing recorded until confirm_proposal), that the call returns a proposal id plus a market-value/cost preview, and that duplicate copies merge into an existing condition line. It stops short of stating proposal expiry, failure modes, or what happens on rejection, so it is strong but not exhaustive.

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?

Purpose is front-loaded in the first clause and the workflow follows in a logical order. The closing MCP note ('only CREATES a pending proposal; nothing is recorded until confirm_proposal is called') largely restates the earlier 'to record it, call the confirm_proposal tool', costing a sentence of redundancy.

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

Completeness5/5

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

With 8 parameters, deep nesting, and no output schema, the description covers the gaps that matter: it describes the return value (proposal id + per-card market value and cost preview), the full create-then-confirm lifecycle, and the cross-tool lookups required. Nothing an agent needs in order to call this correctly appears to be missing.

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% and the nested `source`/`box`/`cards` fields are already documented in detail, so the schema carries the parameter burden. The description only adds cross-tool provenance (variantId from search_cards) and a reminder to surface conditions and money to the user; it adds nothing about the semantics of `editsProposalId`, `share`, or `given` beyond what the schema says. Baseline 3 applies.

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 ('Propose adding trading cards to the user's collection') and immediately enumerates the four acquisition modes (singles, box/packs, gift, trade) that map onto the `source` enum. An agent can distinguish it from siblings like propose_collectible_edit or propose_asset_trade without opening either schema.

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?

Explicit prerequisites and sequencing: look up each `variantId` via search_cards first, then call confirm_proposal with the returned proposalId after the user approves, and show the user cards/conditions/money before approval. It also rules out an assumed alternative ('there is no UI button or proposal card to click in this context'), which is exactly the when-not guidance agents need.

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

All Hundo toolsInspect
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