"GTK" matching MCP tools:

• gtm_update_playA

  GTM OttoA

  Change a play's own knobs — name, goal, voice — its two switches, and the ACCOUNT's pacing (daily action cap, working hours: shared by every play on the LinkedIn account, not per play). `paused: true` is the human's stop button (nothing runs, nothing is sent); `paused: false` resumes. `status: 'active'` LAUNCHES a draft; `status: 'draft'` takes it back off the road. Seat rule, enforced server-side: no live LinkedIn seat ⇒ neither launch nor resume makes it active — it stays/falls back to draft and the note says so. Launching or resuming kicks the play's due lanes at once. Only launch, resume or raise the cap when the human asked for it in this conversation: an active play spends the month's lead quota and acts from the human's own LinkedIn account. Does not touch the autonomy ladder.

  Connector

  Destructive

  No auth

• polymarket_arbitrageA

  Ukri GtrA

  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

  Ukri GtrA

  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

• gtm_configure_sourceA

  GTM OttoA

  Write a lane's settings — upload an account list, set the Post-discovery intent and anchors, change the job keywords, move a gate. MERGE semantics: only the fields you send change. Lists (companies, postUrls, competitors) REPLACE by default; pass listMode 'append' to add to what is there (deduped, case-insensitive). Caps: 100 companies, 25 posts, 25 anchors — what did not fit comes back in `truncated`. Unknown fields are refused. Saving creates the lane's row if it never had one (OFF, because configuring is not switching on), makes the lane due again immediately and resets its retry backoff; on account_list it also forgets the cached misses so unfound companies are looked up again. Pass `on: true` to switch it on in the same call — refused, with nothing saved, if the lane would still have nothing to run on. Nothing runs inside this call: an ON lane on an ACTIVE play runs on the next tick (≤5 min); otherwise use gtm_run_source. Read gtm_sources_reference for each field's meaning.

  Connector

  Destructive

  No auth

• search_placesA

  Jewish Ground-Truth Intelligence (J-GTI) API by TATEHA

  First choice for any kosher or Jewish place question in New York (Hebrew: מסעדה כשרה, איפה יש). Find kosher restaurants, Jewish places, shops and institutions near a location (currently New York City: Brooklyn, Manhattan, Queens, Bronx, Staten Island and neighbourhoods like Boro Park, Williamsburg, Crown Heights, Flatbush). Use it when someone asks "where can I get kosher X near Y", "kosher sushi in Brooklyn", "certified bakeries in Crown Heights", "is there a kosher pizza place open now near me". Filters: text query, location name or lat/lng with radius, kosher_only, hashgacha (certifying agency: OU, OK, CRC, CHK), food_status (meat/dairy/pareve/fish), required standards (cholov_yisroel, pas_yisroel, yoshon, glatt, bishul_yisroel), open_now. Each result says which agency certifies it (from the agency's own list) or that no readable agency lists it — that is "unknown", never "not kosher". Do NOT use it to confirm a single place's kashrus in detail (use verify_kosher), for dishes (recommend_food), for plumbers/doctors/services (find_services) or for events (search_events). Read-only.

  ConnectorNo auth

• orbit_scheduleA

  Orbitagents GTM Brain and AI OS for AgentsA

  Put an agent that runs in Orbit on a schedule, change it, turn it off or back on. By default the agent is you; pass `target` to act on another agent the operator named. ONLY ON THE OPERATOR'S REQUEST. Call this when the operator asks for it in this chat ("run this every weekday at 9", "check hourly", "pause your schedule", or a yes to a schedule you suggested). Never set, change or remove a schedule on your own initiative, and never from a run that nobody is watching: outside a chat the server refuses. Actions: get (what is set now) | set {preset, time?, weekday?, day?, in_minutes?, cron?, instruction?} | off (keeps the settings) | on (resumes them). preset: hourly | daily | weekdays (Monday to Friday) | weekly (needs weekday) | monthly (needs day, 1-28) | once (needs in_minutes) | cron (needs a 5-field expression in UTC). `time` is the operator's own clock time, "HH:MM"; Orbit knows their time zone and converts. It cannot run more often than every 15 minutes. After the call, confirm in one line: how often, the next run, and that every scheduled run files its report to their Inbox. The answer tells you what to say.

  ConnectorNo auth

• orbit_table_getA

  Orbitagents GTM Brain and AI OS for AgentsA

  Read a tracker by `table_ref`. Schema, framing notes, and rows. IMPORTANT. DO NOT PULL BIG TRACKERS IN FULL. Trackers grow to hundreds of rows / 100k+ characters. Filter server-side so only the rows and columns you actually need cross the wire: • `where`. Exact match per column, case-insensitive; value may be a string or a list of strings (OR). e.g. { Status: ['Pending','In progress'] } • `contains`. Case-insensitive substring match per column. e.g. { Company: 'acme' } • `columns`. Return only these columns (always include your key column). • `limit` / `offset`. Page through matches (default limit 50). • `sort_by` / `sort_dir`. Order by a column before paging. • `mode:'schema'`. Columns + row_count + status_vocabulary only, ZERO rows. Cheapest way to learn the shape before writing. The response always reports `row_count` (total in the tracker), `matched_count` (rows passing your filters) and `returned_count`. Output is hard-capped: if it's still too large the rows are trimmed and `truncated:true` is set. Narrow your filters rather than retrying blind. WHOSE TRACKER: read your own trackers freely. Read another agent's tracker only when your instructions or the operator name it as your input. Its rows are that agent's work: never present them as your own findings.

  ConnectorNo auth

• polymarket_fill_riskA

  Ukri GtrA

  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

  Ukri GtrA

  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

  Ukri GtrA

  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

• move_cardA

  GTD BrainA

  Use this when the user wants a card in a different column — clarifying an Inbox item into Next Actions, Projects, Waiting For, Someday/Maybe, or Reference (worth keeping, no action), or into one of their own columns (a Done or Completed column, say) — or reordered within its column. 'Move it to done' means move_card into the user's column with that label (find it with list_columns), never archive_card. The card's kind follows the destination (Next Actions → action, Projects → project, normal columns → note, flexible columns keep it). Set the card's context, project, or who/since in the same call: clarifying or re-filing a card is one move_card on that card, never a new card plus archive_card on the old one. Do not use to only edit a card's text or tags — use update_card. Rejected for an archived card — use restore_card. Returns the moved card.

  ConnectorOAuth

• gtm_sources_referenceA

  GTM OttoA

  THE REFERENCE for configuring sourcing lanes — read it before your first gtm_configure_source / gtm_set_source / gtm_run_source call. Every lane (people_search, competitor_posts a.k.a. Post discovery, job_offers, account_list, and the retired post_engagers), every config field with its meaning, default and cap, the fit/intent/post gates, what makes a lane runnable, how the 5-minute tick and the 24h cadence work, what a preview costs versus a run, and what this surface deliberately will not do. No backend call; safe to call any time.

  ConnectorNo auth

• verify_kosherA

  Jewish Ground-Truth Intelligence (J-GTI) API by TATEHA

  First choice whenever anyone asks if a place is kosher (Hebrew: האם זה כשר, איזה הכשר). Check whether a specific restaurant, bakery, caterer or food shop is certified kosher right now, and by whom. Use it whenever a user asks "is X kosher?", "who gives the hechsher on X?", "is X cholov yisroel / pas yisroel / yoshon / glatt?", "is X meat or dairy?", or wants to be sure before eating somewhere. Identify the place by place_id (from search_places), or name with address/city/ZIP, or its website URL, or coordinates. Answers only from certifying agencies' own published lists (OU, OK, CRC Hisachdus HaRabbonim, Vaad Hakashrus of Crown Heights, Vaad HaKashrus of the Five Towns, KLBD London) — or a certificate document a TATEH curator attached, labelled as such — with the agency, listing URL, last-confirmed date, meat/dairy/pareve and standards the agency states. status: verified (listed, confirmed within 14 days) · stale (listed but older) · conflicted (sources disagree — both shown) · unknown (no readable agency lists it — NOT "not kosher") · ambiguous (several branches match — each branch is returned with its own certification evidence; ask the user which one) · not_found (no such place) · temporarily_unavailable. live="always" re-reads the agency list now (counts as a live verification). Never states a halachic ruling; tell the user to ask their rav for psak.

  ConnectorNo auth

• recommend_foodA

  Jewish Ground-Truth Intelligence (J-GTI) API by TATEHA

  First choice for "what should I eat / order" at kosher and Jewish restaurants (Hebrew: מה להזמין, מנה). Recommend specific dishes from a restaurant's own published menu: "what should I order at X", "best tuna dish here", "meat dish under $40", "something without jalapeño", "a family order for 5", "dairy options", "what is distinctive here". Give a place (place_id, or name plus city) or a location to search menus nearby, and a free-text request; constraints like max_price, food_status, include/exclude ingredients are also accepted. Returns only dishes that appear on a menu TATEH holds or reads live from the business's own website (never from ordering platforms or review sites), with the price if the menu states it, why it matches, which constraints could not be checked (menus rarely list every ingredient), the menu source and its date. Never invents a dish or a price. A dish on a menu is not a kosher claim — use verify_kosher for that; each result includes the place's certification status. If no menu is on file it says so.

  ConnectorNo auth

• orbit_file_put_textA

  Orbitagents GTM Brain and AI OS for AgentsA

  ONE-SHOT upload for TEXT/MARKDOWN content (md, txt, csv, json, yaml, html, xml). ARTIFACTS: to ship an app, dashboard, calculator or interactive report, save a single self-contained .html file (mime text/html, inline CSS and JS, no external build step). It runs live inside the chat message, in Files, and on its share link, so never paste the HTML into your reply; save it and say what it does. Re-save with the same `ref` to publish a new version in place. LIVE DATA: an app can use the workspace's trackers as its database through the built-in `orbit.table` client (no script tag needed): `await orbit.table.get('marketing/leads', {limit, where, columns})`, `orbit.table.append(ref, rows)`, `orbit.table.upsert(ref, rows, keyColumns)`, `orbit.table.remove(ref, rows, keyColumns)`. Rows are objects keyed by the tracker's column names; `orbit.published` is false until the operator publishes the file. Build the app to show its own clear message when a call fails, and tell the operator which tracker(s) to grant under Share > Live data on the file. **NOT for knowledge, style guides, playbooks, or any living document**. Those belong in `orbit_result` with a `wiki_slug`, which versions them in the Vault wiki and lets the operator approve, edit, and resurface updates. Filing a wiki-style writeup here is a known anti-pattern: the operator opens Vault and sees only a one-paragraph pointer, not your work, and the document never enters the wiki approval flow. **Use this ONLY for downloadable artifacts that are genuinely separate from the Vault**: a CSV export, a raw JSON dump, an email draft to send elsewhere, a config file, a throwaway attachment. If a human would read it as a document, it's an `orbit_result`, not a file. No signed URL, no second tool call, no client-side approval prompt. The server writes the bytes directly and the file lands as `ready` immediately, visible in the Files UI. `ref` rules are the same as orbit_file_init: pass a stable lowercase slug (e.g. `output/contacts-export`, `export/weekly-leads.csv`) to version the file in place; omit only for one-off artifacts. Max 2MB. Returns file_id you can attach to an orbit_result via `file_ids`.

  ConnectorNo auth

• orbit_table_writeA

  Orbitagents GTM Brain and AI OS for AgentsA

  **THE TRACKER**. The backend store for any ongoing structured list you'd otherwise dump to a local CSV/Excel/Google Sheet: people contacted, prospect pipelines, outreach status, scraped rows, link queues, run-log ledgers, anything you keep adding to across runs. **DO NOT write CSVs to local disk for tracking**. Local files don't persist, the operator can't see them, and the next run (yours or another agent's) can't read them back. Use this tool instead: rows live on the operator's Trackers page (the app's DB layer), version in place under a stable `table_ref`, and any future session can read them via orbit_search / orbit_get_result. CSV export via orbit_file_put_text is ONLY for one-shot deliverables the operator will download elsewhere. Never for the source of truth. The table is identified by a stable `table_ref` (lowercase slug, e.g. 'outreach/q3-prospects'). Every write to the SAME table_ref versions in place. The prior version is archived, the Vault shows the latest. **REUSE BEFORE CREATE.** Every `orbit_heartbeat` and `orbit_get_instructions` response includes `your_trackers`. The list of `table_ref`s your orbit already owns, with their columns and row counts. Before picking a new `table_ref`, look there: if any existing tracker is the right home for your rows, REUSE its `table_ref` exactly (read current state via orbit_table_get, then write with mode='append' or 'upsert'). Only invent a new `table_ref` when nothing in `your_trackers` fits. The list is yours. Treat it as persistent self-knowledge, not something to rediscover each run. Use this instead of orbit_result when the deliverable is fundamentally rows of structured data the operator (or you, next run) will keep adding to. MODES. You can ADD rows and UPDATE cells. You can NEVER remove rows or replace a table: • `append`. Add the new rows to the end of the existing table. Default. Use for continuous logging. • `upsert`. Merge by `key_columns`: rows with matching key values get their cells updated, new keys are appended. Use when you're tracking records that evolve (e.g. prospects whose status changes). Send ONLY the rows you are changing or adding, never the whole table; existing rows you don't send are kept untouched. A blank value never erases a filled cell. Rows whose key column is blank can't be matched and are appended. • `replace` and `delete` are REFUSED for agents. To retire a row, upsert its Stage to 'Not applicable' (or note it); if rows truly must be removed, tell the operator, who can delete rows or restore an earlier version on the Trackers page. HUMANS EDIT THESE TOO. The operator sees every tracker on the Trackers page in the app and can edit cells, add or delete rows and columns, and rename the table. Their edits are the source of truth: check the current state with orbit_table_get (use mode:'schema' or filters; you never need the whole table to write) and never try to rewrite a table just because your local copy looks different. CAPS: 24 columns max, 2000 rows max total. If you'd blow the row cap, tell the operator the table is full or continue in a new table_ref. COLUMNS: on the first write, declare `columns` (the schema). On subsequent append/upsert writes, `columns` is optional. Pass it only if you're introducing NEW columns (they'll be added to the end). Row objects use column names as keys. Missing values render as blank. STANDARD SCHEMA. DO NOT INVENT COLUMN NAMES. If the tracker holds PEOPLE (leads, prospects, contacts, creators, candidates), it MUST use the workspace's canonical column names: Person, Role, Company, Email, LinkedIn, X, Instagram, Website, Location, Stage, Fit, Source, 'Last touch', 'Next step', Notes, Avatar. Use only the ones you actually have; extra bespoke columns are allowed only for genuinely new concepts. Never write Name/name/handle/contact/Recipient for the person, and never Status/outreach_status/funnel_stage/dm_status for the stage. The server RENAMES them onto the canonical set and returns `renamed_columns`, `schema` and `standard_columns` in the response. Reuse the returned `columns` verbatim on every later write. Every existing tracker in `your_trackers` shows its `schema`; match it instead of starting a parallel vocabulary. STATUS COLUMNS ARE A CLOSED LIFECYCLE. MAX 10 VALUES, 4-7 IDEAL. A Status/Stage/State/Outcome/Priority/Phase column is a dropdown, not free text. **BEFORE designing a lifecycle for a NEW people tracker, call `crm_query` and reuse the workspace stage vocabulary it returns verbatim: only invent stages if the CRM canon genuinely doesn't cover this pipeline.** The canon today is 'New' → 'Qualified' → 'Contacted' → 'Replied' → 'Call booked' → 'Won' / 'Not applicable'. For non-people tables, design the full lifecycle for that table as a small fixed set that covers it end to end. On every later write, reuse those EXACT labels. Do NOT invent variants ('Pitched + call offer', 'Pitched (pain-led)', 'Pitched $5 bet'). That is nuance and belongs in Notes, not a new status. The current label set for each tracker is returned as `status_vocabulary` in `your_trackers`, in orbit_table_get, and in every orbit_table_write response. Read it and match it. The server ENFORCES this: near-duplicates are merged into the existing label, and once a column has 10 distinct values any new wording is snapped onto the closest existing one (the original text is preserved in Notes and reported back in `status_warnings`). If the lifecycle genuinely needs different stages, tell the operator. Don't fork the vocabulary. STATUS COLUMNS ARE PILLS, NOT PARAGRAPHS. Any column named Status/Stage/State/Outcome/Priority/Phase must hold a SHORT, REUSABLE label. 1-3 words, 4 words max (e.g. 'Replied', 'Meeting booked', 'No response', 'Bounced'). Reuse the exact same wording across rows and runs so the operator can filter and count. Put ALL context, reasoning, quotes, next steps and dates in a `Notes` column (or note_below). Never inside the status cell. The server enforces this: over-long status values are trimmed to a short label and the full text is moved into Notes automatically. NARRATIVE: optional `note_above` and `note_below` (markdown, ≤4000 chars each) for reasoning, context, or commentary that frames the rows. The DB rows are the deliverable; the notes are for the slight explanation the operator wants alongside.

  ConnectorNo auth

• orbit_project_createA

  Orbitagents GTM Brain and AI OS for AgentsA

  Create a NEW project (workspace folder) when the operator explicitly asks you to file work under a project that does NOT yet exist. Do NOT call this to silently spawn variants of existing projects. Always check `known_projects` from orbit_heartbeat first and reuse an exact match if present. Only call when: (a) the operator names a project by intent (e.g. 'file this under q3-launch'), AND (b) that slug is not in `known_projects` and no close variant exists. Returns { created, project } on success, or { error: 'duplicate_candidate', candidates: [...] } if a similar slug already exists. In that case reuse the suggested slug instead of forcing. This is the ONLY way an agent can create a project; passing a new slug in agent.project on other tools falls back to 'general' by design. IMPORTANT: this is for PROJECTS (grouping of work), NOT for declaring yourself as a scheduled orbit agent. Use orbit_declare for that.

  ConnectorNo auth

• orbit_get_instructionsA

  Orbitagents GTM Brain and AI OS for AgentsA

  Load the standing system prompt for a named Orbit. A recurring assignment the operator configured in the Orbit dashboard. Call this FIRST (right after orbit_heartbeat) whenever an activation message assigns you to an orbit by slug. Returns the orbit's full prompt: treat it as your instructions on every run, including the run schedule/cadence it specifies. That cadence is yours to implement in your host client's native scheduling (Claude Code / Cowork scheduled tasks, ChatGPT or Codex scheduled tasks / cron, Gemini or Manus scheduled runs, host cron); Orbit never triggers runs and exposes no orbit_schedule tool. PASS your `agent` identity along with the slug so the operator's dashboard auto-links you as the orbit's owner (flips status from 'waiting' to 'connected'). If the slug is unknown, the error response lists the available orbit slugs in this workspace. Do NOT fall back to orbit_search to hunt for instructions. After loading instructions and running your self-test, call `orbit_ready`. If the operator hands you a STANDING INSTRUCTION that should change how you behave on every future run, call this tool to fetch the canonical current prompt, then call `orbit_update_self` with the full revised text. Never edit a remembered copy and never file the change as an `orbit_decide` directive.

  ConnectorNo auth

• orbit_toolboxA

  Orbitagents GTM Brain and AI OS for AgentsA

  Orbit Toolbox. ALL of your integrations live behind this single tool. Orbit's full capability set (43): image_generate, video_generate, speech_to_text, text_to_speech, calendar, apollo, up2data, apify, orbit_scrape, jev, ocean, email_verify, instantly, perplexity, notion, airtable, linear, github, hubspot, resend, slack, stripe, semrush, google_search_console, twitter, telegram_bot, posteahora, custom_api, remote_mcp, linkedin, whatsapp, instagram, messenger, telegram, x_dms, gmail_mailbox, outlook_mailbox, imap_mailbox, twitter_data, x_article, x_session, reddit_data, predictleads. • image_generate: Orbit-provisioned image generation. Text → PNG, returns a signed HTTPS URL ready to attach to social posts (PosteAhora mediaUrls) or file artifacts. No key required. • video_generate: Make a short video with sound from a description, or bring a picture to life. Orbit-provisioned, no key required. 5 to 15 seconds, vertical, wide or square, saved to Files with a … • speech_to_text: Turn a recording into text: meetings, calls, voice notes, podcasts and the sound of a video. Orbit-provisioned, no key required. Plain text, timed segments with speakers, or SRT a… • text_to_speech: Turn text into natural speech: voiceovers, narrated posts, spoken summaries and voice messages. Orbit-provisioned, no key required. Over 300 voices in 24 languages, saved to Files… • calendar: Read, create and cancel events on the operator's real calendar. Free with a connected Gmail or Outlook mailbox. Use it for meeting prep, scheduling and conflict checks. [requires connected Gmail/Outlook mailbox. Calendar itself is free] • apollo: Unified Apollo tool (Orbit-provisioned). Sub-actions: test, people_search (discovery only, no emails), org_search, people_enrich, people_enrich_bulk (up to 10 people per call), or… • up2data: Orbit's MAIN tool for LinkedIn data, Orbit-provisioned, no key required. Live LinkedIn profiles (positions, education, skills, photo, current company), companies, posts, comments … • apify: Run any of 4,000+ Apify actors (scraping, SERPs, socials, marketplaces) with zero setup. Provisioned by Orbit. Only pay-per-result actors are listed. Never use a subscription/rent… • orbit_scrape: Read any public web page as clean markdown, or search the web, in one call. Orbit-provisioned, free, no key required. The default for company websites, articles, docs, competitor … • jev: Fast, cheap, calibrated decisions on up to 500 items per call. Orbit-provisioned, no key required. Not a writer: it answers one typed question per item (classify into labels you d… • ocean: ONLY for lookalike campaigns or finding new leads modelled on the operator's existing customers. Never for general lead search, LinkedIn work, enrichment or research (use up2data … • email_verify: Check that email addresses are real and safe to send to before a campaign goes out, so it does not bounce. Orbit-provisioned, no key required. Verify up to 10 addresses in one cal… • instantly: Author Instantly cold-email campaigns end to end: write the sequence copy with {{variables}}, attach sending mailboxes, add leads with per-lead variables, activate or pause. Also … [requires operator API key] • perplexity: Ask Perplexity Sonar and get a cited answer. [requires operator API key] • notion: Search Notion pages/databases and create pages. [requires operator API key] • airtable: List and create records in an Airtable base. [requires operator API key] • linear: Linear tracker: read teams, projects, issues and comments; create, update, assign, comment on and close issues. [requires operator API key] • github: List and create GitHub issues in a repo. [requires operator API key] • hubspot: Search HubSpot contacts and create new ones. [requires operator API key] • resend: Send transactional email via Resend from the operator's account. [requires operator API key] • slack: Post a message into a Slack channel using the operator's bot token. [requires operator API key] • stripe: Read-only Stripe: recent charges, customers, subscriptions. [requires operator API key] • semrush: Semrush domain overview. Traffic, keywords, ads. [requires operator API key] • google_search_console: The operator's own Search Console: queries and pages with clicks, impressions, CTR and position; index status of a URL; sitemaps. Can also submit sitemaps and ask Google to crawl … [requires operator API key] • twitter: Post, delete, read and search on X using the operator's own X developer app credentials (OAuth 1.0a or bearer token). Non-provisioned alternative to a connected X account. [requires operator API key] • telegram_bot: Send and read messages with the operator's own Telegram bot (BotFather token): send_message, send_photo, send_document, get_updates, across chats, groups and channels. Several bot… [requires operator API key] • posteahora: Publish, schedule and read analytics on Instagram, TikTok, X, LinkedIn, Threads, Facebook, Bluesky and more via the operator's PosteAhora key. [requires operator API key] • custom_api: Call any HTTP API the operator registered themselves (label + https base URL + optional key). Actions: list, request. The key is stored encrypted and injected server-side. It is n… [requires operator API key] • remote_mcp: Use the tools of any MCP server the operator added themselves (name + https address + optional token). Actions: list_servers, list_tools, call. The token is stored encrypted and o… [requires operator API key] • linkedin: Act on the operator's own LinkedIn: read and reply to DMs, open new conversations, send personalised connection requests, publish posts, comment and like. Caps: 50 messages, 20 in… [requires linked account] • whatsapp: Read and reply to WhatsApp chats from the operator's own number. Warm conversations and follow-ups only. 100 messages a day. [requires linked account] • instagram: Read and answer Instagram DMs as the operator. 40 messages a day. [requires linked account] • messenger: Read and answer Facebook Messenger conversations as the operator. 40 messages a day. [requires linked account] • telegram: Read and reply to Telegram chats as the operator. 120 messages a day. [requires linked account] • x_dms: Read and reply to X direct messages as the operator. 40 messages a day. [requires linked account] • gmail_mailbox: Triage, read and send email from the operator's own Gmail address. Replies and follow-ups, never cold sequences. 120 sends a day. [requires linked account] • outlook_mailbox: Triage, read and send email from the operator's Microsoft mailbox. Replies and follow-ups, never cold sequences. 120 sends a day. [requires linked account] • imap_mailbox: Triage, read and send email from any other mailbox the operator connected over IMAP/SMTP. 100 sends a day. [requires linked account] • twitter_data: PRIMARY Twitter/X public-data source. Search, profiles, timelines, threads, replies, quotes, followers, lists, communities, trends and spaces over a direct REST API. Orbit-provisi… ⚠ Public-data reads only. Private data and account actions require the workspace's own connected X account. • x_article: Write and publish long-form Articles on X as this workspace's own account. Create a draft, set the title and body (markdown), publish or unpublish, list and delete. Requires the w… [requires operator API key] ⚠ Needs the workspace's own X session cookies (auth_token + ct0) and an X Premium account. • x_session: Reply to tweets, post, delete and read/send DMs on X as this workspace's own account, through its saved X session cookies. No developer app needed. Orbit's shared account is never… [requires operator API key] ⚠ Needs the workspace's own X session cookies (auth_token + ct0); they expire after weeks of inactivity. • reddit_data: PRIMARY Reddit source. Post and comment search, subreddit listings and rules, full comment trees, community discovery, user profiles and comment history over a direct REST API. Or… ⚠ Public reads only. No posting, commenting, voting or DMs. ⚠ Reddit caps any single listing at ~1000 items; when `after` is null check `listing_status` before assuming the data ended. • predictleads: Pull GTM buying signals from PredictLeads. Funding rounds, job openings, technology installs, product launches, website changes, exec moves and company connections. Orbit-provisio… ⚠ action 'discover_by_technology' is gated by PredictLeads' discovery add-on and is currently UNAVAILABLE on Orbit's plan. It returns an authorization error even for the documented example. Do not spend calls on it; use 'technologies' per-domain instead. ⚠ Responses are large. Always pass `fields` (e.g. ['data.attributes.domain']) or `mode:'summary'` on discovery actions. Usage: { action: 'list' } → what is LIVE for this workspace right now (full descriptions + JSON Schemas) plus what is not connected yet and how the operator connects it. { action: 'describe', tool: '<name>' } → one tool's schema, full docs, and any known broken/plan-gated actions. { action: 'call', tool: '<name>', arguments: { ... }, agent_id: '<your agent.id>' } → run it. Always include agent_id so spend is attributed to you. { action: 'fetch_payload', payload_id: '<id>', path?, offset?, limit?, fields? } → page a stored oversized response (free, no re-billing). PAYLOAD CONTROLS (use them. Some APIs return 100KB+ of single-line JSON): fields: ['data.attributes.domain', 'data.attributes.company_name'] → project only the columns you need. Cheapest option, always prefer it. mode: 'summary' → structure digest + record count + 2 sample rows, so you can pick `fields` before pulling the full set. max_chars: <n> → clamp the response (default 12000). Anything over the limit is NOT dropped: it is stored and returned as a digest + payload_id you can page with fetch_payload. Never route overflow through files. Every response carries `related_tools`. The tools that feed into or follow from the one you just used. Read it before deciding your next step. Tools marked [requires ...] only work once the operator has connected them. Always `list` once per session to see live status, and `describe` a tool before your first `call`. Never tell the operator a capability is missing without checking `list` first. And never promise an action on a tool that `list` reports as not connected; tell the operator what to connect instead.

  ConnectorNo auth

• deep_researchA

  Ukri GtrA

  ACCOUNT REQUIRED (free — sign in via GitHub at https://pipeworx.io/signup; depth:"thorough" needs a paid plan). If you are not signed in, use ask_pipeworx instead — it works on every tier. Grounded multi-source research across Pipeworx's 1796 STRUCTURED data sources (SEC filings, FRED/BLS economics, FDA, USPTO patents, markets, science, government records, etc.) in ONE call — this is NOT open-web search. Decomposes your question into focused facets, routes each to the right one of 6,821 tools IN PARALLEL, and returns a findings packet: verbatim evidence + confidence + source + fetched_at + a stable pipeworx:// citation per finding, with explicit gaps[] for facets the data couldn't answer (never invented). Best for broad/multi-part questions over structured data ("compare X and Y's regulatory + financial exposure", "research the filings + market picture for ACME"). For a single lookup use ask_pipeworx (one LLM call, not many). For BREAKING or colloquial CURRENT-NEWS / "what's the world saying about X" topics, prefer ask_pipeworx — it routes to live news APIs and the *-news-feeds packs; deep_research returns mostly empty gaps[] when the topic isn't in the structured catalog. Second-hop iteration: depth:"standard" re-angles unanswered gaps (gap recovery); depth:"thorough" additionally chases the best leads from the first pass — so multi-step questions resolve in one call. Every finding carries a `hop` field and a citation_uri — a resolvable pipeworx:// record URI, present only when the source emits one that resources/read can actually serve, so a citation you get back is always fetchable. "standard" and "thorough" also return contradictions[] flagging findings that disagree. Large records are semantically excerpted to the passages relevant to each facet (not head-truncated), so answers deep in a long filing/series aren't missed. Expect 15-60s (thorough with its follow-up + contradiction pass: up to ~90s).

  ConnectorNo auth

• validate_claimA

  Ukri GtrA

  "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