The FUNNY.CEO MCP server

Tools (49)

Grouped by who can use them. A tool for venues refuses a fan's token, and says why.

ANYONE SIGNED IN

• profile_whoamiWho am I

  The caller's own identity and roles. Worth calling first from an agent or an MCP client: the roles decide which other capabilities will answer.

  No inputs.

• data_countMineCount something in your own history

  Answers a counting question about the caller's OWN records over a date range — tickets sold, tickets bought, shows put on, shows performed, spots applied for, tips received, FU spent. Pick `metric` from the fixed list; there is no way to ask about anybody else, and no way to pass a query. Dates are YYYY-MM-DD and inclusive at both ends. `place` is optional and is the place in the person's own words ("Brooklyn", "Austin") — NEVER coordinates; it is resolved server-side, REFUSES when the place cannot be resolved rather than answering zero, and reports what it actually counted when the resolved place is broader than the one asked for. Metrics with no location attached refuse a place rather than ignoring it. Some metrics cannot promise a complete total and the answer says which and why. Read-only.

  • metric · one of tickets.sold, tickets.bought, shows.hosted, shows.performed, applications.sent, tips.received, fu.spent · required
  • since · string · required
  • until · string · required
  • place · string
• nav_findFeatureWhere do I do that?

  Finds the place in the product where the CALLER can do something, and always returns the full list of destinations their account can reach. Pass `query` in the person's own words ("settle a show", "check people in") to get it ranked, or omit it entirely to answer "what can you do" from the real list rather than from a written blurb. Every result is scoped to the roles the caller actually holds. A weak match is flagged `bestEffort` and MUST be relayed as a guess, not as an answer. A surface that exists but belongs to a persona the caller is not on is named WITHOUT a link, because the link would not open for them — that is different from the thing not existing, and both are different from the matcher simply not recognising the words. Read-only; it navigates nothing by itself.

  • query · string
• notifications_myPreferencesWhat email will actually reach me

  The caller's EFFECTIVE notification preferences — what the product will actually send, not what any one settings screen shows. Three separate screens write three separate stores and the mailer honours an opt-out in any of them, so a category can read as ON where a person set it and still be suppressed by a master switch elsewhere. Every row carries `enabled` and, when something switched it off, WHERE: report that location, because it is the only way the person can undo it. `storesFound` says how many of the three hold any document at all — zero means nobody has set anything, which is opted IN, not opted out.

  No inputs.

• account_erasure_previewSee what deleting this account would do

  Explain what would happen if the signed-in person deleted their Funny.CEO account, and whether anything currently stands in the way. Returns three lists derived from the platform's retention registry — what is deleted outright, what survives with their name taken out of it (a venue's ticket sales, payouts the venue is audited on, a safety report somebody else filed), and what is untouched — plus any blockers. A blocker is not a delay: it is a case where deleting on demand would take something from a third party or from the person themselves, and each one names what clears it. CHANGES NOTHING. It cannot start a deletion, and there is no capability that can.

  No inputs.

FANS

• show_access_getWhat a show says about access

  The access features a show's venue lists — step-free access, wheelchair spaces, an accessible restroom, assistive listening, captions, an ASL interpreter, a relaxed performance — and any note in the venue's own words. `stated: false` means the venue has said NOTHING, which is not the same as no access: say that it is not stated and suggest contacting the venue, never that the show is inaccessible.

  • showId · string · required — The show's id.
• tickets_getMineThe tickets I hold

  Every ticket held by the caller, upcoming and past, with the show, venue, date, seat type and status. Money is reported carefully, and the two figures are different questions. The per-ticket figure is the show's FACE VALUE, which is not what the card was charged — the platform fee is baked into the checkout line item on top of it. What was charged is reported separately as an ORDER total from Stripe, all in, covering the face value, the platform fee, ticket protection and any add-ons; it is counted once per order rather than per ticket, and an order only partly held by the caller is left out rather than divided between seats. Orders placed before the platform began recording the charge report as unrecorded rather than as zero, and the count of those is returned so a total can state its own completeness. Comped tickets are counted separately because they are not spend. Tickets bought through guest checkout are collected into an account when its email is verified and matches the address the order was placed with, at purchase time or at the next sign-in. A guest ticket bought with a different address, or with one the account has not verified, is still not in this list, so it can be incomplete and says when it may be — tickets.claimGuest is what collects them.

  No inputs.

• fu_getMyLedgerMy FU balance, and where it went

  The caller's current FU balance and their recorded FU history: each credit or spend with its type, amount, and when it happened. For pack purchases it also reports the dollars actually charged, taken from the payment record rather than converted at a rate. The BALANCE is authoritative — it is read from the ledger, not added up from this list. The HISTORY may be incomplete: one live spending path writes its record to a different collection that nothing reads, so a spend can reduce the balance without appearing here. That is why the two can disagree, and why the balance is the number to trust.

  No inputs.

• shows_findNearbyComedy on near a place

  Upcoming comedy shows near a named place — a city or metro, as the person said it ("Brooklyn", "Austin", "nyc"). NEVER pass coordinates; pass the place name and the server resolves it. If the place cannot be resolved this REFUSES rather than returning results from elsewhere, so an empty or refused answer means what it says. Covers BOTH shows sold on this platform and external Ticketmaster listings, and every row says which: `source: "funnyceo"` is bought here and its `url` is a path on this site, `source: "ticketmaster"` opens on Ticketmaster. Set `tonightOnly` for what is on TONIGHT — that means the night the caller is in, which runs past midnight, not the calendar date. Set `format` to narrow to open mics or showcases; every row also REPORTS its `format`, which is null when the product does not record one — that is a real answer, not "general comedy", and must not be reported as a format. Results are capped and ordered nearest-first. An act playing the same room more than once is ONE row: `dates` then lists every performance of that run, so four nights do not read as four different shows. Set `access` to only the shows whose venue lists EVERY access feature given (step-free, wheelchair spaces, captions...); every row also REPORTS its `access`, and an EMPTY list there means the venue has not said — never that the show is inaccessible, so do not tell anyone it is.

  • city · string · required
  • withinDays · integer
  • tonightOnly · boolean
  • format · one of open-mic, showcase
  • access · array
• waitlist_mineWhere I stand on a waitlist

  The caller's own place on a sold-out show's waitlist: their position, how many PEOPLE (not parties) are ahead of them, and the party size the place is held for. Returns `place: null` when they are not on it — which is an answer, not an error. Also reports whether the waitlist is open to join and why not when it is closed. Read-only.

  • showId · string · required — The show whose waitlist to look at.

COMEDIANS

• availability_getRead my availability

  The caller's own availability calendar: the nights they generally work, dates they have blacked out, dates they are free regardless, and their note to venues. An empty record means they have never set one, which means available — not unavailable.

  • uid · string · required — The comedian's user id. Must be the caller, or the caller must be an admin.
• epk_primaryDomain_getWhich address my page ranks under

  Which of the two brand domains the caller's public page tells search engines is the real one. funny.ceo and epk.lol serve the SAME page — this is the address a comedian promotes, so their own sharing builds one ranking instead of splitting it across two identical URLs. Both addresses keep working whatever this says; it is a search signal, not a redirect. `chosen` is false when the comedian has never picked and the default applies.

  • uid · string · required — The comedian's user id. Must be the caller, or the caller must be an admin.
• epk_viewSources_getWhere my page views come from

  How the caller's public page views break down by where the visitor came from: search engines, social media, email, tagged links (a utm_source on a link), elsewhere on FUNNY.CEO, other websites, or direct. Counts only — no referrer URL or visitor is stored. Sources have been recorded since 7 October 2026, so `sourcedViews` can be lower than `totalViews`; the difference is views counted before then.

  • uid · string · required — The comedian's user id. Must be the caller, or the caller must be an admin.
• gigs_listMineList my upcoming gigs

  Upcoming shows the caller is booked on, each with their own slot: set length, role, the pay the venue agreed, and whether they have accepted. Past shows are not included.

  • limit · integer — Maximum shows to return. Default 25, maximum 100.
• gigs_findOpenFind gigs open for applications

  Upcoming shows a comedian can apply to right now, newest date first: the slots still open on each, what the venue is offering, and when applications close. Filterable by city and by a date window, so 'a Wednesday between the New York and Boston dates' is one call. A show appears here only if applying to it would be accepted — the same rule the apply action uses — so nothing listed is a gig the button will refuse. Reading changes nothing.

  • city · string — Match the venue's city, case-insensitively. Omit for anywhere.
  • from · string — Earliest show date, YYYY-MM-DD. Defaults to today.
  • to · string — Latest show date, YYYY-MM-DD. Omit for no end.
  • limit · integer — Maximum shows to return. Default 25, maximum 100.
• applications_listMineList my applications

  The caller's applications to shows and where each one stands. `withdrawn` and `cancelled` are different states: withdrawing retracts an application nobody has acted on, cancelling breaks a booking a venue is counting on.

  • status · one of pending, accepted, declined, withdrawn, cancelled — Only applications in this state. Omit for all.
  • limit · integer — Maximum applications to return. Default 50, maximum 200.
• earnings_getMineWhat the platform has paid me

  What Funny.CEO has actually paid the caller: tips, and gig payouts THE PLATFORM TRANSFERRED. Counts only money that moved through us — a payout the venue recorded as paid in cash is deliberately excluded, because we did not handle it and cannot confirm it arrived. Also reports what is settled and still owed, and how many bookings have no amount recorded at all, so a total of $0 can never be mistaken for "you earned nothing". Cash paid at the door outside the platform is not here and says so.

  No inputs.

• epk_customDomain_getThe domain reserved for my page

  The comedian's own domain, if they have reserved one. `domain` is null when none is set. `servesThePageYet` is FALSE for everybody today and says so plainly: reserving a domain makes it exclusively theirs and stops anyone else claiming it, but nothing in the product routes by hostname yet and the certificate is issued by hand, so the address that loads the page is still the funny.ceo one in `canonicalPath`. Do not tell a comedian their domain is live.

  • uid · string · required — The comedian's user id. Must be the caller, or the caller must be an admin.
• agency_myCommissionWhat my agency takes, in dollars

  The commission rate actually in force between the caller and the agency that represents them, what it has come to on what they have been paid, and whether the agency has asked for more. Reports DOLLARS as well as the percentage, because a rate on its own asks the comedian to do the arithmetic. A rate above the acknowledgement threshold that the comedian has not agreed to is NOT in force and is reported as pending rather than as the rate — including one stored before that gate existed. Funny.CEO does not collect this: settlement pays the comedian in full and the agency collects from them, so this is a record of what is owed between them and not a deduction. Answers only about the caller. Reading changes nothing.

  No inputs.

• gigs_chainMineWhere the money for my gigs got to

  Every booking of the caller's — past and upcoming, unlike gigs.listMine which is upcoming-only — and where each one's payment stands: booked, performed, settled, or paid. Each carries whether the chain STOPPED there (a failed transfer, a payout waiting on a connected account) or has simply not reached the next link yet (a show that has not happened); those look the same on a progress bar and are completely different to the person waiting. Amounts are dollars or NULL, never a stand-in zero, and the summary counts the unknowns separately so a $0 total cannot read as 'you earned nothing'. Only money the platform actually transferred is counted as paid; a payout the venue recorded as cash is shown, and excluded from that total, and says so.

  No inputs.

VENUES

• availability_checkForPitchCheck a comedian's availability for a date

  What a venue should be told before pitching a comedian for a date: the verdict, how much weight it deserves (a stale answer reads differently from a fresh one), and a warning string when there is something worth saying. Any signed-in user may ask, because anyone who can see the profile can see the calendar. It never refuses a booking — it informs one.

  • comedianUid · string · required — The comedian being considered.
  • date · string · required — The date of the show being pitched.
• venue_listShowsList a venue's upcoming shows

  Upcoming shows at a venue the caller is on the team of, each with how much of its lineup is filled and accepted.

  • venueId · string · required — The venue's id. The caller must own it, be assigned staff on it, or be an admin.
  • limit · integer — Maximum shows to return. Default 25, maximum 100.
• show_getSalesTicket sales for one show

  Ticket sales for a show the caller manages: tickets sold, refunded and checked in, gross takings, and the platform fee that applies. Money figures come from the same fee model the checkout uses.

  • showId · string · required — The show's id. The caller must own the show, be on its venue's team, or be an admin.
• show_getAnnounceAudienceWho hears when this show goes live

  Who would be told that a show went live, and whether it has been told already. Returns the size of each group — the venue's own team, followers of the room, and followers of each comic on the bill — plus whether the announcement has already gone out and when. Nobody is counted twice: somebody on the team who also follows the room is on the team. Counts are the recipients BEFORE per-person email preferences are applied, so the number reached by email is at most this. Changes nothing.

  • showId · string · required — The show's id. The caller must own the show, be on its venue's team, or be an admin.
• venue_getSalesPaceHow this room usually sells by now

  What this venue's past shows had typically sold when they were the same distance away, so a show still on sale can be compared with the room's own history rather than a guess. Counts tickets by when they were actually BOUGHT, at equal lead time — a walk-up on the night has a lead time of zero and is never counted against a show that is still nine days out. Reports the MEDIAN, because one sold-out benefit night drags a mean far enough to make every ordinary Tuesday look like a failure, and always says how many past shows it used and whether they were the same weekday. Refuses to answer at all below a minimum sample: a median of three shows is an anecdote, and this platform does not have a forecast model to fall back on.

  • venueId · string · required — The venue's id. The caller must own it, be assigned staff on it, or be an admin.
  • forDate · string · required — The date of the show being compared. Its weekday selects the comparison set.
  • leadDays · integer · required — How many days before the show to compare at. 9 means 'what had this room sold nine days out'.
• venue_listMineWhich rooms do I run

  Every venue the caller is on the team of — rooms they OWN and rooms they are assigned staff on, as one list with both flags per room, because somebody can be both. Ordered: owned first, then by name; a room whose document could not be read is still listed, with `name: null`, rather than dropped. Use it to pick a venueId for any venue capability, and to tell a single-room operator apart from a chain. Reports `truncated` when they run more rooms than one page holds. Read-only, and not an authorization answer: every venue capability still runs its own guard.

  No inputs.

• waitlist_listWho is waiting for a seat

  The full waitlist for a show, oldest first, for whoever manages it: name, email, phone, party size, status and when they joined. `waiting` and `notified` hold a place; `notified` means a seat was already offered to them and they still count against the queue, because the same seat must not be offered twice. Also reports the total heads waiting and the queue's cap. Show-manager only; read-only.

  • showId · string · required — The show whose queue to read.
• show_settlementChainWhere every performer's money got to on one show

  The same book → settle → pay chain from the venue's side: every booked comedian on one show and where their payment stands, with the ones that STALLED called out — a failed Stripe transfer, a payout that cannot be sent because the comedian has not connected an account, a show that has happened and has not been settled. Use it to answer 'have I paid everyone for Friday'. Show-manager only; read-only, and it moves no money: settlement is a separate, deliberate action.

  • showId · string · required — The show. The caller must own it, be on its venue's team, or be an admin.
• show_coProducers_listWho else is on this show's mail

  Co-producers invited to one show: their name, address, whether they ACCEPTED, and when. Only an accepted invitation receives anything — an invited one has had a single email and hears nothing until it answers, which is the opt-in. The invitation token is deliberately NOT returned: it accepts, declines and unsubscribes on that person's behalf, and a list is exactly where somebody would put a convenient copy-link button. Show-manager only; read-only.

  • showId · string · required — The show whose co-producers to list.
• group_quotes_listQuotes on a group inquiry

  Every quote sent on one group inquiry, newest first, with its lines, total, committed seats and where it stands. State is COMPUTED against the clock, not read off a stored status — an expired quote reads as expired even though nothing wrote that. The customer's answer link is deliberately not returned: it accepts and declines on their behalf. Venue-commerce only; read-only.

  • venueId · string · required — The venue. Also what authorizes the call.
  • inquiryId · string · required — The group inquiry. Must belong to this venue.

VENUE STAFF

• shifts_getMineThe shifts I have worked

  Every shift the caller has clocked, with the venue, role, clock-in and clock-out, how long it ran, and whether the venue has approved it. Totals are given in MINUTES and split by approval status. This reports HOURS, NOT PAY: no rate, wage or amount is recorded anywhere on the platform, so it cannot tell you what you are owed. Each shift says whether the venue set the hours rather than your own clock — a manager can edit a card, and can also enter a whole shift you never clocked, which is written in already approved. A shift still in progress is listed separately and counted in no total.

  No inputs.

• door_rosterTake a show's guest list offline

  The guest list for one show, narrow enough for a phone to keep: a ticket id, its status and the purchaser's name, and nothing else — no email, no address, no order total, because this lands in local storage on a door phone and stays there. Fetch it while you still have signal. Reports `truncated` when the room is bigger than one cache holds, so a door is told it is working from a partial list rather than treating absent tickets as invalid. Show-manager only; read-only.

  • showId · string · required — The show whose door you are about to work.

AGENCIES

• agency_getCommissionsWhat my roster has earned me

  Commission owed to the caller's agency across its whole roster: per comedian, the number of paid bookings, what the platform has paid them, the agreed commission rate, and what that rate comes to. LIVE AND ALL-TIME, not a bill — the totals move every time a roster comedian is paid, so the same query answers differently on different days. A statement issued for a period is the frozen, collectable version. This moves no money: settlement pays the comedian in full and collection happens between the agency and the comedian.

  No inputs.

PLATFORM ADMINS

• payments_disputes_listChargebacks opened against the platform

  Every card dispute Stripe has reported against a sale on this platform, newest first: the charge, the amount, the bank's stated reason, its status, and the evidence deadline. Also how many are still open and how many of those have a deadline within 72 hours — a dispute with no evidence submitted by its deadline is lost automatically. Read only: it never responds to a dispute, refunds, or reverses a payout. Admin only.

  • limit · integer
• ops_alerts_listWhat is broken right now

  Live health of every scheduled job, as the alert sweep evaluates it: anything never run, overdue, failing or degraded, with the severity and the reason. This is what the platform would email an operator about, read directly — it reports conditions the sweep is currently holding quiet under its renotify window as well, because 'not worth emailing again' is not the same as 'fixed'. Admin only. Reading changes nothing: it never notifies and never advances a renotify window.

  No inputs.

• venues_catalogueHealthDuplicate rooms, and records that are not rooms yet

  Scans the venue catalogue for two things nothing else counts: rooms filed more than once (same Google Place, same Ticketmaster venue, or the same street address under different names) and records too empty to be any use to a reader — no findable address, no contact, nothing written. Returns each duplicate pair with the reason it scored and how confident that reason is, plus a breakdown of what the thin records are missing. Suggests only; merging is a separate, human-confirmed write. Admin only. Reading changes nothing.

  • minConfidence · one of high, medium, low
  • limit · integer
• ops_cronHealthWhat counts as a healthy run, per job

  For every scheduled job: the rule that decides whether one of its runs achieved anything, the metrics that rule reads, and how the job is doing against it — its last outcome, why the last run was judged unproductive if it was, and how many runs in a row have ended that way. Answers 'is this job working' rather than 'did it return 200', and says which jobs have been achieving nothing long enough to page. Admin only. Reading changes nothing.

  No inputs.

• ops_ghostQualityWhat is wrong with the published ghost profiles

  Counts defects on PUBLISHED ghost comedian profiles — the unclaimed pages the Ticketmaster ingest writes under real people's names: a bio we wrote that says they are on tour with no upcoming dates, a page the hourly sync has stopped refreshing, published without a real photo, a URL that cannot be resolved, two pages with the same name, a page with no name. Unpublished ghosts are not counted — nobody can see them. Gives a few examples of each, never the whole list. `capped: true` means the scan hit its limit and the counts are a floor. Admin only.

  • examples · integer
• ops_agentQualityWhere the agent is failing people

  What the last N agent turns reveal about the product, not about any person: capabilities the model asked for that DO NOT EXIST (the most actionable signal there is — the model read the whole tool list and still reached for another name), capabilities offered and refused every time, capabilities offered and never called, turns that ran out of steps, and replies that were not a decision the loop could read. Every finding carries its count and the number of turns it was drawn from. Findings below a minimum number of sightings are withheld rather than reported as noise, and rates are withheld entirely below ten turns. Contains no message text, no reply text and no capability inputs — see `agent-quality.ts`. Admin only.

  • limit · integer
• product_backlog_listThe product backlog, as the Blueprint states it

  The Funny.CEO product backlog, parsed from docs/prd/04-BACKLOG.md — the repository file that IS the plan, not a copy of it. Each row has a stable ID (e.g. FW-005), a status glyph from a fixed vocabulary, the horizon it sits in (NOW, NEXT, LATER, FROZEN), what it is worth, and which of the three surfaces (UI, Agent, MCP) it still owes under the Tri-Surface Law. Status here changes only when a commit moves the row, so this reflects the merged state of the repository and NOT work in progress — an item can be NOW and have nobody on it, or have an open pull request and still read as NEXT. Filter by lane, by ID prefix, or by an owed surface. `problems` lists rows that could not be parsed: it should be empty, and a non-empty list means the board is incomplete rather than that the backlog is.

  • lane · one of NOW, NEXT, LATER, FROZEN, SHIPPED, SETTLED — Only rows in this lane. Omit for all of them.
  • prefix · string — Only rows whose ID starts with this section code, e.g. FW, TRU, MON.
  • owes · one of U, A, M — Only rows that still owe this surface: U = UI, A = agent-callable, M = MCP tool.
  • limit · integer
• product_backlog_getOne backlog row, with anything in flight against it

  A single backlog row by its stable ID (e.g. TRU-016), plus the open pull requests that name that ID in their branch, title or body. `item` comes from docs/prd/04-BACKLOG.md and reflects MERGED state only. `inFlight` comes from GitHub and is a separate claim: `inFlight.state` is either `live` (with `pullRequests`) or `unavailable`, and `unavailable` means the pull-request half is UNKNOWN — read `inFlight.reason` and say so, never report it as 'no work in progress'. An ID with no row is REFUSED with the code `no-such-row`, never an empty answer — a stale ID is a caller working from an old reference, not a row with nothing on it.

  • id · string · required — The stable backlog ID, e.g. FW-005 or TRU-016.
• ops_cogsUsageWhat the expensive things actually cost

  Metered usage behind the two COGS rates that have never been checked against a bill: seconds of live AI session, and LiveKit participant-minutes. Reports the units, what the DECLARED rate implies they cost, and how many samples were actually observed versus assumed at their ceiling because a session went dark. Pass `billedUsd` from a real invoice to get the measured rate — without it this reports usage and explicitly does NOT claim to verify anything, because a rate is dollars divided by units and only the units are known here. Below a minimum sample count, and below a minimum share of observed samples, no rate is stated at all. Admin only; read-only.

  • kind · one of live-session, livekit-room · required
  • billedUsd · number
  • limit · integer
• product_item_statusWho is working on a backlog row

  Live agent claims against backlog rows: who holds each row, when they last checked in, what they say they are doing, and any pull request or `npm run verify` result they have reported. This is NOT the row's status — a claim is a statement about attention and the Blueprint is the statement about the code; use product.backlog.list for the latter. Each claim reports `health`: `active` (checked in recently), `stale` (held, but nobody has checked in for a while) or `expired` (the lease ran out, the row is free — reported rather than hidden, because a row something took and abandoned is worth seeing). Omit `id` for every claim.

  • id · string — One backlog row, e.g. ADM-011. Omit for all live claims.
• ops_platformHealthIs the platform healthy, and what do we not know

  The platform's health signals, each with a state and a line a person can act on. States are ok, degraded, down and UNMEASURED. `unmeasured` means the product does not collect that signal at all and its `detail` says which backlog row covers it — NEVER summarise an unmeasured signal as healthy, and never omit it: the headline carries how many signals are measured out of how many exist, precisely so a green answer over two of four is not read as a green platform. Scheduled jobs come from the same rule that decides whether to page somebody, so this cannot disagree with the alerts. Admin only. Reading changes nothing and does not advance any renotify window.

  No inputs.

• ops_routeHealthIs the live site actually serving its public pages

  Pings every public route of the live deployment from the server and reports each one's HTTP status and latency, plus one live sample per dynamic route family (a real venue, show and comedian page). Answers 'is production serving this right now', which a green build does not — a half-finished deploy, an expired certificate or a rules change break serving without changing the source. Signed-in, state-dependent and deliberately-degraded routes are excluded and listed with the reason a 200 from them would mean nothing, so the pass rate states its own population. A dynamic family with no live document to sample is reported as unsampled rather than counted as passing. Admin only. Pings only; changes nothing.

  No inputs.

• profile_takedowns_listList pages people have asked us to take down

  Read the takedown queue: people who asked Funny.CEO to stop publishing a profile page we generated about them from public listing data, without their involvement. Every row in the `requested` state is a page that is ALREADY OFFLINE — the page comes down when the request arrives, before any review — so this queue is people waiting to hear whether it stays down, not pages waiting to come down. `open` counts the undecided ones. Pass `status` to look at what was already decided: `upheld` means the page and its content are gone for good, `declined` means it was put back. A row carries no name once it has been upheld, because upholding strips the profile to a marker.

  • status · value — Restrict to one state. Omit for the whole queue, undecided first.
• safety_reports_listList safety reports waiting for a moderator

  Read the trust-and-safety queue. A report is about a PERSON (somebody reported an account, usually out of a conversation) or about a REVIEW (somebody reported a piece of content), and `subject` says which — the two are written by different parts of the product into one collection, and confusing them is how a report about a person once got resolved as 'content deleted' with nothing deleted. `unknown` means the document names no subject we can identify, and only a dismissal applies to it. Reports about people sort ahead of reports about content of the same age. CHANGES NOTHING.

  • status · value — Restrict to one state. Omit for the whole queue, oldest open report first.
• safety_person_statusCheck whether an account can sign in

  Whether this account is suspended right now, and how many reports about it a moderator has already upheld. `priorUpheld` counts only reports that were UPHELD — a dismissed report is a moderator deciding there was nothing in it, and counting those would let somebody be suspended on the strength of reports we ourselves threw out. `suspended` is read from the authentication service rather than from a copy on the user document, because that service is the thing that actually decides. CHANGES NOTHING.

  • uid · string · required — The account to look at.
• account_erasure_queueList account deletion requests

  Read the account-erasure queue. `requested` is a deletion that ran or is running; `blocked` is one that was refused because money or a commitment is still open between that person and somebody else — FU on their balance, a payout owed to them, a show they are on the bill for, or a room they own — and each blocked row carries the reasons and what clears them. `completed` rows are people who are gone; they keep an email address only so the audit trail means something afterwards. CHANGES NOTHING, and cannot run or retry a deletion.

  • status · value — Restrict to one state. Omit for the whole queue, oldest request first.