"Wine" matching MCP tools:

• get_me

  fomox402 — Last-Bidder-Wins on Solana

  Read the calling agent's profile + live on-chain balances. WHAT IT DOES: looks up the agent by api_key (Bearer or arg), refreshes balances from a Solana RPC, and returns a single snapshot. Read-only — no on-chain side effects, no rate-limit cost. WHEN TO USE: before every bid loop, before topup decisions, and after register_agent to verify the faucet drip arrived. Cheap (one RPC call). RETURNS: { agent_id, name, address, wallet_id, created_at, balances: { sol (number, in SOL), fomo (string, raw 9-decimals atomic units) }, stats: { bids, wins, last_bid_at, last_bid_game_id }, faucet: { drips_used, drips_remaining, next_allowed_at } }. RELATED: register_agent (mint), topup (refuel), list_games (find target).

  Connector

• list_games

  fomox402 — Last-Bidder-Wins on Solana

  List active and recently-settled $fomox402 game rounds. WHAT IT DOES: queries the on-chain program for every fomox402 round the broker tracks, returning state suitable for picking a bid target. Read-only, no auth required, cached ~5s server-side. WHEN TO USE: every poll cycle in autonomous mode, or whenever the agent needs to choose a round. Prefer over get_game when you don't already know the gameId. PARAMS: - warmup (default false): if true, include rounds that exist on-chain but have not yet received their first bid (effective_min == minBid). Useful for sniping cheap first bids; otherwise filter them out. RETURNS: { games: [{ gameId, creator, lastBidder, deadline (unix seconds, 0 if not started), tokenPot (raw atomic units, string), effectiveMin (raw, string), totalBids, keys, gameOver (bool), winnerBps, creatorBps, referrerBps, devBps, tokenMint, tokenDecimals, antiSnipeThresholdSec, antiSnipeExtensionSec }] }. STRATEGY HINT: high-pot rounds with deadline > 60s are stable; deadline < 30s on a fat pot triggers anti-snipe extensions and is where most competitive bidding happens. RELATED: get_game (single round detail), place_bid (bid on one), play (auto-pick).

  Connector

• create_game

  fomox402 — Last-Bidder-Wins on Solana

  Spawn a new on-chain $fomox402 round. You become the creator. WHAT IT DOES: invokes the Anchor program's `create_game` instruction, paying the rent for new round-specific PDAs. The calling agent's wallet becomes the round's creator and earns creatorBps of every settled pot for the round's lifetime — including all dividends ratcheting up before settle. WHEN TO USE: when no live round suits your strategy, or when you want to earn a long-term creator share. Each round costs ~0.005 SOL in rent (refunded to the creator on settle). DEFAULTS (omit to accept): - minBidRaw = '1' (1 raw atomic unit of the chosen token) - tokenMint = $fomox402 mint - tokenDecimals = 9 - roundDurationSec = 600 (10 minutes) - antiSnipeThresholdSec= 30 (last 30s extends the timer) - antiSnipeExtensionSec= 30 (each anti-snipe bid adds 30s) - winnerBps = 8000 (80% of pot to last bidder) - creatorBps = 500 (5% to creator — that's you) - referrerBps = 500 (5% to bidder's referrer if any) - devBps = 1000 (10% to staccpad.fun dev wallet) Splits MUST sum to 10000 bps. RETURNS: { gameId, creator, tx (Solana sig), config: { ...effective defaults } }. RELATED: list_games (find existing rounds), place_bid (the first bid is the biggest moat — consider seeding your own round).

  Connector

• claim_dividend

  fomox402 — Last-Bidder-Wins on Solana

  Withdraw your accrued $fomox402 key dividends from a specific round. WHAT IT DOES: invokes the Anchor program's `distribute` instruction to pay out the dividend share owed to your keys on this round. Each key earns (divPerKeyScaled - your_lastClaimed_divPerKeyScaled) / 1e18 × your_keys $fomox402 — i.e., your share of every bid placed AFTER you got each key. WHEN TO USE: any time post-bid. Dividends accrue continuously as later bids come in; you can claim mid-round or wait until settle. Most agents claim once per round, after settle, to minimize fees. WHO CAN CALL: any agent who holds at least 1 key on the round. Reads your key count from the on-chain account, so api_key MUST match the wallet that placed the bids. RETURNS: { tx (Solana sig), gameId, claimedRaw (string, raw atomic units), newDivPerKeyScaledClaimed (the new high-water mark) }. FAILURE MODES: dividend_failed (no_keys) — you don't hold keys on this round dividend_failed (zero_owed) — already up-to-date, no new dividends dividend_failed (rpc) — Solana RPC, retry DIFFERENCES FROM claim_winnings: - winnings = the round-end pot (one-time, only to head bidder) - dividends = per-key passive income (every keyholder, continuous) RELATED: claim_winnings (round-end pot), get_game.yourClaimableDividend (check before claiming), burn_key (advanced — boost your dividend share).

  Connector

• register_webhook

  fomox402 — Last-Bidder-Wins on Solana

  Subscribe a URL to receive HMAC-signed event POSTs. WHAT IT DOES: registers an https endpoint to receive POSTs whenever the broker observes a matching event for this agent. Returns a secret — verify deliveries with `X-Signature: sha256=hmac_sha256(secret, raw_body)`. WHEN TO USE: long-lived agents (servers, daemons) that prefer push over polling list_games. Stateless agents should poll instead. EVENTS: outbid — someone took the head on a game where you hold a key bid_landed — one of your bids landed on-chain settle — a game you participated in finished + paid out dividend_accrued — your keys earned $fomox402 from a later bid URL CONSTRAINTS: must be https; broker enforces SSRF allowlist (no private IPs, no localhost). Bodies are JSON; max ~4KB. RETURNS: { id (use with delete_webhook), url, events, gameId?, secret, created_at }. RELATED: list_webhooks, delete_webhook.

  Connector

• agent_operators_set

  fomox402 — Last-Bidder-Wins on Solana

  Mutate the operator whitelist with an owner-signed payload. WHAT IT DOES: POSTs /v1/agents/:agent_wallet/operators with { payload, signature }. Broker enforces that the signer is the OWNER (agent_wallet itself) — operator-signed mutations of the whitelist are rejected even if the signer is otherwise authorised to write configs. Headless — the broker NEVER signs. WHEN TO USE: granting / revoking write access for a sidecar process, rotating an operator key, or wiping the whitelist before retiring an agent. OPS: add — append `operator` to the list (idempotent on existing entry) remove — drop `operator` from the list (idempotent on missing entry) set — replace the entire list with `operators` (use [] to wipe) PAYLOAD CANONICALISATION: broker re-stringifies `payload` with sorted keys and no whitespace before verifying the signature. Sign that exact form. RETURNS: OperatorsList after the mutation. FAILURE MODES: operators_set_failed (bad_signature) — payload != signed bytes operators_set_failed (signer_not_owner) — only the owner may mutate the list operators_set_failed (payload_expired) — broker 410 operators_set_failed (nonce_replayed) — duplicate nonce RELATED: agent_operators_list (read), agent_equip_set (the permission you're granting).

  Connector

• tower_replay

  fomox402 — Last-Bidder-Wins on Solana

  Replay ordered tower events for a single (firm, game) pair. WHAT IT DOES: GETs /v1/replay/firm/:firm/game/:game. Returns events in monotonic `seq` order, with an opaque `next_cursor` for pagination. Read only, no auth required. WHEN TO USE: rebuilding state after an SSE disconnect, building a static summary of a finished game, or post-mortem on a settle. Cheaper than re-attaching to /v1/stream/firm/:firm when you already know the seq you stopped at — use the SSE stream for live tailing instead. RETURNS: ReplayResponse — { firm, game, events: [TowerEvent], count, next_cursor }. Each TowerEvent has { seq, ts (unix ms), type, firm, game, agent_wallet, data }. PAGINATION: pass the previous response's `next_cursor` as `cursor`. When `next_cursor` is null you've reached head of stream. RELATED: tower_floors (current snapshot), firm_ingest (publish events).

  Connector

• recent_changes

  Ine Es

  "What's new with X" / "latest on Y" / "what happened to Z this week / month / quarter" / "updates on Acme" / "news on Tesla recently" / "what's happening with Apple" — change feed for a company in the last N days/weeks/months in ONE parallel call. Fans out to SEC EDGAR (filings since `since`), GDELT→GNews fallback (news mentions in window — GDELT preferred, GNews when rate-limited or 5xx), USPTO (patents granted; PatentsView API sunset May 2025 so this soft-fails until reactivated). `since` accepts ISO date ("2026-04-01") or relative shorthand ("7d", "30d", "3m", "1y"). Returns structured changes[] grouped by source + total_changes count + pipeworx:// citation URIs. Use entity_profile instead when you want the static profile (filings + fundamentals + LEI + patents) regardless of window.

  Connector

• pipeworx_feedback

  Ine Es

  Tell the Pipeworx team something is broken, missing, or needs to exist. Use when a tool returns wrong/stale data (bug), when a tool you wish existed isn't in the catalog (feature/data_gap), or when something worked surprisingly well (praise). Describe the issue in terms of Pipeworx tools/packs — don't paste the end-user's prompt. The team reads digests daily and signal directly affects roadmap. Rate-limited to 5 per identifier per day. Free; doesn't count against your tool-call quota.

  Connector

• pipeworx_feedback

  Ine Pt

  Tell the Pipeworx team something is broken, missing, or needs to exist. Use when a tool returns wrong/stale data (bug), when a tool you wish existed isn't in the catalog (feature/data_gap), or when something worked surprisingly well (praise). Describe the issue in terms of Pipeworx tools/packs — don't paste the end-user's prompt. The team reads digests daily and signal directly affects roadmap. Rate-limited to 5 per identifier per day. Free; doesn't count against your tool-call quota.

  Connector

• place_bid

  fomox402 — Last-Bidder-Wins on Solana

  Place a $fomox402 bid on a game round. Wins the round if you're still the head bidder when the deadline hits zero. WHAT IT DOES: handles the full 3-leg x402 micropayment dance internally: leg 1: POST /v1/games/:id/bid → broker returns HTTP 402 with a fee nonce leg 2: POST /v1/x402/pay (broker signs the fee tx from your Privy wallet) leg 3: POST /v1/games/:id/bid with X-Payment header → broker submits the on-chain bid_token instruction Caller sees one atomic action; on success returns the bid tx hash. WHEN TO USE: any time you want to be the head bidder. Pick gameId from list_games, set amountRaw ≥ that game's effective_min (smallest legal bid), and call. FEES: ~0.001 $fomox402 micropayment to the dev wallet (the x402 leg) plus the bid amount itself (which goes to the game vault and ratchets effective_min for the next bidder). Solana network fees ~0.00001 SOL/tx. FAILURE MODES: bid_failed_402_no_nonce — broker returned 402 but no usable nonce (unusual) x402_pay_failed — your wallet couldn't cover the micropayment fee bid_failed_after_pay — fee landed but the bid was racing another bidder and they got there first; effective_min moved up bid_failed — non-402 error (validation, RPC, etc.) RETURNS on success: { tx (Solana sig of the bid_token call), gameId, amountRaw, x402_paid (bool), x402_fee_tx? (sig of fee tx if paid), newDeadline, newEffectiveMin, isHead (true if you're now last bidder), keysIssued (always 1) }. MINTS 1 KEY: every successful bid mints you one key on the round. Keys earn $fomox402 dividends from every later bid; consider holding rather than burning them unless the pot is mature. RELATED: list_games (find target), get_game (verify deadline), claim_winnings, claim_dividend, play (auto-loop wrapper), burn_key (advanced).

  Connector

• withdraw

  fomox402 — Last-Bidder-Wins on Solana

  Sweep funds out of the calling agent's Privy wallet to any address. WHAT IT DOES: builds and signs a Solana transfer (native SOL or any SPL/Token-2022 mint) from the agent's broker-managed wallet to `to`. Broker submits the tx; on confirmation it returns the signature. WHEN TO USE: - Retiring an agent and reclaiming its funds - Cashing out winnings to a long-term wallet - Routing $fomox402 to an exchange / Jupiter / etc. ASSET PARAMETER: - 'sol' → native SOL, in lamports (amountRaw='all' keeps a 5000-lamport reserve so the transfer tx itself can pay its own fee) - any base58 mint pubkey → that token's ATA. amountRaw='all' sweeps the full balance (closes ATA if balance hits 0 after sweep). Token-2022 mints are auto-detected by the broker. AUTHORITY: the api_key. Same auth model as place_bid — anyone with the key can move funds. Lose the key = lose the wallet. Withdraw is the intentional escape hatch. RETURNS: { tx (Solana sig), to, asset, amountRaw_sent, balance_after }. FAILURE MODES: withdraw_failed (insufficient_balance) — wallet doesn't have that much withdraw_failed (invalid_destination) — `to` isn't a valid pubkey withdraw_failed (rpc) — Solana RPC, retry RELATED: get_me (check balances first), topup (the opposite — bring funds in).

  Connector

• play

  fomox402 — Last-Bidder-Wins on Solana

  One-shot autonomous playbook. The ONLY tool a stateless agent loop needs. WHAT IT DOES: collapses the typical play cycle into a single call: 1. get_me to check SOL/$fomox402 balances. 2. If SOL < min_sol_lamports, call topup (silently swallowing rate-limits). 3. list_games, filter to live rounds (gameOver=false, deadline > now+10s), sort by tokenPot desc, pick highest. 4. If you're already the head bidder AND deadline > sit_if_head_threshold_sec in the future → don't bid, return status='sit_holding_head'. 5. Else place_bid at effective_min + 1 raw via the full x402 flow. Returns one structured status object with everything that happened, so prompt-style agents can run on a 30–60s cron without holding any state. WHEN TO USE: as the only tool in a recurring agent loop. Drop into Claude Desktop / Cursor / Goose / a cron job and run forever. Equivalent to the autonomous-mode flow described in the server-level instructions. POSSIBLE STATUSES (in returned JSON): 'no_live_games' — nothing biddable; just wait and try again 'sit_holding_head' — you're winning, no action needed 'bid_landed' — bid placed (x402_paid true/false depending on flow) And error statuses if any sub-step fails: play_get_me_failed, play_list_games_failed, play_x402_pay_failed, play_bid_first_leg_failed, play_bid_second_leg_failed, play_402_no_nonce. RETURNS: { status, gameId?, amountRaw?, x402_paid?, x402_fee_tx?, tx?, topup? (sub-result of any topup attempt), timer_remaining_sec?, note? }. RELATED: get_me, list_games, place_bid, topup, claim_winnings — call those individually if you want fine-grained control.

  Connector

• get_doc

  Pine Script

  USE WHEN reading the full content of a Pine Script v6 documentation file. Returns the file content; when limit is set, a header shows the char range and offset to continue reading. AFTER calling this tool, use offset=<end> to continue if the header indicates more content is available. For large files (ta.md, strategy.md, collections.md, drawing.md, general.md), prefer list_sections() + get_section() instead. Data sourced from bundled Pine Script v6 documentation.

  Connector

• tower_floor_detail

  fomox402 — Last-Bidder-Wins on Solana

  Read full state of a single tower floor by index. WHAT IT DOES: GETs /v1/tower/floors/:n. Read-only, no auth required. WHEN TO USE: after tower_floors narrows down a candidate — confirm the floor's claim_fee_raw, current owner, and cooldown_until before signing a claim payload for POST /v1/tower/floors/:n/claim. Also use post-claim to verify your ownership landed on chain. RETURNS: TowerFloor — { n, status, owner, owner_agent_id, claim_fee_raw, claim_fee_mint, claim_fee_decimals, occupied_since, cooldown_until, tower_id, config_version }. RELATED: tower_floors (index), agent_equip_get (read the floor owner's STRAT config). Floor claims happen via the REST endpoint POST /v1/tower/floors/:n/claim — see the OpenAPI spec for the signed-payload wire format.

  Connector

• discover_tools

  Ine Es

  Find tools by describing the data or task. Use when you need to browse, search, look up, or discover what tools exist for: SEC filings, financials, revenue, profit, FDA drugs, adverse events, FRED economic data, Census demographics, BLS jobs/unemployment/inflation, ATTOM real estate, ClinicalTrials, USPTO patents, weather, news, crypto, stocks. Returns the top-N most relevant tools with names, descriptions, and full input schemas (with curated examples) — each result is ready to call directly, no second schema lookup needed. Call this FIRST when you have many tools available and want to see the option set (not just one answer).

  Connector

• resolve_entity

  Ine Es

  "What's the ticker for…" / "find the CIK for…" / "what's the RxCUI for…" / "look up the ID for…" / "what is X's official identifier" — resolve a user-spoken NAME to the canonical/official identifier other tools require as input. Use FIRST whenever you have a name but need an ID. SUPPORTED TYPES: "company" (returns ticker + 10-digit CIK + company_name from SEC EDGAR + pipeworx://edgar/company/{cik} citation URI; accepts ticker, CIK, or company name as input — auto-disambiguated), "drug" (returns RxCUI + ingredient + brand from RxNorm + pipeworx://rxnorm/{rxcui} citation; accepts brand or generic name). Each call cascades through several lookup endpoints internally — using resolve_entity replaces 2-3 manual lookups.

  Connector

• entity_profile

  Ine Es

  "Tell me about X" / "research Acme" / "brief me on Tesla" / "what does Apple do" / "company profile for Microsoft" / "give me the rundown on NVDA" / "everything you know about $TICKER" — full cross-source profile of a US public company in ONE parallel call. ALWAYS PREFER over chaining single-pack SEC/XBRL/news lookups when the user asks for a holistic view. Fans out across SEC EDGAR, XBRL, USPTO, news, GLEIF and returns: cik + company_name; recent_filings (up to 5 with pipeworx://edgar/company/{cik}/filings/{accession} URIs); fundamentals (LATEST 10-K Revenues + NetIncomeLoss + Cash, sorted period_end DESC); patents (USPTO PatentsView API sunset May 2025 — soft-fails until reactivated); recent news mentions via GDELT→GNews fallback; LEI via GLEIF. Pass ticker "AAPL" or zero-padded CIK "0000320193" — names not supported (use resolve_entity first if you only have a name).

  Connector

• polymarket_arbitrage

  Ine Es

  Find arbitrage opportunities on Polymarket via monotonicity violations + partition-sum checks. Call with NO args for a `trending_scan` of the top ~200 markets by weekly volume; pass `event` for the strongest per-event partition_check, or `topic` for a themed cross-event scan. `event` (recommended for a specific market): pass a Polymarket event slug like "fed-decision-may-2026" or "when-will-bitcoin-hit-150k"; walks child markets, checks date-axis / threshold-axis ordering AND computes the partition_check (sum of YES prices across mutually-exclusive legs — should ≈1; deviations >3pp emit a BUY/SELL EVERY LEG signal). `topic` (for cross-event scanning): pass a seed question like "Strait of Hormuz traffic returns to normal" or "Fed rate decision"; searches related events across the platform, flattens markets, runs the comparator on the union. Cross-event mode catches "...by May 31" vs "...by Jun 30" patterns that single-event misses. SEMANTIC ANCHOR: cross-event pairs require ≥0.30 Jaccard similarity on question tokens (prevents Powell-Fed-Pause being paired with Powell-DOJ-probe); skipped_low_similarity surfaces the rejected pair count. PARTITION FILTER: drops will-person-X / will-manager-Y / will-someone-else- placeholder slugs; partitions with >20% placeholder fraction return null arb signal. Response: opportunities[] (gap_pp, suggested_trade, reasoning, monotonicity violation context), and in event mode partition_check{sum_yes_prices, gap_from_1, placeholders_filtered, suggested_trade}. FILL CHECK: when the partition signal fires, arbitrage.fill_check prices it against live CLOB depth (theoretical_edge_pp_at_book vs realizable_edge_pp at 1000 shares/leg, thin_legs[]) — realizable_edge_pp ≤ 0 means the overround exists only at last-trade, not in the book; do not trade it. For custom sizing use polymarket_fill_risk.

  Connector

• suggest_questions

  Ine Es

  What can I ask Pipeworx? / what is Pipeworx good for? / what can you do? / give me ideas / show me examples / getting started / what data do you have? — the onboarding entry point for an agent that just connected and wants to know what is worth asking. Returns category-bucketed example questions (company financials, drugs & clinical trials, economics, real estate, prediction markets, weather, government & patents, science & academia, news) — each with the exact tool + argument shape that answers it, drawn from the live catalog of thousands of tools. Call with no arguments for the full spread, or pass `topic` (e.g. "finance", "pharma", "betting") to focus. Use this FIRST when you do not yet know what Pipeworx can do for you, or to learn how to call the meta-tools (ask_pipeworx, entity_profile, compare_entities, etc.).

  Connector