This Weekend (이번 주말)

행사 정정 제보

report_event_change

Idempotent

지도에 있는 행사의 일정, 장소, 요금, 예약 방식이 바뀌었거나 행사가 취소됐다고 알립니다. 바뀐 경우에는 운영자가 그대로 반영할 수 있도록 바뀐 값을 인자로 함께 넣습니다. 운영자가 승인한 뒤에만 반영합니다. 사용자가 제보하겠다고 할 때만 부르세요.

Input Schema

Name	Required	Description
`fee`	No	요금이 바뀌었을 때 지금 요금. free는 무료, paid는 유료입니다.
`url`	Yes	바뀐 내용을 확인할 수 있는 http 또는 https 주소.
`city`	No	새 장소의 시·도 id. 장소가 바뀌었을 때 넣습니다.
`type`	Yes	change는 일정, 장소, 요금, 예약 방식이 바뀐 경우이고 cancel은 행사가 취소된 경우입니다. change면 바뀐 값을 startDate, place, fee 같은 인자로 함께 넣습니다.
`place`	No	새 장소 이름. 장소가 바뀌었으면 city, district, address, latitude, longitude와 함께 넣습니다.
`address`	No	새 장소의 도로명 주소. 장소가 바뀌었을 때 넣습니다.
`booking`	No	예약 방식이 바뀌었을 때 지금 방식. none은 예약 없이 입장, optional은 예약을 받지만 필수는 아님, required는 예약 필수입니다.
`editKey`	No	제보를 처음 보냈을 때 받은 editKey. reportId와 함께 넣습니다.
`endDate`	No	새 끝 날짜(YYYY-MM-DD). 날짜가 바뀌었으면 startDate와 함께 넣습니다.
`endTime`	No	새 끝 시간(HH:MM, 24시간제).
`eventId`	Yes	바뀐 행사의 id. search_events나 get_event 결과에 있습니다.
`district`	No	새 장소의 시·군·구 이름. 장소가 바뀌었을 때 넣습니다.
`latitude`	No	새 장소의 위도(WGS84). 장소가 바뀌었을 때 넣습니다.
`reportId`	No	이미 보낸 제보를 고칠 때 넣는 reportId. editKey와 함께 넣으면 새로 접수하지 않고 그 제보를 고칩니다. 검토 전이면 내용이 바로 바뀌고, 반려된 제보는 고친 내용으로 다시 접수합니다.
`longitude`	No	새 장소의 경도(WGS84). 장소가 바뀌었을 때 넣습니다.
`startDate`	No	새 시작 날짜(YYYY-MM-DD). 날짜가 바뀌었으면 endDate와 함께 넣습니다.
`startTime`	No	새 시작 시간(HH:MM, 24시간제).
`description`	Yes	무엇이 어떻게 바뀌었는지 10자 이상. 예: 10월 12일 공연이 10월 19일로 미뤄졌습니다.

Output Schema

Name	Required	Description
`event`	Yes	관련된 공개 행사. submit_event에서는 already_listed일 때만 들어 있습니다.
`editKey`	Yes	제보를 고치거나 검토 결과를 볼 때 쓰는 키. 새로 접수할 때 한 번만 알려 주니 reportId와 함께 사용자에게 전하거나 보관해 두세요. duplicate와 already_listed면 null입니다.
`message`	Yes
`outcome`	Yes	received는 새로 접수함, updated는 검토 전인 제보를 고침, resubmitted는 반려된 제보를 고쳐 다시 접수함, duplicate는 같은 제보가 이미 있음, already_listed는 지도에 이미 있는 행사라 접수하지 않음입니다.
`reportId`	Yes	접수 번호. already_listed면 null입니다.
`revisionOf`	Yes	반려된 제보를 고쳐 다시 접수했다면 반려된 이전 접수 번호입니다. 아니면 null입니다.
`reviewStatus`	Yes	pending은 검토 전, approved는 반영됨, rejected는 반영하지 않음입니다. already_listed면 null입니다.

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 29, 2026

TDQS

A4.1/5.0

Behavior4/5

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

The annotations already declare that this is a non-read-only, idempotent, non-destructive tool. The description adds important process context: changed values must be supplied as arguments, and the change is applied only after operator approval.

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

Conciseness5/5

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

The description is four sentences, front-loads the purpose, then covers changed-value inclusion, approval, and the call trigger. It is dense and free of repetition.

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?

Given the full schema, output schema, and annotations, the description supplies the key missing context: operator approval is required and the tool should be called only when the user intends to report. No essential invocation context is missing.

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 the schema already documents all 18 parameters in detail. The description reinforces that only changed values should be included, but adds little parameter-specific meaning beyond what the schema provides.

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

Purpose4/5

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

The description states a specific action and resource: reporting that a mapped event's schedule, place, fee, or booking changed, or that the event was cancelled. It clearly separates the change and cancellation cases, but does not explicitly distinguish this tool from siblings such as submit_event or get_report_status.

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?

It gives a clear trigger and a restriction: call only when the user says they will report an event change. It does not name the alternative tools for related tasks, so the routing guidance is strong but incomplete.

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

All This Weekend (이번 주말) tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?