Skip to main content
Glama

Immersive Commons

by com.immersivecommons
OverviewDiscussionsAdmin

Donate USDC to Immersive Commons via x402 (public)

ic_donate

Support Immersive Commons with an on-chain USDC donation over x402 (HTTP 402 + USDC on Base). No auth required. Returns the donation tiers, the receiving wallet (payTo), the asset + network, and the donate URL. MCP can't run the in-band 402 handshake itself, so to donate: POST https://www.immersivecommons.com/api/x402/donate with an x402 X-PAYMENT header (sign an EIP-3009 USDC authorization for one of the tier amounts to payTo on the given network); the first call with no X-PAYMENT returns a 402 listing every tier in accepts[]. Optional donor { name, message } can be sent in the JSON body and appear on the public donor wall at /donate. Args: { tier?: string (a tier label, case-insensitive — narrows tiers[] to that single tier and adds selected_tier with the exact atomic USDC amount to sign; an unknown label returns error_kind:"validation" naming the valid labels) }.

Input Schema

NameRequiredDescriptionDefault
tierNoA tier label, case-insensitive. Narrows tiers[] to that tier and adds selected_tier with the exact USDC amount to sign.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / tier / description
      Added value: +"A tier label, case-insensitive. Narrows tiers[] to that tier and adds selected_tier with the exact USDC amount to sign."
  2. Changed1 schema field changed
    • removedInput schema / properties / tier / description
      Removed value: -"A tier label, case-insensitive. Narrows tiers[] to that tier and adds selected_tier with the exact USDC amount to sign."
  3. Changed1 schema field changed
    • addedInput schema / properties / tier / description
      Added value: +"A tier label, case-insensitive. Narrows tiers[] to that tier and adds selected_tier with the exact USDC amount to sign."
  4. Changed1 schema field changed
    • addedInput schema / properties / tier
      Added value: +{
+  "maxLength": 64,
+  "minLength": 1,
+  "type": "string"
+}
  5. First observed

TDQS

A4.4/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Adds substantial context beyond the annotations: no-auth requirement, the MCP handshake limitation, the public donor wall exposure of donor {name, message}, and error behavior (error_kind:"validation"). It doesn't address rate limits or the irreversibility of an on-chain transfer, so not quite full coverage.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loads the purpose and is well organized into purpose, flow, and Args. However, the trailing Args block largely restates the tier description already in the schema, adding some redundancy for a fairly dense paragraph.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description correctly enumerates the return values (tiers, payTo, asset + network, donate URL). For a non-trivial multi-step payment flow, an agent has everything needed to invoke it correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3, but the description adds real meaning: case-insensitive matching, the side effect of adding selected_tier with the exact atomic amount to sign, and the validation error listing valid labels on an unknown label.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (donate) and resource (USDC to Immersive Commons) plus the mechanism (x402 / HTTP 402 + USDC on Base), which is immediately distinguishable from the read-only sibling ic_donations_total. An agent knows exactly what this tool accomplishes.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives clear when/how context: no auth required, the two-step 402 flow, and the manual POST workaround since MCP can't run the in-band handshake. It stops short of naming a sibling alternative (e.g., ic_donations_total for reading totals), so no explicit exclusion guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All Immersive Commons toolsInspect
Try in Browser
Shareable, User-Owned Context BackendPeople, applications, and agents read, write, and coordinate together in one context lake. Reach it over MCP, a CLI, a Python SDK, or REST.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources