get_order

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

Annotations already declare readOnlyHint, idempotentHint and openWorldHint, so the safety profile is covered. The description adds one genuine behavioral fact beyond the annotations: closed/terminated orders are still returned rather than filtered. It says nothing about behavior when the order id is unknown, whether an account mismatch errors, or the response shape.

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?

Two short sentences, the core purpose front-loaded and the closed-order caveat second. Every clause carries information; there is no filler.

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?

For a two-parameter read tool with full schema documentation and annotations covering the safety profile, this is close to complete: it states what is retrieved, what the payload contains, and an important data-scope caveat. The remaining gap is what happens on an invalid or inaccessible order id, which is minor for this complexity.

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 100% and the schema descriptions already explain that order_id comes from list_orders and that account_seq falls back to TOSSINVEST_ACCOUNT_SEQ when omitted. The description adds no parameter-level meaning beyond that, so the baseline of 3 applies.

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?

"주문 1건의 상세(상태·체결 내역)를 조회한다" names a specific verb (조회) and resource (단일 주문 상세), and scopes the payload to status and fill/execution history. The word "1건" signals the single-order counterpart to list_orders without naming it, so an agent can tell them apart, though the sibling is only identified in the schema text.

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?

Usage is only implied: fetch one order's detail when you already have its identifier. "종료된 주문도 조회된다" is a useful usage-relevant note that the agent need not fear closed orders being filtered out. There is no explicit statement of when to prefer this over list_orders or get_conditional_order.

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