Skip to main content
Glama
304,904 tools. Last updated 2026-07-22 02:06

"Kick" matching MCP tools:

  • 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
  • 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).
    Connector
  • 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.
    Connector
  • 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).
    Connector
  • Find tools by describing the data or task. Use when you need to browse, search, look up, or discover what tools exist for: SEC filings, financials, revenue, profit, FDA drugs, adverse events, FRED economic data, Census demographics, BLS jobs/unemployment/inflation, ATTOM real estate, ClinicalTrials, USPTO patents, weather, news, crypto, stocks. Returns the top-N most relevant tools with names, descriptions, and full input schemas (with curated examples) — each result is ready to call directly, no second schema lookup needed. Call this FIRST when you have many tools available and want to see the option set (not just one answer).
    Connector
  • "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.
    Connector

Matching MCP Servers

Matching MCP Connectors

  • "Is it true that…" / "fact check" / "verify the claim that…" / "did X really…" / "was Y actually…" / "confirm or refute" / "true or false" — natural-language claim verification against authoritative sources. Use whenever the agent needs to check whether something a user said is factually correct. Company-financial claims (revenue, net income, cash for public US companies) verify via the structured SEC EDGAR + XBRL fast path with exact percent-delta math; ANY OTHER factual claim (macro statistics, rates, prices, drug data, records) automatically falls through to the grounded pipeline — routed to the right live source, answered with verbatim evidence, then judged. Returns a verdict (confirmed / approximately_correct / refuted / inconclusive / unsupported), the grounded or structured actual value with pipeworx:// citation, and reasoning. Replaces 4–6 sequential calls (NL parsing → entity resolution → data lookup → comparison).
    Connector
  • 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).
    Connector
  • Return the caller's account_id, IU balance, USD equivalent at list, frozen flag, and recent ledger entries. Purpose: Surface the caller's current billing state — what they can spend, whether the account is frozen, and how recent entries landed. Use when: The caller wants to check available credit before committing to a large batch, or you are debugging a "why-was-I-charged" question. Do not use when: You just need per-call cost — the `_cost` envelope on every agent-driven tool result carries that inline without a separate call. Capability class(es): Meta (account state), not a capability of the scoring engine. Path fit: MCP only. Path B / C / D deployments have their own billing surface (invoiced separately). Cost: 0 IU. Callable at balance=0 so a customer with zero credit can still self-serve to top up.
    Connector
  • 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. Operator tooling lives elsewhere. Capability class(es): C5 (engine sha attested on every response). Path fit: Validation via MCP (this tool). Path B (in-process wheel) exposes the same registry via `kirk_cascade.list_models()`. Cost: 0 IU. Free tool.
    Connector
  • 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.
    Connector
  • 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).
    Connector
  • ACCOUNT REQUIRED (free — sign in via GitHub at https://pipeworx.io/signup; depth:"thorough" needs a paid plan). If you are not signed in, use ask_pipeworx instead — it works on every tier. Grounded multi-source research across Pipeworx's 1339 STRUCTURED data sources (SEC filings, FRED/BLS economics, FDA, USPTO patents, markets, science, government records, etc.) in ONE call — this is NOT open-web search. Decomposes your question into focused facets, routes each to the right one of 5,088 tools IN PARALLEL, and returns a findings packet: verbatim evidence + confidence + source + fetched_at + a stable pipeworx:// citation per finding, with explicit gaps[] for facets the data couldn't answer (never invented). Best for broad/multi-part questions over structured data ("compare X and Y's regulatory + financial exposure", "research the filings + market picture for ACME"). For a single lookup use ask_pipeworx (one LLM call, not many). For BREAKING or colloquial CURRENT-NEWS / "what's the world saying about X" topics, prefer ask_pipeworx — it routes to live news APIs and the *-news-feeds packs; deep_research returns mostly empty gaps[] when the topic isn't in the structured catalog. Second-hop iteration: depth:"standard" re-angles unanswered gaps (gap recovery); depth:"thorough" additionally chases the best leads from the first pass — so multi-step questions resolve in one call. Every finding carries a `hop` field and a citation_uri (record-level pipeworx:// when the source emits one, else source-level). "standard" and "thorough" also return contradictions[] flagging findings that disagree. Large records are semantically excerpted to the passages relevant to each facet (not head-truncated), so answers deep in a long filing/series aren't missed. Expect 15-60s (thorough with its follow-up + contradiction pass: up to ~90s).
    Connector
  • "Tell me about X" / "research Acme" / "brief me on Tesla" / "what does Apple do" / "company profile for Microsoft" / "give me the rundown on NVDA" / "everything you know about $TICKER" — full cross-source profile of a US public company in ONE parallel call. ALWAYS PREFER over chaining single-pack SEC/XBRL/news lookups when the user asks for a holistic view. Fans out across SEC EDGAR, XBRL, USPTO, news, GLEIF and returns: cik + company_name; recent_filings (up to 5 with pipeworx://edgar/company/{cik}/filings/{accession} URIs); fundamentals (LATEST 10-K Revenues + NetIncomeLoss + Cash, sorted period_end DESC); patents (USPTO PatentsView API sunset May 2025 — soft-fails until reactivated); recent news mentions via GDELT→GNews fallback; LEI via GLEIF. Pass ticker "AAPL" or zero-padded CIK "0000320193" — names not supported (use resolve_entity first if you only have a name).
    Connector
  • "What's new with X" / "latest on Y" / "what happened to Z this week / month / quarter" / "updates on Acme" / "news on Tesla recently" / "what's happening with Apple" — change feed for a company in the last N days/weeks/months in ONE parallel call. Fans out to SEC EDGAR (filings since `since`), GDELT→GNews fallback (news mentions in window — GDELT preferred, GNews when rate-limited or 5xx), USPTO (patents granted; PatentsView API sunset May 2025 so this soft-fails until reactivated). `since` accepts ISO date ("2026-04-01") or relative shorthand ("7d", "30d", "3m", "1y"). Returns structured changes[] grouped by source + total_changes count + pipeworx:// citation URIs. Use entity_profile instead when you want the static profile (filings + fundamentals + LEI + patents) regardless of window.
    Connector
  • Get the REAL current date and time. Call this at the start of a reply and before using any relative time words (yesterday, tomorrow, tonight, next week). Never guess time from context. NEVER write a clock time in your reply that did not come from this tool's output in THIS turn — a timestamp without a fresh call is a hallucination, even if it plausibly continues from an earlier one. ALWAYS pass the user's IANA timezone — this server is remote, so without it you get UTC, not the user's local time.
    Connector
  • Return a self-contained stdlib Python client for scoring at ZERO per-call LLM tokens. Purpose: Hand the caller a Path-A 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 a Path A HTTP consumer of the same MCP endpoint. For sub-millisecond in-process scoring, move to Path B (wheel), Path C (OpenShift Operator), or Path D (Nitro Enclave AMI). Cost: 0 IU. Free tool. The returned client, once running locally, pays 1 IU per scored book (same rate as `kirk_score_book`) with no LLM tokens on top. Cost comparison (2,700,000-book Test-1 rerun): MCP via Sonnet 5: $1,968 + ~15 days wall clock MCP via Haiku 4.5: $656 + ~10 days Python client (this tool): $0.00 + ~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) }
    Connector
  • Ping the sealed backend, confirm engine identity, return the sha256 of the running scoring binary. Purpose: Verify which Kirk build is currently serving scoring calls. Response carries the sealed engine sha (kirk_version) that will stamp any subsequent kirk_score_* result. Use when: You want to record engine sha in your own provenance log before capturing scoring output, or you want a cheap liveness probe ahead of a larger validation batch. Do not use when: You want a scoring result — this returns identity/liveness only, no entropies. Capability class(es): C5 (cryptographic attestation of engine identity). Path fit: Validation via MCP (this tool). Production integrations verify identity via wheel sha (Path B), OpenShift KBS quote (Path C), or Nitro Enclave PCR0 measurement (Path D) — all four paths ship the same sealed binary sha. Cost: 0 IU. Free tool. For agent-driven callers, the _cost envelope still reports iu_this_call=0 and the running session totals. Returns: Dict with `status`, `engine`, `env`, and `kirk_version` (the sealed .so sha). A non-2xx response raises; caller sees a clean MCP tool error.
    Connector
  • Score up to 500 L2 order-book snapshots in one MCP call — returns an entropies list plus engine attestation. Purpose: Batch-score up to 500 snapshots through the sealed engine in a single MCP dispatch. Use when: You are validating batch behaviour, comparing entropy distributions across small book sets, or running interactive experiments up to 500 books at a time. Do not use when: You have more than 500 books, or you are looping this tool from an LLM. Batches >500 raise a structured `batch_too_large` before any ledger debit. For sustained bulk work, call kirk_bulk_howto — the stdlib Python client scores at zero LLM tokens per iteration. Capability class(es): - C2 (variable-universe cross-section entropy — heterogeneous batch shapes are handled by one model without retraining). - C5 (sealed engine sha stamped on every response). - C6 (bit-exact reproducibility across substrates and runs). Path fit: Validation via MCP (this tool). Production bulk workloads live in-process on Path B (wheel), Path C (OpenShift Operator), or Path D (Nitro Enclave AMI); the MCP round-trip is inappropriate for high-throughput consumption. Cost: 1 IU per call regardless of batch size (Gate 3 flat rating; per-batch scaling ships with Gate 6). LLM-agent-scoped cap at 500 books; use kirk_bulk_howto for anything larger.
    Connector
  • Score one day of the Jarett Test-1 QQQ L2 corpus at a caller-supplied override via the desk-01 research daemon. Purpose: Reproduce or extend a specific research configuration on the published Test-1 corpus. Unlike `kirk_score_book*` (sealed backend, fixed model configuration), this tool routes to a local research daemon that accepts caller-supplied model overrides for Milestone-D-Phase-B autoresearch. Use when: You are doing research on the Test-1 corpus or reproducing a specific published sweep configuration. Do not use when: You want an actual product signal — this is a research surface, not a customer capability. Sealed-engine scoring on your own data goes through kirk_score_book / kirk_score_book_batch instead. Also do not use if the caller is external — this tool targets the desk-01 daemon and is scoped for research reproduction. Capability class(es): None on the customer-advertised C1-C6 axis. Internal research surface; the daemon exercises the same engine binary (so C5 attestation still applies) but override behaviour is out of scope for the customer capability map. Path fit: Path A research daemon on desk-01. Not a Path B / C / D surface — there is no in-process wheel exposure of this endpoint. Cost: 1 IU per call. The scoring binary is byte-identical to the sealed multi-cloud sha, so engine identity is attested on every response regardless of the caller's overrides.
    Connector