Belong.net Logo
MCP Cheat Sheet

MCP Tools — CheckIn

Tools for managing EVM-based CheckIn operations via MCP.

venue-deposit

  • Input: { chainId, ownerAddress, venueAddress, amount, rules: { paymentType, bountyType, bountyAllocationType, longPaymentType }, referralAddress?, toCustomerBounty: { visitBountyAmount, spendBountyPercentage }, toPromoterBounty: { visitBountyAmount, spendBountyPercentage }, dailyLimits?, hubId?, activityId?, gasless? }
    • Note: ownerAddress must belong to the authenticated user. Ownership checks use ownerAddress, while transactions are prepared for venueAddress.
    • Note: If an existing venue record is already owned by another user, request is rejected with ownership error.
    • Note: gasless enables sponsorship eligibility checks for this venue.
  • Output: { address_token, address, venueAddress, params: [venueInfo, protection], method: { name: "venueDeposit", ... }, totalAmountToApprove }
    • venueInfo: { rules, venue, amount, affiliateReferralCode, uri }
    • protection: { nonce, deadline, signature }
    • Note: venue-deposit is crypto-only and always returns signable transaction params for the venue deposit call.

pay-to-venue

  • Input: { chainId, customer, venueToPayFor, promoter?, amount, paymentIn }
    • Note: Requires authentication - customer address must be owned by authenticated user
  • Output: { address_token, address, params: [customerInfo, protection], method: { name: "payToVenue", ... } }
    • customerInfo: { paymentInUSDtoken: boolean, toCustomer: { visitBountyAmount: string, spendBountyPercentage: string }, toPromoter: { visitBountyAmount: string, spendBountyPercentage: string }, customer: address, venueToPayFor: address, promoterReferralCode: bytes32, amount: string }
    • protection: { nonce, deadline, signature }

distribute-promoter-payments

  • Input: { chainId, promoter, venue, paymentInUSDC }
  • Output when the backend submits the sponsored transaction: { address, submitted: true, txHash, transactionStatus, signatureExpiresAt? }
  • Output when the request falls back to client submission: { address, params: [promoterInfo, protection], method: { name: "distributePromoterPayments", ... } }
    • promoterInfo: { paymentInUSDtoken: boolean, promoterReferralCode: bytes32, venue: address, amountInUSD: string }
    • protection: { nonce, deadline, signature }
    • Note: backend submission is used only when signer policy allows it and the venue sponsor has gasless enabled, distribute_promoter_payments allowed, and enough gas-bank balance. Otherwise the response remains client-submitted transaction params.
    • Note: clients must branch on submitted: true; do not assume params is always present.

venue

  • Input: { address, chainId }
  • Output: { venue, hubId?, activityId?, gasless, rules, remainingCredits, toCustomerBounty: { visitBountyAmount: number, spendBountyPercentage: number }, toPromoterBounty: { visitBountyAmount: number, spendBountyPercentage: number }, venueId, venueTokenBalance, usdTokenDeposits, longDeposits }
    • Note: venueTokenBalance is the ERC-1155 venue credit balance.
    • Note: usdTokenDeposits and longDeposits are the current venue balances remaining in escrow.

emergency-cancel-payment

  • Input: { chainId, venue, promoter }
  • Output: currently returns a backend-disabled error
    • Note: The route is kept for compatibility, but server-side on-chain execution is temporarily disabled.

update-venue-rules

  • Input: { chainId, venue, rules: { paymentType, bountyType, bountyAllocationType, longPaymentType }, toCustomerBounty: { visitBountyAmount, spendBountyPercentage }, toPromoterBounty: { visitBountyAmount, spendBountyPercentage } }
  • Output: { address, params: [rules], method: { name: "updateVenueRules", ... }, venueId, toCustomerBounty: { visitBountyAmount, spendBountyPercentage }, toPromoterBounty: { visitBountyAmount, spendBountyPercentage } }
    • Note: Updates database with validated bounty allocations and returns transaction parameters for blockchain update

deploy-promoter

  • Input: { chainId, promoter }
  • Output: { address, method: { name: "createReferralCode", ... } }

find-promoter

  • Input: { chainId, promoter }
  • Output: "success" | "failed"

update-venue-settings

  • Input: { ownerAddress, venueAddress, chainId, paymentType?, longPaymentType?, toCustomerBounty?: { visitBountyAmount, spendBountyPercentage }, toPromoterBounty?: { visitBountyAmount, spendBountyPercentage }, dailyLimits?, hubId?, activityId?, gasless? }
    • Note: ownerAddress must belong to the authenticated user. Ownership checks use ownerAddress, while on-chain venue rules apply to venueAddress.
    • Note: If an existing venue record is already owned by another user, request is rejected with ownership error.
    • Note: All fields are optional, but at least one must be provided: paymentType, longPaymentType, toCustomerBounty, toPromoterBounty, dailyLimits, hubId, activityId, or gasless.
    • Note: toCustomerBounty / toPromoterBounty are optional and used when reward config needs to be changed.
  • Output (if rules changed): { venueAddress, chainId, venueId, gasless, rules: { paymentType, bountyType, bountyAllocationType, longPaymentType }, dailyLimits?, hubId?, activityId?, toCustomerBounty?: { visitBountyAmount, spendBountyPercentage }, toPromoterBounty?: { visitBountyAmount, spendBountyPercentage }, address, params: [rules], method: { name: "updateVenueRules", ... } }
  • Output (if rules unchanged): { venueAddress, chainId, venueId, gasless, rules: { paymentType, bountyType, bountyAllocationType, longPaymentType }, dailyLimits?, hubId?, activityId?, toCustomerBounty?: { visitBountyAmount, spendBountyPercentage }, toPromoterBounty?: { visitBountyAmount, spendBountyPercentage } }
    • Note: Replaces update-accepted-payments and update-rewards. Updates payments, rewards, and additional settings in a single call. Automatically determines bountyType and bountyAllocationType from bounty values. Updates database and on-chain rules (if changed). Returns transaction parameters only if rules changed.
    • Note: For bountyType = Both (3), bounty values must be non-negative; active allocation can use visit, spend, or both.

get-belong-check-in-storage

  • Input: { chainId }
  • Output: { contracts: { factory, escrow, staking, venueToken, promoterToken, longPF }, paymentsInfo: { dexType, slippageBps, router, usdToken, long, maxPriceFeedDelay, poolKey, hookData }, fees: { referralCreditsAmount, affiliatePercentage, longCustomerDiscountPercentage, platformSubsidyPercentage, processingFeePercentage, buybackBurnPercentage }, helperContract, checkInContract }
Copyright © 2026