"terminal" matching MCP tools:

• search_components

  Uploadkit

  Fuzzy-search the UploadKit component catalog by any free-text keyword — component name, category, description, or design inspiration (e.g. "apple", "stripe", "vercel", "terminal", "progress ring", "kanban board", "matrix"). When to use: the user describes the vibe or use case but does not know the component name yet ("I want something like Stripe Checkout", "show me Apple-style uploaders"). Prefer this over list_components when the goal is discovery rather than enumeration. Returns: JSON { query, count, matches: [{ name, category, description, inspiration }] }. Read-only, idempotent, case-insensitive.

  Connector

• wsdot_get_ferry_schedule

  wsdot-mcp-server

  Returns departure times for a specific WSF ferry route on a given date. Requires numeric terminal IDs — use wsdot_get_ferry_terminals to resolve terminal names to IDs. Set remainingOnly to true to show only future departures for today (useful for "next ferry" queries). For future dates, all sailings for that day are returned.

  Connector

• niche_session_state

  Niche — Editorial Intelligence

  Universal poll endpoint: read the full current state of a session. Returns status, ranked stories, picked story_id, generated angles, picked angle_id, draft outputs (with trust fields), and an elicitation hint for whatever decision is next. Call this whenever you need to check progress; it's safe and cheap. Each story includes title, summary, headline_candidate (the post-shaped headline distinct from the cluster title), recency_score, relevance_score, freshness_label, and the publication_breakdown of contributing outlets (provenance). Each story also carries a recommended_story_id plus recommendation_reason before a pick. Each draft output's trust data lives under `outputs[i].trust.*` (verifier_blocked_reason, source_faithfulness_score, source_ungrounded_claims, source_diversity_passed, source_recency_passed, source_distinct_count, plus a flags[] array with explicit severity and source_grounding_map). The output top level does not mirror these; read them from `.trust`. Response also includes `phase` (high-level: scanning / drafting / filed / spiked / awaiting), `phase_message` (a rotating gerund, e.g. 'Reading 337 signals'), and `phase_hint` (a one-line agent-facing tooltip with a typical timing band, e.g. 'Clustering, usually 8-15s, no action needed'). The full 17-status state machine is enumerated under `status_glossary` so you can introspect what every state means without discovering it experimentally. For a terminal run, read `outcome` (complete / expired / interrupted / cancelled / failed) rather than the raw `status`: a `failed` status is usually an expired walk-away (a slate was produced) or a refunded interruption, not a real error. Recommended loop: kick off work, then one niche_session_state(wait:30, wait_until:'checkpoint') per stage. It sleeps through the noisy transient statuses (clustering, ranking, generating_*) and wakes only at the next actionable stop (cpN_awaiting_* / complete / failed), or when an async render settles. So a full run is one wait per checkpoint, not several wakes per stage. (`wait_for` is an accepted alias for `wait_until`.) The `wait` plus `since_status` long-poll (wait_until:'change', wakes on any status change) is also supported; prefer 'checkpoint'. Each status' `actionable` flag in `status_glossary[]` indicates which states a 'checkpoint' wait wakes for. Avoid polling every few seconds without `wait`, which may be rate-limited (HTTP 429). niche_story_search is an accepted alias for this tool. Response shape is sparse by default: after a story is picked, only the picked story is returned (not all candidates); same for angles. Set include_unpicked=true to get the full candidate set, useful when revising to a different story or angle. A `sparse_mode` field in the response reports how many items were dropped.

  Connector

• perspective_create

  Perspective AI

  Creates a new perspective in DRAFT status from a natural-language description and starts the design agent. Returns immediately with a job_id and status "pending"; long-poll perspective_await_job with that job_id to receive the generated outline or follow-up question. Behavior: - Creates a new perspective on every call — not safe to retry blindly. Identical input produces a new perspective each time. - If workspace_id is omitted, the user's default workspace is used; errors with "No default workspace found..." if none exists. - Tip: use workspace_list to see all workspaces with their descriptions, then pick the best-matching workspace_id based on context. - Title is auto-generated from the description. - The design agent runs in the background and may take seconds to a minute. Resolve via perspective_await_job; terminal states are "ready" (outline generated, share/direct/preview URLs returned) or "needs_input" (follow-up question requires the user's answer). - description can reference research goals, source URLs, or audience details. Examples: "understand why trial users aren't converting", "convert the form at https://example.com/contact", "talk to churned customers from Q3". - agent_context selects the agent role: 'research' = Interviewer (default; deep qualitative interviews), 'form' = Concierge (replaces static forms with conversational flow), 'survey' = Evaluator (turns surveys into engaging conversations), 'advocate' = Advocate (listens, then responds from a brand/cause playbook). When to use this tool: - The user wants to create a new perspective from a brief. - You're starting the design conversation that may iterate via perspective_respond. When NOT to use this tool: - The perspective already exists and the user wants to change it — use perspective_update. - The agent already asked a follow-up question — use perspective_respond with the user's answer. - Listing or finding existing perspectives — use perspective_list. Typical flow: 1. perspective_create → start design (returns job_id) 2. perspective_await_job → long-poll until "ready" or "needs_input" 3. perspective_respond → if "needs_input", answer and re-poll 4. perspective_get_preview_link → test 5. perspective_update → refine 6. perspective_get_embed_options → deploy

  Connector

• perspective_await_job

  Perspective AI

  Long-polls an async job and returns either its terminal result or another "pending" envelope to keep polling. Supported jobs (started by these tools): - Perspective design — perspective_create / perspective_respond / perspective_update - Conversations explorer — conversations_explorer Behavior: - Read-only — observes a running job. Safe to call repeatedly. - Errors with "Unknown job_id" if no such job exists, or if the id is not a supported job kind. Workspace and perspective access are re-checked on every call. - Each call blocks up to wait_ms (default 30s, min 1s, max 45s). On timeout, returns status "pending" with a progress_cursor — pass it back on the next call to skip already-seen progress events. - Terminal status: - "ready" = job finished successfully (design: outline ready; explorer: answer + sources — discriminate via job_kind) - "needs_input" = design-only follow-up question - Failures are logged with the underlying workflow detail but surfaced as a generic "The job failed. Please try again." to avoid leaking internals. When to use this tool: - Immediately after a start tool returns a job_id. - Re-polling after a previous call returned status "pending" (pass the returned progress_cursor back). When NOT to use this tool: - You don't have a job_id yet — call the start tool first. - Inspecting a finished perspective's config — use perspective_get.

  Connector

• quizbase_list

  QuizBase

  Cursor-paginated browse over the catalog. Quality-first: by default excludes questions flagged for review (use quality='all' for full pool). USE WHEN: full catalog sync, delta sync (updated_since), exhaustive enumeration by filter. NOT WHEN: you only need N random samples (use quizbase_random) or a single record (use quizbase_question_by_id). PAGINATION: stable cursor over id UUIDv7 DESC. First call: omit cursor. Next: pass meta.nextCursor. Stop when nextCursor is null. KEY FILTERS (full parity with REST): - lang: ISO 639-1, default "en". Supported: en, pl. - category (slug), difficulty (trivial|easy|medium|hard|expert — LLM-calibrated), type (multiple|boolean), subcategory (raw slug). - tags (AND), tags_any (OR, max 10): raw tag slugs. - topic (curated, alias resolver), topics_any (OR over curated): higher precision than tags. - regions (cultural affinity, AND): empty = no cultural advantage assumed. Lowercase ISO 3166-1 alpha-2 ('us', 'pl', 'gb') + cultural codes ('jewish', 'christian-catholic', 'islam'). Filter for content statistically more likely known by residents/members. Discover via quizbase_regions. - source (array): include only these of 12 (opentdb, opentriviaqa, kqa-pro, entityq, mintaka, mkqa, nq-open, creak, qasc, arc, webq, quizbase). - exclude_source (array): drop these sources, e.g. ["entityq"]. Applied after source. - license (SPDX): e.g. CC-BY-SA-4.0, MIT. - quality: 'high' (default) = cleanest, most broadly-useful. 'standard' = broader pool incl. niche/too-specific. 'all' = full pool incl. flagged; when 'all', each question gains a "quality" field ('high' or 'needs_review'). - updated_since (ISO 8601): only questions updated after this — for delta sync caches. BATCH + TRANSLATION MAPPING: - ids (up to 250): fetch those exact records in one call (anti-repeat, deep-links, restoring a saved set). Terminal selector — browse filters and cursor are ignored. Missing ids → meta.missing. - content_language (en|pl): with ids, returns each question's sibling in that CONTENT language across the translation chain — the same questions in another language. Distinct from lang (labels only). PAGINATION + COUNTING: - cursor (string): from previous meta.nextCursor. Omit for page 1. - limit (1-100, default 20). - count: none (default, skip — page via nextCursor) | exact (precise COUNT(*), index-only ~25-90ms). OUTPUT: { questions: [...], meta: { count, countMode, language, nextCursor, total? } }. Each question carries full per-record attribution (source, author, license, licenseVersion, licenseUrl, sourceId, url, modifications, lastModified) — identical shape to REST /api/v1/questions. ATTRIBUTION REQUIRED if you redistribute. Credit each question using its own attribution object — see license + licenseUrl + modifications fields per record. COMMON MISTAKES: not passing the cursor on subsequent calls (you'll re-read page 1); polling without updated_since when doing delta sync.

  Connector

• stream_task

  TunnelMind Data API

  Opens a persistent SSE connection that emits events as the task progresses. The stream closes automatically when the task reaches a terminal state or after ~90 seconds (timeout). Heartbeat comments are sent every ~15 seconds to keep the connection alive through proxies. Event types: - `status` — emitted when status changes (pending → running → complete/failed) - `result` — emitted on `complete` with the full result payload - `error` — emitted on `failed`, `cancelled`, or `expired` with error info - SSE comment (`: heartbeat`) — keepalive, no data Use this tool when: - You want real-time progress without polling. - You are in an environment that supports SSE (EventSource API). Do NOT use this tool when: - You want a simple one-shot status check — use `get_task` instead. - Your HTTP client doesn't support streaming responses. Inputs: - `task_id` (path, required): 26-char ULID. Returns: - SSE stream (`text/event-stream`). Each event is `event: <type>\\ndata: <json>\\n\\n`. Cost: - Free. Counts as one request against rate limits when the stream opens. Latency: - First event: <200ms. Stream duration: up to 90s.

  Connector

• submit_workflow

  Botverse

  Submit a multi-step workflow to the Botverse workflow engine. Steps execute in dependency order; parallel branches (multiple steps with the same depends_on) run simultaneously. Returns a workflow_id immediately — poll get_workflow_status every 5–10 seconds until terminal. INTER-STEP REFERENCES: pass a prior step's output into a later step with the string "$.steps.<step_id>.output_key" (e.g. a docx→pdf chain: step to_pdf has depends_on: ["to_docx"] and inputs {"source_url": "$.steps.to_docx.output_key", "input_format": "docx", "output_format": "pdf"} using tool convert_from_url). Workflow params are referenced as "$.params.<name>". No other template syntax (${...} etc.) is supported. BILLING: convert-only workflows run on wallet balance ($0.05/step). Workflows containing transcode or transcribe steps require auto-refill to be enabled at botverse.cloud/dashboard/billing (their cost scales with source duration). Workflow definition uses BWDL (Botverse Workflow Definition Language) — schema at botverse.cloud/schemas/workflow/v1.json.

  Connector

• purchase_book

  bookstore4agents

  Complete a paid purchase of a book. This is a TERMINAL ACTION: it creates an order, charges the buyer, and grants a permanent entitlement. Only call this when the user has EXPLICITLY requested to buy. Never call as part of browsing, price comparison, or information gathering — prices are already visible in search_books results, and free previews are available via get_book_preview. If the user says 'don't buy', 'just compare', 'just tell me the price', or similar — do NOT call this tool. If the user requests an action that requires owning a book they don't own (e.g. commenting on an unowned book), do NOT silently purchase it on their behalf. Instead, tell the user the purchase requirement and ask them to confirm. Spending money is never an inferred default.

  Connector

• get_similarity_match

  hypernatt-terminal

  What happened last time BTC microstructure looked like this? Top-3 historical regime matches with observed about 4h BTC outcomes (NOT vault PnL). USE WHEN: analogies / regime context only. NOT WHEN: trade direction (get_btc_usdc_signal), live trap (get_mm_trap_state), or sizing. RETURNS: hypernatt_similarity_match_v1 with interpretation_contract_v1, confidence_tier, episode_diversity, matches[]. Agents MUST quote do_not_infer rules — never treat similarity_pct as win probability. COST: $0.001 flat via x402 (Base or Solana). Side effects: none.

  Connector

• prepare_upload

  mcp

  Returns the LOCAL shell commands to package your working directory and upload it for an upload-mode deploy (no git, no PAT). Run them in the user's terminal, capture `source_token` from the upload's JSON response, then call deploy_app with that source_token (omit repo). The upload authenticates AUTOMATICALLY with a short-lived ticket minted from your MCP credential — NO API key needed in the command and nothing secret is printed (it falls back to needing $REDU_API_KEY only if minting is unavailable). Excludes node_modules/.git/.venv/build output and .env by default; honors .gitignore when is_git_repo=true.

  Connector

• aetherwave_generate_image

  AetherWave Studio

  Generates one or more images from a text prompt (T2I) or a text prompt + reference image(s) (I2I). Submits the job, polls until terminal, and returns the final image URLs. Default model is 'grok-imagine-t2i' (fast, 6 images per generation, 5 credits). Use list_image_models to see the full lineup with pricing. For I2I, pass `referenceImages` as an array of public image URLs and pick a model with I2I support (e.g. 'grok-imagine-i2i', 'wan-2.5-spicy-i2i'). ## Model selection guide (when the user does not specify a model) Default: `grok-imagine-t2i` (5 cr, 6 outputs per call, fast, general purpose). **Strong recommendation: when a single high-quality output is what's wanted** (most agent / one-shot workflows), prefer `gpt-image-2-t2i` (9 cr @ 1K / higher @ 2K, single deterministic image, best general quality across realism, illustration, typography, and composition; supports up to 2K resolution and most aspect ratios including auto). This is the front-runner for serious creative output where you don't need to pick from 6 variations. Pick a different model when the prompt has these signals: - "single best result" / "one image" / production / no time to pick from variations -> `gpt-image-2-t2i` (9 cr, 1 output, top general quality) - "photoreal" / "photo of" / "realistic" -> `gpt-image-2-t2i` (9 cr, best general realism) or `imagen-4` (12 cr, very high quality) or `z-image-turbo` (3 cr, fastest) - "highest quality" / "premium" / no budget -> `gpt-image-2-t2i` at 2K, or `grok-imagine-quality-t2i` (16 cr @ 1K, 22 cr @ 2K), or `imagen-4-ultra` - Text inside the image (signs, posters, typography) -> `ideogram-v3-t2i` (best in class) or `gpt-image-2-t2i` (also strong) - Artistic / painterly / stylized -> `midjourney-t2i` - Album art / cover art -> `gpt-image-2-t2i` for one strong image; `grok-imagine-t2i` for 6 variations to choose from; `seedream-v4-t2i` if 4K wanted - Logo or design with embedded text -> `ideogram-v3-t2i` - NSFW / adult / explicit -> `wan-2.5-spicy-t2i` (auto-tags creation as 18+; routes to adult gallery) - Cheapest possible / quick test -> `z-image-turbo` (3 cr) - Multiple variations to compare -> keep `grok-imagine-t2i` (6 outputs default) or use `numImages` on a multi-output model For I2I (reference image provided): prefer the dedicated `aetherwave_edit_image` tool for "change something in this image" intent. Use `aetherwave_generate_image` with I2I models only when you specifically want style transfer (`midjourney-i2i`), premium quality (`grok-imagine-quality-i2i`), or adult content (`wan-2.5-spicy-i2i`). Always pass an explicit `aspectRatio` (e.g. "1:1" for square album art, "16:9" for video thumbnails, "9:16" for shorts/reels). Some upstream providers reject submissions with no aspect ratio. Ask the user only when: - The prompt contradicts itself (e.g., "highest quality but cheapest") - The user requested "the best model" with no context, surface 2-3 options with tradeoffs - A single generation would cost more than 20 credits and the user has not confirmed

  Connector

• whatsapp_connect

  local-mcp

  Link WhatsApp to Local MCP by showing a QR code right here in the chat — no Terminal needed. Call this, then on your phone open WhatsApp → Settings → Linked Devices → Link a Device, and scan the QR shown. After you scan, WhatsApp tools (whatsapp_list_chats, whatsapp_read_messages, …) start working. If WhatsApp is already linked, it just reports that.

  Connector

• replay_asof

  Seiche — funding-stress terminal

  Reconstruct the entire funding-stress board as it read on a historical date, point-in-time with no lookahead. Use to test whether Seiche would have flagged a past liquidity episode, or to align a backtest with what was knowable then. Subscriber tool (the Time Machine).

  Connector

• plan_file_info

  PlanExe

  Returns file metadata (content_type, download_url, download_size, expires_at) for the report or zip artifact. Use artifact='report' (default) for the interactive HTML report (~700KB, self-contained with embedded JS for collapsible sections and interactive Gantt charts — open in a browser). Use artifact='zip' for the full pipeline output bundle (md, json, csv intermediary files that fed the report). While the task is still pending or processing, returns {ready:false,reason:"processing"}. Check readiness by testing whether download_url is present in the response. Once ready, present download_url to the user or fetch and save the file locally. Download URLs expire after 15 minutes (see expires_at); call plan_file_info again to get a fresh URL if needed. Terminal error codes: generation_failed (plan failed), content_unavailable (artifact missing). Unknown plan_id returns error code PLAN_NOT_FOUND.

  Connector

• get_checkout_status

  BorealHost

  Poll a checkout session for status updates. Call this after complete_checkout to track payment and provisioning. Polling strategy: - First 60 seconds: every 5 seconds - After 60 seconds: every 15 seconds - Stop after 10 minutes if not completed Checkout statuses (in order): - "not_ready": Missing required fields (slug) - "ready": All fields set, awaiting payment - "awaiting_payment": Stripe checkout page opened, waiting for human - "in_progress": Payment received, site being provisioned - "completed": Site ready — API key included (shown once, then cleared) - "canceled": Checkout was abandoned - "failed": Payment or provisioning failed Terminal statuses: "completed", "canceled", "failed". Args: checkout_id: Checkout session ID Returns (when completed): {"id": "uuid", "status": "completed", "api_key": "bh_...", "api_key_message": "Store this API key securely...", "subscription_id": "uuid", "completed_at": "iso8601"} Note: The api_key field appears ONCE in the first poll after completion, then is permanently cleared. Store it immediately.

  Connector

• mlp_projection

  mlp-tax

  Computes a multi-year tax projection for a publicly traded MLP position, applying the IRS Partner's Basis Worksheet methodology (Lines 1-14) per IRC §705 (basis computation), §731(a) (distributions exceeding basis), §733 (basis reduction), §751 (hot asset recapture), §752 (liability allocation), §1014 (stepped-up basis at death), and §199A (QBI deduction). Returns year-by-year basis erosion, §751 accumulation, annual federal tax, terminal FMV, §1014 step-up value at death, and the break-even sell price. Use when: User holds direct units of a midstream MLP (EPD, ET, MPLX, WES, PAA, NRP, USAC, SUN) and wants to model long-term tax outcomes — when basis reaches zero, total tax paid over the hold horizon, deferred tax eliminated by §1014 step-up at death, or the unit price at which selling matches holding through inheritance. Single position, single lot. Don't use for: 1099-DIV ETFs (AMLP, MLPX, AMZA — these use RIC structure, pay corporate-level tax, and issue 1099-DIV instead of K-1; use a standard cost-basis calculator instead). Multi-position estate analysis — use mlp_estate_planning. Computing basis from actual K-1 data the user has in hand — use k1_basis_compute (single year) or k1_basis_multi_year. Limitations: Single position, single lot — for multi-position portfolios and per-lot optimal sell ordering, see lucasandersen.ai. Federal-level only — does not include state-level basis adjustments or state estate tax. §751 recapture is estimated from default ROC assumptions; actual recapture depends on the partnership's hot-asset disposition schedule. Maintained by Lucas Andersen, MS Finance, with direct positions in major midstream MLPs. Methodology auditable at lucasandersen.ai/methodology.

  Connector

• tool_sa_airport_oracle

  agent-vending-factory

  POST /tools/sa-airport-oracle/run — Returns live flight status from ACSA (airports.co.za). Input: {airport_code: 'JNB'|'CPT'|'DUR', flight_number: string, request_type: 'arrival'|'departure'}. Output: {success, live_status, scheduled_time, estimated_time, actual_time, gate, carousel, terminal, flight_number, airport_code, request_type, error}. Coverage: JNB (O.R. Tambo), CPT (Cape Town Int'l), DUR (King Shaka). Data window: flights within 48 hours. Call GET /tools/sa-airport-oracle/health (free) first — if structure_valid=false, do not proceed. error_type values: 'stale_data' (do not retry), 'not found' (retry after 10-15 min), network error (retry once). flight_number is case-insensitive and normalised to uppercase internally. Read-only — no booking/ticketing. Cost: $0.1200 USDC per call.

  Connector

• open_task_dispute

  Molt2Meet

  Open a formal dispute on a task. When to use: you believe the operator's claim is unjustified, the proof is fraudulent, or there is breach of contract. Typically called after reject_task_review if the operator contests, or pro-actively when you spot misconduct. Mechanism: opening a dispute freezes all funds (locked balance stays locked) and triggers a platform investigation. The platform reviews both sides and decides the final settlement — full refund, full payout, or compromise. Funds remain frozen until the dispute is resolved. Typical resolution time: 1-3 days. Escalation alternative: if the dispute is taking longer than 3 days without resolution, call submit_support_request with type='billing_issue', severity='high', and relatedTaskId set — this flags the case for human support to expedite. Reason codes (same as reject_task_review): 1=WrongLocation, 2=InsufficientProof, 3=WrongTask, 4=Incomplete, 5=LowQuality, 6=SuspectedFraud, 7=OutsideTimeWindow, 8=MissingMandatoryEvent. Requires authentication. Next: monitor task.disputed → terminal state via get_task_events.

  Connector

• varrd_ai

  VARRD — Statistically Validated Trading Edges + AI Research Engine

  Talk to VARRD AI (~$0.25/turn). Describe any trading idea in plain language and the system handles everything — loading decades of market data, charting your pattern, running statistical tests, backtesting with stops, and generating exact trade setups. MULTI-TURN: First call creates a session. Keep calling with the same session_id, following context.next_actions each time. 1. Your idea -> VARRD charts pattern 2. 'test it' -> statistical test (event study or backtest) 3. 'show me the trade setup' -> exact entry/stop/target prices HYPOTHESIS INTEGRITY (critical): VARRD tests ONE hypothesis at a time — one formula, one setup. Never combine multiple setups into one formula or ask to 'test all' — each idea must be tested as a separate hypothesis for the statistics to be valid. Say 'start a new hypothesis' between ideas to reset cleanly. - ALLOWED: Test the SAME setup across multiple markets ('test this on ES, NQ, and CL') — same formula, different data. - NOT ALLOWED: Test multiple DIFFERENT formulas/setups at once — each is a separate hypothesis requiring its own chart-test-result cycle. If ELROND council returns 4 setups, test each one separately: chart setup 1 -> test -> results -> 'start new hypothesis' -> chart setup 2 -> etc. KEY CAPABILITIES you can ask for: - 'Use the ELROND council on [market]' -> 8 expert investigators - 'Optimize the stop loss and take profit' -> SL/TP grid search - 'Test this on ES, NQ, and CL' -> multi-market testing - 'Simulate trading this with 1.5 ATR stop' -> backtest with stops EDGE VERDICTS in context.edge_verdict after testing: - STRONG EDGE: Significant vs zero AND vs market baseline - MARGINAL: Significant vs zero only (beats nothing, but real signal) - PINNED: Significant vs market only (flat returns but different from market) - NO EDGE: Neither significant test passed TERMINAL STATES: Stop when context.has_edge is true (edge found) or false (no edge — valid result). Always read context.next_actions.

  Connector