Tool search 164,478 tools · 10,067 live servers

PostgreSQL SELECT over financial / market / alt-data tables — returns structured rows. Hard rules (query fails otherwise): - SELECT only, no CTE (`WITH ... AS`) — use subqueries. - Period columns are TEXT, not dates — `period_end` is 'YYYY-MM'. Compare as strings (`period_end >= '2024-01'`); a `::date` cast on it fails. - Filter structured tables by ticker (`WHERE ticker IN ('AAPL','MSFT')`; screening: add `ticker NOT LIKE '%-%'` to drop preferred stock). Core equity coverage: US, Japan, Hong Kong, China A-shares, and Korea. Tickers are US bare (AAPL), Japan `.T` (6758.T), Hong Kong `.HK` (00700.HK), A-shares `.SH`/`.SZ` (600519.SH), and Korea `.KS`/`.KQ` (005930.KS). financial_statements, company_snapshot, and price_volume_history span all five. Specialized tables may be narrower — call get_table_schema before treating an empty result as a finding. Tables by domain (call get_table_schema for detail): - Market: price_volume_history (OHLCV history; MUST filter ticker + time_frame), index_price, equity_extended_rt (pre/after/overnight quotes) - Fundamentals: financial_statements (GAAP income/balance/cashflow), company_snapshot (ratios, per-share, growth) - Earnings: earning_call_summary, earning_call_calendar - Analyst: analyst_ratings, analyst_ratings_consensus - Ownership: insider_and_institution_activities - 8-K events: executive_change, company_deal_events, debt_issuance, securities_offering - Executives: executive_profile, executive_compensation - Alt-data: macro / industry / trade / AI-supply-chain — call list_tables(categories=[...])

Return HelloCPA Practice Management info — the standalone product at practice.hellobooks.ai for running a CPA / CA / bookkeeping practice (proposals + CPQ, workflow, time tracking, billing, 6-role RBAC, Gmail/Outlook/Calendar sync, CSV migration from TaxDome / Karbon / Canopy). NOT the Partner Program and NOT a tier in list_plans. Per-user pricing model — US shipped at $9.99/user/month (free up to 2 users + 10 clients, 90-day trial, enterprise at 50+ users). 7 other markets (IN, GB, AU, CA, AE, SG, NZ) are roadmap as of 2026-06-12. Call with no args for the full 8-region matrix + features + meta, or with `country` for one region's status + pricing + competitor frame.

Create ONE event in a human's calendar — the pilot on-behalf write, and the only one. Requires a LIVE consent grant: the human signed a scoped, expiring calendar_write grant for YOUR key fingerprint on their own device (GET /consent/signable → sign locally → POST /consent). Without it this refuses and teaches the way in. The event lands only in the calendar THEY configured (their .ics file or CalDAV); nothing is stored here, and the receipt names the grant that authorized it. Deleting the event in their calendar removes it everywhere.

Count business days between two Australian calendar dates for a specified state or territory. Boundary inclusion is explicit so agents do not have to guess the counting rule.

Calculate an Australian deadline using either calendar days or business days, with an explicit start-date counting rule and optional rolling to the next or previous business day when the calculated date is not a business day.

Normalized annual (10-K) or quarterly (10-Q) financial statements for a US company, from SEC EDGAR XBRL company facts (US-GAAP). Values are raw USD (not scaled); eps_diluted is USD per share. Not this tool for: Korean statements (get_dart_financials), a KR-vs-US pair on one screen (compare_financials_kr_us), or ranking many companies at once (screen_companies, which reads the stored table and covers KR/US/TW/JP/EU). This tool requests one US company's SEC XBRL company facts through the source adapter; results may be reused from a process-local cache for up to 24 hours. data_as_of.generated_at is response creation time, not source retrieval time. Peer comparisons use separately dated database snapshots. Args: - company (required): ticker / company name / CIK (e.g. 'AAPL', 'Microsoft', '789019') - freq: 'annual' (default, from 10-K) or 'quarterly' (discrete Q1-Q3 from 10-Qs; Q4 is not reported separately) - periods: how many most-recent periods, 1-12 (default 3) - metrics: optional subset of [revenue, gross_profit, operating_income, net_income, eps_diluted, assets, liabilities, equity, cash_and_equivalents, operating_cash_flow] (default all) - response_format: 'markdown' (default) or 'json' Returns NormalizedFinancials: {company:{name, id(CIK), ticker}, basis:'US-GAAP (10-K)', periods:[{period:'FY2024', fiscal_year, end, currency:'USD', metrics:{revenue, net_income, ...}}], notes}. periods are most-recent first; fiscal_year = calendar year of the period end date. Examples: - "Apple's revenue and net income for the last 3 years" -> {company:'AAPL', metrics:['revenue','net_income']} - "MSFT last 4 quarters" -> {company:'MSFT', freq:'quarterly', periods:4} Use when: you need US-GAAP fundamentals for a US-listed company. Don't use for: Korean companies (get_dart_financials), stock prices, or IFRS 20-F foreign private issuers (not supported). Errors: unknown company -> use search_edgar_company first; companies without us-gaap XBRL facts (funds, 20-F filers) return an error explaining why.

Screen exchange-traded funds in the local finbridge database on the things that actually distinguish an ETF: premium/discount to NAV, fund size (AUM), the index it tracks, price momentum, and — for US funds — the audited calendar-year TOTAL return from the fund's own prospectus. Funds only. Operating companies are screened by screen_companies (fundamentals) or screen_technical / the four named strategy screens (price signals). ⚠These funds are excluded from screen_companies by construction: that tool ranks on annual financial statements, which funds do not file. Coverage differs by market and the response says so per row: - KR (1,170 listed ETFs): NAV, AUM (net assets, KRW), listed units and the tracked index come from the same daily feed as prices, 2020-01-02 onward. premium_pct is close/NAV-1 computed on the SAME day (mixing dates would be meaningless). - US (5,868 ETFs): no NAV or AUM source exists that we may redistribute, so those fields are null. Instead total_return_pct carries the fund's audited calendar-year total return (distributions reinvested) from SEC prospectus data — the only distribution-inclusive number available. ⚠ret_20d / ret_120d are PRICE returns in every market: ETF distributions are not in the daily bars, so income funds look worse than they were. For US funds compare against total_return_pct to see the gap. ⚠aum is in the listing currency (KRW today). Do not rank across markets on it. ⚠total_return_pct is pinned to ONE calendar year across all rows (reported as total_return_year), because prospectus refresh dates differ per fund — ranking a 2024 figure against a 2025 one would be a silently wrong table. Args: - market: 'kr', 'us', or 'all' (default) - min_aum: minimum net assets in listing currency (KR only; e.g. 100000000000 = 1,000억) - max_abs_premium_pct: keep funds trading within this |premium| of NAV, e.g. 0.5 - min_premium_pct: keep funds at or above this premium (negative values find discounts) - min_price, min_volume: liquidity floors (vol_avg20 is the 20-session average) - index_contains: substring of the tracked index name — 'TR' finds total-return index trackers, '코스피' finds KOSPI trackers - name_contains: substring of the fund name or ticker - total_return_year: calendar year for total_return_pct; omit for the best-covered year - sort_by: aum | premium | abs_premium | ret_20d | ret_120d | ret_250d | volume | total_return (default aum); order: 'asc'|'desc' (default desc) - limit: 1-100 (default 20); response_format: 'markdown'|'json' Returns: {count, market, total_return_year, sort_by, order, rows: [{market, symbol, name, as_of, close, nav, premium_pct, aum, index_name, ret_20d, ret_120d, vol_avg20, total_return_pct, total_return_period}]} Examples: - Large KR ETFs trading close to fair value: {market:'kr', min_aum: 100000000000, max_abs_premium_pct: 0.3, sort_by:'aum'} - KR ETFs at the deepest discount to NAV: {market:'kr', sort_by:'premium', order:'asc'} - KR trackers of a total-return index: {market:'kr', index_contains:'TR', sort_by:'aum'} - US ETFs by audited total return: {market:'us', sort_by:'total_return'} Use when: choosing or comparing funds. Don't use for stocks (screen_companies) or for a single fund's price history (get_stock_prices). Errors: 'database has not been built yet' — ingest has not run; an empty result is not an error (count 0).

Get a bucket website's analytics with bucket_id, or pass publication_id from bucket_get, bucket_publish, or bucket_publication_list. Event instants are UTC; calendar boundaries use the returned account time_zone. 24h is live/hourly; 7d/30d/90d are daily. Exact inclusive windows use both from and to. The returned from/to are the effective retained window; retention_limited is true when a preset was shortened. totals.views excludes bots, totals.hits includes them, and totals.views_all_time is the durable lifetime human-view count even after detailed daily rows expire. Use totals.public_visitor_days for daily public estimates and totals.identified_visitors for protected identities. Public visitor-days are not unique people across days. measurement explains sampling, freshness, method and unavailable reasons; legacy visitors remains for compatibility. sources/referrers and manual_refs are separate overlapping reports. Downloads mean downloads started. usage contains coarse device/browser/OS and aggregate active time/scroll when available. UTMs are not collected. previous_period is null, and comparison values are null, unless the complete preceding window is retained; never treat null as zero. Free returns Basic analytics for 30 days with totals plus up to three paths and sources; paths_truncated or sources_truncated indicates more results exist. Detailed analytics uses the current plan retention. Detailed analytics activity is the newest outcome timeline; paths contains page views, downloads explicit file downloads, and document_pages document-page engagement. Static support assets are excluded.

A crew that plays together: members with levels, weekly slot, upcoming matches, calendar feed.

Club pages that clubs manage themselves: booking link and platform, courts, today's free courts when the club shares its calendar, founding status. Filter by city (phuket, singapore) or ask for one club by name.

Retrieve a one-shot compliance summary for a Norwegian organisation by its 9-digit organisasjonsnummer. Your FIRST call when orienting against a company: one round-trip composes entity_type, nace_codes, mva_registered, data_tier, the full obligations[] catalogue, and the rolling deadlines[] calendar, all from one rule version. obligations[] is byte-identical to get_company_obligations; deadlines[] matches get_company_deadlines (tier_2 adds filing_status). Only { org_number } is exposed, so call get_company_deadlines to control horizon_months. For drill-down call get_company_obligations; for identity without a verdict, use get_company_context instead. Failure modes: NOT_FOUND, SCOPE_INSUFFICIENT (needs read:brreg), UPSTREAM_TIMEOUT, VALIDATION_FAILED. No API key? Bearer apier_sandbox_test_<suffix> (fresh suffix) serves synthetic fixtures; org numbers: GET /api/v1/sandbox/fixtures. Cost: 50 øre (NOK 0.50) per call, prepaid (prices: the get_pricing tool or GET /api/v1/pricing; a shortfall returns INSUFFICIENT_CREDITS with top_up_url). Docs: https://www.apier.no/docs/guides/company-snapshot

Compute the upcoming Norwegian regulatory filing calendar for a specific organisation, looking horizon_months ahead. One entry per (obligation, period) pair: a stable obligation_id matching get_company_obligations, the due_date as ISO 8601 in Europe/Oslo (DST-aware), the legal_reference, and recurrence/adjustment flags. Choose this for the calendar view — when does the next MVA / A-melding / Årsregnskap filing land? Inputs: { org_number (9 digits, MOD-11), horizon_months? (1–60) }. Failure modes: NOT_FOUND, SCOPE_INSUFFICIENT (needs read:brreg), VALIDATION_FAILED. For the per-obligation compliance verdict, use get_company_obligations instead; for the entity-type-level calendar that needs no organisasjonsnummer (and no API key), use get_public_deadlines instead. No API key? Bearer apier_sandbox_test_<suffix> (fresh suffix) serves synthetic fixtures; org numbers: GET /api/v1/sandbox/fixtures. Cost: 50 øre (NOK 0.50) per call, prepaid (prices: the get_pricing tool or GET /api/v1/pricing; a shortfall returns INSUFFICIENT_CREDITS with top_up_url). Docs: https://www.apier.no/docs/guides/norway-corporate-tax-return-deadline

Evaluate the Apier Rulebook for a Norwegian organisation and return every applicable regulatory obligation with its current state and legal reference. One entry per obligation: a stable obligation_id (e.g. `MVA_FILING_BIMONTHLY`), the lovdata legal_reference, the state enum (`filed` / `pending` / `in_progress` / `failed` / `overdue` / `unknown`), the bokmål description inherited byte-for-byte from the Rulebook (never re-translate it), and the freshness window. Deterministic, always against the current instant (no as_of at v1). Choose this for the full obligation menu. Failure modes: NOT_FOUND, SCOPE_INSUFFICIENT (needs read:brreg), VALIDATION_FAILED. For the calendar alone, use get_company_deadlines instead; for the entity-type-level set needing no organisasjonsnummer or key, use get_public_obligations instead. No API key? Bearer apier_sandbox_test_<suffix> (fresh suffix) serves synthetic fixtures; org numbers: GET /api/v1/sandbox/fixtures. Cost: 50 øre (NOK 0.50) per call, prepaid (prices: the get_pricing tool or GET /api/v1/pricing; a shortfall returns INSUFFICIENT_CREDITS with top_up_url). Docs: https://www.apier.no/docs/guides/norwegian-company-obligations

Compute the universal Norwegian regulatory filing calendar — the deadlines that apply to every Norwegian business of the covered categories (MVA, A-melding, Årsregnskap), independent of any specific organisation. One entry per (obligation, period) pair for a single Europe/Oslo calendar year: a stable obligation_id (e.g. `MVA_FILING_BIMONTHLY`), the due_date as ISO 8601 in Europe/Oslo (DST-aware), the lovdata legal_reference, a recurring flag, and a business_day_adjusted flag. Choose this tool for questions like 'when is the next MVA filing deadline' that don't depend on a specific org_number — it requires no organisasjonsnummer. Deterministic: same input + same rulebook_version → byte-identical calendar. Input: optional `year` (integer 2020–2100; defaults to the current Oslo year). Failure modes: SCOPE_INSUFFICIENT (needs read:rulebook), VALIDATION_FAILED on year shape. For a specific company's filing calendar rather than the universal one, use get_company_deadlines instead. Docs: https://www.apier.no/docs/guides/norway-corporate-tax-return-deadline

PRIMARY single-date tool. USE for any one Gregorian date when the ask needs moon phase (incl. blue/blood/supermoon/micromoon flags, Earth-Moon distance, phase_gmt, prev/next blue or blood dates), season/equinox anchors, classical retrogrades (retrogrades_active phase=retrograde), calendars, lunar year, Cosmic card (same card as life/sun — cosmic.also_called + planetary_spread.sun), karmic source/spirit, 14 planetary Life-spread cards, weekday or leap year (calendar_meta.weekday / is_leap_year), day_ruler (weekday planetary ruler Roman/Greek/Norse), or full date identity. NOT for two-person scoring → get_compatibility; name text → get_name. RETURNS cosmic block (incl. karma + planetary_spread) + tarot_majors (greer + tarot_school) + day_ruler (full+extended) + temporal blocks (moon_phase, season, retrogrades_active, calendar_meta, …). planetary_spread and retrogrades_active planets include planet_type/symbol/emoji + names{} (greek,norse,celtic,egyptian,sumerian,babylonian,mesopotamian,arabic,sanskrit,chinese). Each planetary_spread slot carries spread_pos (1-14 canonical Life-spread order; midheaven=13, phoenix=14 — sort by spread_pos; jsonb object keys are unordered). temporal_context={band, payload_scope} (band full|extended|out_of_range; payload_scope full|cosmic_card_only). Out-of-range responses set cosmic_card_available.

USE when a player's season HR# or K# aligns with calendar day-of-month, jersey number, or inning on baseball.plays. NOT for roster cardology → get_team_chemistry; cosmic day card → get_date. Requires retro_id. mode=season (default) | spotlight (tier<=1) | career_summary (aggregates only). lane=both (default) | hr | k. Optional game_dt filter, tier_max (0-4), limit (1-500). RETURNS summary + events[] with pattern labels (day=HR#, HR#=jersey, day=K#=jersey, etc.). Overlay get_date(game_dt) for MCP day-card narrative.

Count and list business days between two inclusive ISO dates. Calendars: weekdays (Mon–Fri) or us_federal (excludes observed US federal holidays).

AI model deprecation calendar: announced and shutdown dates, replacement models, and how many days of migration notice each provider actually gives (median/min/max). Every entry is verified against the provider own deprecation page.

GDP data (gross domestic product). Source: Bundesbank. Quarterly data, price-adjusted, seasonally and calendar-adjusted (2015=100). Parameters: - start/end: YYYY-MM-DD - recent: number of most recent periods Key response fields (German names): - kettenindex: GDP chain-linked index - kettenindex_delta_1q: change vs. previous quarter - kettenindex_delta_1j: change vs. previous year

Computes all 10 Tajika Saham (sensitive points) for a Varshaphal solar return chart. Sahams are the Tajika equivalent of Arabic Parts — mathematically derived zodiac points that focus the annual horoscope on specific life themes. WORKFLOW: BEFORE: RECOMMENDED — asterwise_get_varshaphal — understand the base solar return chart (year lord, Muntha, Varsha Ascendant) before interpreting Saham lords. The Saham is meaningless without knowing which house it occupies from the Varsha Ascendant. AFTER: asterwise_get_varshaphal_harsha_bala — assess the Saham lord's positional happiness score to determine ease or difficulty of manifestation. INPUT CONTRACT: Same as asterwise_get_varshaphal — BirthData plus target_year. target_year (required int): The Gregorian calendar year of the solar return. Not age — the civil year (e.g. 2026). Feeding age instead of year silently produces the wrong return. time (required): Solar return Ascendant is time-sensitive. Accurate birth time is required for reliable Saham interpretation. DO NOT CONFUSE WITH: asterwise_get_varshaphal — returns the full base solar return chart including Muntha, year lord, and planet positions; Saham points are not included there. asterwise_get_varshaphal_harsha_bala — scores planet positional happiness; this tool computes zodiac points, not planet positions. asterwise_get_gemstone_recommendations — birthchart gemstone recommendations, unrelated to Tajika Saham. Full output and error contract: https://docs.asterwise.com/mcp/tools/get-varshaphal-saham/

Computes the eight-Yogini, 36-year Yogini Dasha cycle with two-level period trees and DD/MM/YYYY boundaries from birth data. WORKFLOW: BEFORE: RECOMMENDED — asterwise_get_natal_chart — establishes birth context for interpreting Yogini lords. AFTER: asterwise_get_dasha — optional Vimshottari comparison for the same native. INPUT CONTRACT: Tree lives at data.periods.root[] — agents must not expect a top-level data.periods array. Calendar strings in periods use DD/MM/YYYY. BirthData follows the global contract. DO NOT CONFUSE WITH: asterwise_get_dasha — Vimshottari planet periods with data.periods[] and optional levels 1–5, not Yogini names. asterwise_get_ashtottari_dasha — 108-year system with data.periods.root[] but planet-based rows, not Yoginis. Full output and error contract: https://docs.asterwise.com/mcp/tools/get-yogini-dasha/

Computes Panchanga elements for one calendar date at a geographic location and returns tithi, vara, nakshatra, yoga, karana, and end times in UTC. WORKFLOW: BEFORE: None — this tool is standalone. AFTER: asterwise_get_choghadiya — same-day slot quality for the location. INPUT CONTRACT: date must be YYYY-MM-DD (Pydantic pattern on LocationInput). lat/lon bounds are validated locally. Upstream rejects calendar dates outside 1900–2100. timezone defaults to Asia/Kolkata when the caller leaves the default in LocationInput. DO NOT CONFUSE WITH: asterwise_get_yogas — natal chart yogas, not Panchanga Sun–Moon yoga. asterwise_get_panchanga_calendar — whole-month daily rows, not a single day. Full output and error contract: https://docs.asterwise.com/mcp/tools/get-panchanga/

Returns one row per civil day for a calendar month at a location with condensed tithi, vara, nakshatra, yoga, karana, and rahu_kaal columns. WORKFLOW: BEFORE: None — this tool is standalone. AFTER: asterwise_get_panchanga — expand any single day at full detail. INPUT CONTRACT: year/month/lat/lon validated locally. Timezone handling follows upstream response fields (data.timezone echo). DO NOT CONFUSE WITH: asterwise_get_panchanga — deep single-day Panchanga with degree fields, not a month grid. asterwise_get_muhurta — activity-ranked windows, not a passive calendar. Full output and error contract: https://docs.asterwise.com/mcp/tools/get-panchanga-calendar/

Computes all major Hindu festival dates for a given year and location. Returns 20 pan-Hindu festivals including solar sankrantis (Makar Sankranti, Vaisakhi) and tithi-based festivals (Diwali, Holi, Dussehra, Janmashtami, Ganesh Chaturthi, Ram Navami, and 12 others). WORKFLOW: BEFORE: None — standalone. AFTER: asterwise_get_panchanga — drill into full Panchanga detail for any specific festival date. INPUT CONTRACT: year: integer 1900-2100. Either location (city name) OR latitude + longitude + timezone must be provided. DO NOT CONFUSE WITH: asterwise_get_panchanga_calendar — full Panchanga for every day of a month; not festival-specific. asterwise_get_muhurta — finds auspicious windows for activities; not a festival calendar. Full output and error contract: https://docs.asterwise.com/mcp/tools/get-festival-calendar/

Looks up the Personal Year theme for the current calendar cycle from a name and birth date using only month and day inputs server-side. WORKFLOW: BEFORE: RECOMMENDED — asterwise_get_numerology_profile — see other core numbers first. AFTER: None. INPUT CONTRACT: Only name and date are submitted; the active calendar year is chosen upstream automatically. DO NOT CONFUSE WITH: asterwise_get_numerology_profile — personal_year field there is null; this endpoint supplies the annual theme. asterwise_get_varshaphal — Vedic solar return, not Pythagorean Personal Year. Full output and error contract: https://docs.asterwise.com/mcp/tools/get-personal-year/

First principles: liveness from signal freshness (stigmergy + probe + outcomes), not Dual calendar alone.

Get upcoming and recent earnings releases between two dates. Optionally restrict to a list of tickers. Returns ticker, date, time (BMO/AMC), EPS estimate, and revenue estimate when available. Supports market cap filtering to focus on large-cap or small-cap earnings only.

Get scheduled macro/economic events (CPI, FOMC, jobs reports, GDP, etc.) between two dates. Optionally filter to a single country (ISO-3166 alpha-2, e.g. "US"). Defaults to US when omitted.

Get the forward-looking 10-K / 10-Q SEC filing-deadline calendar within a date window. Optionally restrict to a universe (sp500/ndx/dji/all) and/or a list of form types (default both 10-K and 10-Q).

Get stocks that moved significantly after earnings reports on a given date. Returns pre-computed price changes with earnings surprise data in a single call — no need to chain get_earnings_calendar + get_historical_prices + get_quote per ticker. Includes preEarningsClose, currentPrice, changePct, EPS/revenue actuals vs estimates, and surprise percentages. Filter by minimum absolute % change threshold.

Find companies projected to run out of cash within a date window. Similar to lockup expiration calendars but for cash depletion events. Returns companies sorted by urgency (lowest runway first). Runway is an estimate based on current burn rate — actual depletion depends on future capital raises and operational changes. Default window is today to 90 days out.

Forward-looking legislative catalyst calendar: upcoming House/Senate floor votes (bills and Senate cloture motions) filtered to items that can move tickers. Each item includes the predicted vote window (start/end/granularity/confidence/provenance), marketRelevance (low/medium/high), significance (1-5), affected sectors with direction + mechanism, verified affected tickers with evidence quotes, pass outlook, considerationProcedure (suspension-calendar bills pass ~98% of the time), a conflictBadge when the sponsor traded a verified affected ticker, and tweet/plain summaries. An EMPTY calendar is a normal state — it means nothing market-relevant is scheduled in the window, not an error. Defaults: from=today, to=+14 days, minRelevance=low. IMPORTANT: affectedTickers contains VERIFIED rows only — every ticker carries a verbatim evidenceQuote substring-verified against the actual bill text (no hallucinated tickers). sponsorTradeFacts are restatements of public STOCK Act disclosures with verbatim amount brackets and BOTH transactionDate AND disclosureDate — always cite both dates together (disclosures lag trades by up to 45 days), and never present a fact as evidence of wrongdoing. Vote windows are predictions: check window.provenance for trust level ('uc_explicit' is exact; 'rule_xxii_computed' is a medium-confidence estimate) and window.granularity for how precise the window is (exact time vs day vs week).

Compute the engine's performance metrics from a returns series. Use when the returns came from somewhere other than run_backtest (an external system, a portfolio) — backtest results already include these statistics. Args: returns: Per-bar log returns as {"dates": [...], "values": [...]} parallel arrays (ISO-8601 dates). trading_days_per_year: Required annualization factor — 252 for a daily equities calendar, 365 for 24/7 crypto. Must match the bar calendar of the returns series; a wrong value silently mis-annualizes Sharpe, volatility, and CAGR. benchmark_returns: Optional benchmark series, same shape — adds alpha/beta/capture metrics. trades: Optional trade records (entry_date, exit_date, direction, return_net, ...) — adds trade-level metrics. risk_free_rate: Annual risk-free rate as a decimal. Returns: {"stats": {...}} — the metric set the API key's plan allows. See get_catalog('sections') for every metric's id and description.

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

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.

Turn supplied SEO opportunities into a capacity-aware content calendar and execution plan.

Authenticated user's calendar events. Prefer explicit from/to (YYYY-MM-DD). Shortcuts: today|week|month|year (calendar year)|decade. Browsing noise excluded by default. ($0.10; API key required)

MUTATES the authenticated user Food Diary and calendar. Use when they ate or drank — do not store this as a chat memory. Example: “I had Mee Pok for late lunch with my parents” → log_food({ what: "Mee Pok", kind: "meal", meal_period: "late lunch", with: ["my parents"] }). Optional: place/merchant, amount, consumed_at (ISO). Resolves with/Mum/Dad via person aliases; unknown names do not fail the food write. Tags companions on the mirrored event. Rebuilds life_state. Requires API key or OAuth with scope context. Share tokens cannot write. ($0.10; API key required)

MUTATES one existing Food Diary row the authenticated user owns. Required: food_id (UUID). Optional patch (same fields as log_food): what, kind, place, merchant, notes, consumed_at / meal_period, amount, currency, paid_by, with / people_names / person_ids. Example: add hot tea onto an existing Salmon Bento → update_food({ food_id, what: "Salmon Bento + hot tea" }). Unknown or other-user food_id returns an error and does not create a row. Syncs the mirrored calendar event and rebuilds life_state. Requires API key or OAuth with scope context. Share tokens cannot write. ($0.10; API key required)

MUTATES by removing one Food Diary row the authenticated user owns and its mirrored calendar event. Required: food_id (UUID). Prefer this over delete_event for meals logged via log_food. Unknown or other-user food_id returns an error. Rebuilds life_state. Requires API key or OAuth with scope context. Share tokens cannot write. ($0.10; API key required)

MUTATES the authenticated user calendar. Use for non-food days — funeral, cremation, appointment, dinner, anything that is not a food log. Do not store this as a chat memory. Example (funeral tonight): log_event({ title: "Funeral service — Mr Goh Choo Taw", date: "2026-08-29", time: "8pm", location: "Multi Purpose Hall, Blk 661 Jurong West St 64", category: "funeral" }). Example (Sunday cremation): log_event({ title: "Cremation — Mr Goh Choo Taw", date: "2026-08-30", location: "Mandai Crematorium", category: "funeral" }). Required: title + event_date (YYYY-MM-DD; alias date). Optional: event_time (8pm or 20:00; alias time), end_date, end_time, location, description, category, external_url, people / with / person_ids, idempotency_key (recommended; retries reuse the first write). Unknown people names do not fail the write. Inserts public.events (user-scoped, private), optional event_people, then rebuilds life_state. Requires API key or OAuth with scope context. Share tokens cannot write. ($0.10; API key required)

MUTATES one existing calendar event the authenticated user owns. Required: event_id (UUID). Optional patch (same fields as log_event): title, date / event_date, time / event_time, end_date, end_time, location, description, category, external_url, people / with / person_ids. Unknown or other-user event_id returns an error and does not create a row. For food-diary meals, prefer update_food (it syncs the mirrored event). Rebuilds life_state. Requires API key or OAuth with scope context. Share tokens cannot write. ($0.10; API key required)

Return the Hebrew date of a birth, the Hebrew birthday that follows it, the three birth names of the Renaissance angel tradition and the sephirah of the birth day, from one birth moment. The Hebrew date is computed from the published calendar algorithm rather than looked up, the sunset boundary is a typed request field because it depends on where you were, and the two rival ways of dating the first name are a typed convention the response echoes. Built for Jewish culture and education apps, birth angel features and any product that wants the Hebrew birthday on the same key as the rest of its readings.

Return the day of the Omer count for a date, with the sephirah of the week, the sephirah of the day inside it, the printed Hebrew label and a composed reading. The count is a real, dated, forty nine day observance rather than an invented daily, so outside the window the response says the count is not running and gives the date it next opens. Built for daily widgets, Jewish calendar features and lifecycle emails that want a dated reading rather than a random one.

List the third-party tools embedded in the chat, such as a booking calendar or a form. Embeds needs the Standard plan or higher.

Public timestamp submissions to OpenTimestamps calendars. A submission is pending, not an independently verified Bitcoin confirmation. No key required.

Date arithmetic against a real calendar. ops: add_business_days, diff, tz_convert, is_us_federal_holiday. Holiday data is United States federal only and every response says so.

Festivals happening in a window: this weekend by default, or a calendar month. Filter by country or genre.

Next open 30-minute discovery-call slots on the Cuvo team's calendar, in the user's timezone. Call before offering any times; returns each slot's startIso and human label.

Book a real 30-minute Cuvo discovery call for the user. Requires their explicit confirmation of a specific slot from get_availability plus their real full name and email; the calendar invite goes to that email. Do not book without the user's consent.

Calculate the Kua number, also called the Ming Gua or life gua, from a birth date and sex. Returns the number, the east or west life group, the personal trigram, and all eight compass sectors classified from best to worst. The Chinese year is resolved at Li Chun by default, so an early February birthday is placed in the correct year rather than the calendar one, and the boundary that decided it is echoed back. Built for room and desk placement features, personalised feng shui reports, and any product that needs a favourable direction per person.

Return the monthly flying star plate, the faster overlay that sits on top of the annual one. Months here are SOLAR months: month 1 begins at Li Chun in early February and each month begins at the next of the twelve major solar terms, so they never line up with calendar months. Omit both parameters to get the month in progress. Built for monthly guidance features and for timing work around an affliction that only lands for part of the year.

Scheduled US macro events (FOMC + CPI + NFP + PCE) with dates and consensus. Consensus values are Mako-curated and arrive with provenance (source, source_url, published_at, age_days). An event with no curated consensus carries consensus: null, which means the value is not published rather than zero. Mode 1.2 covers the qualitative-scenario path for events whose consensus is not published. consensus_metrics_expected lists the metric keys a complete consensus would carry for that event type. Market-implied pricing (what_is_priced / CME FedWatch) is a separate quantity and remains deferred. COVERAGE: only fomc, cpi, nfp and pce have dates in this calendar. ecb, boj and boe are accepted for consistency with the consensus vocabulary but carry NO dates, so filtering to them returns an empty list and says so in staleness_flags — that is 'not tracked here', never 'none is scheduled'. Coverage also runs to a fixed last date; a window past it is flagged rather than silently short.

Mayan astrology birth chart from one date: the Tzolkin day sign and coefficient, the Haab date, the full Long Count with its day count, the Calendar Round, the Lord of the Night, the Year Bearer of the Haab year and the five point Cruz Maya, each with composed readings. Built for nawal readings, birth chart features and multi domain spiritual apps that show a Mayan card beside a natal chart. Every school split in the domain is a typed parameter and comes back echoed, so the chart can be reproduced exactly.

Maya Long Count converter that runs both ways: give it a Gregorian date and it returns the Long Count, give it a dotted Long Count and it returns the date. Every answer carries the Julian Day Number, the elapsed day count and the Calendar Round, and the correlation constant is a typed parameter so a value can be matched against any published inscription reading. Built for epigraphy tools, museum and education apps, and anything that has to place a Maya date on a civil calendar.

Mayan energy of the day: the Tzolkin day sign, its coefficient and its trecena for today or for any date you name, with a composed reading. Content is fixed for a given date and rolls over at midnight UTC, so a daily feed can cache it safely and an editorial calendar can be filled weeks ahead. Built for daily energy widgets, nawal of the day feeds and chatbot answers about what today carries.

Mayan calendar grid for a whole civil month: every day of the month with its Tzolkin day sign and coefficient, its trecena, its Haab date and its Long Count. One call fills a monthly grid that would otherwise take a request per day, and the answer is fixed for any month that has already begun. Built for calendar widgets, editorial planners and any app that shows a month of Maya dates at once.

Retrieve all twenty trecenas, the thirteen day periods the 260 day Tzolkin divides into. Each entry returns the period number, the day sign it opens on in both naming traditions, and a composed reading of what the period carries. Built for calendar apps, energy period trackers and content planners that work in thirteen day blocks rather than in weeks.

Retrieve all nineteen periods of the Haab, the 365 day Maya year: eighteen months of twenty days plus the five days of Wayebʼ. Each entry returns the machine id, both spellings of the name, the length, what the name means and a composed reading. Built for calendar reference pages and for any app that has to label a Haab date rather than only compute it.

Next earnings date for a symbol, or a rolling calendar window

Upcoming US economic release dates (FRED calendar, live-fetch)

Upcoming Indian & South-Asian festival dates for planning in the USA. With no `query`, returns the next `limit` festivals soonest-first. With a `query` (e.g. "Diwali", "when is holi"), returns the single soonest matching festival. Each item has name, date (ISO), days_until, emoji and a greeting. IMPORTANT: many Hindu/Sikh/Jain/Muslim festivals follow lunar calendars, so these dates are best-effort — always tell the user to confirm the exact date with their local temple, gurdwara, mosque or a panchang. Returns {'results': [...], 'note': ...}.