메리츠 환전

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

Annotations blanket the whole tool as destructiveHint=true and idempotentHint=false, but the description narrows that by flagging only fx_exchanges (POST) with '⚠ 상태변경', telling the agent that the other three are read-style GETs. That is genuine added context beyond the annotations, though it omits auth requirements and rate limits.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the resource and dispatch mechanism, then a compact table of the four sub-APIs with method and a one-word purpose plus the '⚠ 상태변경' marker. Every line earns its place and nothing is padded.

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

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

An output schema exists, so return values need no prose, and annotations cover the safety profile. The description supplies the dispatch contract, the valid api_type set, and a self-documentation path via 'describe'; only the account parameter and auth prerequisites are left unaddressed.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so the description must carry the load, and it does for api_type: it lists the valid values (the four sub-APIs plus 'describe') and explains params as the container for sub-API arguments. The account parameter is left unexplained, and per-sub-API params are deferred to the describe call, so it is strong but not complete.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a specific domain (메리츠 Open API — 환전) and enumerates the four sub-operations it dispatches (fx_exchanges, fx_exchanges_history, fx_rates, fx_rates_applied) with their HTTP methods and intent. This lets an agent separate it from siblings like meritz_trading or meritz_market, though the sibling differentiation is by domain naming rather than an explicit contrast.

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

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

It explicitly explains the invocation pattern (choose the API via api_type, pass arguments via params) and gives a concrete self-service path: api_type='describe' returns parameter descriptions. It stops short of stating when to prefer this tool over sibling tools, so it sits at clear-context without exclusions.

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