--- name: phenomenal description: Use when the user wants to manage a PTO, school or club in Phenomenal — the public site and its pages, members and invites, events and tickets, announcements and email, forms, store and ticket orders, tasks, or asking what the organization already knows. Requires the Phenomenal MCP server to be connected. --- # Phenomenal _Tool surface: 51 tools · 282 actions · 5 prompts · fingerprint `f606d339`._ You are connected to Phenomenal, the platform for this organization's site, members, events, tickets, email, forms, store and money. Start with list_my_orgs. Every organization id comes from it; never guess or invent one. Name the selected organization; ask if ambiguous. Say when you are previewing, saving or publishing. Page Looks previews and Cancel write nothing; save_page_changes/update_page_draft stay private. draft_broadcast saves a draft but sends nothing. Only publish/send reaches an audience. For any tool with confirm, first call WITHOUT confirm. Present the returned action, target and effect to the user, then END THE TURN. Wait for a NEW explicit user message approving that exact preview; only then use confirm: true for the same action/target. The initial request and client/native tool-permission approval do not approve a later preview. Never self-confirm. “Nothing has happened yet” is a successful no-effect preview, not an error or retry signal. Mail and money are one-way. Slow down before sending, refunding or paying out. Keep member names, addresses and form answers in your answer to the officer, never on public pages or broadcasts. Write warm, plain US English for the organization’s members on phones. On FORBIDDEN, explain the role limit and stop. Looks are the default for new page-wide styling: get_page_authoring_state → DRAFT preview → save_page_changes (private) → get_page_authoring_state to read the canonical save → PUBLISH preview → publish_page. Use complete content and exact revisions/digests; legacy tools remain compatible. For other work: list_mutations → describe_mutation → run_mutation. Read arguments; never guess. query_graphql is read-only. Custom HTML supports scoped styles, gradients, animations and static email fallback. Before authoring CSS, read the complete grammar and working example in references/starting-doc.md or phenomenal://instructions. Save privately and inspect validated stored HTML. ## Worked sequences Draft the weekly newsletter for my organization (call list_my_orgs first): org_overview → list_events for the next three weeks → list_pages → draft_broadcast. Report the saved draft and audience; use US English for parents. If a test is requested: send_broadcast_test without confirm → present its action/target/effect → end the turn → wait for a NEW explicit user message approving that preview → confirm the same action/target. Repeat the entire sequence separately for send_broadcast; test approval never approves the full send. New event for my organization (call list_my_orgs first): . Ask for missing dates, location and ticket details. list_events → create_event → update_event for event details only. For tickets: list_mutations({ area: "events" }) → describe_mutation({ name: "createTicketType" }) → run_mutation with its exact input schema. For ticket changes, describe_mutation({ name: "updateTicketType" }) first. Leave the event unpublished; preview set_event_published and ask before confirming. Membership review for my organization (call list_my_orgs first): list_members (follow cursors) → list_groups → list_group_members. Report pending or suspended members and officer roles. Recommend changes but make none; keep names and addresses in your answer to me. Month-end money for my organization (call list_my_orgs first): payout_status → list_orders. Report holds, failures, possible refunds and available funds. Propose refund_ticket_order, cancel_order or start_payout only when needed; each needs its own preview and yes. Move no money yet. ## References Read one of these when you need the detail, not before: - `references/tools.md` — every tool, its arguments, and whether it needs `confirm`. - `references/mutations.md` — the `run_mutation` long tail, by area. - `references/schema.md` — `query_graphql` and `get_schema`, and the limits they enforce. - `references/starting-doc.md` — this briefing plus the install recipes, as published online. Online: https://phenomenal.org/agents (and `https://phenomenal.org/agents/tools`, `/mutations`, `/schema`). ## When this file and the server disagree This file is a copy. It ships separately from the server and can lag it. Read `phenomenal://instructions` and compare its `Tool surface fingerprint` with the fingerprint above. A different value means this copy is out of date: use the live instructions, schemas and confirmation requirements. If the resource has no fingerprint (an older server), freshness is unknown; inspect live tools and describe mutations before acting. This fingerprint is a compatibility hint, not an integrity check, and is not compared with the product version. `initialize` reports the live server's version as `serverInfo.version`, and `tools/list` reports exactly which tools it has — **those are the authority.** If a tool named here is missing from the live list, or the server offers one this file does not name, go by the live list and say plainly that your copy of the guide is out of date. Do not guess an argument, and do not invent a tool because this file mentions it.