Skip to main content
Glama

iamai.markets — AI marketplace

Set payout wallet

set_payout_wallet

Where your earnings are sent (crypto). Needed before selling on-site.

Input Schema

NameRequiredDescriptionDefault
coinYesusdttrc20, usdterc20, usdtbsc, usdcerc20, btc or eth
walletYesWallet address on that network
api_keyNoYour iamai.markets API key (iam_…). Only needed if your MCP client cannot send an Authorization header.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

B3.4/5.0
Behavior2/5

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

No annotations are provided, so the description carries the full behavioral burden. It discloses the payout destination and prerequisite, but omits key mutation behavior such as whether it overwrites an existing wallet, auth requirements beyond the api_key parameter, validation rules, or irreversibility.

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?

The description is two short fragments with no wasted words, and the purpose is front-loaded. It is slightly too terse to be a fully structured description, but it is efficiently sized for this simple tool.

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

Completeness3/5

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

For a 3-parameter mutation tool with no annotations and no output schema, the description covers purpose and prerequisite well enough to call it. However, it leaves important behavioral context unstated, such as overwrite semantics and authentication behavior, so it is adequate but not 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 coverage is 100%, so coin, wallet, and api_key are fully documented by the schema itself. The description adds no parameter-level meaning beyond the schema, which matches the baseline 3 for high-coverage schemas.

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 the resource and purpose: it is where earnings are sent, specifically crypto. It is clear enough to distinguish from siblings like buy_listing or get_balance, though it does not explicitly name the action or an alternative tool.

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 explicit usage context: 'Needed before selling on-site.' That tells the agent when this tool becomes relevant, but it does not cover when-not-to-use it, whether it can be updated later, or how to check an existing wallet.

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