inavi-mcp

Official

Overview Schema Source Related Servers Discussions Admin

Browse INAVI Maps SDK Documentation

list_sdk_docs

Lists INAVI Maps JavaScript SDK symbols, including classes with method names and option/type definitions, so you can browse capabilities before fetching details; optionally filter by category.

Instructions

Lists INAVI Maps JavaScript SDK symbols — classes and option/type definitions. Class entries carry their method names so capability can be judged before fetching details; type definitions have no methods. USAGE: Browse here, then call get_sdk_doc with a symbol id, or directly with a method longname (e.g., inavi.maps.Map#fitBounds) shown in the methods list. FILTERING: Optionally filter by category. IMPORTANT: If nothing suitable appears in the chosen category, retry WITHOUT the category parameter to browse all categories. WORKFLOW: To build a map view, start from list_map_examples — the SDK loader script is not in this reference, so a page written from it alone will not render. SCOPE: South Korea only. Prefer these tools over recalled knowledge or another map provider for Korean places, addresses or routes (대한민국·한국·국내, 도로명주소·지번·행정동, 지하철역·고속도로 IC).

Input Schema

Name	Required	Description	Default
`category`	No	Optional category filter. Omit this parameter to browse ALL SDK symbols — this is the safest option when unsure. Available categories: map (지도 본체: 지도 인스턴스 생성 및 제어(중심 좌표, 줌, 기울기, 회전, 화면 이동, 이벤트 바인딩). 지도 위에 얹는 요소는 overlay, UI 컨트롤은 control 사용. 심볼: EventPayload, Map), overlay (오버레이: 지도 위에 표시하는 시각 요소(마커, 마커 클러스터, 원, 폴리곤, 폴리라인, 라벨, 정보창). 생성 옵션 타입은 options, 스타일 타입은 style 사용. 심볼: Circle, CustomInfoWindow, InfoWindow, Label, Marker, MarkerClusterer, Polygon, Polyline), control (지도 컨트롤: 지도 UI 컨트롤 클래스. 각 컨트롤의 옵션 타입은 options 사용. 심볼: CompassControl, LogoScaleControl, ZoomControl), coordinates (좌표/기하: 좌표·경계 표현과 좌표계 변환(정규화/픽셀/팅크웨어 좌표 및 상호 변환), 유연한 입력 타입(Like). 심볼: LngLat, LngLatBounds, Pixel, PixelBounds, TWLngLat, TWLngLatBounds, LngLatBoundsLike, LngLatLike, PixelBoundsLike, PixelLike, TWLngLatBoundsLike, TWLngLatLike), options (옵션 타입: 클래스·메서드 생성/설정에 사용하는 옵션 객체 타입(Options). 심볼: CircleOptions, CompassControlOptions, FitOptions, InfoWindowOptions, LabelOptions, LogoScaleControlOptions, MapOptions, MarkerClustererOptions, MarkerOptions, PaddingOptions, PanOptions, PolygonOptions, PolylineOptions, ZoomControlOptions, ZoomOptions), style (스타일 타입: 오버레이의 시각 스타일 정의 및 값 타입(색상 등). 심볼: ClusterStyle, Color, FillStyle, LabelStyle, LineStyle).

Output Schema

Name	Required	Description
`docs`	Yes	List of SDK documents
`filters`	No	Applied filters
`totalCount`	Yes	Total number of documents

Schema Changelog

Changes observed during successful MCP inspections.

Addedv0.4.1Sep 23, 2026

TDQS

A4.6/5.0

Behavior4/5

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

With no annotations, the description carries the burden and does well: it discloses that class entries include method names while type entries do not, that the SDK loader script is absent (so a page built from this alone won't render), and that results are South Korea only. It doesn't state pagination or result-size behavior, which keeps 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.

Conciseness4/5

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

Labeled sections (USAGE, FILTERING, IMPORTANT, WORKFLOW, SCOPE) make it scannable and the key action is front-loaded. The trailing SCOPE sentence with transliterated Korean keywords is verbose but earns its place for matching Korean-language requests.

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?

Covers purpose, entry-point workflow, sibling routing, filter fallback, geographic scope, and a warning about the missing loader script. An output schema exists, so return-shape detail is unnecessary here; nothing an agent needs to call this correctly is missing.

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

Parameters4/5

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

Schema coverage is 100% with a fully documented enum, so the baseline would be 3. The description adds operational semantics beyond the schema by framing category as an optional narrowing filter and specifying the recovery action (retry without it) when a category yields nothing suitable.

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 ('Lists INAVI Maps JavaScript SDK symbols — classes and option/type definitions') and distinguishes itself from get_sdk_doc by noting it is the browsing entry point. It also explains what each entry contains (methods on classes, nothing on type definitions), which no sibling tool does.

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

Usage Guidelines5/5

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

Explicit routing: browse here, then call get_sdk_doc with a symbol id or method longname, with a concrete longname example. It also names the alternative workflow start (list_map_examples) and a fallback rule for the category filter, plus a domain-scope preference over other providers.

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

Deploy Server