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

With no annotations, the description must carry the behavioral burden. It does well by explaining this is a retrieval operation and disclosing that all $ref references are dereferenced. It does not explicitly state there are no side effects, but 'retrieves' strongly implies a read-only operation.

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 scannable with clear PREREQUISITE, USAGE, and NOTE sections. There is slight redundancy between 'Retrieves detailed specification' and 'complete API specification', but every sentence contributes useful information.

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 single-parameter tool with an output schema, the description covers the necessary predecessor step, what input to provide, and what the response will contain. No critical operational detail is missing.

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%, so the baseline is 3. The description adds value beyond the schema by explaining that operationId comes from list_api_specs and is the key to selecting a complete API specification.

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 uses a specific verb and resource: 'Retrieves detailed specification of a specific API'. It clearly differentiates from sibling tools by requiring an operationId and referencing list_api_specs as the prerequisite browsing step.

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 explicitly states a PREREQUISITE ('First use list_api_specs to browse available APIs and obtain the operationId') and a USAGE ('Provide an operationId'), making the correct call flow and tool selection unambiguous.

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?

With no annotations provided, the description carries the full burden and handles it well: it discloses the loader script, the {appKey} placeholder that must be substituted, the fact that data values can be replaced, and the constraint that unsupported API additions must be checked against get_sdk_doc. It also warns that iNavi Maps differs from Google Maps, which is valuable behavioral context.

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 longer than average but each labeled section (PREREQUISITE, LOADER, CUSTOMIZING) adds distinct, actionable information. It is front-loaded with the core purpose and uses clear labels that make the extra guidance scannable rather than bloated.

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 single-parameter retrieval tool with an output schema, the description covers everything needed to call it correctly: how to obtain the id, what the returned template contains, what must be changed before use, and how to safely extend it. No critical gap remains.

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 already documents the id parameter with example values and the instruction to use list_map_examples. The description reinforces the prerequisite but adds little new parameter-level meaning beyond what the schema provides, so the baseline 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?

The description opens with a specific verb ('Retrieve'), a clear resource ('one iNavi Maps HTML example'), and the exact scope ('by id'), and it distinguishes itself from siblings by stating it returns metadata plus the complete HTML template. It is clearly differentiated from list_map_examples and get_sdk_doc.

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 names the prerequisite tool ('Use list_map_examples to find the id') and tells the agent when to involve another sibling ('verify each one with get_sdk_doc first'). The instruction to never invent API syntax also prevents misuse. This is strong routing guidance beyond the schema.

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?

With no annotations, the description carries the full burden. It discloses the Markdown return format, the two accepted input forms, the link-to-docId behavior for referenced types, and the omission of method-level examples. This is strong behavioral context, though it does not cover errors or auth.

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 front-loaded with the core behavior and then adds prerequisite, link semantics, and example-routing in a compact, purposeful way. Every sentence earns its place.

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?

With one parameter, full schema coverage, and no output schema, the description adequately covers return format, input variants, prerequisite browsing, and the relationship to get_map_example. An agent has enough information to invoke the tool correctly.

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 100%, so the schema already fully documents docId. The description reinforces the dual input forms and the list_sdk_docs prerequisite, but adds limited semantic value beyond the 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 the tool retrieves SDK documentation for one symbol as Markdown, and distinguishes whole-symbol retrieval from method-only retrieval. It also names get_map_example as the alternative for runnable code, separating it from sibling tools.

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 instructs the agent to use list_sdk_docs first to obtain ids and method names, and directs runnable-code needs to get_map_example. This gives clear when-to-use guidance and an explicit alternative.

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?

With no annotations, the description carries the full burden of behavioral disclosure. It reveals key behavioral traits: categorization may differ from expectations, reference documents are listed like regular APIs, scope is South Korea only, and it advises a retry-without-category fallback. It does not explicitly state read-only semantics, but the nature of listing is implied. The description adds meaningful behavioral context beyond a bare 'lists APIs'.

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 long but well-organized with labeled sections (USAGE, FILTERING, IMPORTANT, NOTE, SCOPE). It front-loads the core purpose and then provides necessary operational details. Every sentence adds value—no fluff. The length is justified by the complexity of category filtering and the important retry rule, but it could be slightly tightened without losing clarity.

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 that an output schema exists (indicated by 'Has output schema: true'), the description need not explain return values. It covers the workflow, filtering behavior, edge cases, and scope. It also mentions the existence of reference documents and how to access them. For a listing tool with one optional parameter, this is complete and leaves no critical gaps for an agent to call it correctly.

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 sole parameter 'category' is fully documented in the schema with a 100% coverage description, including detailed per-category explanations and usage hints. The description adds the behavioral note about retrying without category and the fact that filtering is optional, but it doesn't add much beyond the schema's already rich semantics. Given the schema coverage, a 3 baseline applies; the retry guidance bumps it to 4.

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 a specific verb+resource: 'Lists available iNavi Maps APIs.' It clearly distinguishes itself from sibling get_api_spec (which retrieves detailed specs) and other listing tools like list_sdk_docs or list_map_examples. The purpose is unambiguous and the tool's role in the workflow is stated.

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 guidance is explicit and prescriptive: 'USAGE: First browse available APIs with this tool, then use get_api_spec to retrieve detailed specifications.' It also instructs when to retry without the category parameter and gives a strong directive to prefer these tools over recalled knowledge or other map providers for Korean data. No ambiguity about when to invoke this tool.

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?

No annotations are provided, so the description carries the full burden. It discloses the return format (one summary per example: id, category, title, description, first two use cases), the filtering behavior (optional category, retry without category), and the scope limitation (South Korea only). It also reveals a behavioral trait: only these templates carry the SDK loader script, which is important context. It doesn't mention pagination or rate limits, but for a browse tool with a clear output schema, this is strong disclosure.

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 dense but well-structured with clear sections (USAGE, FILTERING, IMPORTANT, WORKFLOW, SCOPE). Every sentence earns its place, and the most critical information (start here, use get_map_example) is front-loaded. It is longer than the minimum, but the length is justified by the rich guidance it provides. Slight redundancy in the SCOPE section (listing Korean terms) could be trimmed, but it's not wasteful.

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's simplicity (1 optional parameter, output schema present), the description is complete. It covers what the tool returns, how to use it, when to use alternatives, and the geographic scope. The output schema handles return-value details, so the description doesn't need to explain them. An agent can confidently select and invoke this tool correctly based on this description alone.

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 100%, so the schema already documents the category parameter well, including enum values and their meanings. The description adds value by explaining the filtering workflow (retry without category if nothing suitable) and by reinforcing the category options. It doesn't add much beyond the schema, but the baseline for 100% coverage is 3, and the description's workflow guidance elevates it slightly.

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's purpose: browsing render-ready iNavi Maps HTML examples, with a specific verb ('Browse') and resource ('iNavi Maps HTML examples'). It distinguishes itself from siblings by explicitly naming get_map_example as the follow-up for full metadata/HTML, and mentions list_sdk_docs/get_sdk_doc for SDK documentation. The scope (South Korea only) and the explicit preference over other map providers further sharpen its identity.

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 provides explicit usage guidance: start here for any map rendering request, use get_map_example with the id for full metadata/HTML, retry without category if nothing suitable appears, and use list_sdk_docs/get_sdk_doc for anything a template omits. It also states when NOT to use it (for SDK docs) and gives a clear workflow. This is exemplary guidance for an agent.

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?

With no annotations provided, the description carries the full behavioral burden and largely meets it: it discloses that class entries carry method names while type definitions have none, that a category filter may yield nothing (prompting a retry without it), and that the SDK loader script is absent from this reference so output alone won't render. Minor unaddressed behaviors like ordering or result limits keep it from a 5.

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 longer than average but earns each section with labeled blocks (USAGE, FILTERING, WORKFLOW, SCOPE) that are front-loaded after the core purpose sentence. The density is justified by the routing and scope information; slightly more trimming of the Korean keyword list would make it a 5.

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 browse tool with one optional parameter and an output schema (which covers return values), the description covers everything an agent needs: purpose, follow-up tool, filter fallback, map-view workflow, and geographic scope. No critical gap remains.

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 100% and the category enum already carries rich per-value explanations with symbol lists, so the baseline is 3. The description adds only the operational hint to retry without the category parameter if nothing suitable appears; it does not need to compensate for any schema gap.

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 a specific verb+resource: 'Lists iNavi Maps JavaScript SDK symbols — classes and option/type definitions.' It differentiates from siblings by naming the follow-up tool (get_sdk_doc) and the alternative entry point for map views (list_map_examples), so an agent can select it correctly without opening schemas.

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?

Explicit when/where guidance is given in labeled sections: 'Browse here, then call get_sdk_doc' defines the chaining relationship; 'To build a map view, start from list_map_examples' is an explicit when-not-to-use; 'Prefer these tools over recalled knowledge or another map provider for Korean places' states the exclusion of alternatives. Nothing is left to inference.

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