Spoofy MCP Server

For an automation of kind per_link ("a new post each run"): the link of its next run — the new post, video or track the user wants it on. The run goes out at once as an ordinary order at the price the plan was set up with, charged from the balance (one run of the plan the user already agreed to; nothing else is charged). The link must be one the plan takes (its platform and kind: a post plan takes posts, never a profile or a token page), and each link takes one run only. Errors: not_per_link, wrong_platform / wrong_link_kind (the message says what the plan takes), link_already_used, no_runs_left, automation_ended, automation_paused. A short balance keeps the run waiting and pauses the plan until a top-up covers it; it then goes by itself.

Set up an automation: Spoofy places ordinary orders for the user on a plan. Kinds: spread (a total over time, e.g. {"kind":"spread","service":12,"link":"…","quantity":10000,"over":"3d"}; pace "steady" or "front" for an S-curve growth plan, "launch" for about half straight away then each run smaller), scheduled (one order at start_at), recurring (every "1d"/"6h"/"1w", optional at "14:00" + timezone, with times, until or budget), split (past one order's max), campaign (steps [{service, link, quantity, offset_minutes, over_minutes}] or template: "token-launch" + links), keep_above (target + days + budget; public Telegram channels/groups and YouTube videos only), feed (a public Telegram channel, YouTube channel, CoinMarketCap Community profile, Pinterest profile or board, Bluesky account, Reddit user or subreddit, RSS feed, or an X account while X's API is on: every new post gets quantity of service — or quantity_min + quantity_max, a random whole number in that range for each post; spread_minutes (30–360) + parts (2–10) splits each post's order into parts at random times within the window, each at least the service's minimum (pace "launch": the first part about half); delay_min_minutes + delay_max_minutes start it a random number of minutes after the post; posts: the next N posts, then it completes — "likes on my next 30 posts" is posts 30, no days needed; max_per_day; budget, needed only without posts; change them later with update_automation), per_link (a new post each run: service, quantity each run, runs, optional every "daily" + at "14:00" and days; no link now — each run goes out when its post's link is sent with add_automation_link; runs not used are never charged). For new posts elsewhere (Instagram, TikTok …) order an "On new posts" service instead (find_services; fields username, min, max, posts, delay): the provider watches the account. Service ids come from find_services. THIS SPENDS THE USER'S REAL BALANCE: each run is charged when it goes (never above the planned price). Call first without confirm (or with dry_run: true): you get the plan — every run's time, size and cost, the total and the balance. Tell the user the total and timing and get their explicit OK, then call again with confirm: true and an idempotency_key. Errors: bad_automation / bad_schedule (the message says what to change), budget_required, count_not_readable (keep_above only reads those links), bad_feed (a feed Spoofy does not read; X only while its API is on), too_many_automations, over_order_cap / platform_not_allowed / read_only_key (this key's limits).

One automation with its timeline: every run, the order it placed and what that delivered, or why a run waits or was skipped (balance, budget, a daily limit).

Change a new-post automation's settings (kind feed) while it runs, as PATCH /api/v1/automations/{id} takes them: each post's amount — quantity, or quantity_min + quantity_max (each post gets a random whole number in the range, within one delivery of the service) —, spread_minutes (30–360; 0 = all at once) + parts (2–10: each post's order in parts at random times within the window, each part at least the service's minimum, fewer parts for a small amount) and their pace (even, or "launch": the first part about half), delay_min_minutes + delay_max_minutes (the first part a random number of minutes after the post), posts (the next N posts), max_per_day and budget. Changes apply to posts found from now on; parts already planned keep their plan. Never charged above the price the plan promised. Call first without confirm: you get the settings in words and what they can cost. Tell the user. When they can cost more than its limit (change.budget.raise), the user must agree to the higher limit: then call with confirm: true and settings.confirm_budget: true (or a budget the user chose). Errors: not_editable (another kind, or it has ended), bad_quantity (outside one delivery of the service), bad_automation / bad_schedule (the message says what to change), confirm_budget (the limit would rise without the user's yes).

Stop an automation for good: every future run is cancelled. Orders already running finish, unless cancel_running: true asks those that allow it to cancel too (the undelivered part is refunded). Confirm with the user first.

Ask to cancel a pending or processing order (only when the order says cancelable: true). Whatever was not delivered is refunded to the balance in USD. Confirm with the user first.

Place an order. THIS SPENDS THE USER'S REAL BALANCE (USD) and starts delivery to the link; it cannot be undone except by cancel_order where the service allows it. Before calling: get the price with get_quote and get the user's explicit agreement to that price. Then call with `confirm: true`. Without `confirm: true` nothing is charged and you get the price back so you can ask. `dry_run: true` validates everything (link fits the service, quantity range, key limits) and returns price, balance and whether it is enough — never charges. Pass a fresh `idempotency_key` per intended order so a retry never charges twice. Errors: insufficient_balance (details.shortfall = USD to top up — call get_top_up_info), over_order_cap / over_daily_cap / platform_not_allowed / read_only_key (this key's limits), wrong_platform, bad_quantity, link_busy (too many running on that link: details.available), chain_not_supported. Services with an `input` (find_services) take their fields in `inputs`: `comments` (custom comments, one per line or a list — their number is the quantity), `usernames` (accounts to mention), `hashtag`, `username`, `answer_number` (poll option, 1 = first), `runs` + `interval` (spread out; quantity is per run), or subscription terms (`min`, `max`, `posts`, `old_posts`, `delay`, `expiry`: auto-engagement on future posts, paid up front for at most max × posts). Text we post for the user is checked first: text_blocked = refused, nothing charged; a dry run says `text_review: true` when our team may check it before it starts. Errors also: bad_inputs, inputs_required. Done-for-you services (kind "manual": listings) need a form with images — those are ordered on the website.

Place up to 25 orders in one go — several services, one link or several — paid together from the balance. THIS SPENDS THE USER'S REAL BALANCE (USD) and starts delivery. Use it when the user wants several things at once (e.g. followers + likes + views for one account); for one order use place_order. Every order is checked first at today's price: if any one cannot go (link does not fit, quantity out of range, too many running on one link, balance short…) NONE is placed and each item says why. Then they are placed one by one; should one fail at that very moment, the others stay placed and that one says why (nothing charged for it). Without `confirm: true` nothing is charged: you get each price and the total so you can ask the user. With `confirm: true` also pass `max_total` = the total the user agreed to; if prices moved above it nothing is placed (price_changed). Pass a fresh `idempotency_key` per intended batch: a retry with the same key never places an order twice. Each item takes what place_order takes: `service`, `link`, `quantity`, or `inputs` for services with an `input`. Errors: batch_invalid (details.items says which and why), insufficient_balance (details.shortfall = USD to top up — call get_top_up_info), order_rate_limited, over_daily_cap, price_changed, idempotency_conflict.

The user's automations, newest first, with progress (runs placed, delivered), spend against budget and the next run. Filter by status.

The user's spendable balance in USD. Orders are paid from it.

Status and progress of one order: status (pending, processing, completed, partial, refunded, cancelled, failed), start count, delivered, remains, charge and refunds in USD, and whether it can be cancelled now.

The user's orders, newest first. Filter by status; page with `before` = the smallest order number already seen.

Stop placing new runs until it is resumed (orders already running keep delivering). Nothing is charged while paused.

Exact price in USD for a quantity of one service (from find_services). Checks the quantity is within the service range. Free; spends nothing. Use it to tell the user the cost before place_order. For services with an `input`, pass the same `inputs` as for place_order; the quantity is then the units charged: the number of comments or usernames, per run × runs, or for subscriptions max × (posts + old_posts).

Carry on with a paused automation: the rest of the plan moves by the time it was paused. After a price change, resuming accepts the new price for the runs left — tell the user first.

Find what Spoofy can do for a link or a goal, with prices. ALWAYS call this first: service ids come from here. Give `link` (any profile, post, video, channel, group, token page or website URL) and/or `goal` in plain words, e.g. "500 followers on my tiktok" or "cheap views for this YouTube video". With a link you only get services that fit that exact link (a profile link gets followers, a post link gets likes/views). Returns matching services: `service` (the id to quote/order), name, tier (basic/standard/premium), pricePer1k (USD per 1,000 units), min/max quantity, start time, speed, preset packages with USD prices, and — when the goal names a quantity — a `suggestion` with the exact total for that quantity. A service with an `input` needs those fields in place_order `inputs` (custom comments, accounts to mention, a hashtag, a poll option, runs, subscription terms); `input.quantity` says where the quantity comes from. `query` narrows to services whose words match, e.g. "usa", "brazil", "real", "story". Free; spends nothing. On every service, counts can drop after delivery and drops are not replaced — tell the user before they buy followers, members or likes.

How the user adds money to the balance: stablecoins (USDC, USDT or USDG, on the networks that are on) sent to their own deposit address — one address for every EVM network, another on Solana — credited 1 coin = $1, plus the top-up page link. Use it when an order fails with insufficient_balance. Tell the user to send only the listed coin on the listed network. You cannot move money yourself — give the user the address or the link.