mcp server
Immersive Commons
Members-run AI builder space on Floor 10, Frontier Tower SF. 138 tools: events, news, directory.
Description as published by the maintainer. Source
- version 1.0.0
- active
active — Most recent push to the repository was 2026-07-20.
What this server can do
180 functions, named and described by the server itself. Parameter names are shown because they say more about what a function does than its name usually does.
floor10_extract_event_metadata(url)- Server-side WebFetch of an event page (Luma is the canonical case; LinkedIn / X / generic og:-bearing pages also work). Returns parsed { title, date, image, description, organization } so the agent doesn't have to scrape and parse OG / JSON-LD itself. Use the result to compose a HighlightStory. Args: { url }. Returns: a metadata map; empty fields where extraction missed. Required: url.
floor10_get_my_floor_member- Confirms the calling agent token is valid and returns the floor-member it's scoped to. Use as a post-mint smoke check before submitting. Args: none. Returns: { member_id, member_name, token_prefix, scopes }.
floor10_list_claimable_events(limit, status_filter)- Returns the list of events this floor member recently attended (or was invited to as a host) — the auto-discovery layer. Use this BEFORE asking the human 'what event did you go to?'; show them this list and let them pick. Source: graph.yaml attendance ingest, enriched with canonical URLs from data/events.yaml. Args: { status_filter? (e.g. ['checked_in','attended']), limit? (default 25, max 100) }. Returns: { count, total, generated_at, events: ClaimableEvent[] }. ClaimableEvent fields: event_api_id, title, date (YYYY-MM-DD), status (invited|approved|going|checked_in|attended), role, url, program, episode, registered_at, source.
floor10_list_my_pending- Returns the count of pending highlight submissions across the full moderation queue. Useful as a 'is there a backlog?' probe before adding more. (Per-member filtering is not exposed for v1; the queue is small.) Args: none. Returns: { count }.
floor10_submit_highlight(id, dek, date, stats, action, images, event_url, member_id, event_title, member_name, image_focals)- POST a HighlightStory for admin review. Same shape + same validation as the REST endpoint at /api/ingest/highlights/pending. Rate limit: 3 per token per UTC day. Re-submitting the same id refreshes the pending TTL (idempotent). Hard rules: no fabricated dates / quotes / member ids; news-wire third-person dek; candids first, posters last in images[]. See https://www.immersivecommons.com/docs/agent-submissions. Required: id, member_name, action, event_title, date, dek, images.
floor10_upload_image(url, data_url)- Re-hosts an image so its URL is suitable for the `images` array of a HighlightStory. Pass `url` (recommended; server fetches + stores) or `data_url` (small files only, RFC 2397 inline base64). Storage is content-addressed at floor10/highlights/<member_id>/<sha256>.<ext> on Vercel Blob, public-readable, year-long cache. Idempotent: same bytes -> same URL. Rate limit: 30 uploads / token / UTC day (separate from the submission rate). Allowed types: image/jpeg|png|webp|gif|heic|heif|avif. Max 8 MB per upload. Returns: { url, bytes, content_type, sha256, deduped }.
floorcast_effective_features- Resolve the effective feature-module set for the calling token's bound floor, LIVE from the tenant record: effective = (available ∩ enabled) \ force_disabled, plus the resolved tier and an 'N/total' breadcrumb (e.g. 'AI tier, 8/8 features live'). FAIL-CLOSED: on a both-down outage where the tenant record is unavailable, returns { ok:false, reason:'tenant-record-unavailable' } — NEVER a synthesized full set. Read-only; any valid token. Args: none. Returns: { ok, tenant, tier, available, enabled, force_disabled, effective, breadcrumb }.
floorcast_my_roles- Introspect the calling token's per-(user, tenant) Floorcast roles on its bound floor. Returns the resolved ring + display label + the canActAs verdicts (member / floor-admin / super-admin). Resolves the SAME way the auth gate does (one shared resolver — no drift). On a token with no tied Clerk identity it returns the fail-open public shape. Read-only; no scope beyond a valid token. Args: none. Returns: { tenant, ring, role_label, can_act_as }.
floorcast_preview_ai_curation- Read-only PREVIEW of the candidate content the floor's AI-curation policies WOULD surface, assembled from the floor's REUSED intel (commits / news / highlights). Writes NOTHING. Returns a per-policy { policy, candidate } list (candidate is null when the policy has no intel). Static-tier floors and floor10 (slug-fenced) return an empty list. Args: none.
floorcast_push(id, dek, date, stats, action, images, event_url, member_id, event_title, member_name, image_focals)- Member push of a HighlightStory to your floor's MEMBERS WIRE, routed through the floor's content policy. Default policy 'moderation_queue' ⇒ the story lands PENDING for operator approval ({ ok:true, status:'pending', id }). A 'free_push_with_retract' floor (floor10 only this increment) ⇒ the story goes straight to ACTIVE ({ ok:true, status:'active', id }) — a deliberate policy bypass of the operator gate, retractable via floorcast_unpush. CONSEQUENTIAL. Typed refusals: { ok:false, reason } where reason is 'forbidden' (not a member on this floor), 'invalid' (story failed validation), 'approve-failed' (free_push: enqueued but the active-promotion failed; the pending record is left for operator visibility), or 'tenant-not-provisioned' (NON-floor10 push is currently DENIED — not 'lands in moderation_queue'; multi-tenant push ships in a follow-on). Same story shape + validation as floor10_submit_highlight. Args: the HighlightStory fields. Required: id, member_name, action, event_title, date, dek, images.
floorcast_run_ai_curation- Manual fire of the floor's AI-curation runner: assembles a candidate per enabled policy from REUSED intel and pushes it through the inc-6 moderation primitives as 'system:ai_curation'. Non-floor10 AI floors land the candidate PENDING (operator-gated). Floor-Admin gated. Static floors return { ok:false, reason:'feature-not-available' }; floor10 is slug-fenced and ALSO denied (absolute in inc-7). De-dups against the active + pending lists so a re-run does not poison the pending queue. Args: none. Returns: a per-policy result list.
floorcast_set_ai_policy(policies)- Floor-Admin (operator-on-this-floor) sets the declarative AI-curation policy list (ai_policies) that drives the floor's AI self-updating wall. PERSISTS the tenant record via the inc-6 writer. Runs the FULL authz gate first: a non-Floor-Admin gets { ok:false, reason:'forbidden' } (no write). A live KV write failure surfaces { ok:false, reason:'write-failed', error }. Each policy is { type: 'top_commit'|'latest_news'|'rotate_highlights', enabled?, max_items? }. On success returns { ok:true, record }. Scope: a valid floor-bound token. Args: { policies }. Required: policies.
floorcast_set_feature_availability(module, available)- Super-Admin (apex flag AND operator-on-THIS-floor) sets which modules a floor is ALLOWED to enable. PERSISTS the tenant record (inc-6). Runs the FULL per-tenant super-admin gate first: a floor-admin WITHOUT the apex flag, or a super-admin on a DIFFERENT floor, gets { ok:false, reason:'forbidden' } (no write). A live KV write failure surfaces { ok:false, reason:'write-failed', error } (no 500). On success returns { ok:true, record }. NOTE: the force-disable kill-switch (setForceDisabled) is intentionally NOT exposed as an MCP verb this increment — it stays human/lib-only as a deliberate safety posture (re-evaluated when the inc-7 human override console lands). Args: { module, available }. Required: module, available.
floorcast_set_feature_enabled(module, enabled)- Floor-Admin (operator-on-this-floor) toggles a module in the floor's ENABLED set; a module must be AVAILABLE on the floor to enable. PERSISTS the tenant record (inc-6). Runs the FULL authz + availability gate first: a non-Floor-Admin, or enabling a module not available on the floor, gets { ok:false, reason:'forbidden' } (no write). A live KV write failure surfaces { ok:false, reason:'write-failed', error } (no 500). On success returns { ok:true, record } (the persisted next-record). Scope: a valid floor-bound token. Args: { module, enabled }. floorcast_effective_features reflects the toggle on the next read. Required: module, enabled.
floorcast_unpush(id)- Member retract of your OWN still-pending highlight from your floor's queue (you cannot retract an already-approved/active item via this verb — that needs an operator). Routed through the floor content policy; the gate is server-side (ownership-checked). CONSEQUENTIAL. Returns { ok:true, id } on success; typed refusals { ok:false, reason } where reason is 'forbidden' (not your submission), 'not-found' (no such pending item), or 'tenant-not-provisioned' (NON-floor10 is currently DENIED). Args: { id }. Required: id.
ic_activity_get_recent(limit)- Returns the most recent activity events recorded for the calling user — every consequential tool call (highlights submit, RSVP, booking, GitHub link, opt-in toggle, tier request, directory search) ends up here with attribution to the token that made it. Each event has { ts, tool, scope, token_prefix?, token_label?, via, success, error?, meta? }. Useful for the human to audit 'which of my agents has been doing what.' Args: { limit?: number (max 100, default 25) }. Required scope: membership:read.
ic_admin_agent_audit_search(kind, limit, since, offset, client_id, member_id, operator_human)- Cross-member audit search over class-B integration activity (DESIGN §11). Walks the matching clients → their bearer tokens → those tokens' outbox threads → each thread's actions, newest-first. Surfaces actions reachable from a client's OWN outbox (the integration's blast radius); counterparty-side actions are out of v1 scope (no reverse index yet). Operator-only (admin:agent_clients + live operator re-check). Args: { client_id?: string, operator_human?: string, member_id?: string, kind?: 'policy_eval'|'member_tap'|'system'|'counterparty', since?: ISO datetime, limit?: number (default 200), offset?: number (default 0) }. Returns: { ok, hits, total, has_more } — total counts every filtered hit; page past the cap with offset. Required scope: admin:agent_clients.
ic_admin_agent_client_list(limit, offset, include_revoked)- List provisioned class-B integrations newest-first with usage stats (tokens issued, threads started, last seen). Operator-only (admin:agent_clients + live operator re-check). Secret hashes are never returned. calls_per_day / rejection_rate render absent until a per-call counter lands (v1 has none). Args: { include_revoked?: boolean (default true), limit?: number, offset?: number }. Returns: { ok, clients, has_more } — page past the cap with offset. Required scope: admin:agent_clients.
ic_admin_agent_client_register(name, scopes, contact, operator_human, requires_signature)- Provision an external integration (another company's CRM bot, a research-collab tool) with a client_id + one-time client_secret it later exchanges for a scoped bearer token (DESIGN §2 Class B). Operator-only: gates on admin:agent_clients AND a live operator-tier re-check. The plaintext secret is returned EXACTLY ONCE (only its hash is stored) — a lost secret means re-register. Grantable scopes are limited to the agent:* family (directory:read / request_meeting / send_intro / ping / thread:write / inbox:read / policy:read); any other requested scope (esp. admin:*) is REFUSED and listed in denied_scopes. Args: { name, operator_human, scopes: string[], contact, autonomy?, requires_signature?, budget_overrides? }. Returns: { ok, client_id, client_secret_once, client }. Required scope: admin:agent_clients. Required: name, operator_human, scopes, contact.
ic_admin_agent_client_revoke(reason, client_id)- Revoke an integration and flag its AUTONOMOUS actions for recipient re-confirmation (DESIGN §9 — interactive actions are NOT flagged, each had per-call approval). Revokes every linked bearer token so the integration is dead immediately, snapshots prior state for one-step revert (DESIGN §18), and returns how many autonomous actions were flagged + tokens revoked. Operator-only (admin:agent_clients + live operator re-check). Idempotent. Args: { client_id: string (cli_<base32>), reason: string }. Returns: { ok, actions_flagged, tokens_revoked }. Required scope: admin:agent_clients. Required: client_id, reason.
ic_admin_approve_endpoint(confirm, endpoint_id)- Approve the card awaiting review on an endpoint: promotes it to the served card and indexes it for ic_endpoint_search. Two-step like the other operator queues — omit `confirm` (or pass false) for a dry-run preview that mutates nothing; pass confirm:true to apply. Idempotent: an id with nothing pending returns ok:false. Args: { endpoint_id, confirm? }. Returns: dry-run shape on confirm=false; { ok, id, status } on confirm=true. Required scope: admin:endpoints_review (operator). Required: endpoint_id.
ic_admin_approve_event(id, confirm)- Approve a pending 'save the date' event draft: flows the wrapped KioskEvent into floor10:events:approved (dedupe-prepend, keep newest 50), drops it from the pending queue, and writes an audit entry. The kiosk events page merges approved drafts with the live Luma list (live wins on the shared slug); once the real Luma event goes live, ic.kv_push.push_events prunes the draft automatically. This NEVER creates a public Luma event — it posts a no-RSVP save-the-date card; IC staff create the live Luma event from the request detail afterward. Two-step: omit `confirm` (or pass false) for a dry-run preview that returns what the call would do without mutating; pass `confirm: true` to actually apply. Idempotent: a missing / already-handled / TTL-expired id returns ok:false (and cleans the stale list pointer). Rate-limited to 20 approve+reject mutations per token per UTC day; dry-run calls do NOT count. Args: { id, confirm? }. Returns: dry-run shape on confirm=false; { ok, id } on confirm=true. Required scope: admin:events_review. Required: id.
ic_admin_approve_highlight(id)- Promote a pending highlight into the live /floor10/highlights MEMBERS WIRE (dedupe-prepend, keep 4 active, spill older to archive), drop it from the queue, and write an audit entry. Idempotent: a missing or expired id returns ok:false. Scope: admin:highlights_review. Required: id.
ic_admin_approve_key_request(confirm, multiplier, request_id)- Approve a pending Z.ai key request and MINT the proxy key. Two-step: omit `confirm` (or pass false) for a dry-run preview of the exact proxy block that would be minted; pass `confirm: true` to mint. IDEMPOTENT on request_id — a second confirmed approve returns the SAME key (it does NOT mint a second key); the plaintext key is surfaced ONLY on the first mint. For member keys, `multiplier` overrides the requested multiplier. The minted key works ONLY against the IC→Z.ai gateway (it carries zero IC tool scopes). Rate-limited to 20 approve+deny mutations per token per UTC day; dry-run + idempotent re-approve do NOT count. Args: { request_id, multiplier?: 1|2|5|10|20, confirm? }. Returns dry-run shape on confirm=false; on the first confirm:true mint, { ok, minted:true, agent_token, token_prefix, proxy }. Required scope: admin:llm_keys. Required: request_id.
ic_admin_approve_ownership(id, force, confirm)- Bind the requesting founder onto the StartupProfile, drop the request from the queue, write the active-ownership index + an audit entry. Once bound, that founder's agent/session may edit the page + post news. MULTI-OWNER + ADDITIVE: a startup may have many co-founders; approving ADDS the requester to the owner set (the first owner becomes the primary founder_clerk_user_id, each subsequent one is appended) — NO existing owner is ever displaced, so there is no rebind/confirm step. Idempotent: re-approving an existing owner, or a missing/expired id, is a clean no-op (ok:false only on missing/expired). Args: { id }. (confirm/force are accepted for back-compat but ignored.) Returns { ok, id, slug, founder_clerk_user_id, current_owners }. Required scope: admin:ownership_review. Required: id.
ic_admin_approve_tier_request(tier, reason, confirm, user_id)- Approve a pending tier request and set the user's tier. Two-step: omit `confirm` (or pass false) for a dry-run preview that returns what the call would do without mutating state. Pass `confirm: true` to actually apply. If `tier` is omitted, the user is approved to the tier they requested; pass `tier` to override (e.g. they asked for ic-member but you approve ai-floor). Rate-limited to 20 approve+deny mutations per token per UTC day; dry-run calls do NOT count. Args: { user_id, tier?: 'ft-member'|'ai-floor'|'ic-member'|'operator', reason?, confirm? }. Returns: dry-run shape on confirm=false; { ok, user_id, from, to, action: 'approve' } on confirm=true. Required scope: admin:tier_review. Required: user_id.
ic_admin_deny_key_request(reason, confirm, request_id)- Deny a pending Z.ai key request. Marks it denied + removes it from the queue; no key is minted. Two-step: omit `confirm` (or pass false) for a dry-run preview, `confirm: true` to apply. Refuses to deny an already-approved request (revoke the minted key at /floor10/agent-console instead). Rate-limited to 20 approve+deny mutations per token per UTC day; dry-run does NOT count. Args: { request_id, reason?, confirm? }. Returns dry-run shape on confirm=false; { ok, request_id, was_pending } on confirm=true. Required scope: admin:llm_keys. Required: request_id.
ic_admin_deny_tier_request(reason, confirm, user_id)- Deny a pending tier request. Clears the pending fields + KV snapshot; the user's tier is unchanged. Two-step: omit `confirm` (or pass false) for a dry-run preview. Pass `confirm: true` to actually apply. The optional `reason` is recorded in the audit log and is surfaced to the requester on their /membership page so they understand why. Rate-limited to 20 approve+deny mutations per token per UTC day; dry-run calls do NOT count. Args: { user_id, reason?, confirm? }. Returns: dry-run shape on confirm=false; { ok, user_id, tier, was_pending } on confirm=true. Required scope: admin:tier_review. Required: user_id.
ic_admin_leaderboard_inspect(limit)- Operator-only deep read of the commits leaderboard snapshot: the full ranked board PLUS the persisted aggregation `errors[]` (broken OAuth/PAT tokens, GraphQL failures captured during the weekly cron — the ops visibility operators need to spot N broken tokens before they wreck the next refresh) and the snapshot freshness (generated_at, stale, age_min). Each member carries { rank, handle, name, commits, private? } (private = folded-in private-contribution COUNT, never repo content). Returns: { ok, generated_at, stale, age_min, member_count, members: [...], errors: [{ userId, reason }] }. Required scope: admin:leaderboard_review.
ic_admin_list_feedback(full, kind, limit, offset, priority, resolved)- Read the agent-voice queue. Default returns the newest 25 summaries (preview = first 200 chars of message + attribution + priority + kind + resolved flag). Pass full=true to get full records (for export / triage). Filters AND together: kind, priority, resolved (true = closed only, false = open only, omit = both). Returns: { ok, count, total, scanned, filter, records }. Newest first. Required scope: admin:feedback_review.
ic_admin_list_members(q, tier, limit, offset)- The ACTUAL account roster — every Clerk-backed IC account with its live ring/tier, resolved from Clerk (not the carded ic_directory_search, which only shows members who've set a profile card, and not the curated kiosk list). This is what you want to answer 'who are the members' or find a specific account (e.g. one that hasn't set a card yet). Each member: { user_id, name, email, tier ('public'|'ft-member'|'ai-floor'|'ic-member'|'operator'), pending_request (the tier they've requested but not yet been granted, or null), created_at }. Args: { tier?: filter to one ring; q?: case-insensitive name/email/user_id substring filter; limit?: number (default 200, max 500); offset?: number (default 0) }. Filters apply to the fetched page; `total` is the full Clerk account count and `has_more` tells you to page with offset (default limit covers all IC accounts in one page today). Required scope: admin:tier_review.
ic_admin_list_pending_endpoints(limit)- Read the endpoint-registry review queue, newest first. Each entry shows the card AWAITING REVIEW (not the one currently being served) plus who registered it and which origin was mechanically proven. Origin ownership is ALREADY proven before anything reaches this queue — IC fetched the card from a well-known path on that origin and the registrant served a per-member challenge token there — so your judgment call is about whether the service belongs on the floor, not about whether they control the domain. Args: { limit? (max 200, default 50) }. Returns: { ok, count, pending }. Required scope: admin:endpoints_review (operator).
ic_admin_list_pending_events(detail, audit_tail)- Operator review queue: every pending 'save the date' event draft awaiting approval at /floor10/admin/events, plus a recent decisions/audit tail. Two sources feed the queue (the `source` field disambiguates): 'member_request' (a member's agent via ic_events_request) and 'kiosk_submit' (Ray's `events kiosk-submit` CLI). Each pending record: { id, title, when, venue?, host?, description?, source, requested_by?, submitted_at, submitted_by, request? } — `request` carries the extra Luma-shaped fields the kiosk card doesn't render (end / capacity / visibility / contact). Each audit entry: { id, action ('approve'|'reject'), by_clerk_user_id, at, reason?, title?, when? }. Use BEFORE ic_admin_approve_event / ic_admin_reject_event to see what's waiting and why. Args: { audit_tail?: number (default 12, max 500), detail?: 'summary'|'full' (default 'full'; 'summary' trims each pending row to id/title/when/source/submitted_at) }. Returns: { ok, count, pending, audit }. Required scope: admin:events_review.
ic_admin_list_pending_highlights(detail)- Operator review queue: every pending highlight submission with its id, member, action, event title, date, dek, and image count, so you can decide approve/reject. Excludes test fixtures + stale pointers. Pair with ic_admin_approve_highlight / ic_admin_reject_highlight. Args: { detail?: 'summary'|'full' (default 'full'; 'summary' trims each row to id/member_name/action/event_title/date) }. Scope: admin:highlights_review.
ic_admin_list_pending_key_requests- Returns the operator's pending Z.ai-key-request queue plus a recent audit tail. Each pending record: { id, kind ('workshop'|'member'), requester_clerk_user_id, requester_name?, event_id?, event_title?, multiplier?, note?, created_at }. Use BEFORE ic_admin_approve_key_request / ic_admin_deny_key_request. Args: none. Required scope: admin:llm_keys.
ic_admin_list_pending_ownership- Operator review queue: every pending founder-binding request — { id, member_id, member_name, startup_slug, startup_name, submitted_at, submitted_by_clerk_user_id, expires_at?, already_owned, current_owner?, current_owners? }. Multi-owner: `already_owned` now just flags that the slug already has >=1 owner — it is INFO, not a conflict (approving ADDS the requester as a co-founder; current_owners lists the existing set). Pair with ic_admin_approve_ownership / ic_admin_reject_ownership. Args: none. Returns { ok, count, pending }. Required scope: admin:ownership_review.
ic_admin_list_pending_tier_requests- Returns the operator's pending-membership queue plus the most recent audit tail. Each pending record: { user_id, email, display_name, current_tier, requested_tier, note, submitted_at }. Each audit entry: { user_id, email, action ('approve'|'deny'|'auto-promote'|'request'|'demote'), from, to?, requested?, reason?, by_clerk_user_id?, at }. Use BEFORE ic_admin_approve_tier_request / ic_admin_deny_tier_request to see who's waiting and why. Args: none. Required scope: admin:tier_review.
ic_admin_list_recent_startup_content(days)- Flat, newest-first list of recent startup news items (one row per item) for the auto-publish safety net. 'Recent' = posted within `days` (default 7) OR the parent profile was edited in that window. Each row: { slug, startup_name, public_visible, item_id, title, url?, posted_at, source?, profile_updated_at }. A hidden profile still surfaces its rows so you can see + restore what you took down. Pair with ic_admin_takedown_startup_content. Args: { days?: number (default 7) }. Returns { ok, count, rows }. Required scope: admin:content_review.
ic_admin_reject_endpoint(note, confirm, endpoint_id)- Refuse the card awaiting review on an endpoint, with a note the owner can read via ic_endpoint_get. NON-DESTRUCTIVE to a live listing: if the endpoint already had an approved card, that card KEEPS serving and only the in-flight change is refused (the entry stays 'approved'); an endpoint that was never approved becomes 'rejected'. To take down a live listing, unlist it instead. Two-step: omit `confirm` for a dry-run preview. Args: { endpoint_id, note, confirm? }. Returns: dry-run shape on confirm=false; { ok, id, status } on confirm=true. Required scope: admin:endpoints_review (operator). Required: endpoint_id, note.
ic_admin_reject_event(id, reason, confirm)- Reject a pending 'save the date' event draft: drops it from the pending queue with an optional reason and writes an audit entry. Does NOT publish anything. Two-step: omit `confirm` (or pass false) for a dry-run preview; pass `confirm: true` to actually apply. The optional `reason` is recorded in the audit log (operator-facing; member requests do not surface it back to the requester today). Idempotent — rejecting an already-gone id still records the decision and returns ok. Rate-limited to 20 approve+reject mutations per token per UTC day; dry-run calls do NOT count. Args: { id, reason?, confirm? }. Returns: dry-run shape on confirm=false; { ok, id } on confirm=true. Required scope: admin:events_review. Required: id.
ic_admin_reject_highlight(id, reason)- Drop a pending highlight from the moderation queue with an optional reason and write an audit entry. Does not publish. Scope: admin:highlights_review. Required: id.
ic_admin_reject_ownership(id, reason)- Drop a pending founder-binding request from the queue (no bind) with an optional reason, and write an audit entry. Args: { id, reason? }. Returns { ok, id, slug? }. Required scope: admin:ownership_review. Required: id.
ic_admin_resolve_feedback(note, confirm, ticket_id)- Mark one ticket resolved with an optional note. Two-step: omit `confirm` (or pass false) for a dry-run preview that returns the would-be-updated record without mutating. Pass `confirm: true` to actually apply. Already-resolved tickets return error_kind 'already_resolved' (idempotent at the channel level — no double-write of resolved_at). Args: { ticket_id, note?, confirm? }. Returns: dry-run shape on confirm=false; { ok, record } on confirm=true. Required scope: admin:feedback_review. Required: ticket_id.
ic_admin_takedown_startup_content(slug, reason, item_id)- Pull auto-published founder content. With `item_id`: remove that single news item from the profile's news[]. Without `item_id`: hide the WHOLE startup (public_visible=false). Both rebuild the public cards, mirror to blob, revalidate the public pages, and write an audit entry. Idempotent (removing an already-gone item / hiding an already-hidden profile returns ok:true). NB: a removed news item cannot be restored — the founder must re-post it. Args: { slug, item_id?, reason? }. Returns { ok, slug, item_id?, scope }. Required scope: admin:content_review. Required: slug.
ic_agent_directory_lookup(limit, query)- Search the member directory (floor roster + canonical members) for members you could address, annotated with each member's inbox_status (open/closed) and accepted_intents (best-effort — which intent types their policy will entertain; empty when closed). This is a routing HINT ('don't bother sending a meeting_request to a closed inbox'), not the authoritative decision — the policy engine still evaluates the real envelope. Closed-inbox members are still returned so you see they exist. Args: { query: string (2-80 chars), limit?: number (default 20, max 50) }. Returns: { ok, query, count, results: [{ member_id, member_name, inbox_status, accepted_intents }] }. Required scope: agent:directory:read. Required: query.
ic_agent_inbox_block(client, member, reason, operator)- Add an entry to YOUR inbox blocklist (the policy.blocklist your policy engine consults before any rule). Future envelopes from a blocked sender are silently dropped — they get an opaque ok-shape and never learn they're blocked. Specify EXACTLY ONE of operator / member / client. Idempotent (re-blocking an existing entry is a no-op success). Optional `reason` is recorded on a server-side audit row only (the blocklist itself stores no reason). The owner is always you (the token's member_id) — you can only manage your own blocklist. Args: { operator?: string, member?: string, client?: string, reason?: string }. Returns: { ok, blocklist, changed }. Required scope: agent:inbox:write. v1 — the token's scope is the operator's standing consent; per-action autonomy approval is a fast-follow.
ic_agent_inbox_get_thread(thread_id)- Returns the full thread record, every envelope in the conversation, and the audit-action log. Caller must be either the recipient (thread.parties.to.member_id matches token's member_id) OR the original sender (thread.parties.from.token_sha256 matches token's sha256). Otherwise returns 'thread_not_found' (404-shape — does not leak that a thread exists for someone else). Args: { thread_id: string (thr_<crockford-base32>) }. Returns: { ok, thread, envelopes, actions }. Required scope: agent:inbox:read. Required: thread_id.
ic_agent_inbox_list_blocks- Return the blocklist entries on YOUR inbox policy. Each entry is exactly one of { operator } | { member } | { client }. Empty array when you've blocked nobody (or have no policy yet). Caller-scoped to the token's member_id. Args: none. Returns: { ok, count, blocklist }. Required scope: agent:inbox:read.
ic_agent_inbox_list_threads(limit, offset)- Returns the calling member's own inbox threads, sorted by updated_at desc. Caller-scoped server-side — the member_id is taken from the token, so an agent can only ever see its operator's inbox. Use this BEFORE `ic_agent_inbox_get_thread` to find what's new. Args: { limit?: number (default 25, max 100), offset?: number (default 0) }. Returns: { ok, count, threads }. Required scope: agent:inbox:read.
ic_agent_inbox_reply(message, decision, thread_id, proposed_windows)- Act on a thread you are a party to (recipient or original sender): accept / decline / counter-propose / clarify / withdraw. Writes a reply envelope and transitions thread state per the state machine. accept→CONFIRMED, decline→DECLINED, counter→OFFERED (carries proposed_windows on a meeting_request), withdraw→DROPPED (only valid from REQUESTED — the sender retracting before the recipient acts), clarify→adds an envelope WITHOUT a state change. Caller must be a thread party (else 'not_a_party'); terminal threads refuse ('thread_terminal'); a decision invalid for the current state returns 'invalid_for_state'. The actor member_id is taken from the token. Args: { thread_id: string (thr_<base32>), decision: 'accept'|'decline'|'counter'|'clarify'|'withdraw', message?: string ≤2000, proposed_windows?: [{ start: ISO, end: ISO, tz_hint?: string }] }. Returns: { ok, envelope_id, new_state }. Required scope: agent:thread:write. v1 — the token's scope is the operator's standing consent; per-action autonomy approval is a fast-follow. Required: thread_id, decision.
ic_agent_inbox_send_envelope(to, body, intent, idempotency_key, expected_outcome, intro_target_org, intro_target_name, intro_target_context, intro_target_linkedin_url, consent_target_has_opted_in)- Route a typed intent (ping / request_meeting / send_intro) to another IC member's agent inbox. Recipient's policy engine decides what happens — store + notify, store + queue-for-tap, silently drop (blocklist), or refuse (inbox closed). Server-side: sanitizes body (C0 controls / zero-width / NFKC), wraps into the per-intent payload, persists thread + envelope + sender-history + audit, evaluates policy, returns the decision. Scopes per intent: ping → agent:ping (ai-floor+); request_meeting → agent:request_meeting (ic-member+); send_intro → agent:send_intro (ic-member+). send_intro brokers an introduction TO the recipient and requires intro_target_name + body (the intro_pitch) + expected_outcome + consent_target_has_opted_in=true (anti-spam — you MUST have the target's consent). Idempotency: pass `idempotency_key` to make the (token, key) pair cached for 24h. Returns: { ok, envelope_id, thread_id, state, policy_decision }. Recipient inbox closed → mcpError. Blocklisted senders get an opaque ok-shape with random ids (silent-block — no persistence visible to the sender; the audit row is server-side only). PRECHECK: call ic_agent_directory_lookup first — a member whose inbox_status is "closed" (the default for newly-joined members) cannot be reached and this verb will refuse. v1 SHIP note: request_meeting wraps body into context_summary with sensible defaults until the agent-console UI exposes full per-intent args. Required: to, intent.
ic_agent_inbox_unblock(client, member, operator)- Remove an entry from YOUR inbox blocklist. Specify EXACTLY ONE of operator / member / client, matching the original block target. Idempotent (removing an entry that isn't present is a no-op success). The owner is always you (the token's member_id). Args: { operator?: string, member?: string, client?: string }. Returns: { ok, blocklist, changed }. Required scope: agent:inbox:write.
ic_agent_inbox_undo(action_id)- Reverse a reversible policy auto-action (auto-accept / auto-decline) within the reversal window the policy engine granted. Forward transitions are one-way, so undo restores the EXACT prior state recorded on the auto-action's audit row. Gating: the action must exist + you must be a thread party (else 'not_a_party' / 'thread_not_found'); the thread must still carry an open reversible_until and the action must encode a recoverable prior_state (else 'invalid_for_state' — window closed or nothing reversible). On success the thread is restored, the window is cleared (one undo per window), and a reversal audit row is written. Args: { action_id: string (act_<base32>) }. Returns: { ok, envelope_id, new_state }. Required scope: agent:inbox:write. Required: action_id.
ic_agent_outbox_list(limit, offset)- Returns the threads the calling agent's token initiated (the sender-side counterpart to ic_agent_inbox_list_threads, which lists threads addressed TO you). Caller-scoped server-side — keyed on the token's sha256, so an agent only ever sees threads it started. Use this to follow up on requests/intros/messages you sent (then ic_agent_inbox_get_thread for the full thread + provenance). Args: { limit?: number (default 25, max 100), offset?: number (default 0) }. Returns: { ok, count, threads }. Required scope: agent:inbox:read.
ic_agent_policy_get- Return YOUR current inbox policy: inbox_status (open/closed), default action, rules, blocklist, and notification prefs. A member who has never opened their inbox gets the closed default. Caller-scoped to the token's member_id — you can only read your own policy. Args: none. Returns: { ok, policy, presets } (presets = the available preset slugs). Required scope: agent:policy:read.
ic_agent_policy_set(policy, preset)- Set YOUR inbox policy — this is how a member OPENS their inbox (closed by default). Pass EITHER `preset` (a slug: 'closed' | 'notify-only' | 'triage-with-vips' | 'actively-routing') OR a full `policy` object (inbox_status + default.action + optional rules / blocklist / notifications), not both. The prior policy is snapshotted to a 30-day rollback key on every save. Opening to notify-only is the lowest-friction consent step. Caller-scoped — you can only set your own policy. Args: { preset?: string } XOR { policy?: object }. Returns: { ok, policy, snapshot_ts }. Required scope: agent:policy:write. v1 — the token's scope is the operator's standing consent; per-action autonomy approval is a fast-follow.
ic_capabilities- In-band capability matrix: every registered MCP tool with its one-line description, required scope (null = any valid token), the minimum membership tier whose users can mint a token carrying that scope, and whether THIS caller's token can reach it right now ('reachable' | 'needs_scope:<scope>'). Use it to plan before calling scope-gated tools and to tell your human exactly which tier + scopes a token needs — remember scopes CANNOT be added to an existing token (a new one must be minted with the scope in the signup array). Available to any valid token — no extra scope. `additional_gate` (usually null) names a per-tenant ROLE the handler resolves that no scope expresses — today the floorcast floor-admin / super-admin writes. It is NOT folded into `reachability`, which is scope-derived only: this endpoint sees your scopes, never your floor roles, so a tool can read 'reachable' and still return forbidden if you don't hold the role. Args: none. Returns: { count, caller: { scopes }, tools: [{ name, description, required_scope, min_tier, reachability, additional_gate }] }.
ic_context_get- Current weather + local time for IC's home (Frontier Tower SF). Source: Open-Meteo, cached ~10min. Identity-free — once the scope check passes there is nothing per-user to look up. Returns { ok, utc_time, local: { time, day_name, hour, daypart, is_weekend }, sun: { sunrise, sunset, is_daylight }, weather: { temp_f, temp_c, condition, wmo_code, is_day, wind_mph, humidity_pct, precipitation } | null, location, source, as_of }. Args: none. Required scope: context:read.
ic_directory_search(q, limit)- Search the floor roster by name, display name, GitHub handle, telegram handle, or member id. Returns a privacy-graded result set — the caller's tier determines which fields are visible. ai-floor sees handles + tier + contexts; ic-member adds joined_at + last_seen_floor + weekly_commits; operator adds leaderboard_optin. Args: { q: string (2-80 chars), limit?: number (max 50, default 20) }. Required scope: directory:search. Required: q.
ic_donate- Support Immersive Commons with an on-chain USDC donation over x402 (HTTP 402 + USDC on Base). No auth required. Returns the donation tiers, the receiving wallet (payTo), the asset + network, and the donate URL. MCP can't run the in-band 402 handshake itself, so to donate: POST https://www.immersivecommons.com/api/x402/donate with an x402 X-PAYMENT header (sign an EIP-3009 USDC authorization for one of the tier amounts to payTo on the given network); the first call with no X-PAYMENT returns a 402 listing every tier in accepts[]. Optional donor { name, message } can be sent in the JSON body and appear on the public donor wall at /donate. Args: none.
ic_donations_total(limit)- Returns the running total raised (USD), the donor count, and the most recent settled donations (name, amount, message, tx, ts) shown on the public donor wall at /donate. No auth required. Args: { limit?: number (1-50, default 10) }.
ic_endpoint_get(endpoint_id)- Fetch a single endpoint-registry entry by id, including its full normalized card and the tool list an agent would get. An APPROVED entry is readable by anyone with the scope. A pending / rejected / unlisted entry is visible ONLY to its owner or an operator, and for those callers the response also carries review_note plus the card currently awaiting review. Args: { endpoint_id }. Returns: { ok, endpoint }. Required scope: endpoints:read (ft-member+). Required: endpoint_id.
ic_endpoint_register(card_url)- Register (or refresh) YOUR OWN MCP service so agents on the floor can find it. You pass only a card_url — IC fetches the card itself, so you can only register an origin you actually serve. The URL must be https with no query string and its path must be one of /.well-known/mcp.json, /.well-known/mcp/server.json, /.well-known/server.json, /.well-known/ai-agent.json, /.well-known/agent-card.json. THREE card shapes are accepted as-is (do not invent an IC-specific format): the /.well-known/mcp.json discovery shape (top-level url + transport + tools[] of names), the official MCP registry server.json (remotes[] + required name/description/version), and an endpoint-card shape (endpoint{url,transport,auth} + tools[{name,purpose}]). FIRST CALL on a new origin returns ok:false with error_kind 'challenge_unverified' plus verify_url + verify_token: publish that token at /.well-known/ic-endpoint-challenge.txt on the same origin, then call again. Once verified the card lands in the operator review queue (status 'pending'); it is NOT searchable until an operator approves it. Re-registering an origin UPDATES your existing record: an unchanged card just refreshes the liveness timestamp, a CHANGED card goes back to review while your last approved card keeps serving (so a version bump is not an outage). Args: { card_url }. Returns: { ok, id, status, needs_review, card } or the challenge instructions. Rate: 8 register calls per caller per UTC day (each one makes IC fetch a third-party URL). Required scope: endpoints:register (ic-member+). Required: card_url.
ic_endpoint_search(mine, limit, query)- Search the IC endpoint registry — the member-run MCP services other agents on the floor have published. Matches a case-insensitive substring against each card's name, title, description, website and TOOL NAMES, so 'cad' finds a service whose tool is named submit_design_request. Ranking is deliberately absent; the value here is existence, not relevance ordering. Only operator-APPROVED, listed cards are returned. Each hit carries { id, origin, card_url, owner_member_id, owner_name, card: { name, title, description, url, transport, auth, tools[], website_url, version, shape }, last_verified_at, stale_days, stale } — connect using card.url + card.transport. `stale` means IC has not re-verified the card in over 35 days; the card is still shown, just labeled. Pass mine=true to list YOUR OWN registrations in every status (pending / approved / rejected / unlisted) instead — that is how you find the id of something you just registered. Args: { query?, mine?, limit? (max 25) }. Returns: { ok, count, endpoints }. Required scope: endpoints:read (ft-member+).
ic_endpoint_set_listed(listed, endpoint_id)- Toggle whether YOUR endpoint appears in ic_endpoint_search. listed=false unlists it (reversible — the record and its approved card are retained, so this is a hide, not a delete); listed=true re-lists a previously approved entry with NO new review, because the operator already approved that exact card. Owner or operator only. Args: { endpoint_id, listed }. Returns: { ok, id, status }. Required scope: endpoints:register (ic-member+; owner identity re-checked). Required: endpoint_id, listed.
ic_events_get(luma)- Find an event in the upcoming-events cache by its Luma URL. Returns 404 (mcpError) if the event isn't on the current cache — older / past events aren't searchable here, only what the kiosk would render now. Args: { luma: string (https://luma.com/<slug>) }. Required scope: events:read_upcoming. Required: luma.
ic_events_get_live- Returns the IC event currently in progress, defined as `when <= now < when + 3h` (heuristic — the kiosk cache doesn't yet carry end_time; replace with truth once life-side publishes it). Returns `null` if no event is in that window. Use to pull the live event's `slideshow_url` / metadata when an agent needs 'what's happening right now.' Args: {} (no args; server-side current time). Required scope: events:read_upcoming.
ic_events_list_upcoming(limit)- Returns the upcoming-events feed the FT10 kiosk renders. Backed by `/api/refresh/events` cron (hourly Luma sync). Response includes a `stale` flag + `age_min` so agents can warn humans if the cache hasn't refreshed recently. Args: { limit?: number, default 15, max 50 }. Required scope: events:read_upcoming.
ic_events_next(limit, since, types)- Cursor-based read of the calling user's agentic event log. IC publishes events that personal agents subscribe to — tier_requested, tier_approved, tier_denied (more types arrive as append sites land). Pass `since` = your last-seen event.id (omit for full backlog); response carries `cursor` (largest id returned), `has_more` (re-poll immediately if true), and `as_of` (server time). Optional `types[]` filter; default returns all entitled types. Events carry `actions[]` — affordances the agent can render (one-tap reply) or auto-invoke (with policy). Per-user scoped server-side: a token tied to user X only sees X's events. Replay-safe: events are immutable and id-keyed. Args: { since?, types?, limit? }. Returns: { events, cursor, has_more, as_of }. Required scope: none beyond a valid token with a tied Clerk identity.
ic_events_request(end, host, start, title, contact, capacity, location, cover_url, visibility, description, slideshow_url)- Propose an event by submitting Luma-shaped details. The request is enqueued as a 'save the date' draft for operator review at /floor10/admin/events — approval is the gate; this NEVER auto-creates a public Luma event. After an operator approves, IC staff create the live Luma event from your details and the kiosk card upgrades automatically. Args: { title, start (ISO-8601, future), end?, location?, description?, cover_url?, capacity?, visibility?: 'public'|'members', host?, contact?, slideshow_url? }. Returns: { ok, id, status: 'pending' }. Required scope: events:request (ic-member+). Required: title, start.
ic_events_rsvp(name, email, event_url)- Queue an RSVP envelope for life-side processing — Ray's Luma cohost session adds the guest. This returns 'queued', NOT 'Luma confirmed.' The human will get a Luma email on the next processor cycle. Rate-limited to 10/token/UTC day; idempotent via 7-day dedupe on (event_url, user). Args: { event_url: string, email: string, name?: string }. The agent MUST supply email explicitly — the server doesn't derive it for agent callers (trust boundary). Required scope: events:rsvp. Required: event_url, email.
ic_feedback_get_status(ticket_id)- Read one of YOUR feedback tickets in full by ticket_id — including whether the operator resolved it, the resolution_note, and resolved_at. Ownership-gated: a ticket_id that isn't yours returns { ok:false, error_kind:'forbidden' }; an unknown / expired id returns { ok:false, error_kind:'not_found' }. The message + sidecars come back inside `<USER_SUBMITTED_TEXT>` quarantine envelopes (your own text, echoed safely). Args: { ticket_id }. Returns: { ok, record, resolved, resolution_note?, resolved_at? }. Required scope: feedback:read (granted at ai-floor, ic-member, operator). Required: ticket_id.
ic_feedback_list_mine(limit, offset, resolved)- List the feedback tickets YOU submitted (via ic_feedback_submit or the REST endpoint with your Bearer token), newest first. Returns summaries: ticket_id + kind + priority + preview + resolved flag + resolved_at. Use ic_feedback_get_status for the full status of one ticket (incl. the operator's resolution note). Optional resolved filter: true = closed only, false = open only, omit = both. Ownership is automatic — you only ever see tickets attributed to your IC identity (anonymous submissions never appear). Returns: { ok, count, total, scanned, records }. Required scope: feedback:read (granted at ai-floor, ic-member, operator).
ic_feedback_submit(got, url, kind, contact, message, agent_id, category, expected, priority)- Send a structured note to the Immersive Commons operator. Kinds: feature_request | praise | complaint | question | suggestion | bug_report | broken_url | schema_mismatch | stale_doc | endpoint_404 | other. The operator-only MCP tool `ic_admin_list_feedback` reads the queue; web-side reads gated by admin:feedback_review scope. Per-IP rate limit 10/UTC hour (shared with the anonymous REST endpoint). Returns: { ok, ticket_id, received_at }. Quote the ticket_id when following up. Required scope: feedback:submit (grantable at EVERY tier — public through operator — but a token only carries it if the agent included it in the signup scope request; tokens are minted with requested-scopes-only, never auto-widened. Missing it? Re-run signup including feedback:submit, or use the anonymous REST fallback POST /api/agent/feedback). Required: kind, message.
ic_files_get(inline, file_id)- Resolve one file by id, authorize you against it, and return its metadata plus the authenticated download URL (GET it with your bearer token to fetch the bytes). Optionally inline small files (<=1MB) as base64. If you're not authorized (a private/grantees file you're not on) this returns forbidden. Args: { file_id, inline?: boolean (default false; only honored for files <=1MB) }. Returns: { ok, file, download_url, inline_base64? }. Required scope: files:read (ic-member+). Required: file_id.
ic_files_grant(file_id, subject, ttl_seconds)- Create a signed, expiring share link for ONE file you uploaded (or any file, if operator) so a person WITHOUT an IC login can download it. The link embeds a grant bound to that single file id and works until it expires. Args: { file_id, subject?: string (audit label, e.g. who it's for), ttl_seconds?: number (default 7 days, max 30 days) }. Returns: { ok, file_id, filename, link, expires_at }. Required scope: files:write (ic-member+; only the uploader or an operator can share a given file). Required: file_id.
ic_files_list- List every file in the IC secure vault you're authorized to see: files shared with all IC members, files you uploaded, files you're an explicit grantee of (operators see all). Metadata only — never blob URLs. Each entry: { id, filename, contentType, size, uploadedBy, uploadedAt, visibility ('ic-members'|'grantees'|'private'), label, description, tags, mine, can_manage }. To download one, GET /api/files/<id>/download with your bearer token (or use ic_files_get for the ready URL). Args: none. Required scope: files:read (ic-member+).
ic_files_put(tags, label, filename, grantees, folder_id, visibility, description, content_type, content_base64)- Upload a file (base64) into the IC secure vault and set who can see it. visibility: 'ic-members' (any IC member, default), 'grantees' (only the Clerk user ids you list, plus you + operators), or 'private' (only you + operators). Non-members get access via ic_files_grant (a signed link). Max 25MB per file, 500 files per member. Args: { filename, content_base64, content_type?, visibility?, grantees?: string[], label?, description?, tags?: string[] }. Returns: { ok, id, filename, size, visibility }. Required scope: files:write (ic-member+). Required: filename, content_base64.
ic_files_update(tags, label, file_id, grantees, visibility, description)- Mutate an EXISTING file's visibility / grantees / label / description / tags — you uploaded it, or you're operator. Owner, folder, size, and the underlying bytes can never change here (upload a new file for that). Only the fields you pass are touched; omit a field to leave it as-is. Args: { file_id, visibility?: 'ic-members'|'grantees'|'private', grantees?: string[], label?: string, description?: string, tags?: string[] }. Returns: { ok, file }. Required scope: files:write (ic-member+; only the uploader or an operator). Required: file_id.
ic_folder_create(name, tags, parent, grantees, visibility, description)- Create a folder to group files. Root folder: omit parent. Sub-folder: pass parent (you must own the parent or be operator). visibility: 'ic-members' (default) / 'grantees' (specific Clerk ids) / 'private'. Files inherit access from their folder + ancestors; a folder share-link (ic_folder_grant) admits a non-member to the whole subtree. Args: { name, description?, parent?, visibility?, grantees?, tags? }. Returns { ok, folder }. Required scope: files:write (ic-member+). Required: name.
ic_folder_get(folder_id)- Traverse one folder (or the vault ROOT if folder_id is omitted). Returns { folder, path (breadcrumb), subfolders[], files[] } where each file carries a download_url (GET it with your bearer). Recurse by calling this again with a subfolder's id. This is how you walk a shared folder tree. Args: { folder_id? }. Required scope: files:read (ic-member+).
ic_folder_grant(subject, folder_id, ttl_seconds)- Create a signed, expiring share-link for a FOLDER so a person WITHOUT an IC login can traverse it and download EVERY file in its subtree with ONE link. Only the folder's owner or an operator can share it. The link opens a browsable page; the api_url is the agent-traversable JSON entry (GET /api/folders/shared?grant=). Args: { folder_id, subject?, ttl_seconds? (default 7d, max 30d) }. Returns { ok, folder_id, name, link, api_url, expires_at }. Required scope: files:write (ic-member+). Required: folder_id.
ic_folder_update(name, tags, grantees, folder_id, visibility, description)- Mutate an EXISTING folder's visibility / grantees / name / description / tags — you own it, or you're operator. Owner and parent (its place in the tree) can never change here. Only the fields you pass are touched; omit a field to leave it as-is. Args: { folder_id, visibility?: 'ic-members'|'grantees'|'private', grantees?: string[], name?: string, description?: string, tags?: string[] }. Returns: { ok, folder }. Required scope: files:write (ic-member+; only the owner or an operator). Required: folder_id.
ic_folders_list- List every folder in the IC secure vault you're authorized to see (flat, with parent ids so you can reconstruct the tree). Use ic_folder_get to traverse one. Each entry: { id, name, description, owner, parent, visibility, tags, mine, can_manage }. Args: none. Required scope: files:read (ic-member+).
ic_funko_catalog(kind)- The full catalog of things a Funko Me figure can earn — animation clips, props, skins, stages — with the condition that unlocks each one. No auth required; this is the rules table, not anybody's progress. Use it to explain to a human WHY something is locked, or to show what is worth doing on the floor. An item with no `requires` is granted to every signed-in member. Conditions read as either { signal, gte } (a measurable: commits this week, GLM tokens burned, events attended, days of tenure) or { minTier } (a membership ring). For one member's actual progress against these, call ic_funko_progress. Args: { kind?: 'clip'|'prop'|'skin'|'stage'|'capability' }. Returns: { ok, count, items[{ id, kind, label, blurb?, rarity, requires?, asset? }] }. No auth required.
ic_funko_get(handle)- Fetch a member's published vinyl-figure manifest by handle. PUBLISHED FIGURES ONLY: members are private by default and must opt in. A handle that has not opted in returns exactly the same not_found as a handle nobody ever registered — that is deliberate, and it means you cannot use this tool to test whether a person is a member. Same manifest shape as ic_funko_get_mine (parts not a baked file; `clips` is the unlocked subset; `stats[].value` null means unknown, not zero). The same figure is also available with no MCP client at all: GET https://www.immersivecommons.com/api/funko/m/<handle> (CORS-open, cacheable) — note that route returns the BARE manifest as its body (per contract §7), whereas this tool wraps it as { ok, manifest } like every other MCP tool here. Args: { handle: string }. Returns: { ok, manifest } or { ok:false, error_kind:'not_found' }. Required scope: funko:read. Required: handle.
ic_funko_get_mine- Fetch the caller's OWN vinyl-figure manifest — the parts to render it, the animation clips they have actually unlocked, and the member stats behind those unlocks. Works whether or not the member has published the figure publicly (this is their own token asking about themselves). The figure is composed at runtime from three parts, not one baked file: `parts.body` and `parts.library` are byte-identical for every member and cache once for the whole floor, `parts.head` is per-person. `bakedGlbUrl` appears only if a single-file bake exists and is OPTIONAL FOREVER — never require it. `clips` is the unlocked subset, never the full set: the unlock set is the membership signal. `stats[].value` of null means UNKNOWN (a signal source could not be read), NOT zero — do not render it as 0. Args: {}. Returns: { ok, manifest: { handle, displayName, tier, parts{body,library,head}, bakedGlbUrl?, thumbUrl?, clips[], props[], activeClip, stats[], profileUrl, generatedAt }, publicShare }. Required scope: funko:read.
ic_funko_progress- The caller's OWN unlock snapshot: every catalog item, whether they have earned it, and per-condition progress so you can say '3 more commits' instead of 'locked'. Read `degraded[]` FIRST — it lists the signals that could not be read this pass, and any condition resting on one of those is UNKNOWN, not unmet. Telling a member with 400 commits that they need 5 more because GitHub timed out is the specific failure this field exists to prevent; a progress entry carries `unknown: true` for exactly that case. Args: {}. Returns: { ok, snapshot: { userId, computedAt, signals, granted[], states[{ item, unlocked, progress[{ condition, met, current, target, unknown }] }], degraded[] } }. Required scope: funko:read.
ic_funko_set_public(public_share)- Flip the caller's OWN publicShare switch. TRUE makes their handle, display name, figure parts, unlock set and member stats readable by ANY agent on the internet with no token (via ic_funko_get or a plain GET of /api/funko/m/<handle>); FALSE takes it back, and the endpoint immediately returns the same not_found as an unregistered handle. Default is FALSE — a member is private until they say otherwise, so confirm with your human before turning this on. Reversible either way. Targets the caller's own profile ONLY; there is no argument that names another member. Args: { public_share: boolean }. Returns: { ok, handle, public_share, profile_url }. Required scope: funko:write (ic-member+; live tier re-checked at call time). Required: public_share.
ic_get_my_membership- Returns the calling user's current ring (operator / ic-member / ai-floor / ft-member / public), any pending tier request, and recent tier-history count. Use to check whether the human is already an ic-member before walking them through a tier-request flow. Args: none. Required scope: membership:read.
ic_get_my_workshop_key(request_id)- Retrieve the 5-hour Z.ai Claude-Code key you filed with ic_request_workshop_key, once an IC operator has approved it. Poll with the request_id that ic_request_workshop_key returned. While the operator hasn't approved yet returns { ok:true, status:'pending' } (keep polling). On the FIRST call after approval returns { ok:true, status:'ready', agent_token, bundle } where bundle.copy_paste is the paste-and-go Claude Code setup block. The key is surfaced EXACTLY ONCE and the pickup window is ~15 min after approval, so call again promptly once approved. A second pickup, a lapsed window, or a denied/unknown request returns a terminal status with what to do next. You can only retrieve your OWN request. Args: { request_id }. Required scope: keys:request. Required: request_id.
ic_get_my_zai_key(request_id)- Retrieve the weekly-token Z.ai Claude-Code key you filed with ic_request_zai_key, once an IC operator has approved it. An agent-inbox notification announces approval; this tool is the actual pickup. Poll with the request_id that ic_request_zai_key returned. While unapproved returns { ok:true, status:'pending' } (keep polling). On the FIRST call after approval returns { ok:true, status:'ready', agent_token, bundle } where bundle.copy_paste is the paste-and-go Claude Code setup block. The key is surfaced EXACTLY ONCE and the pickup window is ~15 min after approval, so pick it up promptly. The key itself does not expire (weekly token budget, resets Monday). A second pickup, a lapsed window, or a denied/unknown request returns a terminal status. You can only retrieve your OWN request. Args: { request_id }. Required scope: keys:request. Required: request_id.
ic_get_my_zai_key_usage(request_id)- Report the weekly token usage + remaining budget for the member (weekly-token) Z.ai Claude-Code key you filed with ic_request_zai_key. Poll with the request_id ic_request_zai_key returned (after an operator approved it). Returns { ok:true, weekly_used, weekly_remaining, weekly_cap, multiplier, reset_date } where weekly_used = input+output tokens metered by the IC->Z.ai gateway this week, weekly_cap = base × multiplier, and reset_date is the next Monday (UTC) when the meter rolls over. weekly_used fails soft to 0 if no calls were metered yet or the meter is briefly unreadable. Workshop (5-hour) keys are time-boxed and have NO weekly budget — this returns ok:false for them (check expiry, not usage). You can only read your OWN request. Args: { request_id }. Required scope: keys:request. Required: request_id.
ic_hack_admin_decide_application(eid, note, decision, application_id)- Decide one application. Approving grants the roles that applicant TYPE maps to server-side and consumes a seat — you cannot name a role in this call, which is what makes it safe to hand the admissions desk to a non-operator. An event_admin decides EVERY type, staff included — what an approval may grant is fixed by the table, and no application can ever grant an appointing role (organizer / event_admin); those go through ic_hack_admin_role, operator only. A rejection requires a note; the applicant sees it. `seats_full` on an approval means waitlist them instead. Args: { eid?, application_id, decision: 'approve'|'waitlist'|'reject', note? }. Returns: { ok, application, seats }. Required scope: hack:manage (any tier — the event role is the real gate). Required: application_id, decision.
ic_hack_admin_list_applications(eid, limit, status)- The review queue with everything needed to decide: answers, contact details, and the machine-checked evidence from the applicant's URL. Requires the `event_admin` or `organizer` role ON THIS EVENT — an event_admin runs admissions without being an IC floor operator. Args: { eid?, status? (applied|approved|waitlisted|rejected|withdrawn; default applied), limit? }. Returns: { ok, counts, seats, applications[] }. Required scope: hack:manage (any tier — the event role is the real gate).
ic_hack_admin_phase(eid, phase)- Move the event through PRE -> OPEN -> BUILD -> SUBMIT -> LOCKED -> JUDGING -> RESULTS. One call gates every write surface, so this is the single lever for 'registration closes', 'submissions close', 'results are public'. Moving TO `LOCKED` also freezes every submission record permanently — a later rollback to SUBMIT reopens the window for NEW teams but does NOT unfreeze already-locked ones, so extending a deadline can never silently reopen editing for everyone. Backwards moves are allowed on purpose (deadline extensions are real). Args: { eid?, phase }. Returns: { ok, event, locked_count? }. Required scope: hack:admin (operator), OR hack:manage + the event_admin role on this event. Required: phase.
ic_hack_admin_role(eid, org, email, roles, action, member_id, display_name)- Grant or revoke event roles. This is how judges, sponsors, mentors and volunteers get in — including people who are not IC members at all, addressed by an `ext_...` member id. Grants are ADDITIVE; revoking someone's last role removes them from the roster. Participants and team leads consume a seat; staff do not. Args: { eid?, member_id, roles[], action ('grant'|'revoke'), display_name?, email?, org? }. Returns: { ok, role }. Required scope: hack:admin (operator tier). Required: member_id, roles.
ic_hack_application_form(eid, applicant_type)- Returns the exact questions to answer for one applicant type, so your agent can fill an application without scraping a web form. Each question carries an id, a prompt, a kind (short/long/url/email/bool/choice), whether it is required, and a `why` explaining what the reviewer is actually looking for — answer to the `why`, not just the prompt. Also tells you which roles an approval grants, whether it consumes one of the capped seats, and who decides it. Applicant types: founder, engineer, solo_builder, team, designer, partner_delegate, mentor, judge, sponsor, volunteer, media. Answer keys in ic_hack_apply MUST match the question ids returned here. Args: { eid?, applicant_type }. Returns: { ok, form_version, applicant_type, questions[], grants_roles[], consumes_seat, decided_by }. Required scope: hack:read (any tier). Required: applicant_type.
ic_hack_application_status(eid)- Where your application stands: applied / approved / waitlisted / rejected / withdrawn, plus the reviewer's note when there is one. `waitlisted` means yes-if-a-seat-frees, not no. Args: { eid? }. Returns: { ok, applied, application }. Required scope: hack:read (any tier).
ic_hack_apply(eid, answers, applicant_type)- Submit an application. This does NOT claim a seat: every applicant is reviewed by a human and the seat is only consumed when you are approved, so a full queue never locks out the room. Call ic_hack_application_form first and answer the question ids it gives you. If you supply a product/project URL we fetch it and record which agent surfaces it actually serves (ai-agent.json, MCP, agent-card, llms.txt) for the reviewer — finding none is NOT a rejection, it is a normal starting point, but an inflated claim the probe contradicts is worse than an honest 'none yet'. Re-applying while still pending UPDATES your application rather than creating a second one, so a retry after a timeout is safe. Args: { eid?, applicant_type, answers: { <question_id>: <string> } }. Returns: { ok, application: { application_id, status, evidence[] } } or { ok:false, error:'bad_answers', missing[], invalid[] }. Required scope: hack:register (any tier). Required: applicant_type, answers.
ic_hack_bounty_post(eid, prize, title, sponsor, description)- Publish a sponsor challenge participants can build against. Shows on the event page and in ic_hack_get. Args: { eid?, sponsor, title, description?, prize? }. Returns: { ok, bounty }. Required scope: hack:sponsor + sponsor or organizer role. Required: sponsor, title.
ic_hack_checkin(eid, member_id)- Mark someone as physically present. REFUSES anyone who has not signed the venue NDA — that gate lives here rather than with the volunteer at the badge table, because the venue's requirement is that every person in the building has signed and a human under 9am queue pressure is the wrong place to put that invariant. Idempotent. Args: { eid?, member_id }. Returns: { ok, role }. Required scope: hack:ops + volunteer or organizer role. Required: member_id.
ic_hack_get(eid)- Everything a prospective participant or their agent needs to decide to come: title, dates, venue, current phase, seats total/remaining, whether an NDA is required, the rubric link, and the sponsor bounties posted so far. Args: { eid (default 'anb-hack-01') }. Returns: { ok, event, seats: {total, used, remaining}, bounties[] }. Required scope: hack:read (any tier).
ic_hack_judge_list(eid)- All submissions with their repo, demo, blurb and agent-surface description, plus the scores you have already given. Only works once submissions are locked, so nobody is judged on a moving target. Args: { eid? }. Returns: { ok, submissions[], my_scores[] }. Required scope: hack:judge + judge or organizer role.
ic_hack_judge_score(eid, notes, team_id, criteria)- Record your scores for one team. `criteria` is a map of rubric key to 0..10 (values are clamped, non-numbers rejected rather than coerced). Re-scoring the same team replaces your previous score. Note the standings are ranked by MEAN across judges, not sum, so you are not penalising a team by being one of few who scored it. Your score is advisory input to a human decision, not the decision. Args: { eid?, team_id, criteria: {..}, notes? }. Returns: { ok, score }. Required scope: hack:judge + judge or organizer role. Required: team_id, criteria.
ic_hack_me(eid)- One call that answers 'where do I stand': your event roles, NDA and check-in state, your team and its members, and your submission if you have one. The orienting call for an agent arriving mid-event. Args: { eid? }. Returns: { ok, registered, role, team, submission }. Required scope: hack:read (any tier).
ic_hack_register(eid, org, member_id, display_name, sponsor_visible)- Put a member straight onto the roster as a PARTICIPANT, bypassing the application queue. This is NOT the front door any more: since 2026-08-06 every seat is vetted, so the way in is ic_hack_application_form then ic_hack_apply, and a human decides. This tool is the organizer's override for the case the queue cannot serve — a walk-in at the badge table on day one. Requires the `organizer` role on this event. Registration is separate from ATTENDING: if the venue requires an NDA the person must still call ic_hack_sign_nda or check-in refuses them. Args: { eid?, member_id? (defaults to you), display_name?, org?, sponsor_visible? }. Returns: { ok, role, seats }. Required scope: hack:register (any tier — the organizer role is the real gate).
ic_hack_results(eid)- Team standings ranked by MEAN score across judges, with the judge count alongside each so the sample size is visible rather than hidden inside one number. Organizers and judges can read this from LOCKED onward; everyone else only once the organizer moves the event to RESULTS. Args: { eid? }. Returns: { ok, phase, standings[] }. Required scope: hack:read (any tier).
ic_hack_roster(eid, role)- The attendee list. What you see depends on your role: ORGANIZERS and VOLUNTEERS get the operational view (NDA + check-in state, so the door desk works); SPONSORS get only attendees who explicitly opted in to sponsor visibility, and never NDA or check-in state. Args: { eid?, role? (filter) }. Returns: { ok, roster[], counts }. Required scope: hack:ops for staff, hack:sponsor for sponsors.
ic_hack_sign_nda(eid)- Record that you have signed the venue's NDA. The Cloudflare office requires one from every person in the building, sent 48h ahead; without it the door check-in tool refuses you. Idempotent. Args: { eid? }. Returns: { ok, nda_signed_at }. Required scope: hack:register (any tier).
ic_hack_submit(eid, blurb, title, demo_url, repo_url, folder_id, agent_surface)- Submit (or re-submit) your team's project. Idempotent by team: one submission per team, and calling again overwrites it, which is what 'I fixed the demo link at 2:55' means. `agent_surface` is the field the rubric actually scores — describe what makes the project agent-native (MCP server, agent-readable surfaces, A2A, machine-to-machine auth, agent payments), not just what it does. Once the organizer locks submissions the record freezes and further calls return `locked`. Args: { eid?, title?, blurb?, repo_url?, demo_url?, agent_surface?, folder_id? (a vault folder with slides/video) }. Returns: { ok, submission }. Required scope: hack:submit, and you must be on the team.
ic_hack_team_create(eid, name, looking_for, startup_slug)- Start a team and become its lead. One team per person — leave your current team first. Link `startup_slug` to the IC startup profile you're here to work on, so the weekend's work attaches to something that outlives it. Args: { eid?, name, startup_slug?, looking_for? }. Returns: { ok, team }. Required scope: hack:team, and you must be registered on the event. Required: name.
ic_hack_team_join(eid, team_id)- Join an existing team by id. One team per person, max 6 per team. Args: { eid?, team_id }. Returns: { ok, team }. Required scope: hack:team, and you must be registered on the event. Required: team_id.
ic_hack_team_leave(eid)- Leave the team you're on. If you were the lead, leadership passes to another member rather than orphaning the team; if you were the last member, the team is deleted. Args: { eid? }. Returns: { ok, team }. Required scope: hack:team.
ic_hack_team_list(eid, recruiting_only)- Every team at the event with its name, size, the startup it's working on, and whether it is recruiting plus what it's looking for. Use this to find a team to join rather than asking around the room. Args: { eid?, recruiting_only? }. Returns: { ok, teams[] }. Required scope: hack:read (any tier).
ic_hack_withdraw(eid)- Withdraw. If you were already approved this revokes your roles and frees the seat for someone on the waitlist, which is the polite thing to do the moment you know you cannot come. Args: { eid? }. Returns: { ok, status, freed_seat }. Required scope: hack:register (any tier).
ic_headsets_admin_clear_oos(unit_id)- Operator returns a unit to the available pool. Refuses if the unit has an open incident on it — resolve the incident first (ic_headsets_admin_resolve_incident with verdict 'resolved' or 'absorbed' will also clear OOS automatically as a side effect). Args: { unit_id }. Returns: { ok, message }. Required scope: admin:headsets_review. Required: unit_id.
ic_headsets_admin_force_return(reason, lend_id)- Operator-side close for stuck lends (member unreachable, end-of-day cleanup, etc.). Releases the per-member NX lock so the borrower can lend again. If an open incident exists on the unit, status stays out-of-service even after the force-return. Notes are appended (not overwritten) with operator attribution + reason. Args: { lend_id, reason }. Returns: { ok, message, unit_status }. Required scope: admin:headsets_review. Required: lend_id, reason.
ic_headsets_admin_list_active_lends- Returns every currently-active PICO lend across the fleet, with full borrower attribution. Operator-only. Use to triage 'who has what right now', look for overdue lends, or audit before a force-return. Args: none. Returns: { count, lends: LendRecord[] }. Includes borrower email/telegram (operator scope is the place full PII surfaces; member-level reads strip these). Required scope: admin:headsets_review.
ic_headsets_admin_list_open_incidents(limit)- Returns recent damage / hygiene / loss incidents currently in 'open' status, ready for triage at /floor10/admin/headsets. Operator-only. Each incident: { incident_id, reported_at, unit_id, lend_id, borrower, type, description, photo_present, reporter_name, reporter_role, reporter_contact, status, resolution }. Args: { limit?: number, max 100, default 50 }. Returns: { count, incidents: IncidentRecord[] }. Required scope: admin:headsets_review.
ic_headsets_admin_mark_oos(reason, unit_id)- Operator pulls a unit from rotation. Refuses if the unit is currently lent (force-return first). Appends to the unit's notes with a date stamp + reason. Args: { unit_id, reason }. Returns: { ok, message }. Required scope: admin:headsets_review. Required: unit_id, reason.
ic_headsets_admin_resolve_incident(verdict, resolution, incident_id)- Operator-side incident triage. Verdicts: 'absorbed' (IC eats the cost per waiver §11 good-faith), 'willful-misuse' (member charged), 'resolved' (unit cleared, back to rotation — no charge implied). 'resolved' and 'absorbed' both auto-clear the unit's out-of-service status if it's currently OOS; 'willful-misuse' leaves the unit out (operator decides retirement separately). Resolution note is required (sent into the audit trail). Args: { incident_id, verdict, resolution }. Returns: { ok, message }. Required scope: admin:headsets_review. Required: incident_id, verdict, resolution.
ic_headsets_attest_member(notes, subject_user_id)- Sign off (attest) another ic-member so they can check out a PICO unit. Caller MUST already be attested (operators default, attested members can pass it on). Idempotent — re-attesting refreshes the timestamps. Args: { subject_user_id: string, notes?: string }. Returns: { ok, record }. Required scope: headsets:lend. Required: subject_user_id.
ic_headsets_check_waiver- Returns the calling user's PICO lending waiver state: fresh (signed within 90 days, current version), stale-version (signed but waiver version bumped), expired (TTL elapsed), or missing. Use BEFORE attempting a lend so the agent can route the human to /floor10/headsets/waiver if the waiver isn't fresh. The waiver record stores name/email/phone/telegram/ring at signing; this endpoint returns a SUMMARY (no PII echo) by default. Args: none. Returns: { state: 'fresh'|'stale-version'|'expired'|'missing', version?, signed_at?, expires_at? }. Required scope: headsets:read.
ic_headsets_checkout(unit_id)- Atomically claims a PICO unit for the calling user. Pre-flight: caller must have a fresh waiver (call ic_headsets_check_waiver first if you're not sure). Per-member NX lock prevents double-lending. Returns the new lend_id + due_back_at. Borrower display name + email + telegram are snapshotted from the WAIVER record (not from Clerk live). Args: { unit_id: 'IC1'..'IC8' }. Returns: { ok, lend_id, due_back_at }. Errors include error_kind: 'no_waiver' | 'already_lending' (with existing_lend_id) | 'unit_not_found' | 'unit_not_available'. Required scope: headsets:lend. Required: unit_id.
ic_headsets_get_attestation_status(user_id)- Returns whether a user is attested (signed off to check out PICO units). Defaults to the calling user when user_id is omitted. Operators are attested-by-default and may have no record. Args: { user_id?: string }. Returns: { ok, user_id, is_attested, record? }. Required scope: headsets:lend.
ic_headsets_get_my_lend- Returns the calling user's currently-active PICO lend, or null if they have none. Each member can have at most one active lend at a time (enforced server-side via an atomic SET-NX lock). Use this to answer 'am I currently borrowing a headset?'. Args: none. Returns: { lend: LendRecord | null }. LendRecord fields: lend_id, unit_id, unit_serial, checked_out_at, due_back_at, status, condition_at_checkout, damage_flag. PII fields (email/telegram) are stripped on the MCP path. Required scope: headsets:read.
ic_headsets_get_unit(id)- Fetches the per-unit record for a single PICO unit by id (case-insensitive; IC1..IC8). Returns 404 if the id isn't in the fleet. Use this AFTER ic_headsets_list_inventory if you need fresh status on one unit. Args: { id: string }. Returns: HeadsetRecord. Required scope: headsets:read. Required: id.
ic_headsets_list_inventory- Returns all units in the PICO 4 Ultra Enterprise lending fleet with current status. Same data the /floor10/headsets grid renders. Each record: { id ('IC1'..'IC8'), serial, sku, status ('available'|'lent'|'pending-receipt'|'out-of-service'|'retired'), received_at, notes, qr_url, condition_at_receipt? }. Floor-only policy through 2026-06-14 — units do not leave Floor 10. Args: none. Returns: { count, units: HeadsetRecord[] }. Required scope: headsets:read.
ic_headsets_mark_sop_complete(subject_user_id)- Records that the calling user (must be attested) has walked the named member through the PICO operating SOP. Separate from attestation so the audit log can distinguish 'we ran through SOP' from 'I sign them off.' Typical flow: 1) member signs waiver, 2) call ic_headsets_mark_sop_complete, 3) call ic_headsets_attest_member. Args: { subject_user_id }. Returns: { ok, record }. Required scope: headsets:lend. Required: subject_user_id.
ic_headsets_report_damage(type, unit, photo, lend_id, borrower, description, reporter_name, reporter_role, reporter_contact)- Files an incident on a PICO unit. Anyone with the scope can file (borrower, witness, ops staff). If the unit's current status is 'available', it auto-flips to 'out-of-service' so it isn't re-lent before triage; for 'lent' units the flag rides on the lend record and the unit stays lent until return. If lend_id is supplied, the lend's damage_flag + damage_incident_id are back-filled. Telegram fanout is handled out-of-band by node's ic-notify timer (≤60s page latency). Args: { unit, type, description (20+ chars), reporter_name, reporter_role ('ops-staff'|'borrower'|'member'), reporter_contact, lend_id?, borrower?, photo? (base64 data URL, capped ~5MB) }. Returns: { ok, incident_id }. Required scope: headsets:report_damage. Required: unit, type, description, reporter_name, reporter_role, reporter_contact.
ic_headsets_return(damaged, lend_id)- Closes an active lend. The caller must be the borrower OR an operator. If damaged=true, the unit goes to out-of-service (the operator clears it after triage); otherwise it returns to the available pool. After damaged=true, follow up with ic_headsets_report_damage so the incident is filed with description + (optional) photo. Args: { lend_id, damaged: boolean }. Returns: { ok, unit_status: 'available' | 'out-of-service' }. Required scope: headsets:lend. Required: lend_id, damaged.
ic_headsets_sign_waiver(name, email, phone, telegram, photo_consent, signature_typed)- Records a waiver for the calling Clerk user. 90-day TTL; re-sign required after that or after a waiver version bump. The `ring` field is server-derived from the user's live tier — agents do NOT supply it. Args: { name, email, phone?, telegram?, signature_typed, photo_consent? ('yes'|'no') }. Returns: { ok, record_id, expires_at }. Required scope: headsets:lend. Required: name, email, signature_typed.
ic_health- Probe the MCP surface's four upstream dependencies without firing any real (rate-limited) tool: kv (the floor10 Redis), blob (the last-known-good mirror), rag (the research funnel behind ic_research_ask), and context_source (the Open-Meteo weather feed behind ic_context_get). Each probe reports status 'ok' | 'degraded' | 'down' + latency_ms (+ a note on anything non-ok); the response carries as_of (server ISO time). Probes are timeboxed at ~2s each and run in parallel, so the tool is always fast and NEVER throws. Available to any valid token — no extra scope. Args: none. Returns: { kv, blob, rag, context_source, as_of }.
ic_leaderboard_connect_github(pat)- Verify a GitHub Personal Access Token against api.github.com/user, then store the resulting username on your IC profile. The PAT is DISCARDED after verification — the IC server keeps only your GitHub username + id, then queries commit counts via a server-side PAT during the weekly cron. Use this when the human doesn't want to (or can't) do the Clerk OAuth browser dance. To ALSO count your PRIVATE commits in your total, enable GitHub's private-contributions toggle (web-only — there is no API for it): github.com/<your-username> → 'Contribution settings' button (above your contribution graph) → enable 'Private contributions' (docs: https://docs.github.com/en/account-and-profile/setting-up-and-managing-your-github-profile/managing-contribution-graphs-on-your-profile/publicizing-or-hiding-your-private-contributions-on-your-profile). IC reads only the COUNT of private contributions, never repo names or content, and has no write access to your GitHub. Args: { pat: string }. Returns: { ok, github: { login, id, name?, avatarUrl? }, next_steps: string[] }. Required scope: github:link. Required: pat.
ic_leaderboard_get_board(limit)- Returns the FULL ranked commits leaderboard the FT10 kiosk renders, so an agent never has to scrape the /floor10/commits HTML. Each member carries { rank (1-based), handle, name, commits, private? }. `commits` is the ranking total = public commit contributions PLUS private/restricted contributions folded in (the `private` count is present only for members who enabled GitHub's 'Include private contributions on my profile' toggle — a COUNT only, never repo names or content). Response includes `stale` + `age_min` (vs the ~5min refresh cron) so agents can warn humans if the snapshot is behind. Args: { limit?: number, default 200, max 200 }. Required scope: membership:read.
ic_leaderboard_get_status- Returns the calling user's opt-in flag, linked GitHub username (if any), how the link was made (oauth or agent_pat), and current rank on the rendered snapshot. `this_week` is absent if you aren't on the snapshot yet — the cron rebuilds weekly. Also returns `private_counting: { status: 'active' | 'not_detected', private_count?, how_to_enable, github_settings_path }` — when status is 'not_detected' you can proactively tell the human their private work isn't being counted yet and relay the 10-second fix (it may just mean no private work this week, so don't over-claim the toggle is off). Args: none. Required scope: membership:read.
ic_leaderboard_set_optin(optIn)- Toggle publicMetadata.leaderboardOptIn. Opting IN requires a linked GitHub identity (either Clerk OAuth or our agent-PAT path). Opting OUT is unconditional. Args: { optIn: boolean }. Returns: { ok, optIn, github_username? }. Required scope: leaderboard:manage. Required: optIn.
ic_membership_set_profile(first_name, public_visible, company_website)- Edit the calling user's public-facing profile fields: first name, opt-in visibility, and company website. Company logo is auto-derived from the website at save time (Clearbit + favicon fallback). Re-posting overwrites. Opt-in members are listed publicly on /members and the kiosk; opted-out members are visible to directory:search callers only at their ring or below. Args: { first_name?: string, company_website?: string, public_visible?: boolean }. Returns: { ok, profile }. Required scope: membership:write.
ic_membership_upload_photo(base64, data_url)- Accept a base64-encoded image (PNG / JPEG / WebP / HEIC — anything sharp can decode), server-crop to a 256×256 WebP avatar, store on the calling member's profile. Subsequent calls overwrite. Max raw input 12MB. Args: { data_url?: 'data:image/png;base64,...', base64?: '...' } (one of). Returns: { ok, profile, base64_len }. Required scope: membership:write.
ic_news_get(q, limit, min_velocity)- Returns newagg's velocity-ranked AI news — each item carries url + velocity + summary (plus dek, beat, date, publishedAt, image, focal). This is the RAW aggregator feed (the same firehose that drives the floor10 news kiosk), a DIFFERENT surface from ic_signal_* (which serves THE SIGNAL, the weekly editorial dispatch). The list is already ranked highest-velocity-first; input order is preserved. No auth required. Args: { limit?: number (1-25, default 20), min_velocity?: number (>=1, default 1 — keep only items corroborated by >= this many sources), q?: string (2-80 chars, case-insensitive substring over title + summary) }.
ic_presentations_get(series, session_no)- Fetch a single presentation by its session number (optionally disambiguated by series). Session numbers are VCN-only; non-VCN talks (ClawCamp, standalone Talks) have no session_no — discover those via ic_presentations_list (filter series='ClawCamp'). No auth required. Returns the full ingest-friendly record. Args: { session_no: number, series?: string }. Returns: { scaffold, presentation: { session_no, series, title, date, format, public_url, deployed, speaker?, event?, summary?, content? } } where `content` is the talk's full curated llms.txt distillation (present for decks that ship one — read it instead of fetching the deck). On a miss, an error listing the available { series #session_no } entries. If session_no alone is ambiguous across series, the newest match wins — pass `series` to target one exactly. Required: session_no.
ic_presentations_list(limit, format, series)- List the public archive of presentations given at Immersive Commons events, Vibe Coding Nights (VCN), ClawCamp, and other community talks — newest first, grouped by series. No auth required. NOT to be confused with ic_resources_list (that lists bookable rooms). Use ic_presentations_get for one VCN session's detail. Args: { series?: string (e.g. 'VCN'|'ClawCamp'|'Talk'), format?: 'deck'|'slides'|'video'|'doc'|'link', limit?: number (max 200, default 100) }. Returns: { count, total, series: string[], scaffold, by_series: Array<{ series, presentations: P[] }>, presentations: P[] (flat) } where P = { session_no (number, VCN-only; null for non-VCN talks), series, title, date, format, public_url, deployed, speaker?, event?, summary? }. `scaffold:true` means placeholder data (real manifest not yet synced). `public_url` is a direct view/download link, null if unpublished (local-only).
ic_prints_bed_specs- Published specs for every printer in the Floor 10 farm, so a design tool can size a part to a real build envelope BEFORE submitting it. Each row carries build_volume_mm {x,y,z}, the accepted materials, an operational status, a `verified` flag and a `sources[]` provenance list. HONESTY CONTRACT: any dimension the farm has not published is null, never a guess, and `verified:false` means at least one field is missing or unsourced — do NOT design against an unverified row. `status` is not a live telemetry reading (the web app receives no feed from the farm); 'unknown' is the honest default. Note the auto-slicer only handles PLA, single-quantity, .stl/.3mf/.obj — everything else routes to manual farm-manager review. Args: {}. Returns: { ok, count, printers, verified_count }. Required scope: prints:read (ft-member+).
ic_prints_cancel(note, request_id)- Cancel YOUR OWN print request while it's still pending or accepted (once it's printing, talk to the farm). Args: { request_id, note? }. Returns: { ok, request }. Required scope: prints:submit (ft-member+; submitter only). Required: request_id.
ic_prints_confirm_handoff(note, decision, handoff_id)- Resolve a print handoff a design service staged in YOUR name. Confirming creates the real print request attributed to YOU — it consumes your daily print-submit allowance and your vault quota exactly as if you had submitted it yourself, and the farm reviews it like any other job. Declining closes it with no job. Only the member the handoff names can call this; the brokering service cannot confirm its own handoff. Review `quote` before confirming — that is the term you are agreeing to. Args: { handoff_id, decision: 'confirm'|'decline', note? }. Returns: { ok, handoff, print_job_id? }. Required scope: prints:submit (ft-member+; named member only). Required: handoff_id, decision.
ic_prints_find_by_origin(limit, job_id, service)- Find print jobs a brokering service submitted. Pass service alone to list everything that service has ever put in the queue (newest first), or service + job_id to resolve one of their job ids to the IC print job. THIS IS THE AUDIT SURFACE for brokered work — provenance that cannot be queried is decoration, so this is what makes origin real. READ THE TRUST BOUNDARY: every origin field is a CLAIM BY THE SUBMITTING SERVICE and IC has verified none of it — each record carries ic_verified:false, and `approval_claimed` tells you whether the service even asserted a human review, NOT whether one happened. A job with approval_claimed:false was submitted with no human-review claim at all. Do not treat any of it as IC-attested when deciding whether something goes on a physical machine. Args: { service, job_id?, limit? }. Returns: { ok, count, requests } or { ok, request }. Farm managers only (operators + the farm-crew allowlist) — the scope alone is not enough. Required scope: prints:read (ft-member+, farm-manager identity re-checked). Required: service.
ic_prints_get(request_id)- Fetch one print request by id: status, model file / link, material / color / quantity, and the full status history with manager notes. If a freshly auto-sliced G-code file is ready, the response includes slice_gcode with a download_url (valid 7 days). You must be the submitter (or a farm manager). Args: { request_id }. Returns: { ok, request, slice_gcode? }. Required scope: prints:read (ft-member+). Required: request_id.
ic_prints_handoff_status(handoff_id)- Read one staged handoff by id, or list the handoffs staged in your name. Readable ONLY by the two parties: the brokering service (matched on the exact token that created it) or the member it names. Not readable by operators or farm managers — a handoff is a private term between two parties until it becomes a print job, and the job then carries its own authorization. A pending handoff past its expiry reports as 'expired'. Once confirmed, print_job_id is the pj_ id to follow with ic_prints_get. Args: { handoff_id? } — omit to list the handoffs naming you (member view, newest first). Returns: { ok, handoff } or { ok, count, handoffs }. Required scope: prints:read (ft-member+).
ic_prints_list(limit, queue, include_closed)- List YOUR print requests, newest first. Farm managers can pass queue=true for the whole farm queue (open requests only by default; include_closed=true for full history). Args: { queue?, include_closed?, limit? }. Returns: { ok, count, requests }. Required scope: prints:read (ft-member+; queue view needs farm-manager identity).
ic_prints_submit(color, title, details, file_id, filename, link_url, material, quantity, content_type, content_base64)- File a print request with the Floor 10 print farm. Attach the model ONE of three ways: filename + content_base64 (inline upload, .stl/.3mf/.obj/.step/.stp/.amf/.ply/.gcode/.bgcode/.zip, <=25MB), file_id (a vault file you can read), or link_url (https link to a hosted model, e.g. Printables) — link_url may also accompany either file path. A farm manager reviews every request before anything prints; you'll be notified as it moves (pending -> accepted -> printing -> ready -> collected, or rejected with a note). Args: { title, details? (dimensions / tolerances / purpose), material? (default PLA), color? (default any), quantity? (1..20, default 1), file_id?, filename?, content_base64?, content_type?, link_url? }. Returns: { ok, id, status: 'pending', open_ahead, file_id? }. Rate: 10 requests per caller per UTC day. Required scope: prints:submit (ft-member+). Required: title.
ic_prints_submit_on_behalf(color, quote, title, origin, details, file_id, link_url, material, quantity, source_job_id, target_member_id)- Stage a print you designed FOR an IC member. This does NOT create a print job and does NOT enter the farm queue: it mints a pending HANDOFF that the named member must confirm with their OWN token via ic_prints_confirm_handoff. On their confirm the job is created and attributed to THEM — the member_id you pass is only ever a match predicate, never an identity we write with, so naming a member you have no relationship with just produces a record they can ignore until it expires (7 days). Model transport: link_url (https) or file_id (a vault file the MEMBER can read — final read-authorization is enforced as the member at confirm time, so a file only you can read will fail then). Inline bytes are not accepted. Args: { target_member_id, title, details?, material?, color?, quantity? (1..20), file_id?, link_url?, quote?, source_job_id? }. Returns: { ok, handoff_id, status: 'pending', expires_at, confirm_with }. Rate: 25/broker/UTC day, max 5 pending per member. Required scope: prints:submit_on_behalf (ic-member+). Required: target_member_id, title.
ic_prints_update(note, status, request_id)- Move a print request through the farm lifecycle: pending -> accepted -> printing -> ready -> collected, or reject (from pending/accepted/printing) with a note. Farm managers only — site operators plus the farm crew allowlist; the scope alone is not enough. The requester is notified on every move. Args: { request_id, status: 'accepted'|'printing'|'ready'|'collected'|'rejected', note? }. Returns: { ok, request }. Required scope: prints:manage (ic-member+, farm-manager identity re-checked). Required: request_id, status.
ic_request_tier(note, tier)- Submit a self-declared tier request for the calling user. An IC operator reviews and approves on /floor10/admin/members. Re-posting overwrites the prior pending request. Idempotent. Args: { tier: 'ft-member'|'ai-floor'|'ic-member', note?: string }. Returns: { ok, current_tier, requested_tier, submitted_at }. Required scope: membership:write. Required: tier.
ic_request_workshop_key(note, event_id)- Walk-in flow: request a 5-hour Z.ai Claude-Code key tied to an upcoming IC event. The tool fetches the upcoming-events list SERVER-SIDE, so you only need the `keys:request` scope (not events:read_upcoming). Pass `event_id` = the event's Luma URL (call without it first to see the eligible list). An IC operator approves before the key mints. Args: { event_id?: string, note?: string }. Returns the eligible event list when `event_id` is omitted or unmatched; otherwise { ok, request_id, status:'pending' }. Required scope: keys:request.
ic_request_zai_key(note, multiplier)- ic-member flow: request a weekly-token Z.ai Claude-Code key. Pick a multiplier (1/2/5/10/20× of the base weekly token allowance); an operator approves (and may adjust the multiplier). The minted key resets its token meter every Monday and never expires. Args: { multiplier?: 1|2|5|10|20 (default 1), note?: string }. Returns { ok, request_id, status:'pending', multiplier }. Required scope: keys:request.
ic_research_ask(k, sources, question)- Query the Immersive Commons research RAG corpus (papers + ingested YouTube). Returns top-k chunks with similarity scores and source links. The query text is forwarded to a server-side RAG proxy (supercommons2 via Tailnet Funnel) and NEVER logged on the IC side — privacy contract. Use this for literature lookups, finding related work, surfacing citations the floor has already ingested. Args: { question: string (<=500 chars), k?: number (1-50, default 10), sources?: ('paper'|'book')[] (default ['paper']) }. Returns the upstream RAG response shape — typically { results: [{ paper_id, title, similarity, snippet, link }, ...] }. Required scope: research:query. Required: question.
ic_research_submit(url, note)- Queue a URL (paper, blog post, YouTube video) for operator-reviewed ingest into the supercommons2 RAG corpus. The submission is queued in KV with status 'pending' — an IC operator triages and the sc2-side ingest worker picks up approved entries. Returns immediately with the submission id; this is queue + ack, NOT live ingest. Subsequent calls with the same URL create a new queue entry (no dedupe at v1; operator dedupes on triage). Args: { url: string, note?: string }. Returns: { ok, id, status: 'pending' }. Required scope: research:submit. Required: url.
ic_resources_book(email, end_iso, purpose, start_iso, resource_id)- Queue a booking envelope for life-side processing — Ray's life repo (kernel.frontier_tower for rooms, internal queue for printers) reconciles against the authoritative booking system. Returns 'queued', not 'confirmed.' Rate-limited 10/token/UTC day; 30-day dedupe on (resource_id, user, start_iso). Args: { resource_id: string, start_iso: string, end_iso: string, email: string, purpose?: string }. The agent MUST supply email explicitly — there's no session-derived default on the MCP path (trust boundary, same as ic_events_rsvp). Required scope: resources:book. Required: resource_id, start_iso, end_iso, email.
ic_resources_list- Returns the IC resources roster (3D printers, conference rooms, etc.) with status flags and bookability. Same data the public kiosk renders, plus a staleness gauge. Args: none. Required scope: resources:read.
ic_rooms_add_channel(channel, room_id, channels)- Add one or more NEW channels to a LIVE room at runtime — the channel analog of runtime role-add. Only a SEATED member of the room may add (you can't reshape a room you're not in). Channels are lightweight tags on the room's single committed log: after adding, ic_rooms_send / ic_rooms_read with channel:<name> work IMMEDIATELY. (The richer Cotal native mesh needs a fresh room.py --native attach to mint a cred that includes the new channel — noted in the response's remint_hint; the MCP coordination surface has no such step.) Args: { room_id: string, channel?: string (single add, e.g. 'design'), channels?: string[] (batch add, e.g. ['design','research']) — pass one of the two }. Returns: { ok, reason ('added' | 'already_present'), channel, channels (the room's full channel set after the add), remint_hint } for a single add, or { ok, results, channels } for a batch. Failure reasons: not_a_participant / bad_channel / too_many_channels / not_live. Required scope: rooms:join (ic-member+). Required: room_id.
ic_rooms_create(roles, channels, turn_timeout_s, role_assignments)- Open a LIVE multi-agent room and get its room_id back — the self-service create path (no SSH, no repo). You declare the seats (roles) and who holds them; YOU must hold one (you can't open a room you're not in). Seats assigned to other members are INVITATIONS — a seat map never acts on anyone's behalf; each member still uses their own token to join/post. The room is ready for turns immediately. Args: { roles: string[] (1+ seat names, e.g. ['coder','tester']), role_assignments: Record<role, member_id> (must include your own member_id on some seat), turn_timeout_s?: number (default 7200), channels?: string[] (extra channels beyond the implicit 'general', e.g. ['judges','website'] — one committed log, channel is a tag on each turn) }. Returns: { ok, room_id, roles, role_assignments, created_by, channels }. Other members find it via ic_rooms_list and take an open seat via ic_rooms_join. Required scope: rooms:join (ic-member+). Required: roles, role_assignments.
ic_rooms_join(role, create, room_id, ack_disclosure)- Claim a DECLARED-but-open seat in a live room with your own identity. You must acknowledge the room's plaintext-mesh disclosure (ack_disclosure:true) — #work messages and DMs are plaintext to the IC operator and who-talked-to-whom is observable. Set create:true only to add a brand-new role not yet declared (default false = claim an existing open seat). Args: { room_id: string, role: string (from ic_rooms_list open_seats), ack_disclosure: boolean, create?: boolean }. Returns: { ok, role, member_id, role_assignments } on success; { ok:false, reason } on unknown_role / role_taken / not_live / disclosure_required. Then coordinate with ic_rooms_send / ic_rooms_read. Required scope: rooms:join (ic-member+). Required: room_id, role, ack_disclosure.
ic_rooms_list- List the live agent-rooms you can see, with each room's seats, which are OPEN (unassigned, claimable), who's in, and whether you're already a member. Use it to find a session to join. Args: none. Returns: { ok, rooms: Array<{ room_id, roles, open_seats, members, mine, created_at, channels }> } (newest first; channels defaults to ['general'] for a single-channel room). Take an open seat with ic_rooms_join. Required scope: rooms:join (ic-member+).
ic_rooms_read(since, channel, room_id)- Read a room's committed turns from a cursor — the durable catch-up read, so a late joiner (or any poll) gets the full prior history. Args: { room_id: string, since?: number (stream seq to read from, default 0 = all), channel?: string (filter to one channel tag; next_since still tracks the room's GLOBAL cursor, not a per-channel one) }. Returns: { ok, room_id, state, turns: Array<{ role, member_id, content, at, seq, channel }>, next_since } — pass next_since back to page forward. Readable on live AND torn-down rooms (the log outlives the mesh). Required scope: rooms:join (ic-member+). Required: room_id.
ic_rooms_send(role, channel, content, room_id)- Commit one turn to a room's durable coordination log, as one of YOUR seats. This is the trust-attributed record every member reads (the broker binds your verified member_id to the turn). Args: { room_id: string, role: string (a seat you hold), content: string, channel?: string (default 'general'; must be one of the room's declared channels) }. Returns: { ok, seq } on 202; { ok:false, reason } on wrong_role / role_unassigned (join first) / unknown_channel / rate_limited. Read peers' turns with ic_rooms_read. Required scope: rooms:join (ic-member+). Required: room_id, role, content.
ic_signal_get_issue(slug)- Fetch one issue by slug. Returns the full tree: beats[] (code/label/kicker/storyIds), stories[] (headline/dek/body/image/feature/meta), datespan, classification, published. No auth required. Args: { slug: string (e.g. "issue-05") }. Required: slug.
ic_signal_get_latest- Convenience tool — returns the most-recent issue summary (same shape as one element of ic_signal_list_issues.issues[]). No auth required. Args: none.
ic_signal_get_story(slug, story_id)- Fetch one story by (issue slug, story id). The story id is the kebab-case slug stored on each story (e.g. "grok-build", "shai-hulud-2"). Returns the story tree including body paragraphs, feature card, image, and source citations. No auth required. Args: { slug: string, story_id: string }. Required: slug, story_id.
ic_signal_list_issues(limit)- List issue summaries for THE SIGNAL, Immersive Commons' weekly AI intelligence dispatch. Newest first. No auth required. Args: { limit?: number (max 50, default 10) }. Returns: { issues: Array<{ slug, number, label, classification, title, dek, datespan, published, story_count, beat_count, html_url, markdown_url }> }.
ic_signal_search(q, limit)- Substring search across every published SIGNAL issue. Matches on issue title + dek, beat label + kicker, story headline + dek + body. Case-insensitive. Returns ranked hits with a snippet + the slug + (when matched in a story) story_id. No auth required. Args: { q: string (2-120 chars), limit?: number (max 50, default 10) }. Required: q.
ic_startup_list- List every seeded startup with { slug, name, tagline, bound }, name-sorted. Use this to DISCOVER a valid slug for ic_startup_request_ownership: `bound: false` is UNBOUND; `bound: true` already has at least one owner. Multi-owner: a startup can have several co-founders, so you CAN still file a claim against a `bound: true` slug if you are a DIFFERENT co-founder (it queues for additive operator approval) — only a slug you ALREADY own rejects. Mirrors GET /api/startups and the web member's claim dropdown. Required scope: startup:edit (ic-member+). No signature required.
ic_startup_post_news(url, slug, title, source)- Append a SINGLE STRUCTURED PLAIN TEXT news item (title <=100, optional link, optional source) to your startup's profile. Content auto-publishes (no review queue). NO HTML — the title is plain-text defanged, the link is URL-validated. Newest-first; the list is capped at 8 items (the oldest is dropped to make room). Only the BOUND FOUNDER (clerk_user_id ownership) or an operator (admin:ownership_review) may post. AGENT TOKENS MUST BE SIGNATURE-ENFORCED. Returns { ok, item, news_count }. Required scope: startup:edit. Required: slug, title.
ic_startup_request_ownership(slug, agreement_accepted)- File a PENDING request to be bound as the FOUNDER of a seeded startup slug. This does NOT bind or approve anything — it enqueues an ownership request into the operator review queue at /floor10/admin/ownership; an operator approves it (ic_admin_approve_ownership) and only then is the founder bound (granting edit + news-post rights). Mirrors POST /api/startups/[slug]/claim exactly. You MUST accept content responsibility (`agreement_accepted: true`) — posted news auto-publishes with no per-post review, you are responsible for it. Discover valid slugs via ic_startup_list (entries with `bound: false` are claimable). The slug must already exist (seeded from data/startups.ts) AND be unbound — claiming an already-bound slug is rejected with `error: "already_bound"` (file feedback at /feedback for an operator rebind instead). Re-requesting the same slug coalesces (overwrites your prior pending request). Returns { ok, request_id, slug, startup_name } or a clean rejection (unknown slug / already_bound). Required scope: startup:edit (ic-member+). A signature is NOT required (unlike the founder write tools). Required: slug.
ic_startup_update_profile(name, news, slug, tagline, website, public_visible)- Read-modify-write your startup's public profile: name (<=100), tagline (<=160), website (URL — refreshes the favicon fallback), public_visible, and/or the full news list (<=8 STRUCTURED PLAIN TEXT items, newest-first; replaces the list). NO HTML anywhere — text is plain-text defanged, not HTML-sanitized. The slug is immutable + must already exist (seeded from data/startups.ts). Only the BOUND FOUNDER (clerk_user_id ownership) may write, or an operator (admin:ownership_review) override. AGENT TOKENS MUST BE SIGNATURE-ENFORCED (a bearer-only token is rejected). Omitted fields are left unchanged. Returns { ok, profile }. Required scope: startup:edit. Required: slug.
ic_token_verify(token)- Verify an IC member's agent token that YOUR service accepted, without spending that member's rate budget. *** DO NOT VERIFY BY HTTP STATUS CODE. *** IC's agent surface returns HTTP 200 with an in-band error envelope for an INVALID or absent token (e.g. {ok:false, error_kind:'no_token'}) — it does NOT return 401. Any check of the form `if (response.ok) tokenIsValid = true` therefore ADMITS EVERY FORGERY and fails OPEN. That is true of this tool too: a forged token gets HTTP 200 here. Validity is the `status` field in the BODY and nothing else. READ `status`, WHICH IS THREE-VALUED: 'valid' | 'invalid' | 'indeterminate'. Do NOT branch on `!valid` — `valid` is null when status is 'indeterminate'. 'indeterminate' (rate_limited / backend_unavailable / internal_error) means WE could not answer; it is NOT a rejection, so a rate-limited but perfectly good member must not be refused on it. Retry with backoff, and NEVER write an indeterminate result into a positive cache — otherwise anyone can manufacture a 'valid' verdict by DoSing the verifier. SCOPE DISCLOSURE IS INTERSECTED with your own token's scopes — you learn only which of YOUR capabilities the subject also holds, and scopes_filtered tells you the list was narrowed; it is a floor on their capability, never the whole of it. status:'valid' means the token is live and unrevoked, NOT that the bearer string alone can act: if requires_signature is true the token also needs an RFC 9421 signature per request. Verification never bumps the subject's rate counter or last_used_at, and never echoes the token back — key any cache of your own on a hash, never the raw token. Args: { token }. Returns: { ok, status, valid, member_id?, member_name?, tier?, scopes?, scopes_filtered?, token_prefix?, requires_signature?, sandbox?, reason? }. reason is malformed|unknown|revoked|no_scopes when status='invalid', and rate_limited|backend_unavailable|internal_error when status='indeterminate'. Rate: 200 verifications per calling token per UTC day. Required scope: agent:token:verify (ft-member+). Required: token.
ic_transcribe_get(job_id)- Fetch the result of a DONE transcription job: the markdown + JSON transcript file ids (download with ic_files_get) plus metadata (language, num_speakers, duration, segments). Small markdown transcripts (<=50KB) are inlined as text. If the job isn't done yet this returns not_ready with the current status — poll ic_transcribe_status instead. You must be the submitter (or an operator). Args: { job_id }. Returns: { ok, job_id, result, transcript_md? }. Required scope: transcribe:read (ic-member+). Required: job_id.
ic_transcribe_list(limit)- List YOUR recent transcription jobs, newest first (expired jobs are pruned). Args: { limit? (max 20, default 20) }. Returns: { ok, count, jobs }. Required scope: transcribe:read (ic-member+).
ic_transcribe_status(job_id)- Get one transcription job by id: its status (queued / processing / done / error), source, timing, attempts, and — when done — the result file ids + metadata (also fetchable with ic_transcribe_get). You must be the submitter (or an operator). Poll no more than once per minute. Args: { job_id }. Returns: { ok, job }. Required scope: transcribe:read (ic-member+). Required: job_id.
ic_transcribe_submit(file_id, language, audio_url, num_speakers_hint)- Queue an audio file for offline transcription + speaker diarization by IC's GPU worker. Provide EXACTLY ONE source: a file_id you uploaded via ic_files_put (audio <=25MB) OR an https audio_url. Results (a markdown transcript + a JSON with per-speaker segments) land in the file vault next to the source; poll ic_transcribe_status no more than once per minute, then read the transcript with ic_transcribe_get. Args: { file_id?, audio_url?, language? (BCP-47 hint, e.g. 'en'), num_speakers_hint? (1..10) }. Returns: { ok, id, status: 'queued', queue_position }. Rate: 5 submissions per token per UTC day. Required scope: transcribe:submit (ic-member+).
Last successful function declaration observed on . Source: https://www.immersivecommons.com/api/mcp. We list what the server declared; we do not call any of these functions.
Endpoint status observed on . Source: https://www.immersivecommons.com/api/mcp.
Signals
These are separate measurements of different things. They are deliberately not combined into one score, because a popularity number that mixes website traffic with saves and stars cannot be checked or acted on.
| Signal | Value | What it measures | Window | Observed | Source |
|---|---|---|---|---|---|
| GitHub stars | 0 | Number of GitHub accounts that bookmarked this repository since it was created. It is a bookmark count, not installs, not active users and not quality. | cumulative, all time | GitHub | |
| Last commit | 2026-07-20 | Date of the most recent push to any branch. This is the strongest cheap indicator of whether the project is still maintained. | point in time | GitHub | |
| Open issues | 0 | Open issues plus open pull requests, as GitHub counts them together. A high number can mean an active project or an abandoned one. | as of fetch | GitHub | |
| Latest published version | 1.0.0 | Latest version string the maintainer published to the registry. | as of fetch | Model Context Protocol | |
| Registry record last updated | 2026-07-18 | When the registry record was last updated by its maintainer. | point in time | Model Context Protocol | |
| License | MIT | Licence GitHub detected in the repository. Detection can be wrong; the LICENSE file is authoritative. | as of fetch | GitHub | |
| First listed in the MCP Registry | 2026-07-18 | Date this server was first published to the official MCP Registry. Not a usage or quality measure. | point in time | Model Context Protocol | |
| repository status | active | The repository exists on GitHub and is not archived. This says nothing about how recently it was worked on. | as of fetch | GitHub | |
| mcp tools declared | 180 tools | Number of functions the server itself declared when asked to list them. This is what the server offers an agent, not a measure of how well any of them work. | as of probe | www.immersivecommons.com | |
| mcp endpoint status | ok | The server listed 180 functions when asked. | as of probe | www.immersivecommons.com |
Where to get it
Related, by what their authors tagged them
-
io.github.cyanheads/mcp-ts-core
— last commit 2026-08-02, shares agent-native
Agent-native TypeScript framework for building MCP servers with declarative definitions.
-
io.github.cyanheads/mcp-ts-template
— last commit 2026-08-02, shares agent-native
TypeScript template for building MCP servers with declarative tooling, observability, and auth.
-
Agentry.sh Observability
— last commit 2026-07-13, shares agent-native
Canonical Agentry discovery for coding agents: analytics, errors, deploys, and automation.
-
Hashlock Markets
— last commit 2026-08-03, shares agent-native
Non-custodial cross-chain OTC for AI agents: sealed RFQ, negotiation, HTLC atomic swaps. Testnet.
-
Soma
— last commit 2026-08-06, shares openapi
RMCP runtime for provider-backed agents with CLI, REST, HTTP MCP, plugins, and scaffold support.
-
Myagi - Open Agent Registry
— last commit 2026-08-03, shares openapi
Score any website's AI-agent readiness. Open Agent Registry scanner + platform tools.
-
cn.housingsentinel/housing-sentinel
— last commit 2026-07-16, shares openapi
中国12城官方房产成交数据与进攻/防守买卖信号 MCP。新用户免费试用3天(深圳)。Housing data & signals for 12 Chinese cities.
-
co.servicegraph.mcp/servicegraph
— last commit 2026-06-02, shares openapi
Datasets for founders: directories, newsletters, and agencies, with metrics attached.
-
TempGuru Event Staffing
— last commit 2026-08-05, shares openapi
Plan, price, and request quotes for W-2 event staff across 345 US/CA markets; rates and compliance.
-
DOOMSCROLLR
— last commit 2026-05-27, shares openapi
Build owned-audience websites: pages, posts, products, subscribers, ShopMy/Shopify imports.
These share tags the maintainers applied themselves, such as agent-native, openapi. Common tags like "mcp" or "ai" are ignored for this: agreeing with six hundred other projects is not a similarity.
This is not a recommendation and not a test result. It is a map of what the authors said their work is about.
How the author describes it
Topics the maintainer set on GitHub: agent-native, agent-skills, ai-agents, immersive-commons, immersivecommons, mcp, model-context-protocol, openapi.
This record as data
Every field on this page, with its source and observation date, is in the catalog JSON. Fetch the whole kind at once instead of parsing this HTML.
GET /api/v1/entries/mcp_server.json