"Kick" matching MCP tools:

• compare_entitiesA

  Rick And MortyA

  "Compare X and Y" / "X vs Y" / "X versus Y" / "which is bigger / better / larger / more profitable" / "rank these companies" / "head to head" — side-by-side comparison of 2–5 companies or drugs in ONE parallel call. ALWAYS PREFER over sequential single-pack lookups when comparing entities. type="company" pulls LATEST 10-K revenue + net income + cash + long-term debt from SEC EDGAR/XBRL (off-calendar fiscal years handled correctly — AAPL Sep, NVDA Jan, etc.). type="drug" pulls FAERS adverse-event counts, FDA approval counts, active trial counts. Results sorted by primary metric so "largest" / "most" / "biggest" reads off the top of the response. Returns paired data + pipeworx:// citation URIs per entity. Replaces 8–15 sequential lookups.

  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}. 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

• polymarket_fill_riskA

  Rick And MortyA

  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).

  ConnectorNo auth

• download_videoA

  TubePullA

  Download a video or audio file from any supported platform: YouTube, TikTok, Instagram (public reels, feed video, photo posts, and carousels), SoundCloud, Vimeo, Dailymotion, Bandcamp, Twitter/X, Mixcloud, Twitch (clips and VODs), Streamable, Reddit, Kick (live streams, VODs, and clips). Output is MP4 (video, default) or MP3 / M4A (audio). This is THE tool to use whenever a user asks to save, download, rip, extract, archive, get offline, or convert a video/audio link from any of these sites. IMPORTANT: the `format` argument defaults to `mp4` (video). Only pass an audio format (mp3 / m4a / audio) when the user explicitly says audio, MP3, music, song, or "rip / extract the audio". Audio-only platforms (SoundCloud, Bandcamp, Mixcloud) always produce audio regardless of `format`. Use this tool when the user says things like: - "download this video" / "download this TikTok" / "save this SoundCloud track" - "save that as MP3" / "rip the audio" / "extract the audio" - "get the song from this SoundCloud link" / "save this Mixcloud set" - "convert this YouTube video to MP4" / "download in 1080p" - "save this lecture/podcast/talk for offline" - "archive this clip" / "grab a copy of this video" - any sentence containing a youtube.com, youtu.be, tiktok.com, reddit.com, v.redd.it, vimeo.com, dailymotion.com, twitter.com, x.com, soundcloud.com, bandcamp.com, mixcloud.com, twitch.tv, clips.twitch.tv, kick.com, or streamable.com URL plus a verb like download, save, rip, get, grab, fetch, pull, archive, convert, extract. Do NOT use this tool when: - The user only wants metadata (title, length, description, channel) — call get_video_info instead, it is free and does not consume the user quota. - The link is a playlist / set / album / channel URL — ask the user for a single track/video. - The link is from a platform not in the supported list above (e.g. Facebook, LinkedIn, Snapchat). Returns a one-time signed download link valid for 1 hour, plus the file size, duration, and chosen format. Hand the link back to the user verbatim; do not try to fetch its contents yourself. Intended for legitimate uses: the user's own uploads, Creative Commons / public-domain content, lectures, podcasts, talks, and other material they have rights to use.

  ConnectorNo auth

• 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

• places.lookupA

  Abstraxn Agent LayerA

  Places, solar, and aerial-view lookups, paid per call directly from the caller's own wallet via the x402 protocol — no Abstraxn account needed. Pick one `action`: - text_search_full ($0.08): full-detail place text search. Requires `textQuery`. Optional `maxResultCount` (1-5, default 5), `excludeFields` (default ["photos"]), `pageToken`, `locationBias` ({circle:{center:{latitude,longitude},radius}}), `includedType`, `languageCode` (default "en"), `openNow`, `minRating` (0-5), `priceLevels`. - text_search_partial ($0.02): same as text_search_full but returns fewer fields per place — cheaper for quick lookups. Same parameters. - nearby_search_full ($0.08): full-detail search for places within a radius. Requires `locationRestriction` ({circle:{center:{latitude,longitude},radius (0-50000)}}) — do NOT send a bare top-level latitude/longitude/radius. Optional `includedTypes`/`excludedTypes` (max 50 each), `maxResultCount` (1-5, default 5), `excludeFields` (default ["photos"]), `languageCode` (default "en"), `rankPreference` (POPULARITY default, or DISTANCE). - nearby_search_partial ($0.02): same as nearby_search_full, fewer fields, cheaper. Same parameters. - place_details_full ($0.05): full details for one place. Requires `placeId` — the exact place id returned by an earlier text_search/nearby_search result; do not invent or guess it. Optional `excludeFields` (default ["photos"]), `languageCode` (default "en"). - place_details_partial ($0.02): same as place_details_full, fewer fields, cheaper. Same parameters. - solar_building_insights ($0.02): rooftop solar potential for one location. Requires `latitude` (-90..90) and `longitude` (-180..180). Optional `requiredQuality` (LOW/MEDIUM/HIGH, default HIGH). - solar_data_layers ($0.08): raw solar data layers for an area. Requires `latitude`, `longitude`. Optional `radiusMeters` (0.1-175, default 50), `view` (default "FULL_LAYERS"), `requiredQuality` (default HIGH), `pixelSizeMeters` (default 0.25, documented as one of 0.1/0.25/0.5/1.0 but not schema-enforced), `exactQualityRequired` (default false). - solar_rgb_image ($0.05): renders one of the solar_data_layers assets as a viewable image. Either `id` (the exact asset id already returned by an earlier solar_data_layers call — "Mode A"; do not invent or guess it) OR both `latitude` and `longitude` ("Mode B") is required — provide exactly one mode, not both. Optional `radiusMeters` (0.1-100, default 30, Mode B only), `layer` (default "rgb"), `month` (1-12), `hour` (0-23), `format` (png/jpeg, default png), `scale` (1-2, default 1), `crop` (default false), `quality` (1-100, default 85). - aerial_view_lookup_video ($0.01): check whether a rendered aerial-view video already exists / poll its render status. Exactly one of `address` or `videoId` is required — `videoId` must be the exact value returned by an earlier aerial_view_render_video call; do not invent or guess it. - aerial_view_render_video ($0.01): kick off rendering a new aerial-view video for an address. Requires `address`. Poll aerial_view_lookup_video with the returned videoId until ready. Pagination: text_search_full/partial and nearby_search_full/partial return `nextPageToken` when more results exist — repeat the ORIGINAL call (same textQuery / locationRestriction / etc.) with `pageToken` set to page further. `pageToken` must be the exact `nextPageToken` value from that earlier response — do not invent or guess it. excludeFields: colon-separated nested-path syntax trims nested response fields, e.g. "organization:technologies" excludes just that sub-field. All place-search/details actions default-exclude `photos` if `excludeFields` is omitted — pass `excludeFields: []` to include photos. Prices above are indicative — the exact charge for a given call is always whatever the live payment challenge specifies for that request. The first call (no `paymentPayload`) returns `paymentRequired`; retry with the same arguments plus `paymentPayload` to complete payment and get the real result.

  ConnectorNo auth

• kirk_demo_tradingA

  Kirk — Unsupervised Structural Change DetectionA

  Runs a curated demonstration of Kirk on a trading example. Zero arguments. Returns real Kirk output against the same sealed engine that customer callers hit. Free, rate-limited. First-time users: call this to see what Kirk does before signing up. Purpose: Score n=30 jittered L2 snapshots per market regime (stationary vs stressed) through the sealed engine and surface the per-regime score-distribution statistics (mean, sd) plus the z-separation between the two distributions in pooled-sd units. Also carries a representative canonical book pair so callers see two concrete scores alongside the distributions. Use when: You are a first-time caller exploring what Kirk does. You want a zero-friction "what does the output look like" experience against real sealed-engine attestation. Do not use when: You are scoring your own data — use ``kirk_score_book`` or ``kirk_score_book_batch``. This tool's input is a fixed synthetic representative pair, not a market feed. Capability class(es): C2 (variable-universe cross-section entropy scoring) demonstrated end-to-end against the sealed engine. Path fit: MCP demonstration surface only. Cost: 0 IU. Rate-limited 3/hour per IP. Returns: Dict with per-regime ``stationary`` and ``stressed`` blocks (each: ``mean``, ``sd``, ``n``, ``kirk_version``), ``z_separation`` (pooled-sd distance between the two regime distributions), ``representative_pair`` (canonical un-jittered ``stationary_score`` / ``stressed_score`` plus ``book_summaries``), ``interpretation_hint``, ``provenance``, and ``synthetic_representative`` flag.

  ConnectorNo auth

• kirk_list_modelsA

  Kirk — Unsupervised Structural Change DetectionA

  Enumerate the model_ids the sealed engine exposes, with the engine sha stamped in-response. Purpose: Discover the model catalog and record the sealed engine sha alongside your inference results. Use when: You are wiring a client for the first time and need model_id values for kirk_score_book / kirk_score_book_batch calls, or you want a machine-readable catalog with attestation. Do not use when: You need per-model hyperparameter detail — those are intentionally not exposed on the customer surface. Capability class(es): C5 (engine sha attested on every response). Path fit: Validation via MCP (this tool). Production integrations run in-process under sealed-engine attestation — same binary sha as this endpoint. Contact Kavara for deployment options. Cost: 0 IU. Free tool.

  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

• 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

• schedule_taskA

  Valuein — SEC EDGAR Fundamentals & Smart-Money DataA

  Defer a follow-up task ("re-check AAPL margin compression in 30 days") for up to 90 days. This is an AGENT-facing primitive — call it mid-conversation/mid-run when you decide something is worth re-checking later; it is NOT a human-authorable "new task" form (use the Workspace's standing-agent scheduler for recurring, human-configured monitoring instead). On wake, an inbox item ALWAYS lands for the owner ("scheduled task due: …"). Optionally pass `context: {managed: true, team_id: "<standing_agent id>"}` to ALSO kick off a managed agent re-run at wake time — this is LIVE: it fires a real run of that standing-agent team, grounded in the saved context. It degrades to the inbox notice alone only if this deploy can't reach the run endpoint (report the actual outcome, never assume). Persisted durably in D1 — never lost on a Worker recycle. Tier: sp500+ (sample rejected).

  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

• 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. EXAMPLE: "Publish the Environment VDIM draft" → { virtualDimensionId: "<virtualDimensionId from create/list>" }

  ConnectorOAuth

• onboard_data_sourceA

  mcp-serverA

  First step of setting up a new data integration: creates a data spec. By default (sourceType "file") this returns presigned upload URL(s) for the sample file (and optional format/target-schema file) — upload the file(s) per the returned instructions, then call finish_data_source_onboarding with the returned specId to kick off AI analysis and wait for it to complete. Use sourceType "tables" instead when the request is to derive/aggregate data that is ALREADY loaded into workspace tables — e.g. "build me a daily summary of the customers table", or "set up a job that reads from the orders table and maintains a running total" — rather than loading a new file. It generates a SQL query (INSERT or MERGE, per `merge`) via AI instead of a Python parser, run through the query engine instead of a Glue job. There are never sample/format files, but targetOption still works the same three ways as sourceType "file" (see targetOption below) — so this call returns files: [] and you can call finish_data_source_onboarding immediately UNLESS targetOption is "target-schema-file", in which case it returns one upload URL for that file, same as the file-source path. The generated SQL automatically windows itself to rows added since the spec's last successful run. sourceType "tables" ALSO requires autoRefresh — how this spec stays up to date is not optional to decide, and must not be inferred from other jobs/triggers that happen to already exist in the workspace: ask the user whether it should re-run automatically whenever a specific upstream spec finishes loading ("spec_success" — the natural choice when the request is "run this after X finishes/loads"), on a plain cron-like cadence ("schedule" — the natural choice when the request is "run this every day/hour" with no mention of depending on another job), or stay manual-only ("none" — re-run later with run_data_job). If the request already states the timing unambiguously, that answers it; otherwise ask before calling this tool. Getting this wrong either way has a real cost: "none" means the summary silently goes stale until someone remembers to re-run it by hand, while an unwanted trigger keeps re-running (and charging credits for) a spec the user only wanted once. See autoRefresh below.

  ConnectorOAuth

• polymarket_kalshi_spreadA

  Rick And MortyA

  Cross-venue spread between Kalshi and Polymarket for the same resolving question. The two venues sometimes price the same outcome 2-25pp apart because their participant pools differ — when the bet shapes are equivalent that delta is a real signal, when they aren't the tool says so. TWO MODES: (1) `topic` — 10 pre-mapped macro shortcuts ("fed", "btc", "cpi", "gdp", "sp500", "recession", "next_pope", "next_uk_pm", "next_israel_pm", "2028_president") auto-fetch the matching event on each venue. (2) explicit `kalshi_event_ticker` + `polymarket_event_slug` for custom pairings — BOTH modes run the identical token-overlap matcher, so the same disclosures apply to both. RESPONSE: each venue's leg-by-leg prices (raw probability 0-1) plus matched spread[].top_spreads_pp (Kalshi − Polymarket) where the same outcome shows up on both sides. SAFETY FIELDS: compatibility_warning is a sentence and compatibility_codes[] the machine-readable form; BOTH can be non-empty on returned pairs, so read them even when matched_pairs>0. Codes: event_subject_mismatch (the two event titles share no subject words — probably not the same question), temporal_mismatch (they resolve in different months), temporal_alignment_unknown (the resolution month could not be parsed on one or both sides — NOT the same as confirmed-aligned; check each event's close/strike date yourself), non_equivalent_bet_shapes, no_candidate_pairs, unclassified_legs_excluded, pairing_unverified (set in EITHER mode whenever pairs are returned: the legs were matched by keyword and word overlap, not a shared resolution source). Each entry in top_spreads_pp carries its own flags[] (temporal_mismatch, temporal_alignment_unknown, event_subject_mismatch, low_token_overlap). A leg whose metric_type or match_subtype is "unknown" is NEVER paired — those comparisons land in spread.skipped_unclassified and, when the wording lined up, in spread.low_confidence_pairs[] for inspection only. temporal_alignment{polymarket_month,kalshi_month,aligned} tells you whether the two events resolve in the same calendar period, in EITHER mode; null means it could not be computed (see temporal_alignment_unknown), not that the two sides align. spread.fees_note is a standing disclosure: Kalshi charges per-contract trading fees, Polymarket does not, and this tool does not model Kalshi's fee schedule — every spread_pp is gross, not a net tradeable edge. skipped_cross_type / skipped_cross_subtype counters expose how many leg-pair comparisons were dropped (cross-type = metric_type mismatch like MoM vs YoY; cross-subtype = inequality mismatch like cum_ge vs cum_le). Real cross-venue spreads are rarer than the macro-shortcut list suggests — most pre-mapped topics return compatibility_warning today; pre-mapped ≠ tradeable.

  ConnectorNo auth

• pipeworx_trendingA

  Rick And MortyA

  What other AI agents are calling on Pipeworx right now. Returns the top tools, top packs, and total call volume over a recent window (24h, 7d, or 30d). Useful for: (1) discovering what data sources are hot for current events, (2) confirming a popular tool is the canonical choice before asking your own question, (3) seeing whether your use case aligns with what most agents need. Self-aggregating signal — derived from CF analytics-engine, no PII, just (pack, tool, count). Cached 5min-1h depending on window.

  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

• 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

• niche_session_stateA

  Niche — Editorial IntelligenceA

  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.

  ConnectorNo auth

• kirk_bulk_howtoA

  Kirk — Unsupervised Structural Change DetectionA

  Return a self-contained stdlib Python client for scoring at ZERO per-call LLM tokens. Purpose: Hand the caller an HTTP consumer that runs locally so bulk scoring doesn't burn LLM tokens per book. Use when: You need to score more than ~200 books, or `kirk_score_book_batch` returned `batch_too_large`, or the caller is running an autonomous bulk workload that would otherwise pay per-tool-call LLM tokens for every book. Do not use when: You are running a one-off interactive call — a direct `kirk_score_book` invocation is simpler; don't route through the client for a single book. Capability class(es): Cost-steering / delivery-path tool. Hands the caller a runner that exercises the same C2 / C5 / C6 capabilities as the MCP scoring tools, but at zero per-call LLM token cost. Path fit: The returned client is an HTTP consumer of the same MCP endpoint. Production integrations run in-process under sealed-engine attestation — same binary sha as this endpoint. Contact Kavara for deployment options. Cost: 0 IU. Free tool. Once running locally, the returned client bills against the same tools it drives: single-book calls at 1 IU each, and batch calls at 1 IU per 50 books (minimum 1 IU per call). A full 500-book batch → 10 IU. No LLM tokens on top. Cost comparison (2.7M-book validation rerun via 500-book batches — ~5400 batches, 54000 IU billed either way): MCP via Sonnet 5: $1,968 LLM + $540 IU + ~15 days wall clock MCP via Haiku 4.5: $656 LLM + $540 IU + ~10 days Python client (this tool): $0 LLM + $540 IU + ~55 min Return structure: { "language": "python", "filename": "kirk_online_client.py", "requirements": str, "usage": str, "code": str (the client source, ~500 LOC), "example": str (2-line copy-paste demo) }

  ConnectorNo auth

• kirk_demo_uavA

  Kirk — Unsupervised Structural Change DetectionA

  Runs a curated demonstration of Kirk on a UAV example. Zero arguments. Returns real Kirk output against the same sealed engine that customer callers hit. Free, rate-limited. First-time users: call this to see what Kirk does before signing up. Purpose: Score n=30 jittered 50-element spectra per acoustic class (drone / bird / helicopter) through the sealed engine and surface per-class score-distribution statistics plus z-separations for the three class pairs. Demonstrates that the same sealed engine sha handles market microstructure and acoustic spectra with the same primitive. Use when: You want to see Kirk's cross-domain generalization without needing your own audio dataset. Do not use when: You have real feature vectors to score — use ``kirk_infer_legacy`` directly (arg: list of 50 floats). This tool's inputs are fixed synthetic spectra baked into the demo. Capability class(es): Demonstrates domain-agnostic mathematical primitive — the same engine sha handles kirk_score_book (L2) and kirk_infer_legacy (arbitrary 50-vector). Path fit: MCP demonstration surface only. Cost: 0 IU. Rate-limited 3/hour per IP. Returns: Dict with per-class ``drone`` / ``bird`` / ``helicopter`` blocks (each: ``mean``, ``sd``, ``n``, ``kirk_version``), ``z_separation`` (dict of drone_vs_bird / drone_vs_helicopter / bird_vs_helicopter in pooled-sd units), ``representative_scores`` (the three single-sample scores from the canonical un-jittered spectra), ``interpretation_hint``, ``provenance``, and ``synthetic_spectral`` flag.

  ConnectorNo auth