Which integrations are available for this server?

Integrates with Naver APIs to provide shopping insight trends (category and keyword) and search capabilities (blog, kin, shopping, encyclopedia).

How do I use 네이버 API MCP 서버?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@네이버 API MCP 서버 search shopping for galaxy watch" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

네이버 API MCP 서버

by dataartai

Overview Schema Related Servers Score Discussions

TypeScript

Remote

네이버 API MCP 서버

네이버 쇼핑인사이트 API와 검색 API를 통합하여 제공하는 MCP(Model Context Protocol) 서버입니다.

기능

쇼핑인사이트 API (DataLab)

카테고리별 트렌드 조회

get-category-trends: 분야별 트렌드 조회 (최대 3개 카테고리)
get-category-by-device: 기기별 트렌드 조회
get-category-by-gender: 성별 트렌드 조회
get-category-by-age: 연령별 트렌드 조회

키워드별 트렌드 조회

get-keyword-trends: 키워드별 트렌드 조회 (최대 5개 키워드)
get-keyword-by-device: 키워드 기기별 트렌드 조회
get-keyword-by-gender: 키워드 성별 트렌드 조회
get-keyword-by-age: 키워드 연령별 트렌드 조회

검색 API

search-blog: 블로그 검색
search-kin: 지식iN 검색
search-shopping: 쇼핑 검색
search-encyclopedia: 백과사전 검색

Related MCP server: Naver Search MCP Server

설치

소스코드에서 설치

# 저장소 클론
git clone https://github.com/dataartai/naver-api-mcp.git
cd naver-api-mcp

# 의존성 설치
npm install

# 빌드
npm run build

설정

네이버 개발자 센터(https://developers.naver.com)에서 애플리케이션을 등록하고 클라이언트 아이디와 시크릿을 발급받으세요.
- 쇼핑인사이트 API: DataLab > 쇼핑인사이트 API 사용 신청
- 검색 API: 검색 API 사용 신청
환경 변수 설정:

방법 1: .env 파일 사용 (로컬 개발)

NAVER_CLIENT_ID=your-client-id
NAVER_CLIENT_SECRET=your-client-secret

방법 2: MCP 설정 파일에서 직접 설정

{
  "mcpServers": {
    "naver-api": {
      "command": "node",
      "args": [
        "path/to/naver-api-mcp/dist/index.js"
      ],
      "env": {
        "NAVER_CLIENT_ID": "YOUR-CLIENT-ID",
        "NAVER_CLIENT_SECRET": "YOUR-CLIENT-SECRET"
      }
    }
  }
}

사용 방법

직접 실행

npm start

Claude Desktop 설정

Claude Desktop에서 사용하려면 다음 설정 파일에 추가하세요:

Windows: %APPDATA%\Claude\claude_desktop_config.json

{
  "mcpServers": {
    "naver-api": {
      "command": "node",
      "args": [
        "D:\\OneDrive\\Cursorhome\\naver-api-mcp\\dist\\index.js"
      ],
      "cwd": "D:\\OneDrive\\Cursorhome\\naver-api-mcp",
      "env": {
        "NAVER_CLIENT_ID": "YOUR-CLIENT-ID",
        "NAVER_CLIENT_SECRET": "YOUR-CLIENT-SECRET"
      }
    }
  }
}

참고: 경로는 실제 프로젝트 경로로 변경하세요.

MCP 도구 사용 가이드

쇼핑인사이트 API 도구

카테고리별 트렌드 조회

get-category-trends: 여러 카테고리의 트렌드를 비교 조회

startDate: 시작 날짜 (YYYY-MM-DD)
endDate: 종료 날짜 (YYYY-MM-DD)
timeUnit: 시간 단위 (date, week, month)
categories: 카테고리 배열 (최대 3개)
device: 기기 필터 (pc, mobile, all) - 선택
gender: 성별 필터 (m, f, a) - 선택
ages: 연령대 배열 (10, 20, 30, 40, 50, 60) - 선택

get-category-by-device: 특정 카테고리의 기기별 트렌드

category: 카테고리 ID (예: 50000000)

get-category-by-gender: 특정 카테고리의 성별 트렌드

category: 카테고리 ID

get-category-by-age: 특정 카테고리의 연령별 트렌드

category: 카테고리 ID

키워드별 트렌드 조회

get-keyword-trends: 여러 키워드의 트렌드를 비교 조회

category: 카테고리 ID
keywords: 키워드 배열 (최대 5개)

get-keyword-by-device: 특정 키워드의 기기별 트렌드

category: 카테고리 ID
keyword: 검색 키워드

get-keyword-by-gender: 특정 키워드의 성별 트렌드

category: 카테고리 ID
keyword: 검색 키워드

get-keyword-by-age: 특정 키워드의 연령별 트렌드

category: 카테고리 ID
keyword: 검색 키워드

검색 API 도구

블로그 검색 (`search-blog`)

query: 검색어 (필수)
display: 한 번에 표시할 결과 개수 (1-100, 기본값: 10)
start: 검색 시작 위치 (1-1000, 기본값: 1)
sort: 정렬 방법 (sim: 정확도순, date: 날짜순)

지식iN 검색 (`search-kin`)

query: 검색어 (필수)
display: 한 번에 표시할 결과 개수 (1-100, 기본값: 10)
start: 검색 시작 위치 (1-1000, 기본값: 1)
sort: 정렬 방법 (sim: 정확도순, date: 날짜순, point: 평점순)

쇼핑 검색 (`search-shopping`)

query: 검색어 (필수)
display: 한 번에 표시할 결과 개수 (1-100, 기본값: 10)
start: 검색 시작 위치 (1-1000, 기본값: 1)
sort: 정렬 방법 (sim: 정확도순, date: 날짜순, asc: 가격 오름차순, dsc: 가격 내림차순)
filter: 필터 (naverpay: 네이버페이 연동 상품만) - 선택
exclude: 제외할 상품 유형 (used: 중고, rental: 렌탈, cbshop: 해외직구) - 선택

백과사전 검색 (`search-encyclopedia`)

query: 검색어 (필수)
display: 한 번에 표시할 결과 개수 (1-100, 기본값: 10)
start: 검색 시작 위치 (1-1000, 기본값: 1)

주요 카테고리 ID

패션의류: 50000000
화장품/미용: 50000002
디지털/가전: 50000003
식품: 50000008

API 제한사항

쇼핑인사이트 API (DataLab)

카테고리 배열: 최대 3개까지만 설정 가능 (get-category-trends)
키워드 배열: 최대 5개까지만 설정 가능 (get-keyword-trends)
일일 호출 한도: 하루 1,000회

검색 API

일일 호출 한도: 하루 25,000회
display: 최대 100개
start: 최대 1,000

프로젝트 구조

naver-api-mcp/
├── src/
│   ├── index.ts              # 서버 진입점
│   ├── server.ts             # MCP 서버 정의
│   └── clients/
│       ├── shoppingInsightClient.ts  # 쇼핑인사이트 API 클라이언트
│       └── searchClient.ts            # 검색 API 클라이언트
├── dist/                     # 빌드 결과물
├── package.json
└── README.md

라이선스

ISC

참고 자료

Available Tools

12 tools

get-category-by-ageD

ParametersJSON Schema

Name	Required	Description
`ages`	No
`device`	No
`gender`	No
`endDate`	Yes
`category`	Yes	카테고리 ID (예: 50000000)
`timeUnit`	Yes
`startDate`	Yes

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

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

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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

Parameters1/5

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

Tool has no description.

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

Purpose1/5

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

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

get-category-by-deviceD

ParametersJSON Schema

Name	Required	Description
`ages`	No
`device`	No
`gender`	No
`endDate`	Yes
`category`	Yes	카테고리 ID (예: 50000000)
`timeUnit`	Yes
`startDate`	Yes

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

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

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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

Parameters1/5

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

Tool has no description.

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

Purpose1/5

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

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

get-category-by-genderD

ParametersJSON Schema

Name	Required	Description
`ages`	No
`device`	No
`gender`	No
`endDate`	Yes
`category`	Yes	카테고리 ID (예: 50000000)
`timeUnit`	Yes
`startDate`	Yes

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

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

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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

Parameters1/5

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

Tool has no description.

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

Purpose1/5

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

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

get-category-trendsD

ParametersJSON Schema

Name	Required	Description
`ages`	No
`device`	No
`gender`	No
`endDate`	Yes
`timeUnit`	Yes
`startDate`	Yes
`categories`	Yes	최대 3개까지 설정 가능

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

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

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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

Parameters1/5

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

Tool has no description.

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

Purpose1/5

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

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

get-keyword-by-ageD

ParametersJSON Schema

Name	Required	Description
`ages`	No
`device`	No
`gender`	No
`endDate`	Yes
`keyword`	Yes	검색 키워드 (예: 정장)
`category`	Yes	카테고리 ID (예: 50000000)
`timeUnit`	Yes
`startDate`	Yes

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

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

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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

Parameters1/5

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

Tool has no description.

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

Purpose1/5

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

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

get-keyword-by-deviceD

ParametersJSON Schema

Name	Required	Description
`ages`	No
`device`	No
`gender`	No
`endDate`	Yes
`keyword`	Yes	검색 키워드 (예: 정장)
`category`	Yes	카테고리 ID (예: 50000000)
`timeUnit`	Yes
`startDate`	Yes

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

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

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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

Parameters1/5

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

Tool has no description.

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

Purpose1/5

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

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

get-keyword-by-genderD

ParametersJSON Schema

Name	Required	Description
`ages`	No
`device`	No
`gender`	No
`endDate`	Yes
`keyword`	Yes	검색 키워드 (예: 정장)
`category`	Yes	카테고리 ID (예: 50000000)
`timeUnit`	Yes
`startDate`	Yes

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

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

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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

Parameters1/5

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

Tool has no description.

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

Purpose1/5

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

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

get-keyword-trendsD

ParametersJSON Schema

Name	Required	Description
`ages`	No
`device`	No
`gender`	No
`endDate`	Yes
`category`	Yes
`keywords`	Yes	최대 5개까지 설정 가능
`timeUnit`	Yes
`startDate`	Yes

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

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

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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

Parameters1/5

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

Tool has no description.

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

Purpose1/5

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

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

search-blogD

ParametersJSON Schema

Name	Required	Description	Default
`sort`	No	정렬 방법: sim(정확도순), date(날짜순)	sim
`query`	Yes
`start`	No
`display`	No

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

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

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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

Parameters1/5

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

Tool has no description.

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

Purpose1/5

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

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

search-encyclopediaD

ParametersJSON Schema

Name	Required	Description	Default
`query`	Yes
`start`	No
`display`	No

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

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

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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

Parameters1/5

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

Tool has no description.

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

Purpose1/5

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

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

search-kinD

ParametersJSON Schema

Name	Required	Description	Default
`sort`	No	정렬 방법: sim(정확도순), date(날짜순), point(평점순)	sim
`query`	Yes
`start`	No
`display`	No

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

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

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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

Parameters1/5

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

Tool has no description.

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

Purpose1/5

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

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

search-shoppingD

ParametersJSON Schema

Name	Required	Description	Default
`sort`	No	정렬 방법: sim(정확도순), date(날짜순), asc(가격 오름차순), dsc(가격 내림차순)	sim
`query`	Yes
`start`	No
`filter`	No	필터: naverpay(네이버페이 연동 상품만)
`display`	No
`exclude`	No	제외할 상품 유형: used(중고), rental(렌탈), cbshop(해외직구) 예: 'used:cbshop'

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

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

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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

Parameters1/5

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

Tool has no description.

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

Purpose1/5

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

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

12 tool updatesv2.0.0Aug 9, 2026
- First observedget-category-by-age
- First observedget-category-by-device
- First observedget-category-by-gender
- First observedget-category-trends
- First observedget-keyword-by-age
- First observedget-keyword-by-device
- First observedget-keyword-by-gender
- First observedget-keyword-trends
- First observedsearch-blog
- First observedsearch-encyclopedia
- First observedsearch-kin
- First observedsearch-shopping

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

C2.1/5.0

Disambiguation5/5

Each tool has a unique, clearly identifiable purpose: search tools target different Naver services (blog, kin, shopping, encyclopedia), while trend tools are differentiated by resource (keyword vs category) and dimension (age, device, gender). No two tools appear to overlap in function.

Naming Consistency4/5

Naming follows a predictable verb-noun-modifier pattern (search-<service> and get-<resource>-by-<dimension>/trends). However, there is a minor inconsistency between using 'search' for services and 'get' for trends, and the suffix 'trends' is not a dimension like 'by-age'. Overall still readable and systematic.

Tool Count5/5

With 12 tools, the server is well-scoped, covering a typical Naver API surface without being bloated. Each tool earns its place, and the count is within the ideal range for a focused MCP server.

Completeness4/5

The tool set covers primary Naver search services and trend analytics across multiple dimensions. Minor gaps include missing search services (e.g., web, news, image) and no explicit overall trend endpoint separate from the by-dimension variants, but the core domain is well represented.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

mcp A
ai.llmse
Public MCP server for the LLM Search Engine
Search RAG Systems Developer Tools
102
mcp-serpOAuth
io.github.AceDataCloud
MCP server for Google search results via SERP API
Search Browser Automation Web Scraping
21
Product Management Mcp D
io.github.varvararatta
MCP server for Product Management
Product Management Project Management
2
Airweave SearchOAuth
io.github.airweave-ai
MCP server for searching Airweave collections with natural language queries.
Search Art & Culture Open Data
25,729

Related MCP Servers

Naver MCP Server
Search Web Scraping
pfldy2850
A
license
Not graded
quality
C
maintenance
An MCP server that provides access to Naver OpenAPI services, enabling users to search blogs, news, books, images, and other content through standardized Model Context Protocol interfaces.
Updated a year ago (2025-04-02 17:10 UTC)
114
MIT
Naver Search MCP Server
Search Web Scraping Developer Tools
isnow890
A
license
B
quality
B
maintenance
An MCP server that enables searching various content types (news, blogs, shopping, images, etc.) through Naver's search API.
Updated a month ago (2026-07-26 14:28 UTC)
19
209
84
MIT
Aladin Book Search MCP Server
Search Art & Culture
TeeDDub
A
license
A
quality
D
maintenance
MCP server that allows searching and retrieving book information from Aladin's book store API, including book details, bestseller lists, and category-based searches.
Updated a year ago (2025-08-08 03:28 UTC)
9
4
MIT
naver-mcp
Search Marketing
leedw80
F
license
A
quality
C
maintenance
Naver Search API + Datalab API MCP server with 19 tools for Korean web search and trend analysis.
Updated 3 months ago (2026-06-17 12:21 UTC)
19
19
-

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/dataartai/naver-api-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server

네이버 API MCP 서버

기능

쇼핑인사이트 API (DataLab)

카테고리별 트렌드 조회

키워드별 트렌드 조회

검색 API

설치

소스코드에서 설치

설정

사용 방법

직접 실행

Claude Desktop 설정

MCP 도구 사용 가이드

쇼핑인사이트 API 도구

카테고리별 트렌드 조회

키워드별 트렌드 조회

검색 API 도구

블로그 검색 (search-blog)

지식iN 검색 (search-kin)

쇼핑 검색 (search-shopping)

백과사전 검색 (search-encyclopedia)

주요 카테고리 ID

API 제한사항

쇼핑인사이트 API (DataLab)

검색 API

프로젝트 구조

라이선스

참고 자료

Available Tools

Tool Schema Changelog

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

MCP directory API

블로그 검색 (`search-blog`)

지식iN 검색 (`search-kin`)

쇼핑 검색 (`search-shopping`)

백과사전 검색 (`search-encyclopedia`)