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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the description's listing of GET operations adds little beyond what annotations provide. It does not contradict annotations, but also does not add extra behavioral context like pagination or authentication requirements.

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?

The description is a compact list with a short instruction header. Each endpoint line is informative and the structure is scannable. No filler words, though the list itself is necessary for the api_type values.

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?

Given the tool covers 11 endpoints, the description provides sufficient routing via api_type and a self-service describe option for parameters. The presence of an output schema covers return values. Auth requirements are not mentioned, but that may be handled elsewhere in the API ecosystem.

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?

The schema has 0% description coverage, but the description compensates by enumerating all valid api_type values (the 11 endpoints) and explaining the params object. The describe mechanism provides a way to get further parameter details, adding meaningful guidance beyond the bare schema.

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 clearly states this is the Meritz Open API for account-related queries, listing 11 specific GET endpoints. It names the resource (계좌) and the action (조회) for each, and the account scope distinguishes it from sibling tools like meritz_market and meritz_trading.

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?

The description explains how to use the tool (select api_type, provide params) and mentions the 'describe' mode for parameter explanations. However, it does not explicitly state when to prefer this tool over siblings, though the account-specific scope makes that self-evident.

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

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

Beyond the annotations (destructiveHint=true), the description flags fx_exchanges as a state-changing POST with a warning while labeling the others as GET queries. It also reveals the self-describing describe behavior. It does not detail side effects or permissions, but annotations already signal the risk profile.

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?

The description is compact and front-loaded: one-line usage rule, a self-documentation hint, then a scannable table of the four API variants with the mutation warning. No filler or repetition.

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 multi-endpoint router with a generic params schema, the describe instruction and method listing make the tool callable without further research. It lacks endpoint-specific parameter schemas and auth/rate-limit caveats, but the self-describe mechanism and output schema cover the critical gap.

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?

With 0% schema description coverage, the description compensates by listing the valid api_type values and explaining that params is the argument container. The api_type='describe' mechanism is a practical way for an agent to discover endpoint-specific parameters, though the actual parameter names are not enumerated inline.

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?

Description states the tool is a Meritz Open API wrapper for forex/exchange and enumerates four distinct API calls (fx_exchanges, fx_exchanges_history, fx_rates, fx_rates_applied) with HTTP methods and purpose labels. This makes the tool's scope concrete and differentiates it from account/market/trading siblings.

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 explains the invocation pattern: choose an API via api_type, pass arguments via params, and use api_type='describe' for parameter documentation. However, it does not state when to prefer this tool over sibling tools or give exclusion criteria.

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

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

Annotations already declare readOnlyHint=true, so the description does not need to restate safety. It adds useful content categories (server settings, API catalog summary, known issues), but does not disclose any further behavior such as freshness of known issues, authentication expectations, or output limitations.

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?

The description is a single front-loaded sentence with no filler. Every part contributes meaning: what data is returned and for which general purpose.

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?

Given the zero-parameter schema, read-only annotation, and existing output schema, the description is largely sufficient. The only minor gap is the lack of sibling differentiation or usage context, but for a simple informational endpoint the provided content list is reasonably complete.

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?

The tool has zero parameters and the schema has 100% coverage, so there is nothing for the description to explain about parameters. The baseline of 4 for a parameterless tool applies, and the description does not omit any parameter-related information.

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 states a clear verb ('returns') and specific resources: server settings, API catalog summary, and known issues. It distinguishes itself from the sibling domain tools (account, market, trading, etc.) by describing a meta/informational scope rather than a business operation.

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?

The description gives no explicit guidance on when to use this tool versus alternatives such as meritz_reference or the domain-specific tools. The purpose is clear, but the agent is left to infer usage context from the tool name and siblings.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds valuable behavioral context: the api_type='describe' mode that returns parameter explanations, and the enumeration of the ten sub-APIs, which informs the agent of the tool's full capability without relying on the schema. It does not contradict the annotations.

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?

The description is efficient: it front-loads the purpose and usage pattern, then lists the ten endpoints in a compact, scannable table. Every line serves a purpose—there is no filler or redundant explanation—making it easy for an agent to parse and act on.

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?

Given the tool exposes ten distinct endpoints and has a sparse input schema, the description gives an agent a sufficient overview of available operations and how to discover parameter schemas via the describe mode. The output schema exists, so return value details are covered elsewhere. The description could mention authentication or rate limits, but those are not critical given the read-only, idempotent nature already indicated.

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 description coverage is 0%, so the description must compensate. It does so by listing the valid api_type values (the endpoint names) and explaining that params holds the parameters. It also instructs the agent to use api_type='describe' to obtain detailed parameter descriptions, effectively providing a self-documenting mechanism for a tool with minimal schema information.

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 clearly states the tool provides domestic stock market quotes and lists 10 specific GET endpoints for different data types (candles, investors, orderbook, prices, trades). It distinguishes itself from siblings by specifying '국내주식' (domestic stocks) and by focusing solely on market data, which is separate from trading, accounts, or overseas markets.

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?

The description explains how to choose an API via api_type and how to use params, and mentions that api_type='describe' returns parameter descriptions. However, it does not explicitly state when to use this tool versus alternatives like meritz_overseas_market or meritz_trading; the usage context is implied by the tool name and scope rather than spelled out.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds useful behavioral context: all operations are GET requests, and api_type='describe' returns parameter descriptions dynamically. It does not mention auth or rate limits, but given the annotation coverage this is acceptable.

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?

The description is well-structured: a short usage instruction followed by a compact endpoint table. Each line earns its place by mapping an api_type to a data type. The opening phrase slightly duplicates the title but is not harmful. Overall it is efficient and scannable.

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?

Given the tool is a multi-endpoint dispatcher with opaque params, the description is not fully self-sufficient for direct invocation of each sub-API. It mitigates this by pointing to api_type='describe' for parameter details, and an output schema exists. Still, for an agent to call, say, ovs_market_candles_days correctly, it would need an extra describe round-trip; the static description alone lacks that detail.

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?

Input schema has 0% description coverage, so the description must compensate. It adds meaning by listing valid api_type values and explaining that params should contain API parameters. However, it does not describe the actual keys or structures for the params object, relying instead on the api_type='describe' mechanism as a runtime fallback. This is partial compensation but not full parameter documentation.

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 clearly states this tool provides overseas stock market quotes ('해외주식 시세') and enumerates six distinct endpoint variants with specific purposes such as daily candles, minute candles, orderbook, current price, and trades. This makes the tool's function obvious and differentiates it from sibling tools like meritz_market.

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?

The description tells the agent how to select an API via api_type and provides a table mapping each api_type value to its data purpose. It also instructs to call api_type='describe' for parameter explanations. It does not explicitly discuss when to prefer this tool over meritz_market or meritz_forex, but the overseas-market scope is clear from the title and description.

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

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

The description clearly discloses dispatcher-style behavior: api_type selects one of five GET endpoints, and api_type='describe' returns parameter explanations. This aligns with the annotations (readOnlyHint, idempotentHint, destructiveHint=false) and adds useful behavioral context beyond the schema, though it omits details like error behavior or 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?

The description is compact and efficient: two short prose lines plus a clearly aligned five-row table. The routing instruction is front-loaded, and every line contributes useful information without repetition or 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 read-only router with an output schema, the description provides the essential operation list, HTTP verbs, and a self-describe fallback for parameter details. The main gap is the absence of per-endpoint parameter examples, but the describe mode mitigates this and allows an agent to discover the details at runtime.

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?

With 0% schema description coverage, the description partially compensates by explaining that api_type selects the endpoint and params holds parameters, and by pointing to the describe mode for parameter details. However, it does not document the actual parameters for each of the five endpoints, so an agent must call describe to learn the exact parameter names and formats.

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 identifies the resource as reference data and enumerates five concrete GET operations with clear labels (domestic/overseas market days, market hours, and exchanges). It is specific enough to distinguish the tool from trading or account tools, though it does not explicitly contrast it with siblings like meritz_info or meritz_market.

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?

The description explains the routing mechanics: choose an API via api_type and supply params. It does not explicitly state when to use meritz_reference versus alternative sibling tools, but the listed operation names strongly imply it is for static reference lookups such as market days and exchange lists.

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

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

Annotations already flag destructiveHint=true, readOnlyHint=false, and idempotentHint=false; the description adds a per-endpoint table marking POST state-changing calls with ⚠ 상태변경 and identifies safe GET queries. This provides concrete behavioral detail beyond the generic annotations, and nothing in the description contradicts them.

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?

The text is long but structured as a scannable table; the introductory sentence and describe instruction are the only prose. Each table line adds a distinct endpoint with its HTTP method and safety marker, so the length is justified for a 24-endpoint dispatcher.

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 24-endpoint dispatcher, the description names every order API, its method, and whether it changes state, and points to 'describe' for parameter details. It does not explain abbreviations like 'ovs', authentication prerequisites, or endpoint grouping, and the output schema is expected to cover return shape—adequate but not comprehensive.

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 description coverage is 0%, so the description must carry the parameter-semantics load. It defines api_type as the selector with 24 concrete values listed in the table, and params as the container for endpoint arguments, plus the 'describe' call to discover parameter details. It does not enumerate per-endpoint params, but the mechanism is sufficiently specified.

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 opens with "메리츠 Open API — 주문" and enumerates 24 order-related endpoints, clearly bounding the tool to trading/order operations. The table of domestic, overseas, and reserved order actions distinguishes this tool from sibling domains like account, market, forex, reference, and info.

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 explains the dispatch pattern (api_type selects the API, params holds arguments) and the 'describe' introspection call. However, it never states when to prefer this tool over sibling tools such as meritz_account or meritz_market, nor does it give exclusion criteria or when-not-to-use guidance.

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