MCP가 보유한 Visit Seoul 데이터의 최신성·동기화 상태(마지막 동기화 시각, 건수, 오류)를 확인한다. '데이터 언제 갱신됐어?' 같은 질의에 사용.
| Name | Required | Description | Default |
|---|---|---|---|
| source | No | 원천 구분(예약 파라미터) | |
| category | No | 콘텐츠 대분류 (필수): festival(축제·공연·행사·전시) / attraction(문화·역사·자연·체험 명소) / restaurant(한식·카페·외국음식 등) / shopping(쇼핑·면세점·시장) / accommodation(호텔·숙박) |
Changes observed during successful MCP inspections. Dates show when Glama detected each change.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, and the description aligns by stating it checks status (no mutation). The description adds value by specifying what aspects of sync status are returned (time, count, errors), providing behavioral context beyond annotations.
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 concise with two sentences: one stating the tool's purpose and one providing a concrete usage example. It is front-loaded with the essential information and contains no extraneous text.
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?
The description covers the tool's purpose and behavioral details but lacks information about the output format beyond mentioning 'time, count, errors'. Without an output schema, more explicit description of return structure would be beneficial. It is adequate but not fully complete.
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 description coverage is 100%—both parameters (source, category) are already described with details in the schema. The description adds only minor context: 'source' is a reservation parameter. This does not significantly enhance understanding beyond the schema, so a baseline score of 3 is appropriate.
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 clearly states the tool checks the freshness and sync status of Visit Seoul data, including last sync time, counts, and errors. It provides a specific use case query ('When was data updated?'). This distinguishes it from siblings like get_content_detail and search_contents, which serve different purposes.
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?
The description explains the tool is used to check data sync status and gives an example query. However, it does not explicitly state when not to use it or compare with alternative tools (e.g., when to use search_contents instead). The usage is implied but lacks exclusion guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Each tool serves a unique, clearly distinct purpose: search_contents for searching, get_content_detail for retrieving detailed info by ID, and get_sync_status for checking data freshness. No overlap in functionality.
Tool names follow a consistent verb_noun pattern with snake_case: search_contents, get_content_detail, get_sync_status. The pattern is predictable and intuitive.
With 3 tools, the set is slightly small but appropriate for a focused tourism data query service. Each tool is essential and covers core operations without unnecessary bloat.
The tools cover the primary use cases: searching by various filters, getting detailed content, and checking data sync status. Minor gaps exist (e.g., no direct listing of categories or recommendations), but the core information retrieval workflow is complete.