Skip to main content
Glama

trade_cancel

Read-onlyIdempotent

Cancel your trade offer (Withdraws a trade you initiated; nothing moves, and the other player is notified. Fails with trade_in_progress once their accept is already committing (the trade will complete), and with trade_not_found if the trade is gone.)

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
trade_idYesUUID of the trade offer
session_idYesYour session ID from login/register

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added
  2. Removed
  3. First observed

TDQS

A3.6/5.0
Behavior1/5

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

Annotation Contradiction: annotations declare readOnlyHint=true, yet the description says the tool 'Withdraws a trade you initiated' and 'the other player is notified' — both are state-changing behaviors. This directly contradicts the read-only annotation, making the behavioral picture unreliable.

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?

Single well-structured sentence with the core action front-loaded, followed by necessary side effects and failure modes. Every clause earns its place; there is no boilerplate or repetition.

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?

The description covers what happens (withdrawal), what does not happen (nothing moves), side effects (notification), and both likely failure modes. It does not describe the success return payload, but for a simple cancel action with no output schema the provided context is nearly complete.

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%, so the schema fully documents both required parameters. The description adds no parameter-level meaning beyond what the schema already provides, which matches the baseline score of 3.

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?

Description states a specific verb ('Cancel') and resource ('your trade offer'), and clarifies scope: 'Withdraws a trade you initiated.' This distinguishes it from sibling trade actions like trade_accept and trade_decline without needing to open schemas.

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?

Clear context is provided: it applies to trades you initiated, nothing moves, and the other player is notified. It also gives failure conditions that tell the agent when cancellation is not possible (trade_in_progress, trade_not_found). It does not explicitly name alternative tools, but the usage context strongly implies when it should be used.

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