Skip to main content
Glama

Acquisition status

acquisition_status
Read-onlyIdempotent

Where a purchase stands: waiting for the transfer, paid and waiting for the studio's approval, or approved, with links to the invoice, the certificate of authenticity and the download, which expire. While a private buyer can still withdraw (within fourteen days, until the download begins), it also gives the link to withdraw: if the buyer says they want to withdraw, give them that link. Takes the confirmation code and the buyer email.

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": {
      "confirmation_code": "<confirmation_code>",
      "buyer_email": "<buyer_email>"
    },
    "name": "acquisition_status"
  }
}

Input Schema

NameRequiredDescriptionDefault
buyer_emailYes
confirmation_codeYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A3.6/5.0
Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so the safety profile is covered. The description adds substantive context beyond that: the returned links expire, the withdrawal window is fourteen days and closes once the download begins, and there is a specific action to take on buyer withdrawal requests. Return format details (how links are structured, whether any field can be null) remain unstated.

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?

Everything is packed into one long run-on sentence with the parenthetical withdrawal rule interrupting the status enumeration. The most operational instruction (hand over the withdrawal link) is buried mid-sentence rather than front-loaded or separated, which makes it easier to miss.

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?

There is no output schema, so the description must convey return content, and it does: the three possible states plus the invoice, certificate and download links. The withdrawal-link case is covered too. Gaps are minor, mainly the expiry mechanics of the links and the failure mode for an unknown confirmation code.

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%, so the description carries the burden, and all it does is restate the two field names ('the confirmation code and the buyer email'). It adds no format hints, no indication of case sensitivity or where the code comes from, and no note on what happens if the pair doesn't match a purchase.

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 names the resource (a purchase/acquisition) and the operation (where it stands), and enumerates the concrete states it reports: awaiting transfer, paid pending studio approval, approved. It also lists what comes back (invoice, certificate, download links). Sibling tools like confirm_acquisition and request_acquisition are not named, so differentiation is inferred from the state-enumeration rather than stated.

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 gives a concrete conditional: while a private buyer can withdraw within fourteen days, give them the withdrawal link if they ask. That is real when-to-act guidance. It stops short of an explicit 'use this instead of X when Y' contrast with the sibling tools, so it is a 4 rather than a 5.

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