Skip to main content
Glama
Sign In
glongus-mcp

glongus-mcp

by glongusmain
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

Cancel a purchase from a business (buyer)

cancel_purchase
Destructive

Cancel a UK business purchase under the 14-day right to cancel: refunds instantly before dispatch, or starts a return with instructions once delivered.

Instructions

Buyer only, and only when the seller was a business (transaction seller_is_business: true): the UK 14-day right to cancel. Before dispatch it cancels at once and refunds the price and fee. Once delivered, within 14 days (cancellation_deadline), it starts a return: the result has return_to, the address to send it back to within 14 days, then call mark_return_dispatched. Return postage is your owner's to pay. Only call it when your owner has decided to send it back. Requires GLONGUS_API_KEY.

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": {
      "transaction_id": "<transaction_id>"
    },
    "name": "cancel_purchase"
  }
}

Input Schema

NameRequiredDescriptionDefault
transaction_idYesTransaction id

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.18.0

TDQS

A4.6/5.0
Behavior5/5

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

Annotations already flag destructive=true, and the description goes well beyond them: pre-dispatch behaviour is an immediate cancel with price and fee refund; post-delivery behaviour converts the call into a return flow with a supplied return address and deadline. It also discloses that return postage is the owner's cost and that GLONGUS_API_KEY is required.

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?

Dense but front-loaded: scope and the two branches (pre-dispatch vs. delivered) come before the caveats about postage and the owner's decision. Each clause carries information, though the parenthetical field references make the first sentence slightly overloaded.

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 no output schema, the description carries the burden of describing what comes back, and it does — the result's return_to and the 14-day deadline are disclosed, along with the required follow-up tool. For a single-parameter destructive tool, nothing an agent needs to call it correctly is 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?

Only one parameter exists and the schema documents it at 100% coverage, so the description need not re-explain transaction_id; the seller_is_business and cancellation_deadline fields it references are transaction attributes rather than inputs. It adds no syntax or format detail beyond the schema, which is the expected baseline here.

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 names a specific verb and resource ('cancel a purchase'), then narrows scope precisely: buyer-only, business-seller-only, tied to the UK 14-day right to cancel. The qualifier '(transaction seller_is_business: true)' makes it trivially distinguishable from the sibling cancel_sale.

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?

It states explicit preconditions ('Buyer only', 'only when the seller was a business', 'Only call it when your owner has decided to send it back') and gives the follow-up path after delivery: wait for return_to, ship within 14 days, then call mark_return_dispatched. Both when-to-use and the next step are spelled out.

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

Deploy Server

Other Tools