Skip to main content
Glama
134,441 tools. Last updated 2026-05-23 17:13

"Wine" matching MCP tools:

  • 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
  • Write a STRAT config with a caller-signed payload (CAS-protected). WHAT IT DOES: POSTs /v1/agents/:agent_wallet/config with { payload, signature }. Broker verifies the signature against the agent's owner key OR any wallet on the operator whitelist (see agent_operators_list), checks `expected_version` against the current AgentConfig.version, and writes the new config atomically. Headless — the broker NEVER signs. WHEN TO USE: after a tower floor is claimed, push the STRAT config the tower v0 worker should run. Write again whenever you want to retune the strategy. Refetch with agent_equip_get on a 409 conflict and retry with the bumped expected_version. PAYLOAD CANONICALISATION: broker re-stringifies `payload` with sorted keys and no whitespace before verifying the signature. Sign that exact form. RETURNS: AgentConfig — same shape as agent_equip_get, with `version` incremented to the new high-water mark. FAILURE MODES: equip_set_failed (bad_signature) — payload != signed bytes equip_set_failed (signer_not_authorized) — signer is neither owner nor operator equip_set_failed (version_mismatch) — refetch + retry (broker 409) equip_set_failed (payload_expired) — broker 410 equip_set_failed (nonce_replayed) — broker rejected duplicate nonce RELATED: agent_equip_get (read current version), agent_operators_set (grant another wallet permission to write configs on this agent's behalf).
    Connector
  • Read an agent's STRAT config (the parameters its tower floor runs on). WHAT IT DOES: GETs /v1/agents/:agent_wallet/config. Public read — anyone can audit any agent's strategy. The returned `version` is the CAS token you pass to agent_equip_set as `expected_version` on the next write. WHEN TO USE: before agent_equip_set (to compute the next expected_version), or just to inspect what a competitor's floor is configured to do. RETURNS: AgentConfig — { agent_wallet, version, updated_at, updated_by, config: { strategy, max_bid_raw, cooldown_sec, aggression_bps, custom } }. FAILURE MODES: equip_get_failed (404) — agent has never written a config; treat the version baseline as 0 on the first write. RELATED: agent_equip_set (write), agent_operators_list (who can write).
    Connector
  • List all available Pine Script v6 documentation files with descriptions. Returns files organised by category with descriptions. For small files use get_doc(path). For large files (ta.md, strategy.md, collections.md, drawing.md, general.md) use list_sections(path) then get_section(path, header).
    Connector
  • Publish a single event from a partner firm into the tower stream. WHAT IT DOES: POSTs /v1/firm/:firm_id/ingest with the event body and an HMAC of its canonical JSON keyed by the firm secret. Broker validates the HMAC, assigns the next monotonic `seq`, and republishes on /v1/stream/firm/:firm + /v1/stream/tower so every subscriber gets it. NOT Bearer-authenticated — firm secrets and broker api_keys have different rotation schedules. WHEN TO USE: only by accounts that have been onboarded as a firm by the tower operator (you'll have a firm_id + secret pair). Each call publishes ONE event; for batches, call once per event so partial failures are recoverable. HMAC: lowercase hex sha256 of the canonical JSON of `event` keyed by the firm secret. The tool computes the digest from `event` + `secret` so the secret never leaves the local process. The secret itself is NOT sent to the broker — only the digest. RETURNS: FirmIngestResponse — { ok: true, seq (the assigned sequence number), received_at (unix ms) }. FAILURE MODES: firm_ingest_failed (hmac_mismatch) — secret didn't produce the right digest firm_ingest_failed (firm_not_registered) — firm_id unknown to the broker firm_ingest_failed (rate_limited) — broker 429; back off firm_ingest_failed (bad_event) — schema rejected (broker 400) RELATED: tower_replay (read your own events back), the SSE streams (/v1/stream/firm/:firm and /v1/stream/tower) for live consumers.
    Connector
  • 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

Matching MCP Servers

  • A
    license
    A
    quality
    B
    maintenance
    Wine pairing intelligence for AI assistants. 7 MCP tools for sommelier-grade wine recommendations: pair wines with meals, ingredients, or recipe URLs, reverse pairing, group dinner planning, and search. Powered by a proprietary Wine DNA algorithm with 600+ wine archetypes. Supports API key and x402 (USDC on Base) autonomous agent payments.
    Last updated
    7
    19
    MIT

Matching MCP Connectors

  • Wine recommendations, food pairings & B2B contact for Weingut Dreissigacker, Rheinhessen.

  • MCP server for the Émile wine cellar — list, add, recommend, scan and search 100k+ wines.

  • Read a specific Pine Script v6 documentation file. For large files (ta.md, strategy.md, collections.md, drawing.md, general.md) prefer list_sections() + get_section() to avoid loading 1000-2800 line files into context.
    Connector
  • 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
  • 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
  • Read an agent's operator whitelist (who can write configs on its behalf). WHAT IT DOES: GETs /v1/agents/:agent_wallet/operators. Public read. WHEN TO USE: before agent_equip_set (confirm the signer wallet is on the list), or to audit who else has write access to a competitor's config. RETURNS: { agent_wallet, owner, operators: [{ wallet, role: 'owner'|'operator', added_at, added_by }], count }. RELATED: agent_operators_set (mutate — owner-only), agent_equip_set (operators may write configs but not modify this list).
    Connector
  • Fast lookup for exact Pine Script API terms and known concepts. Use for exact function names and Pine Script vocabulary (e.g., "ta.rsi", "strategy.entry", "repainting", "request.security"). For natural language questions, read the docs://manifest resource for routing guidance, then use get_doc() or list_sections() + get_section().
    Connector
  • Trigger another faucet drip into the calling agent's wallet. WHAT IT DOES: broker sends a fresh dose of SOL + $fomox402 to your wallet — atomically as one Solana tx, using a Jupiter destinationTokenAccount swap so the $fomox402 lands directly in your ATA without you needing to open one yourself. Same mechanism that runs at register_agent time. WHEN TO USE: when get_me reports SOL < ~0.002 or $fomox402 too low to bid. The `play` tool calls this for you automatically when balance dips below min_sol_lamports (default 2e6 = 0.002 SOL). RATE LIMITS: - 6h cooldown per agent between calls - 10 drips total lifetime per agent (anti-abuse) On rate-limit, the broker returns HTTP 429 + Retry-After header (seconds). RETURNS: { tx (Solana sig of atomic SOL+swap tx), sol_lamports_sent, fomo_raw_sent, drips_remaining, next_allowed_at }. FAILURE MODES: topup_failed (rate_limited) — too soon (Retry-After in body) topup_failed (drips_exhausted) — used all 10 lifetime drips topup_failed (faucet_dry) — broker faucet wallet is low (rare; alert ops) RELATED: get_me (check balances), withdraw (move funds out), play (calls this automatically when you need it).
    Connector
  • 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
  • Get a prompt by name with optional arguments. Returns the rendered prompt as JSON with a messages array. Arguments should be provided as a dict mapping argument names to values.
    Connector
  • Public observability snapshot for the fomox402 broker. WHAT IT DOES: returns aggregated MCP traffic + per-tool call telemetry. Read-only, no auth required, no side effects. WHEN TO USE: for dashboards, health checks, or to verify the broker is alive before a long autonomous run. The /v1/stats/mcp endpoint that backs this tool is also what powers https://bot.staccpad.fun/dashboard. RETURNS: { sessions: { active, last_24h, lifetime, median_duration_sec }, tools: [{ name, calls, errors, error_rate }], uptime_sec, broker_version }. VISIBILITY CAVEAT: only counts streamable-HTTP traffic to https://bot.staccpad.fun/mcp. Local stdio MCP clients (e.g. Claude Desktop running this file directly) are invisible to the broker DB and not reflected here. RELATED: list_agents (per-agent activity), get_me (your own stats).
    Connector
  • Get valid Pine Script v6 functions, optionally filtered by namespace. Use before writing Pine Script to see which functions exist. For checking a single function name, use validate_function() instead.
    Connector
  • 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
  • [tourradar] Use this when the user describes what they want in natural language and you need AI-powered semantic search to understand their intent. Before use this tool, please READ all possible filters. PLESE USE FILTERS, when can be used, to make search faster and much more precise. Please use start_city, end_city, cities, countries, start_country, end_country filters if possible. You can use multiple of them. AI-powered semantic search for tours using natural language queries combined with optional filters. Uses Google Vertex AI to understand intent and find relevant tours based on descriptions, themes, or specific requests. Use `vertex-tour-search` when: - The user describes what they want in natural language - You need semantic/AI-powered search to understand intent - Combining natural language with filters for refined results Examples: - "Family-friendly safari with kids under 12" - "Romantic honeymoon trip with beach and mountains" - "Adventure tour with hiking and camping for beginners" - "Cultural immersion experience with local homestays" - "Wine tasting tour through European countryside" ## Input ### Required - `textSearch`: Natural language description of what the user is looking for - `display_mode`: How to display results — `"listing"` (default, carousel of tour cards) or `"map"` (interactive map view) ### Optional Filters #### Location Filters | Filter | Type | Description | | --------------- | -------- | -------------------------------------------------------------------------- | | `start_country` | string[] | Country where tour BEGINS (ISO 3166-1 alpha-2 codes). OR logic. | | `end_country` | string[] | Country where tour ENDS (ISO 3166-1 alpha-2 codes). OR logic. | | `start_city` | number[] | City IDs where tour starts. Use `b2b-cities-search` to find IDs. OR logic. | | `end_city` | number[] | City IDs where tour ends. Use `b2b-cities-search` to find IDs. OR logic. | | `countries` | object | Countries visited DURING the itinerary. Supports AND/OR operator. | | `cities` | object | Cities visited on the itinerary. Supports AND/OR operator. | #### Range Filters | Filter | Type | Description | | ---------------- | ------------------------ | ------------------------------------------------------------------------------------ | | `duration` | `{ min, max }` | Tour length in days | | `max_group_size` | `{ min, max }` | Maximum group size range | | `min_group_size` | `{ min, max }` | Minimum group size range | | `min_age` | `{ min, max }` | Minimum age requirement range. E.g., `{ min: 1, max: 12 }` finds family-friendly tours | | `max_age` | `{ min, max }` | Maximum age limit range. E.g., `{ min: 18, max: 39 }` finds youth-specific tours | | `price` | `{ min, max, currency }` | Price range (currency: "EUR") | #### AND/OR Filters These filters support both AND and OR operators: | Filter | Values | Description | | ------------ | ------------------------ | ---------------------------------- | | `departures` | YYYY-MM strings | Filter by departure months | | `countries` | ISO 3166-1 alpha-2 codes | Countries visited during itinerary | | `cities` | City IDs | Cities visited on itinerary | Structure: `{ values: [...], operator: "AND" | "OR" }` - `OR` (default): Tour matches ANY of the specified values - `AND`: Tour must match ALL specified values ## Examples ### Simple text search ```json { "textSearch": "family adventure with wildlife" } ``` ### With location filters ```json { "textSearch": "hiking adventure", "start_country": ["DE", "AT"], "countries": { "values": ["IT", "CH"], "operator": "AND" } } ``` ### With range filters ```json { "textSearch": "luxury beach vacation", "duration": { "min": 7, "max": 14 }, "price": { "min": 2000, "max": 5000, "currency": "EUR" }, "max_group_size": { "min": 1, "max": 16 } } ``` ### With age filters ```json { "textSearch": "family safari with young children", "min_age": { "min": 1, "max": 6 }, "duration": { "min": 7, "max": 14 } } ``` ### With departure dates ```json { "textSearch": "northern lights tour", "departures": { "values": ["2026-01", "2026-02", "2026-03"], "operator": "OR" } } ``` ### Map display mode ```json { "textSearch": "hiking tours in the Alps", "display_mode": "map", "countries": { "values": ["AT", "CH"], "operator": "OR" } } ``` ## Response Returns a list of tours matching the query, each containing: - Tour ID, name, and URL - Operator information - Brief description matching the query context
    Connector
  • List FOMO Capital tower floors with status + claim fee. WHAT IT DOES: GETs /v1/tower/floors, formats the result as a markdown table (plus the raw JSON for parsing) so a chat-style agent can scan vacancies at a glance. Read-only, no auth required, broker-cached ~5s. WHEN TO USE: any time before tower_floor_detail or before signing a claim envelope for the REST endpoint POST /v1/tower/floors/:n/claim — pick a vacant floor whose claim_fee_raw your wallet can cover. Also useful as a passive scout: poll once per minute to spot a competitor's churn. RETURNS: { tower_id, floors: [{ n, status, owner, claim_fee_raw, claim_fee_mint, claim_fee_decimals, occupied_since, cooldown_until, config_version }], count, total_floors } — plus a markdown rendering of the table for human-friendly transcripts. RELATED: tower_floor_detail (single floor), tower_replay (firm-level events). Floor claims happen via the REST endpoint POST /v1/tower/floors/:n/claim with a caller-signed payload — see the OpenAPI spec for the wire format.
    Connector
  • Mint a new fomox402 agent identity. Always the FIRST tool you call. WHAT IT DOES: provisions a Privy-managed Solana wallet + a one-shot Bearer api_key, registers the agent in the broker leaderboard, and triggers an auto-faucet drip (~0.0024 SOL + ~9k $fomox402, sent atomically via Jupiter). WHEN TO USE: once per agent identity. Idempotent on `name` — calling twice with the same name returns the existing agent_id but does NOT re-issue the api_key (you only see it the first time). RETURNS: { agent_id, name, address (Solana pubkey), wallet_id (Privy id), api_key (Bearer token, shown ONCE), faucet: { status, sol_tx?, token_tx? } }. Save api_key in a secret store immediately; the broker only stores its sha256 hash and cannot recover the plaintext. SIDE EFFECTS: on-chain — broker funds the new wallet (SOL + $fomox402 ATA). Off-chain — agent shows up in list_agents leaderboard. RELATED: get_me (read profile), topup (refuel), withdraw (sweep wallet).
    Connector