Skip to main content
Glama

Request acquisition

request_acquisition

Prepare the purchase of one artwork, or of an album sold only as one set, for a named buyer: it shows the catalogue price (never negotiated, before taxes), the taxes for this buyer, the amount to transfer, the licence (private collection and professional display together), how payment works and what happens next, and returns a confirmation code. Nothing is reserved at this step. Show the details and the licence to the buyer, and only if they agree, call confirm_acquisition with the code. It can be completed only for a private buyer in mainland Spain or the Balearic Islands; a business or professional buyer in mainland Spain or the Balearic Islands; a business buyer in another EU country, with a valid EU VAT number; a business buyer in the United Kingdom, Switzerland, Liechtenstein or Norway, registered for VAT there; a business buyer in the United States; a private buyer in another EU country (VAT of their country, declared by the studio through the EU One-Stop Shop). Any other buyer cannot buy here yet, including a buyer in an EU territory with its own tax rules (such as Åland, the Azores, Madeira or the French overseas departments), or in Greenland or the Faroe Islands, which are outside the EU (not set up yet); a buyer in the Canary Islands (IGIC, not set up yet); a buyer in Ceuta or Melilla (IPSI, not set up yet); a buyer outside the EU (taxes of their country, not set up yet): do not tell them they can, prepare nothing, and pass them on to the studio with request_inquiry. The studio does not sell at all to a buyer in Russia or Belarus (EU sanctions): say so, and do not pass it on.

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": {
      "artwork": "<artwork>",
      "buyer_name": "<buyer_name>",
      "buyer_email": "<buyer_email>",
      "buyer_country": "<buyer_country>",
      "buyer_type": "<buyer_type>"
    },
    "name": "request_acquisition"
  }
}

Input Schema

NameRequiredDescriptionDefault
artworkYesArtwork identifier, or its exact name. An album sold only as one set (such as Splendor) is bought by its name or identifier.
agent_nameNoThe agent buying on behalf of the buyer
buyer_nameYesWho buys: the invoice and the certificate of authenticity go in this name
buyer_typeYesAlways given: ask the buyer whether they buy as a private person or as a business, and never assume it. person: a private buyer. company: a business or professional buying for its activity (a Spanish one withholds income tax; one in another EU country, the United Kingdom, Switzerland, Liechtenstein or Norway is invoiced without Spanish VAT, with a valid VAT number of its country)
buyer_emailYes
buyer_tax_idNoRequired for a company, and for a private buyer in Spain (their DNI or NIE: a Spanish invoice must show it). A company gives its tax ID; outside Spain, its VAT number (EU VAT number, UK VAT number, Swiss UID with MWST, Liechtenstein VAT number or Norwegian organisation number), or the EIN of a US company
buyer_addressNoRequired for a company (its registered address: every invoice shows it) and for a private buyer in Spain or in another EU country. In Latin letters, as for international post
buyer_countryYesTwo-letter country code (ISO 3166-1), such as ES, DE or US
buyer_name_latinNoOnly when buyer_name is written in another alphabet (Greek, Cyrillic, Chinese…): the same name in Latin letters, exactly as in the passport, or as the company is registered. The invoice and the certificate use it
payment_currencyNoEUR, the default: a SEPA transfer from an account in the buyer's name in the SEPA area. USD only for a business in the United States with no such account: the euro total plus the costs of receiving US dollars, which the buyer pays, at today's European Central Bank rate.
buyer_postal_codeNoRequired for a buyer in Spain (the Canary Islands, Ceuta and Melilla have their own taxes) and for a buyer in another EU country, private or business (some territories have their own, such as Åland, the Azores, Madeira or the French overseas departments)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.7/5.0
Behavior5/5

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

Annotations only establish non-read-only, non-idempotent, non-destructive, closed-world. The description adds the material behavior an agent cannot infer: nothing is reserved at this step, a confirmation code is returned, taxes and licence terms are disclosed, and the transaction is completed only via a separate confirm call. It also flags the payment mechanics (SEPA default vs USD surcharge) and the sanction-related refusal.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Purpose and the confirm flow are front-loaded, but the eligibility clause is a single sprawling sentence with nested parentheses and the phrase 'not set up yet' repeated four times, which is harder to parse than a short list would be. The content is largely necessary; the packaging is not.

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?

For an 11-parameter, mutation-adjacent tool with no output schema, the description covers the missing essentials: return value (confirmation code), sequencing to confirm_acquisition, eligibility constraints, and routing for rejected buyers. Nothing an agent needs to call this correctly is absent.

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 coverage is already 91%, so the baseline is 3, but the description adds real meaning beyond the fields by tying buyer_type and buyer_country to concrete tax outcomes (withholding for Spanish companies, Spanish-VAT-free invoicing in the EU/UK/CH/LI/NO, One-Stop Shop for EU private buyers). Minor gap: currency and tax-ID semantics are left almost entirely to 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?

Opens with a specific verb+resource: 'Prepare the purchase of one artwork, or of an album sold only as one set, for a named buyer', and immediately distinguishes it from confirm_acquisition, the sibling that actually completes the purchase. An agent knows exactly what this does and what it does not do (nothing is reserved).

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?

Gives explicit sequencing ('Show the details and the licence to the buyer, and only if they agree, call confirm_acquisition with the code') plus a full eligibility matrix of who can and cannot use it, with named alternatives: ineligible buyers go to request_inquiry, and Russia/Belarus buyers are refused outright with no hand-off. This is when-to-use, when-not-to-use, and where-to-route in one place.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources