Skip to main content
Glama

This Weekend (이번 주말)

물어서 행사 찾기

ask_events
Read-onlyIdempotent

한 문장으로 물으면(예: 이번 주말 부산 불꽃축제, 来週の土曜日 ソウル 展示, free concerts in Seoul on 2026-11-07) 그 말에서 날짜, 지역, 찾는 낱말을 읽어 행사를 찾습니다. 한국어, 영어, 일본어, 중국어로 물을 수 있습니다. 사이트 채팅과 같은 규칙과 뜻 검색으로 읽고 모델은 부르지 않으며, 어떻게 읽었는지 read에 적습니다. 날짜가 없으면 오늘부터 이번 주말까지 찾고, 그 사이에 없으면 60일 안에서 찾습니다. "다음 주는?"처럼 이어 묻는 질문은 앞 질문을 previous에 넣으면 빠진 주제, 지역, 날짜를 거기서 가져옵니다. 날짜와 지역을 이미 알면 search_events가 더 정확합니다.

Input Schema

NameRequiredDescriptionDefault
limitNo한 번에 받을 최대 개수. 1부터 20까지이고 기본값은 10입니다.
previousNo같은 대화에서 앞서 물은 질문들. 오래된 것부터 3개까지 넣습니다. 이번 질문에 없는 주제, 지역, 날짜는 그 말을 한 가장 최근 질문에서 가져옵니다.
questionYes묻고 싶은 말 한 문장(200자 이하). 날짜는 이번 주말, 11월 3일, 2026-11-07처럼 씁니다.

Output Schema

NameRequiredDescriptionDefault
noteYes넓혀 찾았거나 답하지 못한 까닭을 한 문장으로 적습니다. 없으면 null입니다.
readYes질문을 어떻게 읽었는지입니다.
limitYes
rangeYes찾은 날짜 범위(한국 시간). 읽은 날짜가 없으면 null입니다.
totalYes질문에 맞는 행사 수. 가까운 순으로 고른 후보에서 세므로 최대 40입니다.
eventsYes
coverageYes모아 둔 자료의 날짜 범위와 마지막 수집 시각. stale이 true면 저장소 대신 예비 사본에서 읽은 자료입니다.
questionYes
returnedYes
elsewhereYes물은 지역에는 맞는 행사가 없고 다른 곳에는 있을 때만 붙습니다. places는 가까운 시·도부터 그곳 행사 수(count)를, total은 전국 행사 수를 적습니다. 아니면 null입니다.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.6/5.0
Behavior4/5

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

Annotations already cover the safe-read profile, and the description adds real context beyond them: no model is called, matching uses the same rules and stemming as site chat, and the interpretation is reported back in a read field. It also discloses the date-fallback ladder, though it does not describe result shape or limit behavior.

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 the core behavior and the sibling routing comes last, which is the right order. It is dense and slightly repetitive with three example sentences plus repeated language notes, but each sentence carries information an agent needs.

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?

A conversational, rule-based lookup tool with an output schema (including the read field the description references), full parameter documentation, and an explicit fallback policy. Everything needed to invoke it correctly is present.

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%, so baseline is 3, but the description adds genuine meaning for previous — that missing topic, region, and date are inherited from the most recent prior question — beyond the schema's own wording. It also clarifies what the single question string may contain across languages.

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+resource: reads date, region, and keywords out of one sentence and finds events with it. It explicitly contrasts with search_events for the case where date and region are already known, so an agent can tell it apart from its siblings.

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?

Gives concrete when-to-use examples in four languages, says what happens when no date is present (today through weekend, then widening to 60 days), how to chain follow-up questions via previous, and names search_events as the alternative when date/region are known. Nothing is left to inference.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources