# Immersive Commons (remote · www.immersivecommons.com) Members-run AI builder space on Floor 10, Frontier Tower SF. 138 tools: events, news, directory. - Trust score: 70/100 (medium) - Change this week: +6 - Registry status: active - Liveness: live - Owner verified: no - Last scored: 2026-08-03 ## Components - remote · `www.immersivecommons.com`: 70/100 (this document), [markdown](https://verifymcp.io/servers/com-immersivecommons-floor10/api-mcp.md), [page](https://verifymcp.io/servers/com-immersivecommons-floor10/api-mcp) ## Channel facts - Endpoint: `https://www.immersivecommons.com/api/mcp` - Transports: `streamable-http` - Auth: `none` - Version: `1.0.0` ## Trust breakdown How this component scores in each security and reliability category. Every signal is checked automatically against the live server, and we only credit what we can confirm. Scores are 0–100 per category. Scoring method: https://verifymcp.io/docs/scoring (what has changed: https://verifymcp.io/docs/scoring/changelog) Scored 2026-08-03. - **Endpoint Security**: 66/100 - The endpoint's TLS certificate is valid, in date, and uses a strong key. - Authorisation check failed: no authorisation is required to call this server, and it exposes a tool marked destructive (ic_admin_reject_highlight). - HTTPS is enforced; there's no plaintext access path. - The HSTS (Strict-Transport-Security) header is present. - DNSSEC is configured correctly; the domain's records validate against the full chain to the root. - **Transport & Reachability**: 100/100 - Verified streamable-http transport via a live MCP handshake. - **Schema Quality & AI Usability**: 74/100 - 100% of prompts and resources have a non-trivial description (not blank, and not just the item's name). - AI-judged instruction clarity (good). - Context-footprint check failed: tool/resource definitions use about 28837 tokens (~181/item across 159 items; 156 tools + 3 resources), over budget; trim descriptions and params. - Usage-examples check failed: none of the tools include examples. - **Stability & Change Management**: 27/100 - Stability observed for 8 of 30 days with no destabilising changes; credit accrues until the full window elapses. - **Tool Coverage**: 93/100 - 100% of tools have a non-trivial description (not blank, and not just the tool's name). - 80% of tool parameters carry a description. - **Capabilities**: 100/100 - Implements a supported MCP spec version (2025-11-25); the latest is 2026-07-28. - Supports UI / widget rendering. ## Install ### Claude ```bash claude mcp add --transport http com-immersivecommons-floor10 https://www.immersivecommons.com/api/mcp ``` ### Codex ```toml [mcp_servers.com-immersivecommons-floor10] url = "https://www.immersivecommons.com/api/mcp" ``` ### opencode ```json { "$schema": "https://opencode.ai/config.json", "mcp": { "com-immersivecommons-floor10": { "type": "remote", "url": "https://www.immersivecommons.com/api/mcp", "enabled": true } } } ``` ### OpenClaw ```bash openclaw mcp add com-immersivecommons-floor10 --url https://www.immersivecommons.com/api/mcp --transport streamable-http ``` ### Hermes ```yaml mcp_servers: com-immersivecommons-floor10: url: "https://www.immersivecommons.com/api/mcp" ``` ### Other ```json { "mcpServers": { "com-immersivecommons-floor10": { "type": "http", "url": "https://www.immersivecommons.com/api/mcp" } } } ``` The mcpServers block is a cross-client convention. Remote transports vary, so check your client's docs. ## Changelog Every change recorded for this component, newest first. Days that predate change tracking, or that we cannot explain, say so: "we were watching and nothing happened" and "we were not watching" are different claims. ### 2026-08-03 (score 70, +1) - [functional regression] Tool coverage: 87% → 80% - [functional] New tool “ic_hack_results” - [functional] New tool “ic_hack_roster” - [functional] New tool “ic_hack_sign_nda” - [functional] New tool “ic_hack_submit” - [functional] New tool “ic_hack_team_create” - [functional] New tool “ic_hack_team_join” - [functional] New tool “ic_hack_team_leave” - [functional] New tool “ic_hack_team_list” - [functional] New tool “ic_hack_admin_phase” - [functional] New tool “ic_hack_admin_role” - [functional] New tool “ic_hack_bounty_post” - [functional] New tool “ic_hack_checkin” - [functional] New tool “ic_hack_get” - [functional] New tool “ic_hack_judge_list” - [functional] New tool “ic_hack_judge_score” - [functional] New tool “ic_hack_me” - [functional] New tool “ic_hack_register” ### 2026-08-02 (score 69, +1) No change was recorded against any check on this day. Stability & Change Management went from 20 to 23. That category is still filling its 30-day observation window: 6 days of observed history at the previous scan, 7 at this one. The score rises as the window fills, whether or not the server changes. ### 2026-08-01 (score 68, +1) - [security] Tool “ic_capabilities” rewrote its description, which is the text the model reads ### 2026-07-31 (score 67, +1) - [functional] We updated how we score, so this day's move reflects our rubric, not a change to the server ### 2026-07-30 (score 66, +1) - [functional] We updated how we score, so this day's move reflects our rubric, not a change to the server ### 2026-07-28 (score 65, +1) No change was recorded against any check on this day. Stability & Change Management went from 3 to 7. That category is still filling its 30-day observation window: 1 days of observed history at the previous scan, 2 at this one. The score rises as the window fills, whether or not the server changes. ### 2026-07-27 (score 64, +1) - [functional] We updated how we score, so this day's move reflects our rubric, not a change to the server ### 2026-07-26 (score 63) First indexed and scored. ## MCP tools (156) ### `floor10_get_my_floor_member` (~59 tokens) Get my floor-member info 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 }. ### `ic_capabilities` (~241 tokens) What can I do here? (tool catalog + reachability for THIS token) 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:'). 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_health` (~162 tokens) Cheap dependency health probe (KV / Blob / RAG / weather) 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 }. ### `floorcast_my_roles` (~116 tokens) What can this token do on its floor (per-tenant 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_effective_features` (~138 tokens) Which feature modules are LIVE on this floor (resolved) 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_set_feature_enabled` (~193 tokens) Toggle a feature module ENABLED on this floor (Floor-Admin) 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. Input parameters: - `enabled` (boolean, required): true to enable, false to disable. - `module` (string, required): Module id (one of the 8 enum modules). ### `floorcast_set_feature_availability` (~212 tokens) Set a feature module AVAILABLE on this floor (Super-Admin) 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 }. Input parameters: - `available` (boolean, required): true to make available, false to remove. - `module` (string, required): Module id (one of the 8 enum modules). ### `floorcast_set_ai_policy` (~171 tokens) Set the AI-curation policy list on this floor (Floor-Admin) 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 }. Input parameters: - `policies` (array, required): The AI-curation policy list to persist on this floor. ### `floorcast_preview_ai_curation` (~90 tokens) Preview what the AI would surface on this floor (read-only) 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_run_ai_curation` (~135 tokens) Run AI curation now on this floor (Floor-Admin, consequential) 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. ### `floor10_list_my_pending` (~64 tokens) Pending highlights queue (count) 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 }. ### `ic_admin_list_pending_highlights` (~159 tokens) List pending MEMBERS WIRE highlights (operator) 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. Input parameters: - `detail` (string): Response weight. 'full' (default) returns every review field per row; 'summary' trims each row to { id, member_name, action, event_title, date } for cheap queue triage. ### `ic_admin_approve_highlight` (~93 tokens) Approve a pending highlight, publish to the wire (operator) 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. Input parameters: - `id` (string, required): The pending highlight id to approve (the submission slug). ### `ic_admin_reject_highlight` (~75 tokens) Reject a pending highlight (operator) Drop a pending highlight from the moderation queue with an optional reason and write an audit entry. Does not publish. Scope: admin:highlights_review. Input parameters: - `id` (string, required): The pending highlight id to reject (the submission slug). - `reason` (string): Optional moderator note, recorded in the audit log. ### `floor10_submit_highlight` (~360 tokens) Submit a highlight to the moderation queue 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. Input parameters: - `action` (string, required): Verb-clause completing " ". Lowercase. E.g. "spoke at", "hosted", "demoed at". - `date` (string, required): Display ("MAY 08") or ISO date. - `dek` (string, required): News-wire third-person, 1-2 sentences. No editorial verbs. No first person. No fabricated quotes. - `event_title` (string, required) - `event_url` (string) - `id` (string, required): Slug pattern YYYY-MM-DD--. Lowercase, alphanumeric + hyphens. - `image_focals` (object): Optional sparse map of subject focal points in [0, 1] coords (top-left origin). - `images` (array, required): Public URLs only (not base64). Candids first, posters / Luma covers last. Lead card cycles through these. - `member_id` (string): Slug from data/members.yaml. The token attributes the submission server-side regardless. - `member_name` (string, required): Display name as it should appear on the card. - `stats` (array): Convention: RSVPS / ORGANIZATION / ROLE. ### `floorcast_push` (~308 tokens) Push a highlight to your floor (policy-routed) 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. Input parameters: - `action` (string, required) - `date` (string, required) - `dek` (string, required) - `event_title` (string, required) - `event_url` (string) - `id` (string, required) - `image_focals` (object) - `images` (array, required) - `member_id` (string) - `member_name` (string, required) - `stats` (array) ### `floorcast_unpush` (~139 tokens) Retract your OWN pending highlight 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 }. Input parameters: - `id` (string, required): The pending highlight id to retract. ### `floor10_list_claimable_events` (~232 tokens) List events I could write a highlight about 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. Input parameters: - `limit` (integer): Default 25; max 100. - `status_filter` (array): Optional. Filter to one or more statuses. E.g. ["checked_in","attended"] for "really went". Default: all statuses (incl. "invited" so hosts see their own events). ### `floor10_upload_image` (~262 tokens) Upload an image to the IC photo store 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//. 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 }. Input parameters: - `data_url` (string): Inline data URL ("data:image/jpeg;base64,..."). Use for screenshots / small captures the agent generated locally. Capped at the same 8 MB ceiling; base64 has ~33% overhead so practical max is ~6 MB o… - `url` (string): Public URL of an image to fetch and re-host. Recommended path. http(s) only; localhost / cloud-metadata addresses are blocked. ### `floor10_extract_event_metadata` (~102 tokens) Extract event metadata from a 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. Input parameters: - `url` (string, required) ### `ic_get_my_membership` (~73 tokens) Get my membership (tier + pending request) 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_request_tier` (~142 tokens) Request a tier (membership ring) upgrade 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. Input parameters: - `note` (string): Optional context for the operator (e.g. why this ring fits). - `tier` (string, required): The ring you want to claim. 'operator' is not self-requestable — it's operator-assigned only. ### `ic_admin_list_pending_tier_requests` (~135 tokens) List pending membership-tier requests (operator) 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_members` (~287 tokens) List IC members / accounts (operator) 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. Input parameters: - `limit` (integer): Page size (default 200). - `offset` (integer): Page offset (default 0). - `q` (string): Case-insensitive substring match on name / email / user_id. - `tier` (string): Filter the page to accounts currently at this ring. ### `ic_admin_approve_tier_request` (~294 tokens) Approve a pending membership-tier request (operator) 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. Input parameters: - `confirm` (boolean): Set to true to actually mutate. When false / omitted, returns a dry-run preview that does NOT change state and does NOT count against the daily rate limit. - `reason` (string): Optional note recorded in the audit trail. - `tier` (string): Optional override. If omitted, approves the user to the tier they requested. 'operator' is approvable here even though it isn't self-requestable. - `user_id` (string, required): Clerk user_id of the pending requester. ### `ic_admin_deny_tier_request` (~233 tokens) Deny a pending membership-tier request (operator) 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. Input parameters: - `confirm` (boolean): Set to true to actually mutate. When false / omitted, returns a dry-run preview that does NOT change state and does NOT count against the daily rate limit. - `reason` (string): Optional note. Recorded in the audit trail and shown to the requester on their /membership page. - `user_id` (string, required): Clerk user_id of the pending requester. ### `ic_admin_list_pending_events` (~337 tokens) List pending member-event-request drafts (operator) 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. Input parameters: - `audit_tail` (integer): How many recent decisions to include. Default 12; max 500. - `detail` (string): Response weight. 'full' (default) returns every pending field per row incl. description + the nested Luma-shaped request; 'summary' trims each pending row to { id, title, when, source, submitted_at }… ### `ic_admin_approve_event` (~339 tokens) Approve a pending member-event-request draft (operator) 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. Input parameters: - `confirm` (boolean): Set to true to actually mutate. When false / omitted, returns a dry-run preview that does NOT change state and does NOT count against the daily rate limit. - `id` (string, required): The pending event id to approve — the draft slug (e.g. 'demo-night-a1b2c3'), as returned by ic_admin_list_pending_events / ic_events_request. ### `ic_admin_reject_event` (~246 tokens) Reject a pending member-event-request draft (operator) 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. Input parameters: - `confirm` (boolean): Set to true to actually mutate. When false / omitted, returns a dry-run preview that does NOT change state and does NOT count against the daily rate limit. - `id` (string, required): The pending event id to reject — the draft slug. - `reason` (string): Optional moderator note, recorded in the audit log. ### `ic_request_workshop_key` (~194 tokens) Request a 5-hour workshop Claude-Code key (public) 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. Input parameters: - `event_id` (string): The upcoming event you're attending (its Luma URL, e.g. https://luma.com/). Omit to list eligible events first. - `note` (string): Optional context for the operator reviewing the request. ### `ic_get_my_workshop_key` (~197 tokens) Pick up YOUR approved workshop key (poll after requesting) 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. Input parameters: - `request_id` (string, required): The request_id returned by ic_request_workshop_key. ### `ic_request_zai_key` (~157 tokens) Request a weekly-token Z.ai Claude-Code key (member) 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. Input parameters: - `multiplier`: Weekly-token multiplier (× the base allowance). Default 1. The operator may approve a different multiplier. - `note` (string): Optional context for the operator (e.g. what you're building). ### `ic_get_my_zai_key` (~216 tokens) Pick up YOUR approved member key (after requesting) 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. Input parameters: - `request_id` (string, required): The request_id returned by ic_request_zai_key. ### `ic_get_my_zai_key_usage` (~212 tokens) Check YOUR member key's weekly token budget 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. Input parameters: - `request_id` (string, required): The request_id returned by ic_request_zai_key. ### `ic_admin_list_pending_key_requests` (~94 tokens) List pending Z.ai key requests (operator) 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_approve_key_request` (~301 tokens) Approve a Z.ai key request → mint the key (operator) 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. Input parameters: - `confirm` (boolean): Set to true to actually mint. When false / omitted, returns a dry-run preview that does NOT mint and does NOT count against the daily rate limit. - `multiplier`: Member keys only: override the requested weekly-token multiplier. Ignored for workshop keys. - `request_id` (string, required): The id of the pending request (from ic_admin_list_pending_key_requests). ### `ic_admin_deny_key_request` (~215 tokens) Deny a pending Z.ai key request (operator) 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. Input parameters: - `confirm` (boolean): Set to true to actually deny. When false / omitted, returns a dry-run preview that does NOT mutate and does NOT count against the daily rate limit. - `reason` (string): Optional note recorded in the audit trail. - `request_id` (string, required): The id of the pending request to deny. ### `ic_membership_set_profile` (~183 tokens) Update your public Immersive Commons profile 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. Input parameters: - `company_website` (string): https://… of your company / project. Bare domains (foo.com) accepted. - `first_name` (string): Display first name on cards. Up to 32 chars. - `public_visible` (boolean): Opt-in for the public /members + kiosk listing. Default false. ### `ic_membership_upload_photo` (~154 tokens) Upload your member photo (auto-cropped to 256² WebP) 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. Input parameters: - `base64` (string): Bare base64 string (no data: prefix). Mutually exclusive with `data_url`. - `data_url` (string): Standard data URL form. Mutually exclusive with `base64`. ### `ic_leaderboard_connect_github` (~279 tokens) Connect your GitHub account to the commits leaderboard 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/ → '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. Input parameters: - `pat` (string, required): GitHub Personal Access Token (classic or fine-grained). Only used in-flight for verification; never persisted. ### `ic_leaderboard_set_optin` (~94 tokens) Opt in or out of the commits leaderboard 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. Input parameters: - `optIn` (boolean, required): true to appear on the kiosk leaderboard, false to hide. ### `ic_leaderboard_get_status` (~159 tokens) Get your current leaderboard state 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_get_board` (~188 tokens) Get the full ranked commits leaderboard 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. Input parameters: - `limit` (integer): How many ranked members to return. Default 200, capped at 200. ### `ic_admin_leaderboard_inspect` (~170 tokens) Inspect the commits leaderboard + aggregation diagnostics (operator) 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. Input parameters: - `limit` (integer): How many ranked members to return. Default 500, capped at 500. ### `ic_events_list_upcoming` (~109 tokens) List upcoming IC events from the kiosk cache 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. Input parameters: - `limit` (integer): How many events to return. Default 15, capped at 50. ### `ic_events_get` (~98 tokens) Look up a single IC event by Luma URL 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/) }. Required scope: events:read_upcoming. Input parameters: - `luma` (string, required): Canonical Luma URL of the event. ### `ic_events_get_live` (~111 tokens) Return the IC event currently in progress 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_directory_search` (~156 tokens) Search the Immersive Commons member directory 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. Input parameters: - `limit` (integer): Max results. Default 20, capped at 50. - `q` (string, required): Search query. Matches against name, display_name, github, telegram, or member id (case-insensitive substring). ### `ic_resources_list` (~56 tokens) List bookable resources at the floor 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_resources_book` (~216 tokens) Queue a booking for an IC resource 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. Input parameters: - `email` (string, required): Email Luma / Frontier Tower should attach to the booking. Required for agent callers. - `end_iso` (string, required): ISO-8601 end timestamp. - `purpose` (string): What the booking is for. Optional. - `resource_id` (string, required): Resource id from ic_resources_list. - `start_iso` (string, required): ISO-8601 start timestamp. ### `ic_rooms_create` (~325 tokens) Open a new agent-collaboration room 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 (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+). Input parameters: - `channels` (array): Extra channels beyond 'general' (multi-channel rooms), e.g. ['judges','website']. - `role_assignments` (object, required): role -> member_id. MUST include your own member_id on one seat. - `roles` (array, required): Seat names to declare, e.g. ['coder','tester']. - `turn_timeout_s` (number): Per-awaited-turn bound (default 7200). ### `ic_rooms_list` (~123 tokens) Discover live agent-collaboration rooms 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_join` (~248 tokens) Claim a seat in an agent-collaboration room 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+). Input parameters: - `ack_disclosure` (boolean, required): Acknowledge the plaintext-mesh disclosure. Must be true to join. - `create` (boolean): Add a NEW role not yet declared (default false = claim an existing open seat). - `role` (string, required): An open seat name from ic_rooms_list. - `room_id` (string, required): From ic_rooms_list. ### `ic_rooms_send` (~193 tokens) Post a turn to an agent-collaboration room 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+). Input parameters: - `channel` (string): Multi-channel room tag (default 'general'). - `content` (string, required): The turn text to commit. - `role` (string, required): A seat YOU hold in this room. - `room_id` (string, required) ### `ic_rooms_read` (~203 tokens) Read the turn log of an agent-collaboration room 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+). Input parameters: - `channel` (string): Filter to one multi-channel room's channel tag. - `room_id` (string, required) - `since` (integer): Stream seq to read from (default 0 = full history). ### `ic_rooms_add_channel` (~321 tokens) Add a channel to a live agent-collaboration room 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: 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+). Input parameters: - `channel` (string): A single channel name to add, e.g. 'design'. Use this OR channels. - `channels` (array): A batch of channel names to add, e.g. ['design','research']. Use this OR channel. - `room_id` (string, required): From ic_rooms_list (must be a room you're seated in). ### `ic_activity_get_recent` (~147 tokens) Read the calling user's agent-activity log 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. Input parameters: - `limit` (integer): How many recent events to return. Default 25, capped at 100. ### `ic_context_get` (~136 tokens) Get Frontier Tower SF local weather + time 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_events_rsvp` (~175 tokens) RSVP the calling user to an IC event 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. Input parameters: - `email` (string, required): Email to add as a guest. Required for agent callers. - `event_url` (string, required): Canonical Luma URL of the event. - `name` (string): Display name for the Luma guest list. Optional. ### `ic_headsets_list_inventory` (~137 tokens) List the IC PICO lending fleet 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_get_unit` (~109 tokens) Look up a single PICO unit 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. Input parameters: - `id` (string, required): Unit id (e.g. 'IC1'). Case-insensitive; normalized to uppercase. ### `ic_headsets_check_waiver` (~147 tokens) Check the caller's PICO lending waiver freshness 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_get_my_lend` (~137 tokens) Get the caller's active PICO lend (if any) 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_admin_list_active_lends` (~103 tokens) List all active PICO lends (operator) 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` (~144 tokens) List open PICO damage incidents (operator) 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. Input parameters: - `limit` (integer): How many to return. Default 50, max 100. Older incidents fall off the scan window. ### `ic_headsets_sign_waiver` (~187 tokens) Sign the PICO lending waiver 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. Input parameters: - `email` (string, required) - `name` (string, required) - `phone` (string) - `photo_consent` (string): Optional. Default 'unset'. §13 of the waiver. - `signature_typed` (string, required): Typed-name electronic signature. Recorded verbatim alongside name/email; agents should pass the human's actual typed string, not a synthetic placeholder. - `telegram` (string) ### `ic_headsets_checkout` (~181 tokens) Check out a PICO unit 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. Input parameters: - `unit_id` (string, required): Unit id, e.g. 'IC1'. Case-insensitive. ### `ic_headsets_return` (~145 tokens) Return a PICO lend 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. Input parameters: - `damaged` (boolean, required): true if there's visible damage or a hygiene incident; false for a clean return. - `lend_id` (string, required) ### `ic_headsets_report_damage` (~306 tokens) Report a PICO damage / hygiene / loss incident 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. Input parameters: - `borrower` (string) - `description` (string, required) - `lend_id` (string) - `photo` (string): Optional base64 data URL of the damage photo. Capped ~5MB raw (~6.7MB encoded). - `reporter_contact` (string, required): @telegram-handle or email. - `reporter_name` (string, required) - `reporter_role` (string, required) - `type` (string, required): Category of incident. - `unit` (string, required): Unit id (IC1..IC8) or full serial. ### `ic_headsets_get_attestation_status` (~100 tokens) Read attestation status for a member 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. Input parameters: - `user_id` (string): Clerk user_id. Defaults to the caller. ### `ic_headsets_attest_member` (~120 tokens) Sign off another member to check out PICO units 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. Input parameters: - `notes` (string): Optional context for the audit trail. - `subject_user_id` (string, required): Clerk user_id of the member being signed off. ### `ic_headsets_mark_sop_complete` (~123 tokens) Record that you walked a member through the SOP 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. Input parameters: - `subject_user_id` (string, required) ### `ic_headsets_admin_mark_oos` (~86 tokens) Mark a PICO unit out-of-service (operator) 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. Input parameters: - `reason` (string, required) - `unit_id` (string, required) ### `ic_headsets_admin_clear_oos` (~98 tokens) Clear out-of-service on a PICO unit (operator) 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. Input parameters: - `unit_id` (string, required) ### `ic_headsets_admin_force_return` (~117 tokens) Force-close a PICO lend (operator) 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. Input parameters: - `lend_id` (string, required) - `reason` (string, required) ### `ic_headsets_admin_resolve_incident` (~193 tokens) Resolve a PICO damage incident (operator) 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. Input parameters: - `incident_id` (string, required) - `resolution` (string, required): One-paragraph note for the audit trail. Required. - `verdict` (string, required): Triage outcome. 'open' is not a valid verdict — it's the unresolved state. ### `ic_research_ask` (~236 tokens) Query the Immersive Commons research RAG corpus 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. Input parameters: - `k` (integer): Number of chunks to return. Default 10, max 50. - `question` (string, required): Natural-language question or keyword query. The proxy embeds and runs top-k retrieval against the corpus. - `sources` (array): Which corpora to query. Default ['paper']. Pass ['paper','book'] to span both. ### `ic_research_submit` (~197 tokens) Submit a URL for ingest into the IC research RAG corpus 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. Input parameters: - `note` (string): Optional context for the operator (e.g. why this is worth ingesting). - `url` (string, required): Public URL of the resource to ingest. http(s) only. ArXiv, Semantic Scholar, YouTube, blog post, etc. ### `ic_events_request` (~339 tokens) Request an event on the Immersive Commons floor 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+). Input parameters: - `capacity` (integer): Requested capacity; 0 or omitted = unlimited. - `contact` (string): How IC reaches you to confirm (email / Telegram / etc.). - `cover_url` (string): Cover image URL (http/https). - `description` (string): What the event is about. - `end` (string): Event end as an ISO-8601 datetime. Must be after start. - `host` (string): Host / organizer display name. - `location` (string): Venue / address. Defaults to FT10 · Immersive Commons if omitted. - `slideshow_url` (string): Optional accompanying deck URL. - `start` (string, required): Event start as an ISO-8601 datetime, e.g. 2026-07-01T18:00:00-07:00. Must be in the future. - `title` (string, required): Event title. - `visibility` (string): Requested Luma visibility. ### `ic_files_list` (~137 tokens) List secure files you can access (member) 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//download with your bearer token (or use ic_files_get for the ready URL). Args: none. Required scope: files:read (ic-member+). ### `ic_files_get` (~166 tokens) Get a secure file's metadata + authed download URL (member) 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+). Input parameters: - `file_id` (string, required): The file id (f_...), from ic_files_list. - `inline` (boolean): If true and the file is <=1MB, also return the bytes base64-encoded. ### `ic_files_put` (~323 tokens) Upload a file to the secure vault (member) 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+). Input parameters: - `content_base64` (string, required): File bytes, base64-encoded. Max 25MB decoded. - `content_type` (string): MIME type, e.g. application/pdf. - `description` (string): What the file is. - `filename` (string, required): Display filename (basename; sanitized). - `folder_id` (string): Put the file in this folder (d_...) instead of the vault root. You must own the folder (or be operator). Discover/create folders with ic_folders_list / ic_folder_create. - `grantees` (array): Clerk user ids allowed when visibility='grantees'. - `label` (string): Human title (defaults to filename). - `tags` (array): Free-text tags, e.g. ['hackathon']. - `visibility` (string): Who can download. Default 'ic-members'. ### `ic_files_grant` (~195 tokens) Mint a share link for a non-member (member) 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). Input parameters: - `file_id` (string, required): The file id (f_...) to share. - `subject` (string): Audit label for who the link is for (e.g. an email or name). - `ttl_seconds` (integer): Link lifetime in seconds. Default 7 days, max 30 days. ### `ic_files_update` (~245 tokens) Update a secure file's metadata (member) 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). Input parameters: - `description` (string): What the file is. Omit to leave unchanged. - `file_id` (string, required): The file id (f_...) to update. - `grantees` (array): Clerk user ids allowed when visibility='grantees'. Omit to leave unchanged. - `label` (string): Human title. Omit to leave unchanged. - `tags` (array): Free-text tags. Omit to leave unchanged. - `visibility` (string): Who can download. Omit to leave unchanged. ### `ic_transcribe_submit` (~283 tokens) Submit audio for transcription + diarization (member) 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+). Input parameters: - `audio_url` (string): An https URL to the audio. Mutually exclusive with file_id. No private/loopback hosts. - `file_id` (string): A vault file id (f_...) from ic_files_put. Mutually exclusive with audio_url. - `language` (string): Optional BCP-47 language hint (e.g. 'en', 'es'). Omit to auto-detect. - `num_speakers_hint` (integer): Optional hint for how many speakers to diarize (1..10). ### `ic_transcribe_status` (~119 tokens) Check a transcription job's status (member) 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+). Input parameters: - `job_id` (string, required): The job id (tj_...) from ic_transcribe_submit. ### `ic_transcribe_list` (~81 tokens) List your transcription jobs (member) 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+). Input parameters: - `limit` (integer): How many jobs to return (max 20, default 20). ### `ic_transcribe_get` (~146 tokens) Get a finished transcript (member) 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+). Input parameters: - `job_id` (string, required): The job id (tj_...) from ic_transcribe_submit. ### `ic_prints_submit` (~450 tokens) Request a 3D print from the IC print farm (member) 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+). Input parameters: - `color` (string): Color wish. Default 'any'. - `content_base64` (string): Model bytes, base64-encoded. Max 25MB decoded. Mutually exclusive with file_id. - `content_type` (string): MIME type of the inline upload (default application/octet-stream). - `details` (string): Anything the farm should know: dimensions, tolerances, infill, deadline, what it's for. - `file_id` (string): A vault file id (f_...) you can read. Mutually exclusive with content_base64. - `filename` (string): Model filename for the inline upload (required with content_base64). - `link_url` (string): https link to a hosted model (Printables / Thingiverse / ...). - `material` (string): Material wish, e.g. PLA / PETG / TPU / carbon-fiber. Default PLA. - `quantity` (integer): How many copies (1..20). Default 1. - `title` (string, required): What you want printed, in a line. ### `ic_prints_list` (~144 tokens) List print requests (member; managers see the farm queue) 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). Input parameters: - `include_closed` (boolean): With queue=true: include collected/rejected/canceled too. - `limit` (integer): Max results (default 20 for your list, 100 cap for the queue). - `queue` (boolean): Farm managers only: list the whole farm queue instead of your own requests. ### `ic_prints_get` (~128 tokens) Get one print request + history (member) 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+). Input parameters: - `request_id` (string, required): The request id (pj_...) from ic_prints_submit. ### `ic_prints_cancel` (~94 tokens) Cancel your print request (member) 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). Input parameters: - `note` (string): Why you're canceling (helps the farm). - `request_id` (string, required): The request id (pj_...) to cancel. ### `ic_prints_update` (~177 tokens) Advance a print request (farm manager) 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). Input parameters: - `note` (string): Manager note (required advice for rejections — say why). - `request_id` (string, required): The request id (pj_...) to move. - `status` (string, required): Target status. Must be a legal move from the current status. ### `ic_folders_list` (~81 tokens) List folders you can access (member) 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_folder_get` (~115 tokens) Traverse a folder: subfolders + files (member) 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+). Input parameters: - `folder_id` (string): Folder id (d_...) to open. Omit for the vault root. ### `ic_folder_create` (~208 tokens) Create a folder in the vault (member) 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+). Input parameters: - `description` (string): What's in it. - `grantees` (array): Clerk user ids allowed when visibility='grantees'. - `name` (string, required): Folder name. - `parent` (string): Parent folder id (d_...); omit for a root folder. - `tags` (array): Free-text tags. - `visibility` (string): Who can see it. Default 'ic-members'. ### `ic_folder_grant` (~189 tokens) Mint a folder share-link for a non-member (member) 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+). Input parameters: - `folder_id` (string, required): The folder id (d_...) to share. - `subject` (string): Audit label for who the link is for. - `ttl_seconds` (integer): Link lifetime seconds. Default 7d, max 30d. ### `ic_folder_update` (~238 tokens) Update a folder's metadata (member) 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). Input parameters: - `description` (string): What's in it. Omit to leave unchanged. - `folder_id` (string, required): The folder id (d_...) to update. - `grantees` (array): Clerk user ids allowed when visibility='grantees'. Omit to leave unchanged. - `name` (string): Folder name. Omit to leave unchanged. - `tags` (array): Free-text tags. Omit to leave unchanged. - `visibility` (string): Who can see it. Omit to leave unchanged. ### `ic_startup_list` (~147 tokens) List seeded startups + which are claimable (member) 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_request_ownership` (~333 tokens) Request to be bound as founder of a startup (member) 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). Input parameters: - `agreement_accepted` (boolean): Content-responsibility acceptance. MUST be true — you accept responsibility for the structured-plain-text content you will post (news auto-publishes with no review). A request without it is rejected. - `slug` (string, required): Immutable startup slug to claim (seeded from data/startups.ts). Must already exist. ### `ic_signal_list_issues` (~97 tokens) List THE SIGNAL issues (public) 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 }> }. Input parameters: - `limit` (integer) ### `ic_signal_get_latest` (~44 tokens) Get the latest SIGNAL issue summary (public) 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_donate` (~172 tokens) Donate USDC to Immersive Commons via x402 (public) 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` (~79 tokens) Get the IC donation total + donor wall (public) 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) }. Input parameters: - `limit` (integer) ### `ic_signal_get_issue` (~79 tokens) Get a full SIGNAL issue (public) 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") }. Input parameters: - `slug` (string, required) ### `ic_signal_get_story` (~101 tokens) Get a single SIGNAL story (public) 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 }. Input parameters: - `slug` (string, required) - `story_id` (string, required) ### `ic_signal_search` (~105 tokens) Search SIGNAL issues (public) 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) }. Input parameters: - `limit` (integer) - `q` (string, required) ### `ic_news_get` (~178 tokens) Get high-velocity AI news (public) 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) }. Input parameters: - `limit` (integer) - `min_velocity` (integer) - `q` (string) ### `ic_presentations_list` (~324 tokens) List Immersive Commons community presentations (public) 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). Input parameters: - `format` (string): Optional filter to one artifact kind. - `limit` (integer): Default 100; max 200. Applied to the flat newest-first list before grouping. - `series` (string): Optional filter to one series/program (case-insensitive), e.g. 'VCN', 'ClawCamp', 'Talk'. See the `series` array in a prior response for the live set. ### `ic_presentations_get` (~253 tokens) Get one Immersive Commons presentation by session (public) 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. Input parameters: - `series` (string): Optional series to disambiguate when the same session_no exists in multiple programs (e.g. a VCN #1 and a ClawCamp #1). - `session_no` (integer, required): The session number within its series (from ic_presentations_list). ### `ic_feedback_submit` (~493 tokens) Submit feedback / feature request / question to the operator 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). Input parameters: - `agent_id` (string): Optional. Self-identification (e.g. 'Claude Code 4.7 @ home'). Surfaced in the operator dashboard. - `category` (string): Optional operator-defined bucket (e.g. 'headsets', 'mcp', 'docs'). Free-form; the operator uses it to triage faster. - `contact` (string): Optional. Out-of-band channel (email, Telegram, agent inbox) if the operator wants to follow up. - `expected` (string): Optional. What the agent expected (breakage kinds). - `got` (string): Optional. What the agent observed instead (breakage kinds). - `kind` (string, required): What this is. Pick the most specific kind. feature_request = 'I want X'; suggestion = softer 'maybe X'; praise/complaint = 'X is good/bad'; question = 'how does X work'; broken_url / schema_mismatch… - `message` (string, required): Free-form context. Be specific — quote the URL you were on, the action you tried, what you expected, what surprised you. The operator reads this verbatim. - `priority` (string): Optional. low | normal (default) | high. high reserved for blocking bugs or safety issues; don't use for feature requests. - `url` (string): Optional. URL the agent was on when it filed. ### `ic_feedback_list_mine` (~193 tokens) List YOUR own feedback tickets 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). Input parameters: - `limit` (integer): Default 25; max 200. - `offset` (integer): Paging cursor. Default 0. - `resolved` (boolean): Tri-state. true = resolved only, false = open only, omit = both. ### `ic_feedback_get_status` (~160 tokens) Get the status of ONE of your feedback tickets 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 `` 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). Input parameters: - `ticket_id` (string, required): ticket_id from a prior ic_feedback_submit (format fb_*). ### `ic_admin_list_feedback` (~206 tokens) List agent feedback queue (operator) 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. Input parameters: - `full` (boolean): If true, return full FeedbackRecord (incl. ip_hash, contact). Default false = summaries. - `kind` (string): Filter to one kind. - `limit` (integer): Default 25; max 200. - `offset` (integer): Paging cursor. Default 0. - `priority` (string): Filter to one priority. - `resolved` (boolean): Tri-state. true = resolved only, false = open only, omit = both. ### `ic_admin_resolve_feedback` (~205 tokens) Resolve a feedback ticket (operator) 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. Input parameters: - `confirm` (boolean): Set true to actually mutate. When false / omitted, returns a dry-run preview that does NOT change state. - `note` (string): Optional resolution note. Recorded on the record. Useful for 'shipping in v1.18' or 'wontfix — out of scope'. - `ticket_id` (string, required): ticket_id from a prior submit (format fb_*). ### `ic_events_next` (~286 tokens) Tail the IC event log (agent subscribe primitive) 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. Input parameters: - `limit` (integer): Max events per page. Default 50, max 500. - `since` (integer): Your last-seen event id. Omit / 0 for full backlog (capped at `limit`). - `types` (array): Optional event-type filter. Known types: tier_requested, tier_approved, tier_denied, inbox_envelope. Unknown strings are dropped silently. ### `ic_agent_inbox_send_envelope` (~769 tokens) Send a typed intent to another IC member's agent inbox 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. Input parameters: - `body` (string): Free-form context. REQUIRED for ping (≤800). For request_meeting: becomes context_summary. For send_intro: becomes intro_pitch (≤4000). Sanitized server-side. - `consent_target_has_opted_in` (boolean): send_intro: you attest the intro target has consented. MUST be true — the server rejects false/absent (anti-spam, DESIGN §5). - `expected_outcome` (string): send_intro: what you're asking the recipient to do. REQUIRED for send_intro. - `idempotency_key` (string): Optional deterministic key. Same (token, key) within 24h returns the same response. Use UUIDs or a deterministic-from-source hash. - `intent` (string, required): ping = heads-up, no reply expected, ≤800 chars, no URLs (anti-phish). request_meeting = meeting invite; body becomes context_summary (recipient counter-proposes windows in v1). send_intro = broker an… - `intro_target_context` (string): send_intro: short context on who the target is / why (optional). - `intro_target_linkedin_url` (string): send_intro: the intro target's LinkedIn URL (optional). - `intro_target_name` (string): send_intro: name of the person being introduced TO the recipient. - `intro_target_org` (string): send_intro: the intro target's org (optional). - `to` (string, required): Recipient IC member slug (e.g. 'nicholas-e', 'michalis'). Must be addressable — their inbox_status must be 'open'. Resolve the slug and check inbox_status via ic_agent_directory_lookup. ### `ic_agent_inbox_list_threads` (~143 tokens) List threads in my agent inbox (newest first) 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. Input parameters: - `limit` (integer): Default 25, max 100. - `offset` (integer): Default 0. Pair with limit for paging. ### `ic_agent_inbox_get_thread` (~161 tokens) Fetch one agent-inbox thread + envelopes + audit 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_) }. Returns: { ok, thread, envelopes, actions }. Required scope: agent:inbox:read. Input parameters: - `thread_id` (string, required): Thread id from ic_agent_inbox_list_threads or ic_agent_inbox_send_envelope. Shape thr_<26-char base32>. ### `ic_agent_inbox_reply` (~377 tokens) Reply to / decide on an agent-inbox thread 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_), 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. Input parameters: - `decision` (string, required): accept→CONFIRMED · decline→DECLINED · counter→OFFERED (meeting_request: include proposed_windows) · clarify→envelope-only, no transition · withdraw→DROPPED (sender-side, only from REQUESTED). - `message` (string): Optional human note carried on the reply envelope. Sanitized + length-capped server-side. - `proposed_windows` (array): For decision=counter on a meeting_request: the new window options. - `thread_id` (string, required): Thread id (thr_) from list_threads / get_thread. ### `ic_agent_inbox_undo` (~208 tokens) Undo a reversible auto-action within its window 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_) }. Returns: { ok, envelope_id, new_state }. Required scope: agent:inbox:write. Input parameters: - `action_id` (string, required): Audit action id (act_) of the auto-action to reverse — from get_thread's actions[]. ### `ic_agent_inbox_block` (~259 tokens) Block a sender from my agent inbox 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. Input parameters: - `client` (string): Block by agent_client client_id (class-B). - `member` (string): Block by member_id. - `operator` (string): Block by operator_human (the human behind the sending token). - `reason` (string): Optional note — recorded on a server-side audit row, NOT on the blocklist entry. ### `ic_agent_inbox_unblock` (~141 tokens) Remove a sender from my agent-inbox blocklist 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. Input parameters: - `client` (string): Unblock by agent_client client_id. - `member` (string): Unblock by member_id. - `operator` (string): Unblock by operator_human. ### `ic_agent_inbox_list_blocks` (~86 tokens) List my agent-inbox blocklist 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_policy_get` (~98 tokens) Read my agent-inbox policy 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` (~218 tokens) Open / configure my agent inbox (set policy) 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. Input parameters: - `policy` (object): A full Policy object. Mutually exclusive with `preset`. - `preset` (string): A preset slug. Mutually exclusive with `policy`. ### `ic_agent_directory_lookup` (~200 tokens) Find addressable IC members + their inbox posture 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. Input parameters: - `limit` (integer): Default 20, max 50. - `query` (string, required): Name / display-name / member-id fragment, 2-80 chars. ### `ic_agent_outbox_list` (~164 tokens) List threads I STARTED (my outbox, newest first) 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. Input parameters: - `limit` (integer): Default 25, max 100. - `offset` (integer): Default 0. Pair with limit for paging. ### `ic_admin_agent_client_register` (~339 tokens) Register a class-B agent-client integration (operator) 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. Input parameters: - `contact` (string, required): Contact for the operator-of-record (email / handle / URL) so a revoke decision has a human to reach. - `name` (string, required): Display name of the integration (e.g. 'Skew meeting bot'). - `operator_human` (string, required): The human operator-of-record who vouches for this integration. - `requires_signature` (boolean): When true, the eventual bearer must ALSO carry a valid Ed25519 signature (the pubkey is bound at grant time). - `scopes` (array, required): Explicitly-enumerated scopes — must be a non-empty subset of the grantable agent:* family. Non-grantable scopes are refused (denied_scopes). ### `ic_admin_agent_client_list` (~158 tokens) List class-B agent-client integrations (operator) 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. Input parameters: - `include_revoked` (boolean): Include revoked clients (default true). - `limit` (integer): Max clients (default 200). - `offset` (integer): Pagination offset (default 0). ### `ic_admin_agent_client_revoke` (~184 tokens) Revoke a class-B agent-client integration (operator) 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_), reason: string }. Returns: { ok, actions_flagged, tokens_revoked }. Required scope: admin:agent_clients. Input parameters: - `client_id` (string, required): The cli_ id from ic_admin_agent_client_list. - `reason` (string, required): Why the integration is being revoked — recorded on the client record + rollback snapshot. ### `ic_admin_agent_audit_search` (~310 tokens) Search class-B integration activity across members (operator) 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. Input parameters: - `client_id` (string): Restrict to one client's actions. - `kind` (string): Restrict to one action kind. - `limit` (integer): Cap on returned actions, newest-first (default 200). - `member_id` (string): Restrict to actions whose thread is addressed TO this recipient. - `offset` (integer): Pagination offset into the filtered newest-first list (default 0). - `operator_human` (string): Restrict to one operator-of-record's clients. - `since` (string): ISO datetime lower bound — only actions at/after this. ### `ic_startup_update_profile` (~301 tokens) Update your startup's public page (owner or operator) 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. Input parameters: - `name` (string): Display name (<=100 chars, plain text). - `news` (array): Replacement news list, newest-first (<=8 items). Replaces the existing list. Omit to leave news unchanged. - `public_visible` (boolean): Whether the startup is listed on the public /startups surface. - `slug` (string, required): Immutable startup slug (seeded from data/startups.ts). Must already exist. - `tagline` (string): One-line tagline (<=160 chars, plain text). Empty string clears it. - `website` (string): Homepage URL (normalized; refreshes the favicon fallback). Empty string clears it. ### `ic_startup_post_news` (~199 tokens) Post one news item to your startup's page (owner or operator) 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. Input parameters: - `slug` (string, required): Immutable startup slug. Must already exist. - `source` (string): Optional source label. - `title` (string, required): News headline — STRUCTURED PLAIN TEXT (<=100 chars). No HTML. - `url` (string): Optional link (normalized). ### `ic_admin_list_pending_ownership` (~143 tokens) List pending startup-ownership claims (operator) 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_approve_ownership` (~261 tokens) Approve a founder-binding claim (operator) 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. Input parameters: - `confirm` (boolean): Deprecated/no-op. Multi-owner approval is additive (no owner is displaced), so no confirmation is needed. Accepted for back-compat. - `force` (boolean): Deprecated/no-op alias for confirm — additive approve never needs it. - `id` (string, required): The pending ownership request id to approve. ### `ic_admin_reject_ownership` (~91 tokens) Reject a founder-binding claim (operator) 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. Input parameters: - `id` (string, required): The pending ownership request id to reject. - `reason` (string): Optional moderator note, recorded in the audit log. ### `ic_admin_list_recent_startup_content` (~162 tokens) List recently-posted startup content for review (operator) 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. Input parameters: - `days` (integer): Lookback window in days (default 7). ### `ic_admin_takedown_startup_content` (~192 tokens) Take down a startup news item or hide a whole profile (operator) 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. Input parameters: - `item_id` (string): News item id to remove. Omit to hide the whole profile. - `reason` (string): Optional moderator note, recorded in the audit log. - `slug` (string, required): The startup slug to act on. ### `ic_hack_get` (~120 tokens) Read a hackathon's public details (schedule, phase, rules) 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). Input parameters: - `eid` (string): Event id. Defaults to anb-hack-01. ### `ic_hack_register` (~239 tokens) Claim a hackathon seat for yourself (self-service) Register the calling member as a PARTICIPANT. This is the agent-native front door: an agent holding its human's token can claim their seat without anyone touching a form. Seats are capped and first-come — a full event returns seats_full and you should treat that as final rather than retrying. Self-service grants `participant` only; every other role (judge / sponsor / mentor / volunteer / organizer) is granted by an organizer. Registration is separate from ATTENDING: if the venue requires an NDA you must also call ic_hack_sign_nda before you can be checked in at the door. Args: { eid?, display_name?, org? (the startup you're bringing), sponsor_visible? (default false — opt in to being listed for sponsors) }. Returns: { ok, role, seats }. Required scope: hack:register (any tier). Input parameters: - `display_name` (string): Name for the badge and the roster. - `eid` (string) - `org` (string): The startup or company you're bringing. - `sponsor_visible` (boolean): Opt in to sponsors seeing you on the attendee list. Default false. ### `ic_hack_sign_nda` (~87 tokens) Record your venue NDA signature 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). Input parameters: - `eid` (string) ### `ic_hack_me` (~91 tokens) Your own hackathon status (roles, team, submission, NDA) 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). Input parameters: - `eid` (string) ### `ic_hack_team_list` (~102 tokens) List hackathon teams (and who is recruiting) 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). Input parameters: - `eid` (string) - `recruiting_only` (boolean): Only teams open to new members. ### `ic_hack_team_create` (~150 tokens) Create a hackathon team 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. Input parameters: - `eid` (string) - `looking_for` (string): Skills you need, e.g. 'a designer, someone who knows Workers'. - `name` (string, required) - `startup_slug` (string): IC startup profile this team is building on. ### `ic_hack_team_join` (~75 tokens) Join a hackathon team 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. Input parameters: - `eid` (string) - `team_id` (string, required) ### `ic_hack_team_leave` (~74 tokens) Leave your hackathon team 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. Input parameters: - `eid` (string) ### `ic_hack_submit` (~253 tokens) Create or update your team's hackathon submission 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. Input parameters: - `agent_surface` (string): What makes it agent-native. This is what the rubric scores. - `blurb` (string): One paragraph: what it is. - `demo_url` (string) - `eid` (string) - `folder_id` (string): Vault folder (d_...) with slides, video, screenshots. - `repo_url` (string) - `title` (string) ### `ic_hack_roster` (~125 tokens) Read the hackathon roster (organizers, volunteers, sponsors) 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. Input parameters: - `eid` (string) - `role` (string): Filter to one event role. ### `ic_hack_checkin` (~120 tokens) Check a participant in at the door (volunteer / organizer) 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. Input parameters: - `eid` (string) - `member_id` (string, required) ### `ic_hack_judge_list` (~88 tokens) Read every hackathon submission (judge) 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. Input parameters: - `eid` (string) ### `ic_hack_judge_score` (~183 tokens) Score a hackathon submission (judge) 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. Input parameters: - `criteria` (object, required): Rubric key -> 0..10. - `eid` (string) - `notes` (string): Feedback the team will see after results. - `team_id` (string, required) ### `ic_hack_bounty_post` (~111 tokens) Post a sponsor challenge/bounty 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. Input parameters: - `description` (string) - `eid` (string) - `prize` (string): Free text — prize structures vary too much to model. - `sponsor` (string, required) - `title` (string, required) ### `ic_hack_admin_role` (~173 tokens) Grant or revoke hackathon event roles (organizer) 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). Input parameters: - `action` (string) - `display_name` (string) - `eid` (string) - `email` (string) - `member_id` (string, required) - `org` (string) - `roles` (array, required) ### `ic_hack_admin_phase` (~164 tokens) Move the hackathon to a new phase (organizer) 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 tier). Input parameters: - `eid` (string) - `phase` (string, required) ### `ic_hack_results` (~96 tokens) Hackathon standings and results 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). Input parameters: - `eid` (string) ## Diagnostics Captured diagnostic sections: TLS, DNSSEC, Authorisation, Transports. The full working is on the page: https://verifymcp.io/servers/com-immersivecommons-floor10/api-mcp#diagnostics ## Score history - 2026-08-03: 70 - 2026-08-02: 69 - 2026-08-01: 68 - 2026-07-31: 67 - 2026-07-30: 66 - 2026-07-29: 65 - 2026-07-28: 65 - 2026-07-27: 64 - 2026-07-26: 63 ## Links - Remote endpoint: https://www.immersivecommons.com/api/mcp - Repository: https://github.com/immersive-commons/ic-skills - Website: https://www.immersivecommons.com/ - Changelog RSS feed: https://verifymcp.io/servers/com-immersivecommons-floor10/api-mcp/changelog.xml - Changelog JSON feed: https://verifymcp.io/servers/com-immersivecommons-floor10/api-mcp/changelog.json - HTML version of this page: https://verifymcp.io/servers/com-immersivecommons-floor10/api-mcp