"Kick" matching MCP tools:

• draft_motion_from_matterA

  transaction-coordinatorA

  Kick off an AI-drafted motion using a saved PrimaCoda matter as the source of facts. Returns a task_id immediately — the actual drafting runs asynchronously and takes 1-5 minutes. Poll with check_motion_status. Use this instead of asking the customer to upload PDFs again. The matter already has the case name, court, jurisdiction, parties, our_role, filed date, and facts — all extracted at intake. Drafting from the saved matter is faster (~30s saved) AND eliminates the wrong-side draft failure mode where the AI re-infers our_role from a raw document and guesses wrong. Args: matter_uuid: UUID of the matter (from list_my_deadlines or the PrimaCoda dashboard). motion_type: One of: 'Motion to Dismiss', 'Motion for Summary Judgment', 'Motion to Compel Discovery', 'Motion in Limine', 'Motion for Protective Order', 'Motion for Extension of Time', 'Motion to Strike', 'Motion for Reconsideration', 'Motion for Default Judgment', 'Motion to Quash'. Other values pass through. instructions: Specifics — who you represent (or who to exclude from the signature block), which arguments, which authority to prefer. Strongly recommended: vague instructions yield vague motions. api_key: Your PrimaCoda MCP API key (starts 'pck_').

  ConnectorNo auth

• polymarket_arbitrageA

  Rick And MortyA

  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

• revit_export_ifcA

  Revit MCPA

  When to use: Kick off a Model Derivative translation of a previously uploaded Revit URN into IFC (IFC2x3 Coordination View 2.0 by default) so the model can be exchanged with non-Autodesk tools (Solibri, BIMcollab, Tekla, openBIM workflows). When NOT to use: Do not use for SVF/SVF2 web viewing (that happens automatically in revit_upload), and do not call repeatedly while a prior IFC job is still inprogress — poll the manifest instead. APS scopes: data:read data:write viewables:read (Model Derivative job + manifest). Rate limits: APS default ~50 req/min per app per endpoint; Model Derivative translation jobs ~60 req/min; OSS uploads size-limited per file to 100MB for direct upload, larger via resumable. Errors: 401 APS token expired — refresh. 403 scope insufficient — add data:write. 404 URN not found — confirm model_id was translated. 409 not applicable. 429 rate limited — back off. 5xx APS upstream — retry with jitter up to 3x. Side effects: Creates a Model Derivative job and, on completion, a new IFC derivative inside the model's manifest. Safe to re-run (APS deduplicates) but each call with x-ads-force may retranslate.

  ConnectorNo auth

• transcribe_feedA

  PodLearnA

  Bulk/season transcription — kick off transcription for up to `max` (cap 25) not-yet-transcribed episodes of a podcast feed in ONE call. Pass the `feed_id` from search_podcasts / list_feed_episodes. Already-transcribed episodes are skipped free. COSTS 1 credit per newly enqueued episode (or subscription quota) — CONFIRM the cost with the user first. Enqueue-and-poll: returns each enqueued episode_id; poll get_episode_details until transcription_status is "completed".

  ConnectorNo auth

• voiceover_batchA

  CluesoA

  Set voiceover text and/or trigger speech generation for any number of clips in a single call. Each entry chooses its own action: - "set_text" — set transcript for a clip (clip_index + text) - "generate_speech" — async TTS for a clip (returns immediately; wait: true blocks until it lands) - "set_and_generate" — set text and kick off TTS in one entry (+ text) Emotion tags: put ElevenLabs emotion/audio tags in square brackets in the text, e.g. "[excited] And it just works." or "[whispers] Here's the trick." — the voice performs them and they're never spoken or shown. Use them sparingly, before the phrase they colour. Pauses: <pause:1.5s> in the text is exact silence of that length, anywhere including the very start (a lead-in before the first word) and the very end (a hold after the last); word timings account for it, and get_clip's voiceover_text shows existing pauses the same way, so keep them when you rewrite. Unlike the [pause] emotion tag, which is a performed beat of no set length. Sizing a script: narration runs roughly 2–2.5 words per second depending on the voice — size the script to the target length, generate the voiceover, then read the real clip durations back (get_clip, once `busy` is empty) before timing visuals. Address a clip the same way as everywhere else: `clip_index`. Pass `clip_id` instead if you already have it — it survives clips being inserted or reordered mid-build — but you never need both; whichever you omit is looked up once for the whole call. Entries within one call are applied in order. Returns one result object per input entry. All text-set actions land in ONE save; the TTS for generate/set_and_generate runs async per clip after. Sync points: if get_clip's `voiceover_text` for the clip contains `<SYNC_MARKER N>` tokens (a screen recording's on-screen actions), your new text must carry every one of them, each exactly once and in order, placed where that action is narrated. Otherwise the entry is refused and nothing is written. Rephrase the words between the tokens freely. IMPORTANT — generating speech RESCALES the whole clip, it does not clamp it: when audio is generated (generate_speech / set_and_generate), the clip's duration is reset to the spoken audio length, and then EVERY element on that clip is retimed proportionally by (new duration ÷ old duration). start_time, end_time and every keyframe timestamp are multiplied by that factor. Nothing is merely truncated — on a 6s clip that becomes 1.02s, an animation you placed at [0, 1.6] ends up at [0, 0.27]. Zoom elements whose window falls under the minimum after scaling are DROPPED entirely. Generation is async, so this lands AFTER this call has already returned success. So: generate speech BEFORE placing time-sensitive elements — then re-read the clip and check what your elements actually became, not just the clip duration. Concurrency: parallel-safe (conflict domain: a clip's voiceover). The server merges each clip's voiceover under a per-guide lock and preserves that clip's elements, so you can fan voiceover work out across subagents by clip — and it's safe to run alongside element edits. Two concurrent edits to the SAME clip's voiceover do not last-write-win — both claim that clip's voiceover path, so the later one is REJECTED and nothing is written; re-read and re-apply. Do NOT run concurrently with whole-clip/whole-project mutations on the same guide (update_clips on that clip, structural clip ops, add_audio, update_project).

  Connector

  Destructive

  No auth

• create_videoA

  VidGuyA

  Kick off an ASYNC full video production job (the Quick Create flow). SPENDS CREDITS (dynamic, ~50–200 by duration/type — the exact amount comes back as creditsReserved). Returns a jobId; poll get_job until completed. For UGC video types ('ugc','brainrot','ugc-broll','ugc-demo') you MUST supply a script and a characterId: a saved actor from list_characters / list_character_library, or "auto" to let VidGuy pick a talking-head actor whose setting, gender and age fit the script (free; saved as a character on the account). With "auto" the response carries characterId + actorPick {picker, fit, setting} — pass that characterId on the next videos to keep the same actor across a campaign. Credits refunded automatically on failure.

  Connector

  Destructive

  OAuth

• generateA

  maginary-mcpA

  Kick off a generation via POST /api/gens/. Args: prompt: The user's words, passed through as-is. Do NOT add flags the user did not ask for — no ``--ar``, no ``--flagship``, no model flags. Every extra flag costs credits; adding them unrequested is wrong. Standard quality is the default and is cheap; ``--flagship`` is ~4× more expensive and must only be used when the user explicitly asks for best quality. If the user asks about quality or aspect ratio: ask them first (standard vs flagship, landscape vs portrait) before generating. Flags go at the END, only when the user asked: ``--1``/``--2``/``--3``/``--4`` = image count (default 4), ``--ar 16:9`` = aspect ratio, ``--flagship`` = best quality. Unknown flag: call ``get_parameter(name)`` first — never guess. Examples — user says "a fox": prompt is ``"a fox"``. User says "a fox, landscape, best quality": prompt is ``"a fox --ar 16:9 --flagship"``. **Image-to-image (img2img):** Place one or more public image URLs in the prompt, followed by editing instructions: ``"https://cdn.example.com/photo.webp reimagine as oil painting --ar 16:9"`` The engine extracts URLs automatically and switches to img2img mode. Multiple URLs trigger multi-input mode (compositing/combining). Use ``upload_image`` first if images aren't already hosted. **Image-to-video:** Place an image URL in the prompt AND add ``--mp4`` plus video flags (``--5sec``, ``--1080p``). Or use ``execute_action`` with ``action_type="img2vid_basic"`` on a completed generation's image. **Style reference (--sref) is NOT img2img:** ``--sref <url>`` copies the visual *style* of a reference image (colors, mood, composition) without using the image content as input. A bare URL in the prompt edits the actual image; ``--sref`` transfers style. callback_url: Optional HTTPS URL that will receive a webhook when the generation reaches done / failed. See https://maginary.ai/blog/webhooks-guide for signature verification. Returns: On success, the created generation record. Key fields: ``uuid`` (use to poll), ``action_type``, ``processing_state``, ``expected_output_count``. On failure, an ``isError`` result instead (nothing is raised), with a JSON body whose ``error`` field is one of: - ``"auth"`` — no/invalid API key. Surface the message directly to the human. - ``"payment_required"`` — out of credits. The body carries ``billing_url`` and top-level x402 fields (``accepts``, ``resource``): either send the human to ``billing_url`` to top up, or pay programmatically via x402 (settle ``accepts[0]`` with USDC on Base and retry). - ``"demo_not_found"`` — ``--demo`` prompt has no matching seeded generation. ``available_demos`` lists valid prompts. - ``"failed"`` — anything else (invalid prompt, rate limit, backend or network error); see ``message``. x402 over MCP: a ``payment_required`` result also carries the x402 fields at the top level (``accepts``, ``resource``); an x402-capable client signs ``accepts[0]`` and calls this tool again with the payment in ``_meta["x402/payment"]``. The settled call returns the generation with ``x402_receipt`` (and ``_meta["x402/payment-response"]``); a wallet's first settlement creates its account. Subsequent requests use wallet-signed auth headers (X-Wallet-Address/Signature/Timestamp) or pass an API key as ``_meta["maginary/api_key"]``. Every flag that exists, and its state: Flags, live (35): --ar, --output-count (--1/--2/--3/--4), --seed, --transparent, --sref, --sw, --png, --jpg, --webp, --svg, --2k, --4k, --upscale, --vary, --varysubtle, --varystrong, --panleft, --panright, --panup, --pandown, --zoomout, --mp4, --video-resolution (--480p/--540p/--720p/--1024p/--1080p/--2160p / --4k (4k, Seedance 2 Pro)/--480p24 / --480p24fps/--540p24 / --540p24fps/--720p24 / --720p24fps/--1024p30 / --1024p30fps/--1080p24 / --1080p24fps), --video-fps (--24fps/--30fps/--50fps/--60fps), --video-duration (--4s / --4sec/--5s / --5sec/--6s / --6sec/--8s / --8sec/--10s / --10sec/--12s / --12sec), --flagship, --sora, --soralite, --nanobananapro, --nb2, --gpt2, --gpt2high, --seedance2, --seedance2pro, --demo. Partial (4, only some models honour them): --no, --zoomout2x, --zoomoutexpand, --zoomoutexpand2x. Reserved (2, the parser rejects them): --cref, --cw. Any other --flag is rejected with `Unrecognized parameter`. Details: `get_parameter(name)`.

  ConnectorNo auth

• classify_segment_groupA

  SliqA

  <summary>Kick off classification of the group's in-scope canonical people, in the background. The scope is the group's criteria (campaigns and teammates). People in scope are tagged automatically within about 15 minutes of being looked up or contacted, so call this right after creating a group to tag the people already there now, or with `force=True` to re-classify everyone (a re-tag after editing the group or its tags). Without `force`, only people not yet classified for this group are processed. Results are not immediate — read them afterward with get_segment_rates / query_segment_people. Classification costs credits (a flat per-person rate). The return carries the count of people the run will process and the credits it will charge (exact — the same population the run bills), so you can tell the user the cost; a run never charges more than the balance. If the balance can't cover the estimate the run is not enqueued — the return says so, and you should relay it.</summary> <returns> <description>Dict with the in-scope person count and estimated credit cost, plus whether the run was enqueued or blocked for insufficient credits. Enqueued -> {"enqueued": true, "group_id", "person_count", "estimated_credits"}. Blocked -> {"enqueued": false, "reason": "insufficient_credits", "group_id", "person_count", "estimated_credits", "balance"}.</description> </returns>

  ConnectorOAuth

• kalshi_weather_edgeA

  Rick And MortyA

  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

  Rick And MortyA

  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

• research_rowA

  Rick And MortyA

  Claygent-style per-row research: answer ONE question about ONE company and return a JSON object matching your output_schema, with every field wrapped in its own evidence — {value, evidence_url, quote, status}. status is NEVER self-reported by the model: "found" means this code independently verified the model's quote is a VERBATIM substring of text actually fetched; "inferred" means a value was given but the quote could not be verified; "not_established" means no source answered the field, and its value is always null — never guessed, never a blended score. Sources: "web" fetches the company's own site (entity.domain required — homepage, /about, /leadership) via fetch_url; "catalog" checks entity_profile (SEC EDGAR; resolved:false for a private company is expected, not a failure); "both" (default) tries both. max_cost (USD, default 0.02, max 0.50) scales how many pages are fetched and refuses up front if it is too small to pay for even one extraction call (floor $0.002) — never silently overspends. A row where every source comes back empty costs nothing: every field is mechanically not_established with NO model call made. For a boolean/derived field (e.g. "does this company sell to healthcare"), the quote only has to SUPPORT the value — a descriptive sentence about customers/products counts, the source need not state the answer verbatim. leadership_page_status ("fetched"|"not_found"|"not_attempted", plus leadership_note) says plainly whether a leadership/team page was actually read, so a named-person field (head_of_sales) coming back not_established is distinguishable from "this company just doesn't publish one" vs. "we never checked". model_output_empty:true means the model returned nothing usable (a transport/budget problem) — every field is not_established for THAT reason, never read as 20 individual "no" judgments. Use with a fixed question + schema across many rows for "Claygent over N companies with a hard cost cap" (composes with batch callers). For picking from a fixed label list instead of extracting open fields, use classify_row (cheaper, one model call).

  ConnectorNo auth

• propose_automationA

  CRM ConnectorA

  AI Agents (inside one system): Use when the customer wants something to keep happening by itself inside one system on AI Agent (not for a one-off change: use propose_changes), such as "when a deal is won and the amount is above 5,000, add a kick-off task for the owner and a note". It turns that into one fixed rule on one record type: when (trigger), only if (conditions), then (actions). Before calling it, describe the rule in plain words (when, only if, then, and whether it also acts on records that already match) and get a yes. Nothing runs yet: the answer gives the rule as one sentence, how many records it would have acted on in the last 30 days with examples, and an approval link. Share that link: the rule only starts once the customer approves it there, and from then on the platform runs it again and again without asking. Use describe_record_type for the field keys; each action is one of the actions of propose_changes (set_fields, add_note, add_task and so on), with the values that action takes there. Pass replaces with an automation id to change an existing rule. A rule only acts inside that one system: to sync records between two systems, use an integration (plan_integration). It never deletes and never records a payment.

  Connector

  Destructive

  No auth

• start_agentic_launchA

  Demand Discovery AIA

  Kick off Day 1 of the 90-day Agentic Launch for a completed Demand Discovery Report. Demand Discovery surfaces named prospects matching the idea's ICP and DRAFTS the first outreach batch. It sends NOTHING automatically - the user reviews and sends from their hosted manage page. Outreach is drafted to come from Amy @ Demand Discovery, with replies routed to the user's own email. Call this after a paid report is "ready" and the user wants to act on it (e.g. "generate prospects", "start agentic launch", "find me people to talk to", "yes, do the outreach"). Pass the reportId, the user's email, and the alTriggerToken from the ready report if you have it. The email MUST be the address the user themselves provided earlier in this conversation (their report-delivery email) - if you don't have it in context, ask the user first; NEVER invent one or use a placeholder like user@example.com (placeholders are rejected and the launch will not start). The response returns a manageUrl where the user reviews/sends the drafted outreach (and can switch the sender to their own Gmail).

  ConnectorNo auth

• upload_modelA

  ScanBIM MCPA

  Ingest a 3D model from a public URL into APS OSS and kick off a Model Derivative translation job, returning the URN plus a browser viewer link and QR code. Supports 50+ formats: Revit (.rvt/.rfa), Navisworks (.nwd/.nwc), IFC, FBX, OBJ, SolidWorks, point clouds (E57/LAS/RCP), CAD (DWG/STEP/IGES), etc. When to use: you have a publicly downloadable 3D file (S3 presigned URL, GitHub raw, etc.) and need it translated to SVF2 so it can be viewed, measured, or clash-checked via other tools. When NOT to use: the file is only on a local disk or behind auth (fetch will fail) — first push it to a public URL. Do not call to re-translate a model already uploaded; call get_model_metadata instead. APS scopes: data:read data:write data:create bucket:read bucket:create viewables:read Rate limits: APS default ~50 req/min per app per endpoint; Model Derivative translation jobs ~60 req/min; OSS uploads size-limited per file to 100MB for direct upload, larger via resumable. Errors: 401 APS token expired/invalid — refresh; 403 scope or resource permission denied; 404 source file_url not reachable or bucket not found — check the ID; 409 bucket name conflict (bucket already owned by another app — pick a unique bucketKey); 429 rate limited — backoff and retry; 5xx APS upstream outage — retry with jitter. Side effects: NON-IDEMPOTENT. Creates the scanbim-models bucket if absent, uploads a new OSS object with a timestamped key (each call creates a distinct object even for the same input), submits a Model Derivative job (x-ads-force=true overwrites prior derivatives for the same URN), and inserts a row into D1 usage_log + models table.

  ConnectorNo auth

• start_agentic_launchA

  Demand Discovery AIA

  Kick off Day 1 of the 90-day Agentic Launch for a completed Demand Discovery Report. Demand Discovery surfaces named prospects matching the idea's ICP and DRAFTS the first outreach batch. It sends NOTHING automatically - the user reviews and sends from their hosted manage page. Outreach is drafted to come from Amy @ Demand Discovery, with replies routed to the user's own email. Call this after a paid report is "ready" and the user wants to act on it (e.g. "generate prospects", "start agentic launch", "find me people to talk to", "yes, do the outreach"). Pass the reportId, the user's email, and the alTriggerToken from the ready report if you have it. The email MUST be the address the user themselves provided earlier in this conversation (their report-delivery email) - if you don't have it in context, ask the user first; NEVER invent one or use a placeholder like user@example.com (placeholders are rejected and the launch will not start). The response returns a manageUrl where the user reviews/sends the drafted outreach (and can switch the sender to their own Gmail).

  ConnectorNo auth

• publish_virtual_dimensionA

  Costory: Your Finops MCPA

  Validate the latest **persisted** pending virtual dimension draft, then promote it to published and kick off a BigQuery refresh. `virtualDimensionId` in inputs equals `id` from list/get/search. Requires a pending draft row — call update_virtual_dimension_draft for an existing virtualDimensionId (or create_virtual_dimension_draft for a brand-new VDIM) before publish. Preview alone does not create a draft. Rejects invalid drafts with draftValidation errors (no publish). On success returns `virtualDimensionId`, immutable `bqName`, `name`, `computeStatus`, and published rules — does not wait for the refresh job. After publish, query using returned `bqName` for groupBy/filterCel in query — bqName is immutable (set at create from the initial name) and does not change when name is renamed. `computeStatus` is `REFRESHING` when the refresh job was queued (async — poll via get or list_virtual_dimensions until `COMPLETED` before querying), or `TO_REFRESH` when the draft was promoted but queuing the refresh job failed — do not query yet; retry publish or re-check `computeStatus` until `COMPLETED`. Deletes the pending draft version. Clerk MCP only — not available on the service route. Demo orgs are read-only unless the Clerk caller is an org admin on that tenant. EXAMPLE: "Publish the Environment VDIM draft" → { virtualDimensionId: "<virtualDimensionId from create/list>" }

  Connector

  Destructive

  OAuth

• classify_message_tag_groupA

  SliqA

  <summary>Kick off classification of the group's in-scope sent messages, in the background. The scope is the group's criteria (channel, campaigns, conversation positions, teammates). Once a run has classified a message, new sends in that scope are tagged automatically once a day, so call this to tag what's already sent now (right after creating a group, or to catch up before the next daily run), or with `force=True` to re-classify everything (a re-tag after editing the group or its tags). Without `force`, only messages not yet classified for this group are processed. `channel` narrows to LinkedIn or email; `sent_after` classifies only messages sent on or after that instant. Results are not immediate — read them afterward with get_message_tag_rates / query_tagged_messages. Classification costs credits (a flat per-message rate). The return carries the count of messages the run will process and the credits it will charge (exact — the same prospect-resolved population the run bills), so you can tell the user the cost; a run never charges more than the balance. If the balance can't cover the estimate the run is not enqueued — the return says so, and you should relay it.</summary> <returns> <description>Dict with the in-scope message count and estimated credit cost, plus whether the run was enqueued or blocked for insufficient credits. Enqueued -> {"enqueued": true, "group_id", "message_count", "estimated_credits"}. Blocked -> {"enqueued": false, "reason": "insufficient_credits", "group_id", "message_count", "estimated_credits", "balance"}.</description> </returns>

  ConnectorOAuth

• rotateSpritesheetA

  Ludo AI Game AssetsA

  Re-render a previously generated sprite animation from a new view: the same motion and timing, seen from a different angle (e.g. a front-facing walk cycle turned into the same walk seen from the back). Pass the `spritesheet_url` you received from `animateSprite`, `animateSpriteKeyframes`, `transferMotion`, `editSpritesheet` or an earlier call - it must be a spritesheet you generated within the last 7 days; arbitrary external images are not accepted - and, as `image` (URL or base64), the character exactly as it must appear in the new view: it becomes the first frame of the animation. To produce that image, call rotateSprite on the animation's first frame (or any image of the character) and pick the view you want. An optional `final_image` fixes the last frame (it defaults to the first frame, for cyclic or returning animations), and an optional `prompt` steers the result: the character's facing in the new view ("its back to the camera"), where the action goes ("the kick goes to the left of the frame"), or anything else about the motion. Runs on hydra (default) or hydra-plus (finer detail). The job result is the same sprite result as animateSprite (`spritesheet_url`, `video_url`, grid fields, optional GIF and frame URLs). The animation covers the source's own length (up to 5 seconds; a longer source is sped up to fit), so omit `duration` unless you need to change that. Credits are held for that length when the job is accepted, or for 3 seconds when it is shorter (a new view is a new generation, and hydra generates at least 3 seconds); the final charge is the model's rate × seconds of video generated, never more than was held, and the difference (or everything, if the job fails or is cancelled) is refunded. Pass an optional request_id to tag the result for later retrieval via listGenerations (type spritesheet). Async generation job: returns `{id, status}` - poll `getApiJob` (job and credit contract: see the server instructions). Credits: Cost varies by model and duration (credits/second × duration).

  ConnectorNo auth

• start_auditA

  webabilityA

  Kick off a FULL accessibility audit deliverable for a URL — a persistent, timestamped artifact, not an inline scan. Runs the server-side pipeline (axe + advanced checks + mobile viewports + annotated screenshots + optional agent spot-check) and produces a downloadable report and a formatted Excel workbook (Cover / Status / Barriers / ADA context sheets) stored durably. Returns immediately with an audit `id`; poll `get_audit` for progress and, when complete, download URLs. Use this when someone needs a durable artifact to attach as evidence of testing effort for a compliance officer or legal response — for iterating on code, use scan_page + verify_fix instead. Needs a free WebAbility account (sign in by connecting https://mcp.webability.io/mcp/auth, or run `webability login`). Set includeAgent:true to add the slower agentic manual-audit pass. To audit a local dev server, open a tunnel (`webability-tunnel --port 3000`) and pass its URL as `url` with the printed secret as `tunnel_secret`; keep the tunnel open until get_audit reports complete (about 5 minutes) — the pipeline loads the page several times.

  ConnectorNo auth

• archive_evidenceA

  Rick And MortyA

  What did a web page say on a given date? Finds the archived capture of a URL nearest that date across the Internet Archive Wayback Machine, Common Crawl and Arquivo.pt, reads it, and returns the readable text (HTML stripped) with the capture timestamp, a link to the archived copy, and the GAP between the date asked for and the capture actually used (e.g. "Captured 1.5 day(s) before the requested date"). One call replaces the find-capture, fetch-record, parse-HTML chain. If no archive holds a capture within max_gap_days (default 30) it answers status "no_capture" and names the nearest capture before and after the date with their gaps, so a distant capture is never passed off as the page on that date. Every archive's outcome is listed in sources[]; one that timed out or errored says so with its upstream status, and if all of them failed the answer is error "archives_unavailable", not no_capture. Captures are immutable and cached by capture id; served_from says whether the text came from cache or upstream. Use archive_compare to see what changed between two dates.

  ConnectorNo auth

• fussballde_matchdayA

  Crawlora MCPB

  Returns the matches of a competition's current matchday, of a numbered matchday (matchday, 1 to the competition's matchday count, reported as matchday_count) or of the matchday around a date. Each match has teams, date, kick-off time, score and status (finished, scheduled, cancelled, annulled, abandoned, no_show or other, with result_qualifier such as after_penalties on a decided result). Cups and tournaments have no numbered matchdays; for them the response lists the competition's `rounds` (each round id works as `competition_id` to read that round) and labels every match with its `round`. Dates, times and scores are decoded from the site's obfuscated glyph fonts. Use fussballde_match_plan for the whole season schedule or fussballde_match for one match in detail.

  ConnectorNo auth