Skip to main content
Glama
205,112 tools. Last updated 2026-06-15 04:06

"Ko-fi" matching MCP tools:

  • Look up correspondent banking / settlement instructions (SSI) for a bank. Returns the correspondent banks (nostro accounts) that a given bank uses to settle payments in a specific currency, including account numbers (when available) and intermediary chains. Essential for payment routing and pre-validation. Each correspondent is annotated with a clearing_note indicating whether it can clear the currency directly (located in a home country for that currency) or needs its own correspondent. If the note suggests a further lookup, call ssi_lookup on the correspondent's SWIFT code to find the full clearing chain. IMPORTANT — known data gaps to respect: - Account numbers may be empty for some/all correspondents. The response surfaces an `account_availability_note` in those cases. Do NOT invent account numbers. Use swift_lookup() to find the bank's own published correspondent banks page when accounts are missing. - `is_preferred` is rarely populated — its absence is a DATA gap, not a signal. When `preferred_correspondent_note` is present (all flags false), do NOT infer a "preferred"/"natural" correspondent, and equally do NOT tell the user the bank "has no preference" or "rotates" — do not draw attention to the flag at all. Any listed BIC is a valid clearing route. - `intermediaries` is almost always empty in our dataset — an empty list does NOT mean the payment is direct. - `asset_category` per correspondent is COMMERCIAL (for customer MT103 credit transfers) or FINANCIAL (for bank-own-account / interbank MT202/pacs.009 settlements). The `asset_category_note` summarises the split — match the listed correspondents to the user's flow type (customer payment vs treasury/interbank). Always inspect the response's top-level `next_steps` array — it chains the swift_lookup / country_banking_rules / bank_holidays calls that complete a settlement-instruction answer. Requires an API key with an active PRO, VIP, or FI subscription. To get started: call mcp_register → mcp_verify → subscribe to a PRO/VIP/FI plan at https://ohmyfin.ai/subscription. Args: swift: SWIFT/BIC code of the bank (e.g., "DEUTDEFF", 8 or 11 chars). currency: ISO 4217 currency code (e.g., "USD", "EUR", "GBP"). api_key: Your Ohmyfin API key (prod-...). Can also be passed via KEY header or Authorization: Bearer header. Examples: ssi_lookup("DEUTDEFF", "USD") # Deutsche Bank USD correspondents ssi_lookup("HSBCHKHH", "EUR") # HSBC HK EUR correspondents ssi_lookup("DEUTDEFF", "USD", api_key="prod-abc123...")
    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
  • "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
  • CONTRACT tool. Call when the user asks which contract to choose, whether to switch provider, or how much they can save. Returns ranked contracts, switch recommendation and estimated savings. Includes current spot price — no need to call spot_price separately. Key fields: - switch_recommended (bool) - best_spot / best_fixed - action.expected_savings_local_year - decision_hint ("spot_recommended" / "fixed_recommended") Contract comparison available in: FI, SE, NO, DK, DE, GB, AU, NZ. If consumption unknown, uses zone defaults (Nordic 2000, DE 3500, GB 2700, AU 4500, NZ 8000 kWh). Set heating="electric" for heat pumps/floor heating. Tool priority: - Current price only → spot_price - Timing → cheapest_hours - Contract/switching → best_energy_contract (this tool) Args: zone: Contract comparison: FI, SE, NO, DK, DE, GB, AU-NSW/VIC/QLD/SA/TAS, NZ-NI/SI. Spot price only for all other zones. consumption: Annual electricity consumption in kWh. heating: "district" or "electric" (default: district).
    Connector
  • Create a new Avocado AI Flow pre-built with a node-graph pipeline, and return its id and direct URL so the user can open it on the canvas. You design the whole pipeline: pass the nodes and edges and the server validates socket compatibility, aligns video models to the input shape, lays the graph out left-to-right, and adds a caption per step. Edges reference nodes by 0-based index in the `nodes` array. This creates (does not run) the flow — the user runs it from the editor. Use the capability map below to choose node types, models, and handles: You are Avo, a senior creative-workflow designer inside Avocado AI's Flow editor. The user describes a creative goal; you respond with a node-graph proposal that the editor previews on the canvas. Think like a production director: design the FULL pipeline needed to get a polished result, not the minimum number of nodes. DESIGN PRINCIPLES — build capable, complete pipelines: - Match the pipeline's ambition to the request. A throwaway test is 2-3 nodes; a real deliverable (an ad, a UGC video, a product shot, a music video) is usually 5-12 nodes. Use up to 24 when it genuinely helps. - Prefer multi-stage quality: generate → refine (imageEditor) → upscale → animate, rather than a single generate node. Add an upscale step before any final image/video deliverable. - Use BRANCHING and FAN-OUT. One output can feed many nodes: e.g. one hero image → three different video models for variations the user can pick from; one script → both a voiceover and the video prompt. - Use PARALLEL TRACKS that converge: e.g. a voice track and an image track both feeding a lip-sync video; or a music track plus a visuals track. - Use the `llm` node to do creative thinking inside the graph — write or expand a script, brainstorm a prompt, turn a rough idea into a detailed image/video prompt — then wire its text output into the next node. - Pick the BEST model for each step (see the menus below). Don't leave everything on defaults — choosing models is a big part of the value. - Set per-node settings (aspect ratio, resolution, duration, voice, variations) when the request implies them (e.g. 'vertical' → 9:16, 'short' → duration 5, '3 options' → variations 3 or three branches). HARD RULES: - Use only the node types listed below. Never invent new ones. - Every edge must connect compatible socket types (text→text, image→image, audio→audio, video→video). - Give every runnable node a short `stepLabel` ('Step N — …') — it renders as a caption beneath that node. - `stickyNote` is only for standalone notes; never use it to caption a node (use `stepLabel`). Optionally add ONE stickyNote describing the workflow. - Any schema field you don't need must be `null` (numbers like `variations` too). MODEL MENUS (set the node's `model` to one of these ids): image (text-to-image) — `model` ids: • fal-ai/nano-banana-2 — fast, strong all-rounder (default) • fal-ai/gpt-image-2 — best instruction-following & legible text • fal-ai/bytedance/seedream/v5/lite/text-to-image — photoreal • fal-ai/flux-pro/v1.1-ultra — high detail / fidelity • fal-ai/nano-banana-pro — premium quality • fal-ai/recraft/v4/text-to-image — design, brand, vector-style • fal-ai/ideogram/v3 — posters & typography imageEditor (image + prompt → edited image) — `model` ids: • fal-ai/nano-banana-2/edit — default, multi-image (up to 14 inputs) • openai/gpt-image-2/edit — precise instruction edits • fal-ai/bytedance/seedream/v5/lite/edit — photoreal edits • fal-ai/flux-pro/kontext/max/text-to-image — style / context transfer • fal-ai/gemini-25-flash-image/edit — fast edits (the `image` input accepts MULTIPLE connections for compositing/restyle) imageUpscale (image → larger image) — `model` ids: • fal-ai/topaz/upscale/image — best quality (default) • fal-ai/recraft-crisp-upscale, fal-ai/clarity-upscaler, fal-ai/crystal-upscaler llm (text → text) — `model` ids: claude-haiku (default), gpt-4o-mini, kimi-k2, seed-1.8. Put the instruction in `prompt`. voice (text → speech) — pick a `voice` by name: Sarah (cheerful), Roger (deep), Laura (soft), Charlie (warm), George (bold), Callum (energetic), River (calm), Liam (reliable). The script comes from an upstream text/llm node wired into `in` — do NOT put the script in the voice node's prompt. music (text → music) — set `duration` to one of 30,60,90,120,180,240,300 (seconds). Put the music description in `prompt`. videoUpscale (video → sharper video) — add after a video node for final deliverables. No model field. VIDEO node — choose `model` to match the input shape (it drives which input handles the node renders): • Text → video: `kling3-pro`, `sora-2`, `veo3-1-fast`, `seedance-2.0-t2v`. Wire text to `prompt`. • Image → video (I2V): `veo3-1-fast`, `kling3-pro`, `seedance-2.0-i2v`, `hailuo-pro`. Wire the image to `image`. For keyframe models (`kling-o1`, `veo3-1`) wire `start-frame` + `end-frame`. • Lip-sync / talking-head: `fabric` (image + audio, NO prompt — never wire text into Fabric) or `infinitalk` (prompt + image + audio). Wire audio to `audio`. Audio-over-stills narration: `ltx2-audio`. • Multi-image reference / character consistency: `vidu` (≤7), `veo3-1-ref` (≤10), `kling-elements` (2-4 ordered frames), `happy-horse-ref` (≤9). Wire EACH image to the SAME `ref-images` handle (it accepts multiple connections). Never use the plain `image` handle. • Seedance reference (image + video + audio refs): `seedance-2.0-ref` / `seedance-2.0-ref-fast`. Wire to `ref-images` / `ref-videos` / `ref-audio`. • Motion control (drive a character with a motion video): `kling3-motion-control`. Wire character to `image`, motion clip (videoUpload) to `motion-video`. Edge handle hints: - When the target has multiple typed inputs (Video, Image Editor), set `toHandle` explicitly (`prompt`, `image`, `audio`, `ref-images`, `start-frame`, `end-frame`, `motion-video`). The editor otherwise picks the first type-compatible handle, which may be the wrong slot. - Never wire text into Fabric. Never wire a single image into a multi-ref model's `image` slot — use `ref-images`. Available node types (id — purpose — inputs / outputs): - text — Prompt — in: in<text> | out: out<text> - llm — LLM — in: in<text> | out: out<text> - upload — Upload — in: — | out: out<image> - videoUpload — Video Upload — in: — | out: out<video> - image — Image — in: in<text> | out: out<image> - imageEditor — Image Editor — in: prompt<text>, image<image> | out: out<image> - imageUpscale — Image Upscale — in: image<image> | out: out<image> - video — Video — in: prompt<text>, image<image>, start-frame<image>, end-frame<image>, ref-images<image>, ref-videos<video>, ref-audio<audio>, audio<audio>, motion-video<video> | out: out<video> - videoUpscale — Video Upscale — in: video<video> | out: out<video> - voice — Voice — in: in<text> | out: out<audio> - music — Music — in: in<text> | out: out<audio> - stickyNote — Sticky Note — in: in<annotation> | out: out<annotation> Edges reference nodes by index in the `nodes` array (0-based). In the examples below, any field not shown is `null`. EXAMPLES — study the PATTERNS (multi-stage, fan-out, parallel tracks), copy the handle names exactly: Example 1 — UGC talking-head with scripted voice + final upscale: nodes=[ {type:"llm",stepLabel:"Step 1 — Write a punchy 15s script",prompt:"Write a 15-second energetic UGC script for the product.",model:"claude-haiku"}, {type:"voice",stepLabel:"Step 2 — Voiceover",voice:"George"}, {type:"upload",stepLabel:"Step 3 — Upload character photo"}, {type:"video",stepLabel:"Step 4 — Lip-sync video",model:"fabric"}, {type:"videoUpscale",stepLabel:"Step 5 — Upscale to deliver"} ] edges=[ {fromIndex:0,toIndex:1,fromHandle:"out",toHandle:"in"}, {fromIndex:1,toIndex:3,fromHandle:"out",toHandle:"audio"}, {fromIndex:2,toIndex:3,fromHandle:"out",toHandle:"image"}, {fromIndex:3,toIndex:4,fromHandle:"out",toHandle:"video"} ] Example 2 — Text → image → refine → upscale (quality chain): nodes=[ {type:"text",stepLabel:"Step 1 — Prompt",prompt:"A cinematic product shot of a matte-black bottle on wet stone, golden hour"}, {type:"image",stepLabel:"Step 2 — Generate hero",model:"fal-ai/flux-pro/v1.1-ultra",aspectRatio:"4:3"}, {type:"imageEditor",stepLabel:"Step 3 — Add brand label",prompt:"Add a minimal embossed logo on the bottle",model:"fal-ai/nano-banana-2/edit"}, {type:"imageUpscale",stepLabel:"Step 4 — Upscale",model:"fal-ai/topaz/upscale/image"} ] edges=[ {fromIndex:0,toIndex:1,fromHandle:"out",toHandle:"in"}, {fromIndex:1,toIndex:2,fromHandle:"out",toHandle:"image"}, {fromIndex:2,toIndex:3,fromHandle:"out",toHandle:"image"} ] Example 3 — Fan-out: one image → three video variations (different models): nodes=[ {type:"upload",stepLabel:"Step 1 — Source image"}, {type:"text",stepLabel:"Step 2 — Motion brief",prompt:"Slow cinematic push-in, gentle parallax"}, {type:"video",stepLabel:"Variation A — Veo",model:"veo3-1-fast",aspectRatio:"9:16",duration:"5"}, {type:"video",stepLabel:"Variation B — Kling",model:"kling3-pro",aspectRatio:"9:16",duration:"5"}, {type:"video",stepLabel:"Variation C — Seedance",model:"seedance-2.0-i2v",aspectRatio:"9:16",duration:"5"} ] edges=[ {fromIndex:0,toIndex:2,fromHandle:"out",toHandle:"image"}, {fromIndex:0,toIndex:3,fromHandle:"out",toHandle:"image"}, {fromIndex:0,toIndex:4,fromHandle:"out",toHandle:"image"}, {fromIndex:1,toIndex:2,fromHandle:"out",toHandle:"prompt"}, {fromIndex:1,toIndex:3,fromHandle:"out",toHandle:"prompt"}, {fromIndex:1,toIndex:4,fromHandle:"out",toHandle:"prompt"} ] Example 4 — Multi-image reference video (character consistency): nodes=[ {type:"upload",stepLabel:"Ref 1 — Character front"}, {type:"upload",stepLabel:"Ref 2 — Character side"}, {type:"upload",stepLabel:"Ref 3 — Outfit detail"}, {type:"text",stepLabel:"Scene prompt",prompt:"The character walks through a neon market at night"}, {type:"video",stepLabel:"Generate with refs",model:"veo3-1-ref",aspectRatio:"16:9"} ] edges=[ {fromIndex:0,toIndex:4,fromHandle:"out",toHandle:"ref-images"}, {fromIndex:1,toIndex:4,fromHandle:"out",toHandle:"ref-images"}, {fromIndex:2,toIndex:4,fromHandle:"out",toHandle:"ref-images"}, {fromIndex:3,toIndex:4,fromHandle:"out",toHandle:"prompt"} ] Example 5 — Music video: parallel music + visuals tracks converging: nodes=[ {type:"music",stepLabel:"Track 1 — Score",prompt:"Dreamy lo-fi beat, 90 BPM",duration:"60"}, {type:"text",stepLabel:"Track 2 — Scene",prompt:"A lone astronaut drifting past a glowing planet"}, {type:"image",stepLabel:"Keyframe",model:"fal-ai/nano-banana-pro",aspectRatio:"16:9"}, {type:"video",stepLabel:"Animate",model:"ltx2-audio",aspectRatio:"16:9"} ] edges=[ {fromIndex:1,toIndex:2,fromHandle:"out",toHandle:"in"}, {fromIndex:2,toIndex:3,fromHandle:"out",toHandle:"image"}, {fromIndex:0,toIndex:3,fromHandle:"out",toHandle:"audio"} ] Return only the structured object — no prose, no markdown.
    Connector
  • 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). Describe the issue in terms of Pipeworx tools/packs — don't paste the end-user's prompt. 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.
    Connector

Matching MCP Servers

  • A
    license
    -
    quality
    C
    maintenance
    Enables querying Statistics Finland's public statistical database using PxWeb API. Supports retrieving table metadata and pulling data with PxWeb query objects.
    Last updated
    MIT

Matching MCP Connectors

  • Finnish Patent and Registration Office (PRH) — YTJ open data MCP.

  • Statistics Finland (StatFin) PxWeb MCP.

  • 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
  • Reverse SSI lookup — find banks that use a given correspondent for a currency. Given a correspondent BIC, currency, and origin country, returns the banks in that country that have a declared nostro at the correspondent for that currency. Inverse of ssi_lookup. Returns only swift + name per bank — to retrieve the account number, intermediary chain, or other SSI details for a specific bank from the result list, call ssi_lookup(bank_swift, currency) on it. Country and currency are required (not optional) — both bound the result set and the query is rejected without them. Requires an API key with an active PRO, VIP, or FI subscription. Tight per-account daily caps apply (5/day on PRO, 10/day on VIP/FI/trial). Args: correspondent_swift: BIC of the correspondent bank (e.g. "IRVTUS3N"). currency: ISO 4217 (e.g. "USD"). country: ISO 3166-1 alpha-2 of the client banks (e.g. "AE"). name_prefix: Optional prefix on bank name (e.g. "AL"). page: 1–4. Defaults to 1. api_key: Your Ohmyfin API key (prod-...). Can also be passed via KEY header or Authorization: Bearer header. Examples: banks_using_correspondent("IRVTUS3N", "USD", "AE") banks_using_correspondent("CITIUS33", "USD", "SA", name_prefix="AL")
    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
  • Retrieve a value previously saved via remember, or list all saved keys (omit the key argument). Use to look up context the agent stored earlier — the user's target ticker, an address, prior research notes — without re-deriving it from scratch. Scoped to your identifier (anonymous IP, BYO key hash, or account ID). Pair with remember to save, forget to delete.
    Connector
  • Search the Nordic financial database for company filings, press releases and macroeconomic summaries. Use this as the primary tool for any question about Nordic listed companies, markets or macro conditions. Do not use to retrieve a full document — results are chunked text excerpts; use parse_pdf_to_text for the full original document. Do not use for Swedish company registration data — use get_company_info instead. The database contains ~1 million vectors across four Nordic markets (NO/SE/DK/FI). COMPANY FILINGS Annual reports (XBRL/ESEF) and quarterly reports from ~1 500 listed companies across Oslo Børs, Nasdaq Stockholm, Nasdaq Helsinki, Nasdaq Copenhagen and First North markets. Covers 2020–present. Strong coverage for NO and SE; growing coverage for DK and FI. EXCHANGE ANNOUNCEMENTS & PRESS RELEASES Regulatory filings, exchange announcements and press releases from listed companies in NO, SE, DK and FI. Covers 2020–present. MACROECONOMIC SUMMARIES Quarterly macro summaries covering key indicators per country: Norway (NO): policy rate, FX rates, CPI, house prices, credit growth, electricity price, salmon price, GDP components Sweden (SE): policy rate, house price index, household credit Denmark (DK): policy rate, house price index, household loans, electricity price Finland (FI): house price index, household debt-to-income ratio, electricity price Use report_type='macro_summary' and country='NO'/'SE'/'DK'/'FI' to filter. Use fiscal_year and a quarter reference in your query, e.g. "Norwegian housing market Q1 2024". Args: query: What you are looking for, e.g. 'net interest margin outlook', 'salmon price Q3', 'dividend policy', 'fleet utilization', 'Norwegian housing market 2024 Q1', 'Swedish policy rate inflation 2023' ticker: Optional — filter by company ticker, e.g. 'SALM', 'EQNR', 'NDA' fiscal_year: Optional — filter by year, e.g. 2024 report_type: Optional — one of: 'annual_report' – Nordic XBRL/ESEF annual reports 'quarterly_report' – Quarterly/interim reports 'press_release' – Exchange announcements and press releases 'macro_summary' – Quarterly macroeconomic summaries sector: Optional — filter by sector: 'seafood' – seafood companies 'energy' – energy / oil & gas 'shipping' – shipping companies country: Optional — filter by country code: 'NO', 'SE', 'DK' or 'FI' limit: Number of results after reranking (default 5, max 20) Returns: List of relevant text excerpts with metadata, reranked by relevance. Each result includes rerank_score, hybrid_score, vector_score, company, ticker, country, fiscal_year, report_type, period, filing_date and the full text chunk. Returns an empty list if no relevant results are found or if the Qdrant database is temporarily unreachable.
    Connector
  • Fetch today's hourly day-ahead electricity spot prices for a Nordic bidding zone. Use this for current and near-term (today/tomorrow) price queries. Do not use for historical price analysis — use search_filings with report_type='macro_summary' and a date reference in the query for that purpose. Tomorrow's prices are published by NordPool around 13:00 CET; requests before that time will return "not yet available" for the tomorrow field. All zones return prices in EUR/kWh (NordPool day-ahead, native currency). Norwegian zones (NO1–NO5) use hvakosterstrommen.no; all other zones use ENTSO-E. Args: zone: Bidding zone code. Options: NO1 (East/Oslo), NO2 (Southwest), NO3 (Central/Trondheim), NO4 (North), NO5 (West/Bergen), SE1–SE4, DK1, DK2, FI. include_tomorrow: Set to True to also fetch tomorrow's hourly prices if already published (default False). Returns: Dict containing zone, date, current_hour_utc, current price, and a 'today' summary with min/max/avg and the full hourly list. Includes a 'tomorrow' key if include_tomorrow=True. Returns {'error': '<message>'} if price data is unavailable for the requested zone or date.
    Connector
  • Composite "should I add this npm package to my project" check in ONE call — fans out across deps.dev (license + advisories + version history) and bundlephobia (gzipped/minified bundle size, dependency count, ESM/tree-shake support). Use whenever an agent asks "is X safe / popular / small" or "what does adding lodash cost me". Returns a summary block (is_latest, license, published_at, advisory_count, bundle_kb_min, bundle_kb_gz, dependency_count, has_esm, tree_shakeable), per-advisory detail, links, and a list of recent alternative versions. NPM ecosystem only in v1; PyPI / Maven / Cargo / Go fall under deps.dev:version directly. Partial failures degrade gracefully — bundlephobia's first measurement on a new version can take 5-30s; sources_failed will list it if it times out, the rest still returns.
    Connector
  • Track a SWIFT payment by UETR or reference number. Basic SWIFT payment tracking enriched by data from certain banks in the correspondent chain. Returns the overall payment status and, when available, per-bank details showing which banks reported information about this payment. IMPORTANT — UETR vs Reference: The UETR (Unique End-to-End Transaction Reference) is a UUID assigned to every SWIFT gpi payment. Tracking by UETR succeeds ~80% of the time. Tracking by reference number alone succeeds less than 1% of the time because most banks only index by UETR. → Always provide the UETR if available. → The reference number is Field 20 of the MT103 (or the equivalent <InstrId>/<EndToEndId> in pacs.008). It is the sender's transaction reference. Still valuable — provide it alongside the UETR when you have both. WHEN THE USER HAS ONLY A REFERENCE AND NO UETR ("how do I find / trace my payment?", "I have a reference number but no UETR, where is it?"): This is exactly the scenario this tool can attempt — do NOT answer from general knowledge. A reference-based trace cannot be run from the reference alone; you MUST first collect three things from the user: 1. amount — the exact amount as sent 2. currency — ISO 4217 (e.g. "USD") 3. date — the send date (within the last 90 days) Then call track_payment(reference=..., amount=..., currency=..., date=...). State the expectation up front: reference-only tracing succeeds less than 1% of the time. In parallel, tell the user how to recover the UETR for a reliable (~80%) trace: ask the SENDING bank for the MT103 confirmation — the UETR is in Block 3, tag {121:} (a UUID v4), stored by every gpi-enabled bank against the payment. Re-run with uetr= once they have it. (swift_message_reference("MT103") returns the full field/UETR-recovery reference if you need to cite specifics.) IMPORTANT — Interpreting bank details: Each entry in the 'details' array represents a bank that reported data about this payment. The bank could be the SENDER, the BENEFICIARY, or ANY INTERMEDIARY/CORRESPONDENT in the chain. Do NOT assume a bank is an intermediary just because it appears in the list — we only know the payment passed through that bank. The bank's role is only known when it self-reports via push API (indicated by a non-null 'role' field). Requires an API key with an active FI subscription. To get started: call mcp_register → mcp_verify → subscribe to an FI plan at https://ohmyfin.ai/subscription. Args: uetr: UETR (UUID v4 format, e.g. "eb6305c8-0710-4e41-84ad-f58db3083e82"). Strongly recommended — tracking without UETR rarely returns results. This is the Unique End-to-End Transaction Reference assigned to every SWIFT gpi payment. reference: Sender's bank reference number (MT103 Field 20 / pacs.008 InstrId). Useful alongside UETR for cross-referencing, but alone it rarely produces results. Required only if uetr is not provided. amount: Transaction amount as sent (e.g. 15000.00). Must match the original payment amount — even small differences may prevent tracking from finding the payment. currency: ISO 4217 currency code (e.g. "USD", "EUR", "GBP"). date: Transaction date. Preferred format: YYYY-MM-DD (ISO 8601). Also accepted: DD.MM.YYYY or DD-MM-YYYY (European format). Must be within the last 90 days. api_key: Your Ohmyfin API key (prod-...). Can also be passed via KEY header or Authorization: Bearer header. Returns a dict with: status: Overall payment status — one of: "success" — payment delivered to beneficiary (final) "in progress" — payment is being processed (may update) "returned" — payment was canceled/returned after processing (final) "rejected" — payment was refused (final) "on hold" — temporarily held, e.g. compliance review "future" — scheduled for a future value date "unknown" — no tracking data available yet status_raw: ISO 20022 status code (ACCC/ACSP/RJCT/PDNG) or null status_reason: ISO 20022 reason code if available, or null lastupdate: Date of last status change (YYYY-MM-DD) or null details: Array of bank-level tracking entries (see role_explanation in each entry for how to interpret the bank's role) not_found_guidance: Present only when nothing was found — concrete next steps (UETR recovery, exact-match checks). Relay these to the user instead of improvising; a miss on a reference-only trace is the expected outcome and does NOT mean the payment failed. Examples: track_payment(uetr="eb6305c8-0710-4e41-84ad-f58db3083e82", amount=15000, currency="USD", date="2026-03-10") track_payment(uetr="eb6305c8-0710-4e41-84ad-f58db3083e82", reference="FT2603100123", amount=15000, currency="USD", date="2026-03-10") track_payment(reference="FT2603100123", amount=5000, currency="EUR", date="12.03.2026")
    Connector
  • Multi-language, multi-source web search that goes beyond Anglo-centric results. Supports 15 languages (fr/de/es/it/pt/nl/ja/zh/ko/ar/ru/sv/pl/tr/en) with automatic detection. Aggregates results from Mojeek (independent search engine, multilang) and Wikipedia (native multilang API), with DDG and HN as English-language complements. Returns deduplicated results ranked by cross-engine consensus. Use when you need non-English search results, when DDG fails, or for geographically-biased queries. Phase 2 #7 of the geo/lang expansion plan. Note: Brave/Bing/Searx are blocked from DO IPs — configure AICI_RESEARCH_PROXY_URL for residential proxy.
    Connector
  • Grounded multi-source research in ONE call. Decomposes your question into focused sub-questions, routes each to the right one of 3,745 tools across 884 authoritative sources IN PARALLEL, and extracts a grounded answer per facet — verbatim evidence, confidence, source, fetched_at, and a stable pipeworx:// citation on every finding, with explicit gaps[] for facets the data couldn't answer (never invented). Returns a structured findings packet you can synthesize for your user; the facts arrive pre-verified. Use for broad or multi-part questions ("compare X and Y's exposure to Z", "research the regulatory + financial + market picture for ACME"); use ask_pipeworx for single lookups — it's one LLM call instead of many. Requires a Pipeworx account (sign in via GitHub at https://pipeworx.io/signup); depth:"thorough" requires a paid plan. Expect 15-60s.
    Connector
  • 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). Describe the issue in terms of Pipeworx tools/packs — don't paste the end-user's prompt. 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.
    Connector
  • 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. 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 fires in two cases — (a) matched_pairs:0 with skipped_cross_type>0 means the venues frame the topic with non-equivalent bet shapes (e.g. Kalshi range_bucket point-in-time vs Polymarket cumulative_threshold touch-anywhere — no arb exists), (b) matched_pairs:0 with skipped_cross_type:0 and both venues >5 legs means the token-overlap matcher found nothing in common — events likely semantically unrelated despite the topic keyword. temporal_alignment{polymarket_month,kalshi_month,aligned} tells you whether the two events resolve in the same calendar period; aligned:false means spreads are mathematically meaningless across the temporal gap. 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.
    Connector
  • REQUIRES one of `event` (single-event mode) OR `topic` (cross-event mode) — call with no args fails. Find arbitrage opportunities on Polymarket via monotonicity violations + partition-sum checks. `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.
    Connector
  • Étude d'implantation labo en 1 appel (V0.23). Géocode l'adresse cible puis agrège EN PARALLÈLE 7 sections : `territoire` (densités PS commune vs national + établissements), `demande` (profil démographique du BASSIN — rayon — via profil_iris : âge, CSP, revenu pondéré), `concurrents` (labos FINESS), `pourvoyeurs` (MCO/EHPAD/SSR/dialyse — drivers écosystémiques), `prescripteurs` (médecins RPPS + IDEL Ameli), `cds` (centres de santé), `referentiels` (qualité couverture FINESS↔SIRENE). Remplace ~15 appels MCP individuels par 1. Renvoie des RÉSUMÉS (count / top-N / moyenne), JAMAIS de listes brutes. AUCUNE interprétation métier (pas de 'désert médical' ni de verdict GO/NO-GO) — le caller LLM applique sa grille. DÉGRADATION (lis `couverture` — 1 drapeau par section) : `"ok"` | `"partiel:<raison>"` | `"indisponible:<raison>"`. Si une source est down, SA section est flaggée et le RESTE est renvoyé — comble alors le trou via l'outil unitaire correspondant (etablissements_finess_in_radius, professionnels_rpps_in_radius, densite_sante, centres_sante_in_radius…). Échec d'ANCRAGE (géocodage KO / adresse douteuse / code INSEE indérivable) = rejet total (RangeError). Pièges internalisés : Paris/Lyon/Marseille basculés sur le département (`meta.plm_mode=true`) ; `prescripteurs` expose `precis_count` (PS géolocalisés à l'adresse, pas au centroïde commune) ; `cds` sans distance individuelle (centroïde commune). WORKFLOW : appelle CET outil pour DÉMARRER une étude, puis creuse les sections `partiel`/`indisponible` via les unitaires, puis `enrichir_concurrents` sur le top 3 de `concurrents.top`. Sources : IGN (géocodage), FINESS DREES, RPPS/ANS, Ameli/CNAM, INSEE/FILOSOFI, SIRENE/DINUM.
    Connector