Skip to main content
Glama
Sign In
tmw-mcp

tmw-mcp

by bjorn
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

trade_lock

Locks your side of a trade to signal readiness to commit, confirming you are prepared to complete the exchange in The Mana World.

Instructions

Lock your side of the trade (indicate readiness to commit).

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "trade_lock"
  }
}

Input Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.4

TDQS

B3.3/5.0
Behavior2/5

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

No annotations are provided, so the description must carry the full behavioral burden. It only states that the tool locks your side of the trade and indicates readiness to commit; it does not describe whether the action is reversible, what happens after locking, whether it requires the other party to act, or any side effects or permissions.

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?

The description is a single, front-loaded sentence with no wasted words. It efficiently conveys the core action and its intended meaning.

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

Completeness2/5

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

With no annotations, no output schema, and no parameters, the description carries the entire burden of explaining behavior. It is too minimal for a state-changing trade action: it omits the sequence with related tools (e.g., trade_request, trade_accept, trade_commit), what locking entails, and any conditions or consequences.

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?

The tool has zero parameters and schema description coverage is effectively 100% (nothing to document). Per the rubric, 0 params yields a baseline of 4; the description adds no parameter details because none exist.

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 states a specific verb and resource: 'Lock your side of the trade.' The parenthetical clarifies the purpose as indicating readiness to commit, which implicitly distinguishes it from trade_commit. However, it does not explicitly name trade_commit as a distinct sibling, so the differentiation is not fully spelled out.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The phrase 'indicate readiness to commit' implies the condition under which the tool should be used, but it does not explicitly compare against alternatives such as trade_commit or explain when not to use it. Usage is only implied, not directly stated.

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