Immersive Commons

{
  "id": "aix_d98d928571",
  "name": "Immersive Commons",
  "operator": "(unclaimed - source: registry-official · publisher: com.immersivecommons)",
  "description": "Members-run AI builder space on Floor 10, Frontier Tower SF. 138 tools: events, news, directory.",
  "depth": 2,
  "status": "unclaimed",
  "last_crawled": "2026-09-24",
  "missing_fields": [
    "pricing",
    "operator.identity"
  ],
  "skills": [
    "calendar-sync",
    "citation-check",
    "onchain-data"
  ],
  "protocols": {
    "mcp": "https://www.immersivecommons.com/api/mcp",
    "a2a": null
  },
  "pricing": null,
  "regions": [
    "global"
  ],
  "languages": [
    "en"
  ],
  "reputation": {
    "tasks_completed": null,
    "dispute_rate": null,
    "p95_latency_ms": 3346,
    "uptime_30d": 1,
    "onchain_volume_30d_usd": null
  },
  "aix_score": 41,
  "verification": {
    "identity": "none",
    "health": "probe/24h",
    "pricing": "unknown",
    "last_check": "2026-09-24T23:01:00.967Z"
  },
  "pricing_model": "unknown",
  "links": [
    {
      "label": "homepage",
      "url": "https://www.immersivecommons.com/"
    },
    {
      "label": "repository",
      "url": "https://github.com/immersive-commons/ic-skills"
    }
  ],
  "avatar": "https://github.com/immersive-commons.png?size=160",
  "socials": [
    {
      "label": "github",
      "url": "https://github.com/immersive-commons"
    }
  ],
  "profile": {
    "mcp_server": "immersive-commons-floor10",
    "mcp_version": "1.39.0",
    "tool_count": 22,
    "tools": [
      {
        "name": "ic_signal_list_issues",
        "description": "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 }> }."
      },
      {
        "name": "ic_signal_get_latest",
        "description": "Convenience tool — returns the most-recent issue summary (same shape as one element of ic_signal_list_issues.issues[]). No auth required. Args: { include_stories?: boolean (default false — when true the issue's story list is inlined as stories[] with id/title/dek, saving a follow-up ic_signal_get_issue round trip) }."
      },
      {
        "name": "ic_donate",
        "description": "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 "
      },
      {
        "name": "ic_donations_total",
        "description": "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) }."
      },
      {
        "name": "ic_signal_get_issue",
        "description": "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\") }."
      },
      {
        "name": "ic_signal_get_story",
        "description": "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 }."
      },
      {
        "name": "ic_signal_search",
        "description": "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) }."
      },
      {
        "name": "ic_news_get",
        "description": "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). Items come back ranked highest-velocity-first (ties keep the feed's own order). 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 sub"
      },
      {
        "name": "ic_presentations_list",
        "description": "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 "
      },
      {
        "name": "ic_presentations_get",
        "description": "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 — re"
      },
      {
        "name": "ic_funko_catalog",
        "description": "The full catalog of things a Funko Me figure can earn — animation clips, props, skins, stages — with the condition that unlocks each one. No auth required; this is the rules table, not anybody's progress. Use it to explain to a human WHY something is locked, or to show what is worth doing on the floor. An item with no `requires` is granted to every signed-in member. Conditions read as either { signal, gte } (a measurable: commits this week, GLM tokens burned, events attended, days of tenure) or { minTier } (a membership ring). For one member's actual progress against these, call ic_funko_progr"
      },
      {
        "name": "ic_spatial_beta_program",
        "description": "Everything needed to apply to the Immersive Commons spatial-computing beta: the terms (50 testers, 5 weeks, $160 paid ON COMPLETION, in person at Frontier Tower San Francisco, strict NDA, a pre-release AI spatial-computing device 6-12 months from release), every application question, and the REASON each is asked. Call this BEFORE ic_spatial_beta_apply so you answer well instead of guessing. `gates` names the three booleans that decide most applications - the NDA, the 5-week commitment, and being able to attend in person; a no to any of them is very likely a rejection, and saying so honestly be"
      },
      {
        "name": "ic_spatial_beta_apply",
        "description": "Submit an application to the 50-person spatial-computing beta. WRITES a real application under a real person's name and commits them to a 5-week in-person NDA-bound program, so CONFIRM EVERY ANSWER WITH YOUR HUMAN FIRST and never invent one on their behalf - particularly the NDA, commitment and in-person answers, which are promises they have to keep. Call ic_spatial_beta_program first for the catalog and the exact allowed values. One application per email address; a second is refused rather than silently merged. The response carries a `claim_token` shown EXACTLY ONCE: surface it to your human "
      },
      {
        "name": "ic_spatial_beta_status",
        "description": "Where one application stands. Needs BOTH the application_id and the claim_token returned at submission: an id alone returns only public slot counts and never anyone's record, because ids travel through URLs and chat logs and must not work as credentials. A wrong or missing token is answered exactly like an unknown id, so this cannot be used to test whether an id exists. Args: { application_id, claim_token }. Returns: { ok, found, application?, cohort }. No auth required."
      },
      {
        "name": "ic_forms_list",
        "description": "Every form Immersive Commons is currently taking answers to, filtered by who you are. START HERE — do not guess a form id. Each entry carries its `form_id`, title, summary, the membership ring it is open to, whether YOU can answer it right now, and if you cannot, the reason and the ring you would need. A form you can SEE but not answer is LISTED rather than hidden, because a program nobody outside can discover is a program nobody outside ever joins; a form you may not see at all is omitted, because a list of titles you cannot open is a disclosure with no upside. What a listing never contains i"
      },
      {
        "name": "ic_forms_get",
        "description": "The whole definition of one form: every question, its `kind` (short | long | bool | choice | email | url), whether it is required, the exact `options` a `choice` answer must match, and a `why` saying what the answer is actually used for. THIS IS THE READ-BEFORE-YOU-WRITE TOOL — call it before ic_forms_submit so you answer well instead of guessing, and relay each `why` to your human rather than deciding for them what a question is really asking. `facts` carries the program's own terms (things like how long it runs and what it pays) as ordered label/value pairs — read them to your human BEFORE t"
      },
      {
        "name": "ic_forms_submit",
        "description": "Submit answers to one form. NO TOKEN REQUIRED — a form whose audience is `public` takes answers from a caller with no account at all, which is deliberate: the web page accepts anonymous submissions, so an agent path that demanded a token would make acting for your human HARDER than doing it by hand. Each form still declares its own audience ring and it is checked here, live, on every call; a refusal names the ring and how to ask for it, and is distinct from 'no such form'. THIS WRITES A REAL SUBMISSION UNDER A REAL PERSON'S NAME. CONFIRM EVERY ANSWER WITH YOUR HUMAN BEFORE CALLING THIS AND NEV"
      },
      {
        "name": "ic_forms_my_submission",
        "description": "The status of one submission — YOUR human's, never anybody else's. No token required. Two ways in: a signed-in identity resolves its own record with no id at all, or `submission_id` plus the `claim_token` handed back once at submit time opens the record that token belongs to. An id ALONE never works: ids travel through URLs and chat logs, and if an id were a credential every stranger's answers would be readable by anyone who ever saw a link. A wrong id, a wrong token and an id that was never issued all return the same `found: false`, so this cannot be used to test which ids exist. What comes b"
      },
      {
        "name": "ic_forms_withdraw",
        "description": "Take your human's own submission back. NO TOKEN REQUIRED, and no token grants this on anyone else's behalf: the ONLY things that open a record here are your human's signed-in identity or the submission_id plus the one-time claim_token handed back at submit. An operator cannot do it for them, a reviewer cannot do it for them, and `admin:forms_manage` does not reach this — withdrawing belongs to the person who submitted, because a reviewer withdrawing on somebody's behalf is a rejection wearing that person's name. CONFIRM WITH YOUR HUMAN BEFORE CALLING, in the plainest words you have. THIS CANNO"
      },
      {
        "name": "ic_scheduling_list_meeting_types",
        "description": "What you may book with one IC member: every PUBLIC meeting type they publish, with its duration, location kind, notice window and booking horizon. START HERE — a slug guessed rather than read is the commonest way an availability call returns not_found. NO TOKEN REQUIRED, and that is the point: a visitor's agent must be able to discover a member's booking link without an IC account, exactly as a human opening the link can. Visibility is filtered in the scheduling service's own SQL — members_only, unlisted and deactivated types never reach this response and are not filtered here, so an empty mee"
      },
      {
        "name": "ic_scheduling_get_availability",
        "description": "Open slots for one meeting type AND the member's full booking policy, in ONE response. The policy is included deliberately so you can solve locally instead of probing: repeated narrowing calls are what turn a lookup into a negotiation, and this surface refuses to be negotiated with. Every start/end is UTC ISO-8601 with a trailing Z; member.tz and the echoed viewer_tz are IANA zone names — never do wall-clock arithmetic without one. READ complete BEFORE YOU READ slots. ok:true with complete:false is an INCOMPLETE SUCCESS, not a failure: part of the member's calendar could not be read, coverage."
      },
      {
        "name": "ic_scheduling_manage_booking",
        "description": "The way OUT of a booking, and it is first-class on purpose: an agent that has to ask its human to click a link in an email simply ghosts, and no-shows are the failure mode that actually burns members' time. NO TOKEN REQUIRED — the booking's own cancel_token IS the credential, exactly as a form's claim token is for an account-less submitter. Putting the exit behind an IC account nobody was issued is how a person ends up emailing a human to be removed. Authorization has not been skipped, it has MOVED into the resource: the token is checked in constant time and a WRONG token gives the SAME answer"
      }
    ],
    "profiled_at": "2026-09-24T23:01:00.967Z"
  },
  "unreachable": false
}