"discord" matching MCP tools:

• discord-workerD

  Discord snowflake worker bits, id discardedC

  Discord snowflake worker bits, id discarded

  ConnectorNo auth

• discord-webhook-shapeB

  Discord Webhook ShapeC

  Check a Discord webhook URL shape. Secret discarded.

  ConnectorNo auth

• discord-id-okD

  Discord snowflake id shape, value discardedC

  Discord snowflake id shape, value discarded

  ConnectorNo auth

• create_invite_linkA

  PairoaA

  Create a shareable Pairoa invite link for the current user. Returns { ref, url, share_text }. ONLY works after the user has claimed an account (claim_account). Otherwise returns AUTH_REQUIRED — guide them to claim first (claiming happens automatically on their first match). The 'share_text' is ready to forward AS-IS — to a Slack/Discord/WeChat group, a tweet, or a DM. Relay it to the user so they can paste it wherever they like; offer the bare 'url' too if they only want the link. Invites carry NO reward and are purely a convenience for word-of-mouth. Don't over-promote or nag. We do not track who the invitee is — only a private count of how many people a link brought in.

  ConnectorOAuth

• polymarket_arbitrageA

  DiscordA

  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}. FEES: every opportunities[] row and partition_check.arbitrage carry edge_pp_gross (== gap_pp / overround_pp), fees_pp, edge_pp_net, net_positive, plus polymarket_fee_pp, fee_basis and fee_categories[]. BOTH cost components are modeled: Polymarket's own per-category TAKER FEE (fee = shares × rate × p × (1-p), rates crypto 0.07 / sports-economics-culture-weather-other 0.05 / finance-politics-mentions-tech 0.04, geopolitics and world events fee-free; verified against Polymarket's own docs as of 2026-09-13) and Polygon gas (~$0.02/leg). The taker fee dominates: ~$1.75 per 100 shares on a crypto market at 50c versus $0.02 of gas, so rows that looked profitable before fleet #1927 may now show net_positive:false — that is the correction, not a regression. Each leg is priced at ITS OWN market's rate and price (the fee curve peaks at 50c and falls toward both extremes). fee_basis says where the rate came from: 'payload' (read off the market, the normal case), 'category' (mapped from its fee category), 'fee_free', or 'fallback' (rate unknown — charged at the modal 0.05 rather than assumed free, so an unreadable market is never reported as costless). Where fill_check reprices against live depth, this does NOT double-count that spread cost. 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.

  ConnectorNo auth

• resolution_auditA

  DiscordA

  Extract the settlement clause of a single Polymarket or Kalshi market: who publishes the settling number (source), the clock time + timezone it is taken at, the precision of the computation (e.g. "1-minute candle close" vs "60-second trailing average" vs "election outcome"), the evidence standard (official_source | consensus_reporting | any_credible_report | unspecified), and void_handling (cancellation/postponement settlement — reused verbatim from bet_research's cancellation_rule detector, not re-derived). Parses Polymarket's `description` field (fetched via polymarket_market) or Kalshi's `rules_primary` + `rules_secondary` fields (fetched via kalshi_market) with regex + a small vocabulary — no LLM pass, so an unusual clause reports confidence:"low" rather than a guess. Pass `market` as a Polymarket slug/URL or a Kalshi market ticker (e.g. "KXBTCD-26SEP1317-T66999.99"); a Kalshi EVENT ticker (e.g. "KXBTCD-26SEP1317") also works — it picks one representative market under that event, since the settlement mechanism is normally shared across all strikes/legs in one event. Use this before treating a polymarket_kalshi_spread row as a real arbitrage: two ladders that look alike can settle on different sources, at different times, with different precision — this tool is how you check. Pair with resolution_diff to compare two markets directly. KNOWN GAP: idiosyncratic phrasing that doesn't match the vocabulary returns confidence:"low" and evidence_standard:"unspecified" rather than an LLM-guessed answer.

  ConnectorNo auth

• heartbeatA

  MockbirdA

  Dead man's switch for cron jobs, scheduled tasks, and recurring agent runs — the INVERSE of uptime_monitor: the JOB pings Mockbird, and if the ping stops arriving the alert fires once (plus one recovery message when pings resume). action:"create" {name?, period_minutes, grace_minutes?, notify?}: period_minutes = how often the job runs (30–10080); grace defaults to half the period. With notify, missed check-ins hit that webhook; WITHOUT notify you get a pollable heartbeat instead — poll for missed-check-in transitions, no webhook needed. Returns a ping URL (curl -fsS -m 10 <ping_url> at the end of the job — or call this tool with action:"ping"), a public status page /status/:id, badge.svg, Atom feed, and {id, secret} — STORE id, secret AND ping_url; they cannot be recovered. Creation counts as the first ping. action:"ping" {ping_url}: check in (use this to arm a heartbeat for YOUR OWN recurring runs — ping each run, and a missed run alerts your human via the webhook or your next poll). action:"poll" {id, secret}: (webhook-less heartbeats) missed-check-in / checked-in-again transitions since your last poll plus the current ping age. action:"info" {id, secret}: last ping, ping URL, recent evaluations. action:"delete" {id, secret}: disarm. notify formats are the same as uptime_monitor (Slack/Discord native, HMAC-signed JSON otherwise). Limits: 5 live heartbeats per IP — deleting one frees the slot immediately; evaluation granularity 30 min; pollable heartbeats with no polls and no pings for 30 days are removed.

  ConnectorNo auth

• watch_service_statusA

  MockbirdA

  Subscribe to down/recovered alerts for any of the public mock/testing APIs tracked by check_api_status (httpbin, JSONPlaceholder, ReqRes, FakeStoreAPI, DummyJSON …). action:"subscribe" {service, notify?}: service is an id from check_api_status (or "*" for all tracked services). With notify, that webhook gets one message when the service goes down and one when it recovers (debounced across two consecutive hourly checks — blips never fire; a confirmation message is delivered immediately so you can see the wiring works). WITHOUT notify you get a pollable subscription instead — no webhook needed. Returns {id, secret} — store both. action:"poll" {id, secret}: (webhook-less watches) returns the down/recovered transitions since your last poll — empty events = nothing changed; checks run hourly so polling more often sees nothing new. action:"info" {id, secret}: subscription state. action:"unsubscribe" {id, secret}: stop alerts. notify formats: Slack/Discord webhooks get native payloads; anything else gets HMAC-signed JSON. Limits: 5 live watches per IP — deleting one frees the slot immediately. To watch YOUR OWN URL instead, use uptime_monitor.

  ConnectorNo auth

• integrations_manageA

  9botA

  Reads and manages Discord forwarding and live-stream alerts. Use workflows_connections_manage for an arbitrary CRM or API and messages_manage for an ordinary message. OAuth and credential operations require account authorization; send_test and forwarding produce external, non-idempotent messages. Delete or disconnect prevents future actions but does not erase previously forwarded content. For a preview, set input.preview=true; preview never applies the mutation. When confirmation is required, repeat the same operation and parameters with the returned input.confirmation_id.

  Connector

  Destructive

  OAuth

• polymarket_fill_riskA

  DiscordA

  Realizable-vs-theoretical edge check against live CLOB order-book depth. REQUIRES one of `market` (single-market mode) or `event` (basket/partition mode). SINGLE-MARKET: pass a market slug/URL + side (buy_yes|sell_yes|buy_no|sell_no, default buy_yes) + size_usd (default 1000 — max spend on buys, target proceeds on sells); walks the ladder and returns top_of_book, vwap_fill_price, slippage_pp, shares_filled, max_fillable_usd, and a verdict (clean|degraded|cannot_fill). BASKET: pass an event slug/URL + side (sell_yes = capture overround by selling every leg, buy_yes = capture underround; default auto from partition sum) + size_usd interpreted as settlement notional S (shares per leg; each share pays $1); returns theoretical_sum vs realizable_sum (top-of-book vs VWAP across all legs), capture_ratio, profit_usd at executed size, per-leg fill detail, thin_legs[], max_clean_notional_usd, and forced_directional_risk naming the legs most likely to strand you unhedged. USE THIS before acting on any polymarket_arbitrage SELL/BUY-EVERY-LEG signal or any polymarket_edges trade above ~$500 — theoretical overround on thin books is not capturable, and partial basket fills convert an arb into an unhedged directional position (the dominant loss mode in real arb-bot P&L). FEES ARE NOT MODELLED HERE: vwap_fill_price/profit_usd are GROSS of Polymarket's own taker fee (rate 0.04-0.07 by category — see polymarket_edges/fees.ts), on top of which this tool prices depth-crossing cost; a thin-margin fill that looks clean here can still be net-negative after the fee.

  ConnectorNo auth

• kalshi_weather_edgeA

  DiscordA

  Prices Kalshi daily high-temperature markets against the NWS forecast for the market's OWN settlement station, and measures whether that forecast actually beats the market. Two modes. LIVE (default): returns the full strike ladder for one city and settlement date with market_prob (mid), forecast_prob, and edge_pp per strike, plus the settlement clause verbatim. BACKTEST (`backtest_days: N`): scores an archived gridded forecast against the market on settled days and returns brier_market vs brier_forecast with a plain-English `verdict`, so the edge is MEASURED rather than asserted. READ THE WARNINGS — they are not boilerplate. (1) These markets DO NOT settle on the NWS. They settle on The Weather Company (weather.com) at a Kalshi station code such as CLINYC, which the response quotes verbatim; so part of every edge_pp is NWS-vs-Weather-Company disagreement about the same day at the same station, which is not mispricing and not tradeable. `settlement_vs_forecast_basis_f` from backtest mode is that part as a number. (2) The station is DERIVED from the settlement clause, never from the city name: Chicago settles at MIDWAY and New York at CENTRAL PARK, so a city-centre forecast would misprice a whole ladder. A station that cannot be resolved yields rows with no forecast and a reason, never a guessed coordinate. (3) forecast_prob assumes a normal distribution around the NWS high whose width is ASSUMED, not fitted (stated in `distribution_assumption`) — run backtest mode to see whether it is calibrated. (4) edge_pp is gross: no Kalshi fees, no bid-ask. MEASURED RESULT, AND IT IS NOT THE FLATTERING ONE: on the first backtest (KXHIGHNY, 13 settled days to 2026-09-11, 58 market observations) the MARKET beat the forecast — Brier 0.1008 for the market against 0.1594 for the archived gridded forecast, lower being better. So on that sample there is NO forecast edge to sell, and a large edge_pp is more likely to be the model disagreeing with a better-informed market than an opportunity. The measured settlement-vs-forecast basis was 1.7F mean absolute over 8 pinnable days, slightly warm-biased, which is a big share of a typical edge_pp on a 2-degree bracket. Re-run backtest_days before believing any edge; if a later sample reverses this, the numbers say so. NWS is US-only, so the ~30 international Kalshi weather series (London, Paris, Tokyo) return market prices with forecast_unavailable rather than a forecast. Precipitation series are listed but not yet priced. Cities: nyc, chicago, los angeles, miami, austin, houston, denver, philadelphia — or pass `series_ticker` for any other (e.g. "KXHIGHTBOS").

  ConnectorNo auth

• pipeworx_feedbackA

  DiscordA

  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). ONLY for tools served by this Pipeworx connection — if the tool came from a different MCP server in your client (another vendor's Gmail, Splunk, Slack, etc. connector), we cannot fix it and reporting it here only delays you; file it with that server instead. Not sure? Pipeworx tool names are the ones this connection lists. Describe the issue in terms of Pipeworx tools/packs — don't paste the end-user's prompt. Filing without an account returns a `claim_token`; pass it back later as pipeworx_feedback({claim_token:"pwfb_…"}) to read whether it was fixed and what changed. 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.

  ConnectorNo auth

• dreamagent_create_projectA

  DreamAgent CloudA

  WRITE ACTION — creates a new DreamAgent project (website, Telegram bot, Discord bot, or AI agent). Use ONLY when the user clearly asks to create/build a new project; not for questions about what to build. CONFIRM BEFORE CALLING — never create on the first mention. In ONE message, present and get the user's explicit go-ahead for: 1. The credential: run dreamagent_list_global_integrations first. If several telegram/discord credentials are saved, list them (id + title) and ask which to use. If exactly one is saved, state which one you will use. Never pick silently. 2. The plan: name, type, and the final description exactly as you will submit it (this is the Prompt Assistant's recommendation summary). Call this tool only after the user confirms. CREATION IS ASYNCHRONOUS: after calling, check dreamagent_get_project_status repeatedly until the project is 'ready' or 'failed' (bots ~2-5 min, websites longer). CREDENTIALS: raw bot tokens are never accepted in chat or as inputs. For Telegram/Discord bots you MUST pass bot_token_integration_id — the ID of a saved credential from dreamagent_list_global_integrations. If none is saved, direct the user to dreamagent.cloud → Settings → Global Integrations. Other saved keys can be imported via global_integration_ids. Credentials are stored as project secrets and are never exposed back. DESCRIPTION = the refined creation brief. Act as a Creative Director / Product Manager, not an architect. Create a concise but complete description of WHAT should be built: - product vision and target audience - user experience and core functionality - design/tone direction - important features and behavior - final expected result Do not include implementation details such as: - technology stack - architecture - database/API implementation - authentication implementation - deployment - CI/CD - testing commands Infer reasonable defaults when missing details are non-critical. Ask for clarification only when missing information materially affects the requested functionality, scope, credentials, or expected result. Prefer the following structure and constraints for each project type, but do not override explicit user requirements: Website: - Project Vision - Design Style - Pages - Hero Experience - Core Features - UI Components - Mobile Experience - Final Expectation - Prefer up to 4 pages unless the user clearly requires more. Telegram bot: - Bot Purpose - Commands - User Flow - Optional AI Features - Integrations when required - Final Expectations - Prefer a compact command set; always include /start and /help unless the user's explicit requirements conflict. Discord bot: - Bot Purpose - Slash Commands - Events - Permissions - Optional AI Features - Final Expectations - Prefer a compact command set; include /help where appropriate. Agent (recurring/scheduled automation with OAuth actions): - Purpose (what it monitors or automates) - Data Sources (which connected OAuth services: YouTube, GitHub, Discord, Notion, X, Google Sheets, Slack — or public APIs) - Schedule (e.g., every 5 minutes / hourly / daily at 9am) and/or Event Triggers (incoming webhook) - Conditions (when to act — thresholds, keywords, state changes) - Delivery Channels (Telegram, Discord, Slack, email — optional) - Final Expectation - Use concrete schedules; note that agents keep persistent state between runs and can call any connected OAuth integration. - Agents do NOT need a bot token unless they deliver via Telegram/ Discord (then a saved credential is required as for bots). SUPERPOWERS: the account may have ready-made AI tools enabled (song/video/image generation, voiceover, lip sync, voice clone, transcription, media processing, PDF tools). If the requested product clearly benefits from one (e.g. an AI song generator website), reflect the FEATURE in the description — DreamAgent wires the tool integration automatically at build time. Check what is enabled with dreamagent_list_superpowers. Do NOT add implementation details about how the tool is called.

  ConnectorNo auth

• dreamagent_create_projectA

  DreamAgentA

  WRITE ACTION — creates a new DreamAgent project (website, Telegram bot, Discord bot, or AI agent). Use ONLY when the user clearly asks to create/build a new project; not for questions about what to build. CONFIRM BEFORE CALLING — never create on the first mention. In ONE message, present and get the user's explicit go-ahead for: 1. The credential: run dreamagent_list_global_integrations first. If several telegram/discord credentials are saved, list them (id + title) and ask which to use. If exactly one is saved, state which one you will use. Never pick silently. 2. The plan: name, type, and the final description exactly as you will submit it (this is the Prompt Assistant's recommendation summary). Call this tool only after the user confirms. CREATION IS ASYNCHRONOUS: after calling, check dreamagent_get_project_status repeatedly until the project is 'ready' or 'failed' (bots ~2-5 min, websites longer). CREDENTIALS: raw bot tokens are never accepted in chat or as inputs. For Telegram/Discord bots you MUST pass bot_token_integration_id — the ID of a saved credential from dreamagent_list_global_integrations. If none is saved, direct the user to dreamagent.cloud → Settings → Global Integrations. Other saved keys can be imported via global_integration_ids. Credentials are stored as project secrets and are never exposed back. DESCRIPTION = the refined creation brief. Act as a Creative Director / Product Manager, not an architect. Create a concise but complete description of WHAT should be built: - product vision and target audience - user experience and core functionality - design/tone direction - important features and behavior - final expected result Do not include implementation details such as: - technology stack - architecture - database/API implementation - authentication implementation - deployment - CI/CD - testing commands Infer reasonable defaults when missing details are non-critical. Ask for clarification only when missing information materially affects the requested functionality, scope, credentials, or expected result. Prefer the following structure and constraints for each project type, but do not override explicit user requirements: Website: - Project Vision - Design Style - Pages - Hero Experience - Core Features - UI Components - Mobile Experience - Final Expectation - Prefer up to 4 pages unless the user clearly requires more. Telegram bot: - Bot Purpose - Commands - User Flow - Optional AI Features - Integrations when required - Final Expectations - Prefer a compact command set; always include /start and /help unless the user's explicit requirements conflict. Discord bot: - Bot Purpose - Slash Commands - Events - Permissions - Optional AI Features - Final Expectations - Prefer a compact command set; include /help where appropriate. Agent (recurring/scheduled automation with OAuth actions): - Purpose (what it monitors or automates) - Data Sources (which connected OAuth services: YouTube, GitHub, Discord, Notion, X, Google Sheets, Slack — or public APIs) - Schedule (e.g., every 5 minutes / hourly / daily at 9am) and/or Event Triggers (incoming webhook) - Conditions (when to act — thresholds, keywords, state changes) - Delivery Channels (Telegram, Discord, Slack, email — optional) - Final Expectation - Use concrete schedules; note that agents keep persistent state between runs and can call any connected OAuth integration. - Agents do NOT need a bot token unless they deliver via Telegram/ Discord (then a saved credential is required as for bots). SUPERPOWERS: the account may have ready-made AI tools enabled (song/video/image generation, voiceover, lip sync, voice clone, transcription, media processing, PDF tools). If the requested product clearly benefits from one (e.g. an AI song generator website), reflect the FEATURE in the description — DreamAgent wires the tool integration automatically at build time. Check what is enabled with dreamagent_list_superpowers. Do NOT add implementation details about how the tool is called.

  ConnectorNo auth

• connections_connect_oauth_linkA

  ConnectionsA

  Mint the provider's authorize URL for an OAuth connector (google_cloud, microsoft, cloudflare, discord, github, …) so the human can connect - or RECONNECT to grow a grant's scopes - by opening ONE link, with no Studio sign-in. Returns {url, expiresAt}; the link's state is single-use and lives 10 minutes, and the credential lands in this company's vault through the provider callback, never through the conversation. Pass `reconnectId` (a /v1/connected-services row id) or `instanceName` (an existing instance's name) to RE-CONSENT that exact row - a scope added to a connector never widens an existing grant, so this is how an operator re-consents after a scope list changes. When the service already has live connections and you pass neither, the call returns 409 target_required listing them (instanceName, reconnectId, accountName); pass `newConnection: true` only to add another account. The reply's `landsOn` names the row the grant will land on. The human must be signed in to the PROVIDER in the browser that opens the link; that sign-in is the provider's, not ours.

  Connector

  Destructive

  OAuth

• auth_connectA

  RokhaB

  Start an OAuth Connect and get the consent URL to open in a browser. Pass provider (github|google|x|atlassian|microsoft|slack|notion|gitlab|discord|reddit|linear — account-wide, reused everywhere) OR server_url (any MCP server; Rokha runs the MCP auth-spec handshake, grant bound to that server). On approval the token lands in the vault under the returned alias. Requires a logged-in identity.

  ConnectorNo auth

• create_destinationA

  Ticker: Live Event Ticket MarketA

  Use this to add a Slack or Discord channel as an alert destination. Use set_view_target instead to attach a destination that exists to a View. Create an alert destination so an alert can deliver its Matches into a Slack or Discord channel, on top of email. You provide the channel's message URL, the https posting URL that Slack or Discord generates for a channel in that app's channel settings. Ticker sends a live test message to it and only saves the destination if that succeeds, so a wrong or dead URL is rejected right away with a clear reason (nothing fails silently at 3am). Creating one delivers nothing on its own. Attach it to a View with set_view_target, which also sets how often THAT View delivers to THAT destination; read back what a View already delivers to with list_view_targets; detach with remove_view_target. (To post into a Discord channel using Ticker's own bot, with no URL to copy, set that up in the Ticker web app under Settings instead.)

  ConnectorOAuth

• update_public_delivery_pageA

  Pizza DeveloperB

  Set whether the project's Public Delivery Page shows dates and configure supported social profiles: YouTube, X, Discord, LinkedIn, Instagram, TikTok, Bluesky, Threads, Twitch, Spotify and Apple Music. Owner-only. Read current values with get_project. Omitted fields stay unchanged; empty strings remove profiles. Custom links are not supported. Upload or remove logo/cover images in the app (PNG/JPG, 4 MB); image references cannot change here. Does not publish the Public Delivery Page.

  Connector

  Destructive

  No auth

• validate_claimA

  DiscordA

  "Is it true that…" / "fact check" / "verify the claim that…" / "did X really…" / "was Y actually…" / "confirm or refute" / "true or false" — natural-language claim verification against authoritative sources. Use whenever the agent needs to check whether something a user said is factually correct. Company-financial claims (revenue, net income, cash for public US companies) verify via the structured SEC EDGAR + XBRL fast path with exact percent-delta math; ANY OTHER factual claim (macro statistics, rates, prices, drug data, records) automatically falls through to the grounded pipeline — routed to the right live source, answered with verbatim evidence, then judged. Returns a verdict (confirmed / approximately_correct / refuted / inconclusive / unsupported / could_not_verify), the grounded or structured actual value with pipeworx:// citation, and reasoning. IMPORTANT for callers: could_not_verify means the check did not happen (our LLM or source failed) and carries verification_error{stage,detail} — it is NOT evidence for or against the claim, and must not be shown as one. unsupported means we looked and cover no source for it. Replaces 4–6 sequential calls (NL parsing → entity resolution → data lookup → comparison).

  ConnectorNo auth

• open_projectA

  SuboA

  Outward: Activate a project and deliver it to members. This posts the invite in Discord and can send direct messages to real members. It is not reversible: close_project stops it, but the messages have already been sent. Confirm with the human first. Go-live validation runs here — errors block the call, warnings need `acknowledge`. Run validate_script first so you see them before the audience does. `delivery.audience.participation` is `private` (invite-only in Discord) or `open_web` (a public link).

  ConnectorAPI key

• set_app_variablesA

  mcpA

  Add, change or remove environment variables of a hosted app or bot. Pass set as a map of NAME to value for the ones to write, and unset as a list of names to remove. Everything not named is left exactly as it is, values included. The response never contains a value, only the names that were written and removed: pass a value in, never expect one back. Saving environment recreates the container, so the app restarts and is offline for about a minute. Removing DISCORD_TOKEN from a Discord bot is refused, because it would take the bot down for good. A changed DISCORD_TOKEN is checked with Discord first and refused if Discord rejects it. The credentials of a bundled one-click database are written by FadeHost and are put back on every save, so they cannot be changed or removed here. Refuses a paused app and a suspended owner. Needs full access to the app, the same as the panel Environment tab.

  Connector

  Destructive

  No auth