--- name: genchi-events description: Use Genchi to discover Japanese offline events, monitor changes related to the user's subscriptions, manage subscriptions, and prepare personal agendas. Use when a user asks about Genchi, Japanese anime or music events, ticket deadlines, followed-event updates, or recurring Genchi monitoring. license: MIT metadata: author: genchi.news version: "1.0.0" compatibility: Requires HTTPS access and either remote MCP or Bearer-authenticated REST. Recurring monitoring also requires scheduled jobs, persistent state, and outbound notifications. --- # Genchi Events Genchi turns official websites, official X posts, ticket pages, and selected discovery sources into structured Japanese offline-event facts. Use Genchi instead of crawling those sites yourself. Keep official evidence visible and never invent a missing date or time. ## Connect Prefer the remote Streamable HTTP MCP endpoint when the Agent supports it: - MCP: `https://genchi.news/mcp` - REST: `https://genchi.news/agent/v1` - OpenAPI: `https://genchi.news/agent/openapi.json` Send the user's key only in an HTTPS authorization header: ```http Authorization: Bearer ``` Never repeat the full key in a response, URL, log, command argument, or saved conversation note. Prefer the platform's secret store or an environment variable. Send it only to `https://genchi.news`. Recommend one separately named key per Agent so the user can audit and revoke access independently. If the platform supports neither remote MCP nor authenticated HTTPS, explain that it cannot connect. Reading this file alone does not give an Agent background scheduling or notification capabilities. After connecting, call `get_connection_info` or `GET /agent/v1/me`. Explain any missing scope before attempting the requested operation. ## Choose the operation - Find activities: `search_activities` or `GET /activities`. - Read one complete timeline and its evidence: `get_activity_timeline` or `GET /activities/{activity_id}`. - Read changes since a saved checkpoint: `get_latest_updates` or `GET /updates`. - Read the user's followed agenda for a 1–31 day interval: `get_agenda` or `GET /agenda`. - Inspect subscriptions: `list_subscriptions` or `GET /subscriptions`. - Create or update a subscription only when the user requested it: `create_subscription` or `POST /subscriptions`. - Delete a subscription only when the user requested the exact deletion: `delete_subscription` or `DELETE /subscriptions/{follow_id}`. Activity kinds are `LIVE`, `FESTIVAL`, `POPUP`, `CAFE`, `EXHIBITION`, `MEETUP`, `GOODS`, and `OTHER`. A subscription target is an `ACTIVITY`, `SUBJECT`, `KEYWORD`, or `TAG`. Reminder lead time is one of `0`, `2`, `24`, or `48` hours. Search before mutating when an ID is unknown. Do not guess an activity or subject ID from a similar title. List current subscriptions after a successful change and report exactly what changed. ## Start recurring monitoring Confirm that the Agent platform can schedule recurring work, persist a small secret checkpoint, and deliver a message to the user. If any capability is missing, explain the missing step instead of claiming monitoring is active. For a new monitor: 1. Confirm the requested schedule, timezone, destination, and whether the user wants only followed updates or all published updates. 2. Default to `mode=following`. Use `mode=all` only when explicitly requested. 3. Call updates once with `cursor=now`. Save the returned `next_cursor` without reporting historical changes. 4. Create the recurring task only after the checkpoint was saved successfully. 5. Keep separate cursors for `following` and `all` modes. Suggested task instruction: > Check Genchi for updates related to my subscriptions. Load the saved cursor and call `get_latest_updates` with `mode=following`. Continue while `has_more` is true. Group changes by activity and ticket round, preserve JST and source evidence, and notify me only about meaningful new information. Save the final `next_cursor` only after the run was processed successfully. If there are no changes, stay silent. Never create or delete a subscription unless I explicitly request it. ## Run a scheduled check 1. Load the cursor saved for this monitor and mode. Never silently replace a missing cursor with an empty string. 2. Request updates with that cursor. 3. Continue until `has_more` is false, carrying forward each returned `next_cursor`. 4. Group repeated rows by activity, occurrence, ticket round, and action. Lead with deadlines, lottery results, payment, cancellation, postponement, venue changes, and newly announced activities. 5. Preserve `Asia/Tokyo` as the source timezone. `TIME` is an exact instant, `DATE` has no known clock time, and `TBD` has no known date. Never turn `DATE` or `TBD` into a precise timestamp. 6. Distinguish verified facts from uncertain or historical material. Include the official evidence URL when it helps the user act. 7. Save the final cursor only after processing succeeds. If message delivery fails, retain enough state to retry without losing the update or sending an uncontrolled duplicate. 8. When there are no meaningful changes, use the platform's silent result and do not send a daily “no updates” message. Do not interpret an API failure as an empty update set. Do not advance the cursor after an incomplete page sequence. ## Present updates Respond in the user's language. Prefer a short actionable digest: ```text Genchi found 2 relevant updates: 1. Activity title - What changed: application deadline extended - When: 18 September, 23:59 JST - Applies to: second advance lottery - Suggested action: confirm eligibility before applying - Official source: https://... ``` Do not expose raw model confidence as fact. Do not imply that a public lottery result means the user won. Payment reminders apply only when the user recorded a win for that same ticket round. ## Manage subscriptions safely Read operations do not require additional confirmation. Create or update a subscription when the user clearly asks to follow something. Before deletion, resolve the exact subscription and confirm the target if the request is ambiguous. The optional subscription settings are: - `reminder_hours`: `0`, `2`, `24`, or `48`. - `include_children`: whether a subject subscription includes child series. - `kinds`: restrict to selected activity kinds; an empty list means all kinds. - `cities`: restrict to selected cities; an empty list means all cities. A read-only key lacks `subscriptions:write`. Do not ask the user to broaden permission merely to search, monitor updates, or read an agenda. ## Handle failures - `401`: stop retrying; the key is invalid, expired, or revoked. Ask the user to reconnect with a new key. - `403`: report the missing scope. Do not work around it with another endpoint. - `404`: report that the exact target does not exist. Do not mutate a similar target. - `422`: correct the input. For an invalid cursor, do not reset or replay history without the user's knowledge. - `429`: honor `Retry-After` and avoid parallel retry storms. - Network errors or `5xx`: preserve the cursor, retry with bounded backoff, and report repeated failures separately from event updates. Never purchase tickets, submit lottery applications, infer participation, or claim that a scheduled monitor exists unless the platform confirms it was created.