Skip to main content
Glama
neneungyul2

Naver Search MCP Server

by neneungyul2

datalab_shopping_by_age

Analyze Naver shopping trends by age group (10s–60s+) to compare generational buying preferences; find the category code first, then query a date range and time unit.

Instructions

👶👦👨👴 Analyze shopping trends by age groups (10s, 20s, 30s, 40s, 50s, 60s+). Use find_category first. BUSINESS CASES: Age-targeted products, generational preferences, lifecycle marketing. EXAMPLE: '개발 도구는 어느 연령대가 많이 구매하나?' (연령별 쇼핑 트렌드 - 먼저 find_category 도구로 카테고리 코드를 찾으세요)

Input Schema

NameRequiredDescriptionDefault
agesYesAge groups
endDateYesEnd date (yyyy-mm-dd or 'today' for KST today)
categoryYesCategory code
timeUnitYesTime unit
startDateYesStart date (yyyy-mm-dd or 'today' for KST today)

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A3.8/5.0
Behavior3/5

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

No annotations are provided, so the description carries the burden; it discloses the find_category dependency and the aggregate/analytical nature of the call, but says nothing about data source, date-range limits, rate limits, or whether multiple age groups can be combined in one request.

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-loaded with purpose and bucket list, then prerequisite, then use cases and an example. The decorative emoji row and the bilingual restatement of the prerequisite are slightly redundant, but no sentence is wasted.

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

Completeness3/5

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

For a five-required-parameter analytical tool with no annotations and no output schema, the description covers purpose and the category prerequisite but leaves the agent guessing about date-range constraints, whether 'ages' is a multi-select filter, and what the result shape or granularity looks like.

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?

Schema description coverage is 100% and enum values are declared for ages and timeUnit, so the baseline is 3. The only added value is the 'find_category first' hint telling the agent where the category code comes from, which is genuinely useful but covers just one of five parameters.

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 ('Analyze shopping trends') and a specific dimension ('by age groups') with the exact buckets enumerated, which cleanly separates it from siblings like datalab_shopping_by_gender and datalab_shopping_by_device.

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?

Explicitly states the prerequisite sequence ('Use find_category first', repeated in Korean in the example) and lists concrete business cases for when this is the right tool. It doesn't rule out the nearest sibling (datalab_shopping_keyword_by_age), so it stops short of full routing guidance.

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