Mahshar MCP Server

Mahshar

The API marketplace for humans and autonomous agents, powered by USDC on Arc.

Mahshar lets API providers monetize existing endpoints without rebuilding billing infrastructure. Buyers and autonomous agents can discover APIs, pay per call in USDC, and receive responses through Mahshar's payment-aware proxy.

• Live: https://mahshar.xyz
• Network: Arc Mainnet
• Chain ID: 5042

What Mahshar Does

For sellers:

• List an existing API without changing its backend.
• Set a USDC price per call.
• Support public or credential-protected upstream APIs.
• Keep upstream credentials hidden from buyers.
• Track calls, earnings, and withdrawal state.
• Receive seller earnings through the marketplace accounting flow.

For buyers and agents:

• Discover APIs programmatically.
• Inspect machine-readable API metadata.
• Pay per request using USDC.
• Retrieve responses tied to the exact purchase.
• Never receive the seller's upstream credentials.

Public Discovery and Buyer Application

Mahshar provides crawlable public discovery surfaces without requiring a wallet connection:

• Marketplace for browsing active pay-per-call APIs.
• What is Mahshar? for a public overview of the marketplace and payment-aware API access.
• For API Providers for provider education and the path to listing an existing API.
• Stable API detail URLs at /apis/<listing-id>/<slug>.
• Public agent guidance, documentation, and support.
• robots.txt and a generated sitemap for public discovery.

The public discovery layer is isolated from wallet authentication, payment execution, and proxy behavior. The wallet-enabled /buyer application remains the place to connect a wallet and execute paid API requests.

Supported Upstream Authentication

The Client Credentials profile must be enabled by the operator. Authorization Code + PKCE is present in the implementation but disabled in Production. An active provider connection does not activate a listing; publication still requires verification. Stored credentials and tokens are server-side data and are not included in buyer responses or public discovery metadata. Provider authentication details.

How a Paid API Call Works

Buyer / Agent
  → Discover API
  → Request paid endpoint
  → x402 payment requirement
  → USDC settlement
  → Canonical target authorization
  → Seller credential injected server-side where required
  → Upstream API
  → Durable purchase-scoped response
  → Buyer / Agent

Settlement, delivery, and response recovery have distinct durable identities. A recovery capability can retrieve only the response associated with its exact purchase.

Beyond the Arc Reference Apps

circlefin/arc-commerce demonstrates purchasing application credits with USDC, while circlefin/arc-p2p-payments demonstrates wallet-based peer-to-peer payments.

Mahshar adds application-layer primitives for machine-readable paid API discovery, MCP-native discovery and externally signed execution, x402 pay-per-call API monetization, canonical upstream authorization before credential injection, server-side seller credential isolation, prepared-call integrity, purchase-scoped response recovery, and durable payment, settlement, accounting, and delivery state handling.

Mahshar composes existing x402, MCP, Circle Gateway, USDC, Arc wallet, CCTP, and bridge infrastructure; it does not claim to have invented those technologies. See Reusable Arc primitives for implementation boundaries, verification status, and extraction requirements.

Arc Mainnet

Mahshar's production network is Arc Mainnet, chain ID 5042 (eip155:5042). Marketplace prices, buyer payments, platform accounting, and seller earnings are denominated in USDC.

Public Arc Mainnet Verification

Mahshar-owned:

• Platform EOA: 0x052650D1764406d702252B20B2294346A594A1ef
• Successful Arc Mainnet transaction: 0xa3efb83ad9ac4f2164d36b2579104cb7fb19c986cd623206b27387330e33fa33

The public address above is Mahshar's platform wallet on Arc Mainnet. The linked historical transaction is a successful call from that wallet to the official Arc Memo contract and can be independently verified in the Arc explorer. It is evidence of Mainnet operation and is not presented as independent proof of an x402 buyer purchase. Private signing material is never committed to the repository.

Automatic Memo writes have been removed. The linked transaction remains historical Mainnet evidence; paid API execution relies on Circle Gateway settlement and durable purchase, delivery, and response records, with no auxiliary platform-wallet transaction.

Official Arc/Circle contracts currently used by Mahshar:

These are official system contracts, not Mahshar contracts. Mahshar currently deploys no custom smart contract.

The installed Circle x402 runtime requires explicit Arc Mainnet RPC configuration and its current Mainnet compatibility settings. See .env.example and agent integration for the repository's operational contract.

Wallet Authentication

Normal browser authentication is designed to avoid repeated signature prompts:

Connect wallet
  → Sign one login challenge
  → Fixed eight-hour authenticated session
  → Use normal marketplace features without repeated wallet prompts

The server stores an opaque, wallet-bound session in an HttpOnly cookie. The session has a fixed expiry and does not become permanent through activity. Wallet changes isolate private state and require authentication for the newly connected wallet.

Fresh operation-specific signatures remain required for:

• Seller withdrawals.
• endpoint_url changes.
• auth_type changes.
• Stored credential, OAuth configuration, or provider connection changes.
• Authentication parameter-name changes.
• HTTP method changes.
• Dynamic-path, path-parameter, or query-parameter security-contract changes.

Normal navigation, private reads, and edits to names, descriptions, categories, prices, examples, documentation, and other presentation fields use the existing session.

Security Architecture

Mahshar includes layered controls for payment-aware proxying and wallet-scoped marketplace data:

• Canonical upstream target validation before credential injection.
• Traversal and encoded-traversal rejection.
• Declared dynamic-path and query-parameter contracts.
• Duplicate-query and credential-query collision protection.
• Seller credential non-disclosure.
• Purchase-scoped response recovery.
• Durable x402 settlement and delivery state.
• Atomic seller withdrawal reservations.
• Durable fencing for ambiguous external execution.
• Wallet-scoped private buyer and seller data.
• Independent wallet and trusted-IP rate-limit buckets where applicable.
• Bounded serialized response delivery.
• A bounded declarative path/query matcher rather than arbitrary request-path JavaScript regular expressions.
• Bounded response-retention and wallet-authentication pruning.
• Origin and Fetch Metadata checks for session-authenticated mutations.
• Fresh one-use operation authorization for sensitive listing changes.

These controls reduce identified risks; they are not a claim that the system is vulnerability-free. See Security documentation and SECURITY.md.

API Response Safety

Seller verification measures a representative serialized response. A response near Mahshar's delivery limit produces a seller-visible warning, and an over-limit representative response cannot complete verification. The runtime serialized-response limit remains authoritative for every paid delivery.

Verification observes one response and cannot guarantee that the upstream API will return the same size later.

Seller Withdrawals

Before external withdrawal work begins, Mahshar creates an atomic database reservation against the seller's currently available earnings. Concurrent requests cannot reserve the same earnings twice.

If submission or mint execution becomes ambiguous, the reservation remains locked in a recoverable submission_unknown or mint_unknown state. Confirmation and reconciliation are idempotent, and ambiguous money-moving operations are not blindly retried. The dashboard presents a status-check action instead of offering a duplicate withdrawal.

Machine Discovery

Autonomous clients should start with the public discovery endpoint and its current machine contract:

• MCP V1 endpoint: https://mahshar.xyz/api/mcp (stateless discovery through search_apis and get_api, real x402 challenge preparation and externally signed replay through execute_api_call, and purchase-capability recovery through get_purchase_response). Mahshar never accepts buyer private keys, signs automatically, or takes custody. A scripted external MCP Canary verified four paid Production executions covering HTTP Basic, custom API-key header, custom Authorization token, and multiple credential headers. All four responses and purchase-scoped recoveries succeeded, with matching application accounting and no observed duplicate payment or credential exposure. Gateway nanopayment balances updated; final onchain batch settlement was not independently verified. This was a scripted harness, not a fully autonomous AI agent. Earlier external-client verification also covered same-authorization replay without duplicate payment.
• OpenAPI document
• Agent integration guide

Runtime discovery and OpenAPI URLs are generated from the configured canonical marketplace origin.

Admin Acquisition

The first bounded Production mock canary completed successfully. Continuous draft-only acquisition is deployed. Execution follows operator-approved configuration and Admin Start/Stop controls. All server-only acquisition flags default to false; the existing bounded Discovery Worker remains the default. Enabling acquisition flags requires separate operator approval; deployment does not start the Worker. The consumed canary and historical invitations remain preserved.

The Brevo acquisition delivery integration is deployed with real sending disabled by default. Immutable acquisition drafts and simulated results remain separate from ordinary Admin Outreach messages. A separately authorized real delivery requires ADMIN_ACQUISITION_BREVO_ENABLED=true, verified sender/channel approval and current consent-backed recipient eligibility; a published email address is not permission to send. Only current, validated V2 template drafts can enter the linked Outreach reservation and one-shot transport path. Unsafe historical invitations remain blocked and all historical drafts remain unchanged. ADMIN_ACQUISITION_MODE requires exactly one authorized operating mode: ADMIN_ACQUISITION_CANARY or ADMIN_ACQUISITION_CONTINUOUS. Continuous mode reuses bounded cloud batches of up to 60 minutes, immediate eligible-run continuation, checkpoints, quotas and Start/Stop/Resume. It renders and saves the approved versioned English invitation template using current verified identity and contact evidence, independently of dispatch eligibility; draft preparation itself invokes no invitation inference and creates no reservation or dispatch. Company and product names require fresh provider-owned naming evidence; directory titles, OpenAPI titles and documentation headings are not independent naming proof. An unverified or conflicting company name uses a neutral greeting; an unverified or conflicting product name uses the approved generic API invitation. Application and database validation protect draft persistence, reservation and final transport, including historical drafts with unverified names. Historical Groq drafts remain preserved and qualification AI is unchanged. Directory contracts remain supporting evidence, historical skips remain available separately from current readiness, and Brevo stays deactivated. Existing provider-level reservation, DNC, suppression and sending authorization checks remain enforced. Rejected or uncertain real deliveries retain their reservations and are never automatically resent.

The Admin Worker dashboard separates distinct discovered/qualified providers, validated saved template and Groq invitations, and real accepted initial Outreach invitations. Simulated delivery never counts as a real send. Preparation counts distinguish immutable versioned template drafts from historical Groq drafts and require explicit persisted provenance; mock and historical unknown-origin drafts are excluded. Live Activity shows persisted checkpoints and Worker lifecycle events, with the latest three events initially and older saved history on demand. Exact executing stages are not inferred. Provider Activity lists each provider once by latest saved activity, shows three providers initially, and offers View All with pagination. View is read-only and includes saved research, provider activity timelines, exact invitation text and delivery details. Dashboard polling refreshes every 12 seconds while visible. Contact research distinguishes verified email, official form available, CAPTCHA/manual review required, unresolved research and no contact found. Provider View exposes saved official contact URLs; forms remain manual and a published email does not grant sending permission. Bounded commercial-first refresh revisits legacy no-email investigations while retaining technical qualification and contact history. Trusted provider reply counts remain unavailable until inbound sender identity is supported.

See Admin Acquisition controls and activation boundaries.

Admin Worker discovery has eight deployed, read-only catalog adapters: APIs.guru, Public API Lists, GitHub Public APIs, publicapis.dev's MIT repository, the Apify Store catalog, x402 List, PayAPI Market and bolthub. The additive source-allowlist migration is installed. Durable cursors, cached catalogs and bounded recovery share provider history, qualification, verified-contact and Pending Emails checks. Twelve other sources remain disabled. Discovery requires an authorized Worker Start; it neither executes paid catalog tools nor sends email automatically. Groq-backed qualification is separate from the deterministic acquisition canary and continuous Worker. See Admin Worker discovery.

Pending Emails is a separate Admin-only Automation page at /admin/operations/pending-emails for tracking emails sent externally. It uses verified, qualified Worker contacts independently of invitation drafts and preserves permanent manual-sending history without sending email or fabricating delivery receipts. The registry migration is installed in Production. Historical reconciliation/import and Worker processing require separate operator authorization; this deployment does not start the Worker or enable email delivery. See Admin Pending Emails.

Wallet Funding

Mahshar supports Circle Onramp funding for a connected Arc Mainnet wallet. It is available from the dashboard Wallet workspace and from the Buyer application when additional Arc USDC is needed.

The dashboard provides explicit Circle Bridge Kit flows for SDK-supported Mainnet USDC routes into the user's connected Arc Mainnet wallet. The dedicated Solana to Arc workspace moves supported SPL USDC from a connected Solana source wallet to that Arc wallet. Route availability is derived from the installed SDK rather than a fixed list in this README.

After USDC arrives on Arc, depositing it into the user's Gateway balance is a separate, explicit wallet action through Circle App Kit. Bridge and wallet funding flows remain separate from paid API execution; completing a bridge does not automatically purchase or call an API.

See dynamic Circle routes for implementation details and current limitations.

Repository Structure

The reviewer-oriented primitive inventory maps the reusable payment, proxy, discovery, MCP, integrity, and recovery patterns to their implementation files.

Database Setup

Follow Database bootstrap. A fresh environment requires the reviewed base schema followed by the complete ordered migration chain; migrations must not be skipped or reordered.

Security Documentation

• Wallet and marketplace authentication
• x402 settlement and delivery durability
• Risk-proportional controls
• Safe listing path and query patterns
• Recoverable response retention

Security reports should follow SECURITY.md.

Development

npm install
npm run dev

Type-check the project:

npx tsc --noEmit --incremental false --pretty false

Create a production build:

npm run build

Environment

Copy .env.example to .env.local and provide the required local values.

Never commit production secrets. Server-only private keys, service-role credentials, encryption material, API keys, internal API secrets, and cron authorization secrets must never use a NEXT_PUBLIC_ prefix.

Arc Mainnet RPC roles

• Passive browser Arc Wallet USDC reads use the optional, browser-safe NEXT_PUBLIC_ARC_MAINNET_RPC_URL, then Arc's official public RPC, an Arc-confirmed connected wallet provider, and finally Mahshar's fixed-purpose same-origin balance endpoint.
• The balance endpoint and other server-side Arc reads use the server-only ARC_MAINNET_RPC_URL. This value may contain provider credentials and is never exposed to the browser.
• Transaction simulations and receipt checks retain their operation-specific public clients; read failover does not select or submit a write transport.
• Transactions are still submitted only through the connected wallet after the existing chain-convergence and user-confirmation checks.

NEXT_PUBLIC_ARC_MAINNET_RPC_URL is optional. If configured, it must be a non-secret Arc Mainnet endpoint that permits browser CORS. The shared wallet-balance cache is intentionally short-lived (four seconds); successful balance-changing actions force a refresh.

License

MIT.