Skip to main content
Glama
Sign In
inavi-mcp

inavi-mcp

Official
by inavi-systems
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Get INAVI Maps Example HTML

get_map_example

Retrieve a ready-to-use INAVI Maps HTML example by ID, including its metadata and full template. Find the ID with list_map_examples, then insert your app key before running.

Instructions

Retrieve one INAVI Maps HTML example by id, with its full metadata (description, keywords, use cases, features) and the complete HTML template. PREREQUISITE: Use list_map_examples to find the id. LOADER: The template ends with the SDK loader script. Its domain is filled in, but {appKey} is left as a placeholder — substitute a real application key before the page will run. CUSTOMIZING: Data values (coordinates, zoom, labels, colors) can be replaced freely. Options, methods, events or styles the template does not show may be added, but verify each one with get_sdk_doc first — never invent API from memory or another provider, as INAVI Maps and Google Maps differ in syntax.

Input Schema

NameRequiredDescriptionDefault
idYesExample ID to retrieve (e.g., "marker-basic", "shapes-polyline"). Use list_map_examples tool first to see available IDs.

Output Schema

NameRequiredDescriptionDefault
metadataYesComplete metadata for the selected example
htmlContentYesComplete HTML template code with INAVI Maps API integration

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.4.2
    • changedOutput schema / properties / htmlContent / description
      Previous value: -"Complete HTML template code with iNavi Maps API integration"New value: +"Complete HTML template code with INAVI Maps API integration"
  2. Changed2 schema fields changedv0.3.10
    • removedInput schema / $schema
      Removed value: -"http://json-schema.org/draft-07/schema#"
    • removedOutput schema / $schema
      Removed value: -"http://json-schema.org/draft-07/schema#"
  3. First observedv0.3.9

TDQS

A4.2/5.0
Behavior4/5

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

With no annotations, the description carries the full burden and delivers: it discloses the {appKey} placeholder gotcha that prevents the template from running, notes the loader script at the end, and warns that INAVI and Google Maps syntax differ so API must not be invented. It omits return size or pagination expectations, keeping it short of 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.

Conciseness4/5

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

Front-loads the core action, then uses bolded labels (PREREQUISITE, LOADER, CUSTOMIZING) to segment secondary guidance so an agent can scan it. Slightly dense, but each labeled block conveys a distinct, actionable fact.

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

Completeness5/5

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

An output schema exists, so return structure need not be spelled out, yet the description still previews the payload (metadata plus template). Combined with the prerequisite, the placeholder warning, and the customization rules, nothing needed to call it correctly is missing.

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

Parameters3/5

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

The single id parameter is already fully documented in the schema (100% coverage), including example values and the pointer to list_map_examples. The description only restates that lookup is by id, adding no format or constraint detail beyond the schema.

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

Purpose5/5

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

States a specific verb and resource ("Retrieve one INAVI Maps HTML example by id") plus exactly what is returned (metadata and complete HTML template). This clearly distinguishes it from the sibling list_map_examples, which only enumerates ids.

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

Usage Guidelines4/5

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

Gives an explicit prerequisite ("Use list_map_examples to find the id") and a clear routing rule for related work (verify any extra API surface with get_sdk_doc first). It does not state when to avoid this tool, but the retrieve-by-id scope makes misuse unlikely.

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

Deploy Server

Other Tools