Skip to main content
Glama
525,747 tools. Updated 2026-09-06 23:04

"Sky" matching MCP tools:

  • Complete the trip: from a resort, find the nearest gateway airport(s) and get flight-search links from your home airport. The "get there" leg of the funnel — pair with find_best_powder / find_powder_trips (find fresh snow) → this → book_lodging (stay). Args: resort (slug, required — use search_resorts to resolve a name), optional origin (your home-airport IATA like DEN, or a city name).
    ConnectorNo auth
  • Recommend dark-sky sites near a location, ranked by whether the drive is worth it. Use for "where should I drive to stargaze near X". Sites are grouped by drivability (how far), then ranked by a drive-worth score combining the best weather window over the next 7 nights, how much darker the site is than the user's location, and drive time. Drive times are approximate (straight-line x 1.3), not routed. Args: lat: Latitude in decimal degrees (-90..90). lon: Longitude in decimal degrees (-180..180). limit: Max sites to return, 1-12 (default 5). Returns {ranking (methodology note), tiers:[{tier, label, hint, sites:[...]}], nearest_km, uncertainty_note, attribution} — sites grouped into drivability tiers. Include the methodology note when presenting — it explains the ordering honestly.
    ConnectorNo auth
  • Get the turning points between two dates — dasha changes and slow-planet ingresses. This is the two-clocks view: the dasha sequence counted from birth (which theme is switched on) against gochara, the real sky on that date (the trigger). Use it for "what happens in the next five years", "when does this period change", "when does Saturn cross my Moon". get_dasha_periods answers when one clock changes; this answers when both point at the same thing. Every date is exact, bisected against the ephemeris to the day — not a sampled approximation. Args: chart_id: Handle returned by create_chart. The birth data is reused; the range below is independent of the chart's transit_date. start_date: YYYY-MM-DD, inclusive. end_date: YYYY-MM-DD, after start_date. systems: Dasha systems to include — vimshottari, yogini, ashtottari, chara_jaimini. Defaults to all four. Antardasha changes are reported for vimshottari only; the rest give mahadashas. types: Restrict to dasha_change, ingress and/or sade_sati. Defaults to all three. include_samples: Add a periodic strip showing the running dasha chain and Saturn/Jupiter position between the events. Off by default and capped at 13 rows, one year of months — for one date in full detail use get_transits. The event list is shorter when it is on. step: Spacing of that strip — month, quarter or year. Ignored unless include_samples is set. Returns the events, the natal anchors they are counted from, and the standing Sade Sati state at start_date. A range with more turning points than fit in one response is truncated **explicitly**, with the date to resume from — it is never silently shortened.
    ConnectorNo auth
  • Treasury float yield routing analysis for idle Mercury bank balances. Computes how much can be swept above a reserve threshold, then evaluates whether deploying into sUSDS (Sky Protocol Savings Rate) on Base is viable before a settlement deadline. THIS TOOL DOES NOT MOVE FUNDS. It returns a structured recommendation with expected net yield, deployment amount, exit timing, and step-by-step execution instructions. All fund movement decisions remain with the client. Safety rules enforced: • Always keeps thresholdUsd in Mercury — never swept • Maximum 90% of sweepable amount deployed to sUSDS • Minimum 2-hour window required (shorter windows don't cover gas) • Minimum $50,000 sweepable (below this, gas costs exceed yield) • Exit triggered 30 minutes before settlement deadline Current instrument: sUSDS (Sky Protocol) — instant on-chain entry/exit, ~6.25% APY, Base chain, no US person restrictions, no de-peg events on record. Workflow: 1. mercury.accounts → get accountId and available balance 2. mercury.sweep → get yield recommendation and execution steps 3. If PROCEED → follow execution.steps to wire funds and deploy 4. mercury.accounts again at exit time → confirm balance restored
    ConnectorNo auth
  • Semantic search INSIDE a fetched record. Pass the text you already pulled (e.g. a SEC 10-K body, an article, a long tool result) plus a natural-language query; get back the top-N passages with character offsets and similarity scores. Use when the record is too big to cram into the prompt — search_within saves context, returns only the passages that matter, and every passage carries an offset so the agent can verify a verbatim quote. Pairs with ask_pipeworx_grounded: fetch with the gateway, ground over the relevant passages instead of the whole document. BGE-base-en embeddings + cosine over 500-char overlapping windows; cap is 200K chars (longer inputs are truncated and flagged).
    ConnectorNo auth
  • "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 patents, federal contracts (USAspending), FDA-licensed biologics (Purple Book), H-1B hiring (DOL LCA), news and GLEIF, and returns: cik + company_name (+ resolved_from/resolved_to when `value` was a 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); federal_contracts (USAspending awards where the company is the recipient); fda_products (FDA-licensed biologics — vaccines, cell/gene therapies — from the Purple Book; a company with only small-molecule/generic drugs will show none here, that is expected, not a failure); hiring (H-1B sponsorship volume + salary range from DOL LCA filings); recent news mentions via GDELT→GNews fallback; LEI via GLEIF. `sources_used` / `sources_failed` say which of these actually returned data for THIS company — an empty section is a real "no data", not a bug. Pass a ticker ("AAPL"), zero-padded CIK ("0000320193"), OR a company name ("Moderna") — names now resolve via SEC EDGAR's company-name match; a private company (no CIK/ticker) returns resolved:false with an explicit `notes` line, not a bare failure. `type` accepts "company" or "ticker" interchangeably — both take the same `value` shapes above.
    ConnectorNo auth

Matching MCP Servers

Matching MCP Connectors

  • Factual sky for AIs: ISS, auroras, archives. Never confuses unexplained with extraterrestrial.

  • Observational astronomy in one place

  • 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
  • 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
  • Generate a CUSTOM t-shirt print from a text prompt (AI, takes 2-10 min). SPENDS THE ACCOUNT OWNER'S STUDIO CREDITS: tell them the cost and their balance and get a yes BEFORE calling this — never spend silently, and never spend to 'try something' on your own initiative. Credits are earned (20 free on signup, 20 with every tee bought), so a wasted one is a real loss to them. Free exception: preserve=true prints their own image as-is and costs nothing. IMPORTANT: first call studio_options and ask the human to pick placement + product (and optionally background); do NOT silently use defaults. Args: prompt (design description), product? (one of ['kids_basic_tshirt_boy', 'kids_basic_tshirt_girl', 'kids_oversize_tshirt_boy', 'kids_oversize_tshirt_girl', 'mens_basic_tshirt', 'mens_oversize_tshirt', 'womens_basic_tshirt', 'womens_oversize_tshirt']), background? (t-shirt background, one of ['washed-beige', 'washed-black', 'washed-blue', 'washed-brown', 'washed-gray', 'washed-green', 'washed-orange', 'washed-pink', 'washed-red', 'washed-yellow', 'watercolor-beige', 'watercolor-blue', 'watercolor-sky']), placement? (print size/position, one of ['portrait_extended', 'square_center', 'chest_small']), model? (nb2 default | gpt-image-2 — both 1 credit, different styles), image_url? (https link to the user's OWN image — used as style/subject reference), preserve? (true = print the user's image exactly as-is, no AI redraw — kids' drawings, own art; FREE, no credits; requires image_url). Returns print_id — poll studio_status until done.
    ConnectorNo auth
  • Treasury Float Yield Routing Analysis — OPTIONAL, CLIENT-DIRECTED ONLY. Analyzes whether idle settlement float can be productively deployed into a yield-bearing instrument between the current time and a scheduled settlement deadline. Returns a structured recommendation with expected yield, exit timing, liquidity assessment, slippage estimate, and a mandatory risk disclosure. THIS TOOL DOES NOT MOVE FUNDS. It provides analysis only. All execution decisions are made by the client or agent acting on explicit instruction. DPX charges a flat fee for this analysis and does not receive any portion of yield earned. Current supported instrument: sUSDS (Sky Protocol Savings Rate). Selected because: • Instant on-chain entry and exit (no T+1 delays) • No US person restrictions • Real asset backing (tokenized RWAs + Spark borrow rates) • Available on Base chain via bridge • No de-peg events recorded (unlike synthetic alternatives) Safety parameters enforced: • Maximum 90% of settlement amount — 10% always stays in USDC • Early exit triggered 30 minutes before settlement deadline (not 15) • Slippage guard: if DEX USDC/USDS quote shows >0.1% slippage, recommendation = HOLD • Minimum viable window: 2 hours (shorter windows do not justify entry/exit gas costs) Not recommended if: • Settlement window is < 2 hours • Amount is < $50,000 (gas costs erode yield) • Client has not acknowledged the risk_disclosure object in this response • Settlement is time-critical with zero tolerance for delay
    ConnectorNo auth
  • Generate a cohesive SET of custom images with TRANSPARENT backgrounds, each one a separate isolated subject sharing one visual style (icons, logos, sprites, UI assets that need to drop onto any backdrop). The style parameter says how everything is drawn; the subjects parameter says what to draw. The style can also come from reference images via the styleReferences parameter - alone, or best combined with the style text (text plus references holds a style tightest), so an existing set can be extended in its original style across many calls. Returns a zip download URL. Each call costs 1 credit. When a solid colored background fits the user's use case, generate_image_set (1 credit per call) is the faster choice. Run generation calls sequentially, never in parallel - only one generation runs at a time per API key. Output formats: PNG (lossless) or WebP. JPG is not supported because it has no alpha channel. Size and quality considerations match generate_image_set: leaving width and height unset delivers native resolution (best quality, varies between generations); fixing them resamples to that box, and fixing one axis lets the other hug each subject. IMPORTANT - style and subject description rules for best results: The style applies to every image in the set, so it is what keeps them visually consistent. Put HOW the images are drawn (technique, palette, surface treatment) in the style, and make each subject description only about WHAT that one subject is, not how it looks. A quick test for any phrase: is it WHAT the subject is, or HOW it is drawn? HOW belongs in the style, shared across the set. - Get the style and the subject descriptions right with the user before you call. When their request puts how an image is drawn, a background, or a scene into a subject description (or names the subjects to draw in the style rather than as separate entries in the subjects list), fix it as you compose the call: routine moves of shared technique into the style you can just make, but when a change drops or alters something they explicitly asked for, tell them what you are adjusting and why first. Each call costs a credit, so it is worth getting this right up front rather than spending one on a framed or scene-filled result. - The style describes the visual treatment of the images (e.g. 'watercolor', 'pixel art', 'stained glass'). It must NOT mention background color, image count, layout, or sizing. - Do not list the subjects to draw in the style (e.g. 'illustrations of a fox, an owl, and a deer'); the style is only the shared visual treatment, and the subjects belong in the subjects list, one per entry. A category or theme word is fine (e.g. 'insect illustration'). - Do not put background color or background descriptions in the style or subject descriptions. - Avoid framing the style as a type of painted canvas ('oil painting', 'acrylic painting', 'gouache painting', 'pastel painting'). These tend to produce each image as a rectangular framed canvas with its own colored background, rather than an isolated subject. Prefer 'illustration' or a specific technique: 'watercolor illustration', 'pen-and-ink sketch', 'ink wash', 'relief-etching', 'pastel drawing', 'woodblock print'. - Avoid color-field or atmospheric phrasings in the style ('luminous backgrounds of violet, rose, and gold', 'set against jewel-tone fields', 'dreamlike rainbow atmosphere'). These instruct the image model to fill each image with colored atmosphere, producing framed compositions rather than isolated subjects. Describe only the linework, palette, and technique of the subjects themselves. - Do not describe an aged, weathered, cracked, or textured surface, ground, wall, panel, or paper that the whole artwork sits on ('on aged wood', 'cracked fresco wall', 'aged parchment surface'); name the art tradition(s) or style(s) instead ('fresco-style illustration'). Texture that belongs to a subject's own material is fine ('a weathered bronze shield', 'a cracked ceramic vase'). - No captions, labels, or annotations. Text that is part of the depicted object is fine (e.g. 'STOP' on a stop sign, 'EXIT' on an exit sign). - No grid lines, borders, frames, or separators. - No overlapping or collage-style arrangements. - Do not connect the subjects to each other or give them shared physical elements: no wires, cords, chains, ropes, ribbons, vines, or threads running between subjects, no frame or banner they share, no phrasing like 'connected by' or 'strung together', and no single continuous line or tube forming multiple subjects. Each subject must be drawable in complete isolation; connections inside one subject (a chain on an amulet, laces on a boot) are fine. - No dramatic/long drop shadows (subtle shadows are fine). - Image descriptions should describe WHAT to depict, not where to position it. - Each image is ONE isolated subject, not a scene. Describe the subject with its pose or action and anything it directly holds, rides, or interacts with, but not the surrounding setting, environment, landscape, or sky. For a single composed scene (a figure set within an environment), use generate_illustration instead. - Do not use size words (large, tiny, small, etc.) on the overall image subject (e.g. 'a large elephant', 'a tiny mouse') - all images are produced at the same size. Size words on details within the image are fine (e.g. 'a plate with a small insignia'). - Maximum 18 images per generation. Do not put the image count in the style. - Subjects must be distinct: entries that differ only in case, punctuation, or spacing count as the same subject and the call is rejected. Explicit filenames must be distinct too (a different extension alone is not distinct). - The style must actually describe a visual style, and each subject must name a drawable subject; text that does not is rejected. - Style description max length: 500 characters. Image description max length: 200 characters each. - Size: width and height are separate parameters, each 256 to 512 pixels when given. Both given is an exact box; one given fixes that axis and the other hugs each subject (so images in the set differ on it, and it may fall below 256); neither given delivers native resolution, which is also the path to larger images. - Sizing: relative (the default) keeps the sizes the model gave the subjects in relation to one another, one scale for the whole set; fill scales each subject on its own to fill its frame less the margin, the icon-set convention, giving up relative size and enlarging subjects smaller than the frame (the result says by how much). Both can be changed later with edit_image_set. - Icons: the subject count sets how large a batch's icons can later be exported with export_icons, crisp at every density: about a 136px base size with 13 to 18 subjects, 160 with 10 to 12, 180 with 7 to 9, 192 with 5 or 6, 256 with 4 or fewer. Every generation result states its batch's own crisp base size. - If the style check returns a suggested cleanup, show the user the specific changes and get their confirmation, then resubmit the approved prompt with validation set to "skip" so it generates exactly as approved (resubmitting without "skip" re-runs the check and may return further suggestions). See the validation parameter for when to use "skip" and "auto-apply". - If a "Rate limit exceeded" error is returned, wait the suggested number of seconds before retrying. Do not retry immediately.
    ConnectorAPI key
  • Current sky positions vs natal chart for a single day. Returns all 10 planets with tropical longitudes and active aspects to natal positions using transit orbs: major 3°, sextile 2°, minor 1°. Provide start_date for a specific day; defaults to today. WORKFLOW: BEFORE: asterwise_get_western_natal — establish natal chart first. AFTER: asterwise_get_western_transits_weekly — for week view. INPUT CONTRACT: birth — WesternBirthData (date, time, lat, lon, timezone). house_system ignored for this endpoint. start_date (optional YYYY-MM-DD) — defaults to today. DO NOT CONFUSE WITH: asterwise_get_western_transits_weekly — 7 days vs 1 day. asterwise_get_western_transits_monthly — 30-day window vs single day. Full output and error contract: https://docs.asterwise.com/mcp/tools/get-western-transits-daily/
    ConnectorOAuth
  • Treasury Float Yield Routing Analysis — OPTIONAL, CLIENT-DIRECTED ONLY. Analyzes whether idle settlement float can be productively deployed into a yield-bearing instrument between the current time and a scheduled settlement deadline. Returns a structured recommendation with expected yield, exit timing, liquidity assessment, slippage estimate, and a mandatory risk disclosure. THIS TOOL DOES NOT MOVE FUNDS. It provides analysis only. All execution decisions are made by the client or agent acting on explicit instruction. DPX charges a flat fee for this analysis and does not receive any portion of yield earned. Current supported instrument: sUSDS (Sky Protocol Savings Rate). Selected because: • Instant on-chain entry and exit (no T+1 delays) • No US person restrictions • Real asset backing (tokenized RWAs + Spark borrow rates) • Available on Base chain via bridge • No de-peg events recorded (unlike synthetic alternatives) Safety parameters enforced: • Maximum 90% of settlement amount — 10% always stays in USDC • Early exit triggered 30 minutes before settlement deadline (not 15) • Slippage guard: if DEX USDC/USDS quote shows >0.1% slippage, recommendation = HOLD • Minimum viable window: 2 hours (shorter windows do not justify entry/exit gas costs) Not recommended if: • Settlement window is < 2 hours • Amount is < $50,000 (gas costs erode yield) • Client has not acknowledged the risk_disclosure object in this response • Settlement is time-critical with zero tolerance for delay
    ConnectorNo auth
  • Edits an existing image guided by a text prompt. Pass a public `imageUrl` plus a `prompt` describing the change ("add a moon to the sky", "swap the background for a neon city", "make it look like a comic panel"). Submits, polls, and returns the edited image URL(s). Default model is 'grok-imagine-i2i' (6 cr per call, returns 2 variations, ~30s, best cost-to-quality on standard edits). Other I2I-capable models: 'seedream-v4-edit', 'wan-2.5-spicy-i2i', 'flux-kontext-pro', 'qwen-image-edit', 'gpt-image-1.5-i2i' (slow, ~5min). Use list_image_models for full lineup. Note: source URLs with spaces or parentheses may fail upstream; prefer clean URLs. ## Model selection guide for edits Default: `grok-imagine-i2i` (6 cr per call, returns 2 variations = 3 cr/image effective, fast ~30s, strong general-purpose edit quality). Pick a different model when: - Need a single deterministic output, or 4K resolution -> `seedream-v4-edit` (7 cr per image, supports 1K/2K/4K, multi-image up to 6) - Subtle edits / preserve composition / character consistency -> `flux-kontext-pro` or `flux-kontext-max` - NSFW edits -> `wan-2.5-spicy-i2i` - Highest quality, time is not a concern (~5 min OK) -> `gpt-image-1.5-i2i` or `grok-imagine-quality-i2i` (16 cr @ 1K, 22 cr @ 2K) - Stylized / artistic transformation -> `midjourney-i2i` If the user simply says "edit this image" with no other signal, default to `grok-imagine-i2i`.
    ConnectorNo auth
  • List SnowSure insight categories (live conditions, current season, last season, forecast trust, patterns, SnowSure index, ground truth). Use before get_insights to choose a category filter. Lighter than raw leaderboards — retrospective and verification-backed cards.
    ConnectorNo auth
  • 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 1517 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,798 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 — a resolvable pipeworx:// record URI, present only when the source emits one that resources/read can actually serve, so a citation you get back is always fetchable. "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).
    ConnectorNo auth
  • 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).
    ConnectorNo auth
  • "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
  • "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.
    ConnectorNo auth
  • "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 / could_not_verify), the grounded or structured actual value with pipeworx:// citation, and reasoning. IMPORTANT for callers: could_not_verify means the check did not happen (our LLM or source failed) and carries verification_error{stage,detail} — it is NOT evidence for or against the claim, and must not be shown as one. unsupported means we looked and cover no source for it. Replaces 4–6 sequential calls (NL parsing → entity resolution → data lookup → comparison).
    ConnectorNo auth
  • 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.
    ConnectorNo auth