Get iNavi Map Example HTML

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.