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

Answers "who has filed this quarter's results, who hasn't, and what came in since last time?" — filed / not-yet lists against the statutory deadline, plus a diff of filings new since the previous publish. Built for stateless agents: polling this replaces a webhook. | "누가 냈고 누가 아직인가 · 지난번 이후 새로 뜬 건 뭔가"에 답합니다. 법정 마감 D-day 와 직전 발행 대비 신규 목록까지. 상태를 못 들고 다니는 에이전트를 위한 도구입니다.

Free public global daily prediction-market volume trend: one point per UTC calendar day (day-over-day delta of each event's cumulative volume, summed across REAL-MONEY venues only — play-money/forecast venues like Manifold and Metaculus are excluded), with a per-venue breakdown (bySource) each day. Captured forward since 2026-07-02, bounded to a rolling ~90-day window; a day or venue with no known value is a gap (null), never a zero bar — do not read a gap as zero activity. Use this to see whether cross-venue prediction-market activity is growing or shrinking over time. No API key required.

"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 — BOTH modes run the identical token-overlap matcher, so the same disclosures apply to both. RESPONSE: each venue's leg-by-leg prices (raw probability 0-1) plus matched spread[].top_spreads_pp (Kalshi − Polymarket) where the same outcome shows up on both sides. SAFETY FIELDS: compatibility_warning is a sentence and compatibility_codes[] the machine-readable form; BOTH can be non-empty on returned pairs, so read them even when matched_pairs>0. Codes: event_subject_mismatch (the two event titles share no subject words — probably not the same question), temporal_mismatch (they resolve in different months), temporal_alignment_unknown (the resolution month could not be parsed on one or both sides — NOT the same as confirmed-aligned; check each event's close/strike date yourself), non_equivalent_bet_shapes, no_candidate_pairs, unclassified_legs_excluded, pairing_unverified (set in EITHER mode whenever pairs are returned: the legs were matched by keyword and word overlap, not a shared resolution source). Each entry in top_spreads_pp carries its own flags[] (temporal_mismatch, temporal_alignment_unknown, event_subject_mismatch, low_token_overlap). A leg whose metric_type or match_subtype is "unknown" is NEVER paired — those comparisons land in spread.skipped_unclassified and, when the wording lined up, in spread.low_confidence_pairs[] for inspection only. temporal_alignment{polymarket_month,kalshi_month,aligned} tells you whether the two events resolve in the same calendar period, in EITHER mode; null means it could not be computed (see temporal_alignment_unknown), not that the two sides align. spread.fees_note is a standing disclosure: Kalshi charges per-contract trading fees, Polymarket does not, and this tool does not model Kalshi's fee schedule — every spread_pp is gross, not a net tradeable edge. skipped_cross_type / skipped_cross_subtype counters expose how many leg-pair comparisons were dropped (cross-type = metric_type mismatch like MoM vs YoY; cross-subtype = inequality mismatch like cum_ge vs cum_le). Real cross-venue spreads are rarer than the macro-shortcut list suggests — most pre-mapped topics return compatibility_warning today; pre-mapped ≠ tradeable.

"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 — BOTH modes run the identical token-overlap matcher, so the same disclosures apply to both. RESPONSE: each venue's leg-by-leg prices (raw probability 0-1) plus matched spread[].top_spreads_pp (Kalshi − Polymarket) where the same outcome shows up on both sides. SAFETY FIELDS: compatibility_warning is a sentence and compatibility_codes[] the machine-readable form; BOTH can be non-empty on returned pairs, so read them even when matched_pairs>0. Codes: event_subject_mismatch (the two event titles share no subject words — probably not the same question), temporal_mismatch (they resolve in different months), temporal_alignment_unknown (the resolution month could not be parsed on one or both sides — NOT the same as confirmed-aligned; check each event's close/strike date yourself), non_equivalent_bet_shapes, no_candidate_pairs, unclassified_legs_excluded, pairing_unverified (set in EITHER mode whenever pairs are returned: the legs were matched by keyword and word overlap, not a shared resolution source). Each entry in top_spreads_pp carries its own flags[] (temporal_mismatch, temporal_alignment_unknown, event_subject_mismatch, low_token_overlap). A leg whose metric_type or match_subtype is "unknown" is NEVER paired — those comparisons land in spread.skipped_unclassified and, when the wording lined up, in spread.low_confidence_pairs[] for inspection only. temporal_alignment{polymarket_month,kalshi_month,aligned} tells you whether the two events resolve in the same calendar period, in EITHER mode; null means it could not be computed (see temporal_alignment_unknown), not that the two sides align. spread.fees_note is a standing disclosure: Kalshi charges per-contract trading fees, Polymarket does not, and this tool does not model Kalshi's fee schedule — every spread_pp is gross, not a net tradeable edge. skipped_cross_type / skipped_cross_subtype counters expose how many leg-pair comparisons were dropped (cross-type = metric_type mismatch like MoM vs YoY; cross-subtype = inequality mismatch like cum_ge vs cum_le). Real cross-venue spreads are rarer than the macro-shortcut list suggests — most pre-mapped topics return compatibility_warning today; pre-mapped ≠ tradeable.

Use when a user asks for drawdowns, weak periods, best-versus-worst results, or whether a headline hides an unfavorable distribution. Returns detailed cuts of the current-rule historical replay: per calendar year, per theme, return distribution buckets, holding periods, the ten best and ten worst closed trades, the open book, and closed+open combined on identical buckets. Use `section` to pull one cut instead of all of them. Signal data, not investment advice.

Use when a user asks for stricter time-ordered evidence, weak years, benchmark underperformance, or a check against look-ahead. Returns the committed cache-frozen annual walk-forward artifact. Each year's candidate is selected using only earlier observations and then traded for the next calendar year with next-open execution and costs. Returns the content-derived evidence id, input hash manifest, aggregate results, and paged per-symbol/year rows. Weak periods and underperformance versus buy-and-hold are retained. Set artifact to 'pooled_selection' for the class-pooled selection audit (per-name and pooled rule selection both converge to the untuned class engine) or 'model_portfolio' for the monthly walk-forward of the shipped model-portfolio construction (12-1 momentum top 10/20 among engine-long quality stocks, every risk profile, benchmarks, monthly picks, broad-universe check). Historical validation, not live performance or advice.

For one live listing, find the closest calendar-confirmed stays with the same length when preferred dates do not work. Results are not priced; call get_quote for the final total.

Trip-condition board for tracked tourist spots (SF Bay Area, Napa, Monterey/Big Sur): one verdict per spot with per-factor readings. Factors per spot (only the ones that matter for that place): visibility (vision-model webcam reading), heat and cold (NWS hourly — outdoor-seating and heatwave-cancellation bands, freeze flag), wind (nearest NDBC buoy or forecast — the Big Sur sun-and-wind balance), smoke (EPA AirNow AQI — wildfire haze), alerts (NWS CAP + advisories), strikes (BART/511), road (Caltrans closures incl. SR-1/Big Sur). Pass spot_id (e.g. "golden-gate", "napa", "big-sur") for one spot plus its `week`: a 7-day forecast outlook per local calendar day (hi/lo °F, conditions, flags like "extreme heat"/"freezing"/"windy") for picking a visit day. Week rows are forecast-only; visibility/smoke/alerts are live signals and appear in `factors`. Statuses are good|caution|bad|unknown; the spot verdict is the worst non-unknown factor, and `flagged` names which factor(s) drove it. "unknown" means that feed is not reporting fresh data — an empty or stale feed shows unknown, never all-clear. Some cameras are labeled proxies in `note` (e.g. Alamo Square has no public camera facing the Painted Ladies). Thresholds documented in gateway/spots.py.

Reserve a slot and get a payment link. This is the only way to buy — there is no checkout on the website. The slot is held for 30 minutes. Confirm the exact time and the price with the buyer before calling this, and use their real email address: the calendar invitation and receipt go there. You must call list_products first, put the session options to the buyer in your own reply, and wait for them to choose. This tool needs the catalogue_token from that call and buyer_confirmed_session: true, which you may only set once the buyer has actually answered. Choosing a session on their behalf from what they said earlier is not the same as asking, and is not acceptable here. Before calling, ask the buyer what they want to discuss and what they are hoping to get out of the call, and pass their answers as topic and desired_outcome. Fifteen minutes is short; the seller uses these to prepare, and a booking that arrives blank wastes some of the time the buyer paid for.

Buy a certificate. Certificates are objects, not appointments: there is no slot, no calendar entry and no meeting. One is issued the moment payment settles, emailed as a PDF, and registered against a hash anyone can verify. Use this instead of create_order, which is only for booking time. As with sessions, show the buyer what is on offer and let them choose rather than deciding for them.

Bitcoin and Ethereum trend signal: the long-only state for each sleeve (LONG or CASH), the 50-day trend gate each trades on, and the BTC 200-day master gate that overrides both — evaluated on UTC daily closes, with price and day change. A rules-based risk-on/risk-off verdict for crypto, not raw price data. Free tier: exactly one completed UTC close behind — evaluated every calendar day, weekends included, and stamped with the close it used (signal_close_date). Live sibling on the newest close (x402, pay-per-call): get_crypto_trend_live.

get_crypto_trend on the newest completed UTC daily close — evaluated every calendar day including weekends, stamped with the close it used. The free tool is one close behind. No wallet? get_crypto_trend is free. $0.005 USDC per call (x402).

Fetch the bundled critical skill pack (regime + risk_calendar + health). Call this on every boot before any trading decisions. Returns the current market regime, known risk events in the next 14 days, and a market health score — three synthesised verdicts that every strategy depends on.

Fetch a specific Agentberg skill pack by name. Critical skills (regime, risk_calendar, health) are automatically bundled in get_skills. Optional skills: 'rotation' for sector money-flow analysis, 'narrative' for macro headline synthesis.

Call cc.economic_calendar — Upcoming high-impact macroeconomic events (CPI, FOMC, NFP, etc.) with forecast vs previous values. 60-min cache. Purpose: Upcoming high-impact macroeconomic events (CPI, FOMC, NFP, etc.) with forecast vs previous values. 60-min cache. Behavior: READ-ONLY. Does not place orders, move funds, or mutate your exchange account. Responses may be cached (~3600s). Auth: X-Api-Key or x402 payment proof (X-PAYMENT / __x_payment). Anonymous unauthenticated calls receive HTTP 402 with payment accepts. Cost: $0.001 USDC per successful call (x402 Base USDC pay-per-use or prepaid X-Api-Key balance). Linked Connect keys are free. This is billing, not a side effect. Rate limit: 60/min (per API key). Tier: standard. Returns: Array of events with dates, countries, impact level, forecast/actual/previous values. Guidelines: Use for research / signal context. Pair with cc.agent_strategy (paper) before any live order. Do not invent fills from this data alone. Tags: macro, calendar, fomc, cpi, nfp, economic.

"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 — BOTH modes run the identical token-overlap matcher, so the same disclosures apply to both. RESPONSE: each venue's leg-by-leg prices (raw probability 0-1) plus matched spread[].top_spreads_pp (Kalshi − Polymarket) where the same outcome shows up on both sides. SAFETY FIELDS: compatibility_warning is a sentence and compatibility_codes[] the machine-readable form; BOTH can be non-empty on returned pairs, so read them even when matched_pairs>0. Codes: event_subject_mismatch (the two event titles share no subject words — probably not the same question), temporal_mismatch (they resolve in different months), temporal_alignment_unknown (the resolution month could not be parsed on one or both sides — NOT the same as confirmed-aligned; check each event's close/strike date yourself), non_equivalent_bet_shapes, no_candidate_pairs, unclassified_legs_excluded, pairing_unverified (set in EITHER mode whenever pairs are returned: the legs were matched by keyword and word overlap, not a shared resolution source). Each entry in top_spreads_pp carries its own flags[] (temporal_mismatch, temporal_alignment_unknown, event_subject_mismatch, low_token_overlap). A leg whose metric_type or match_subtype is "unknown" is NEVER paired — those comparisons land in spread.skipped_unclassified and, when the wording lined up, in spread.low_confidence_pairs[] for inspection only. temporal_alignment{polymarket_month,kalshi_month,aligned} tells you whether the two events resolve in the same calendar period, in EITHER mode; null means it could not be computed (see temporal_alignment_unknown), not that the two sides align. spread.fees_note is a standing disclosure: Kalshi charges per-contract trading fees, Polymarket does not, and this tool does not model Kalshi's fee schedule — every spread_pp is gross, not a net tradeable edge. skipped_cross_type / skipped_cross_subtype counters expose how many leg-pair comparisons were dropped (cross-type = metric_type mismatch like MoM vs YoY; cross-subtype = inequality mismatch like cum_ge vs cum_le). Real cross-venue spreads are rarer than the macro-shortcut list suggests — most pre-mapped topics return compatibility_warning today; pre-mapped ≠ tradeable.

Get realized FX volatility for a currency pair, and size the FX risk on an exposure held to a future date. Computes 30-day and 90-day annualized volatility from historical ECB reference rates (standard deviation of daily log returns, annualized by sqrt(252)). Returns a qualitative bucket: LOW (<5%), MEDIUM (5-15%), HIGH (15-25%), VERY_HIGH (>25%), PEGGED (currency peg — near-zero volatility, e.g., USD/AED, USD/HKD). Also returns practical daily/weekly movement estimates and a settlement_risk_note explaining what the volatility means over a typical T+2 settlement period — use these to advise users on FX risk for their specific payment. PASS horizon_days WHENEVER THE USER'S EXPOSURE RUNS PAST SETTLEMENT. It returns a `horizon` block: the volatility scaled to that horizon as an actual rate band at 1 and 2 sigma, which end of the band hurts a payer versus a receiver, and what the band does and does not tell them about hedging. Use it for questions shaped like: - "should I hedge / lock in / take a forward for <future period>?" - "how far could <pair> move by <date>?" - "what rate should I budget for next year?" - "I have invoices in <currency> through 2027 — what is my risk?" - any exposure not settling within a few days. Count the calendar days from today to the date the exposure ends and pass that. Rough is fine — the band moves with the square root of time, so a month either way barely changes it. Read `sample_depth` before quoting any figure: this is REALISED volatility from a short history, not implied volatility, and the sample may be shorter than the horizon asked about (`horizon.beyond_sample`). Say so. IMPORTANT — the band is the range of FUTURE SPOT. It is not a rate anyone can transact at, and the width of the band is NOT the cost of a hedge. A forward is priced off the interest-rate differential between the two currencies, which we do not hold and must not guess or recall from memory. Relay `horizon.hedge_cost_note` rather than inventing forward points, a carry figure, or a "typical" hedging cost. Never state a forward rate. Args: base: Base currency (ISO 4217, e.g., "EUR") target: Target currency (ISO 4217, e.g., "TRY") horizon_days: Optional. Calendar days from today to the end of the exposure (1-1825). Omit for spot/settlement risk only. Examples: fx_volatility("EUR", "USD") fx_volatility("USD", "TRY") fx_volatility("GBP", "JPY", 506) # exposure running to end-2027 fx_volatility("EUR", "PLN", 90) # invoice settling in a quarter

Calculate the value/settlement date for a payment. Determines when a payment will settle based on: - Source and destination country holiday calendars - Weekend conventions (Sat/Sun or Fri/Sat) - Currency center holidays (if FX conversion involved) - Settlement convention (T+0, T+1, T+2) Args: source_country: Sender's country (ISO 3166-1 alpha-2, e.g., "US") dest_country: Receiver's country (ISO 3166-1 alpha-2, e.g., "DE") settlement_type: One of "wire" (T+0 domestic / T+1 international), "fx_spot" (T+1 or T+2 based on pair), "sepa" (D+1), "sepa_instant" (T+0) base_currency: Base currency for FX (ISO 4217, e.g., "USD"). Required when settlement_type is "fx_spot". target_currency: Target currency for FX (ISO 4217, e.g., "EUR"). Required when settlement_type is "fx_spot". from_date: Start date in ISO format (YYYY-MM-DD). Default: today. You do not know today's date — omit this argument unless the user named a specific send date. If the user's date is relative ("the 20th", "next Friday", "month-end"), read the `today` block in any response from this tool, bank_holidays or is_business_day_check and resolve against that. Examples: value_date("US", "DE") value_date("US", "DE", "fx_spot", "USD", "EUR") value_date("DE", "FR", "sepa") value_date("US", "US", "wire", from_date="2026-07-03")

BETA. Estimate when a SWIFT payment will arrive: a corpus-grounded arrival window with an honest tail, computed from real completed payments we have tracked, projected onto the currency's banking calendar. This estimator is in BETA and still calibrating. Say so when you present a number: call it an estimate or a typical window, never a commitment, and never let a user plan an irreversible decision (a cutoff, a contractual settlement date) on it without that caveat. The payload carries beta=true while this holds. Two modes: - Forward (default): "when will it land" — returns P50/P90/P95 arrival dates, sample size, confidence, competing non-arrival risk, delay-risk factors, and (where validated) the most likely correspondent route. - Reverse: pass arrive_by_date (YYYY-MM-DD) — returns the latest send date such that arrival by that day is likely ("send by Thursday to land by month-end"). INPUT DISCIPLINE (important): - Mid-flight payment: pass ONLY the uetr (from TrackingContext or track_payment). The server resolves the current status, currency and elapsed time deterministically from the tracking record. NEVER compute elapsed_business_days yourself. - Pre-trade question ("how long will a USD wire from X to Y take?"): pass currency + sender_bic/receiver_bic (8 or 11 chars, or bank names). current_status / elapsed_business_days are for this path only. Reading the answer honestly (relay these to the user): - basis.n is the sample size and confidence reflects it; when confidence is "low", present the window as a rough range, never a promise. - route.confirmed=false means the route is INFERRED from settlement instructions on file, not confirmed by GPI — say so. - basis.route_adjusted=true means we hold no completed payments for this exact pair and the window was lifted to a route-composed estimate: the SSI-implied correspondent chain (route.intermediaries hops) with typical processing time per hop. Present it as a route-based estimate, not as observed statistics, and never quote the faster currency-pool average alongside it as if corridor-specific. - mode="outlier" means the payment is already slower than ~90% of similar payments: stop quoting a window, explain the usual manual causes (compliance review, repair/RFI, missing cover) and pivot to the stuck-payment diagnostic flow. - non_arrival.p_reject is the share of similar payments that were returned or rejected rather than delivered. - "Delivered" (ACCC) means delivered to the beneficiary bank per GPI; funds can become usable in the account slightly later. Available on every surface to any caller with an active subscription. The estimate itself costs no credits (tracking a payment does cost credits; never describe tracking as free). Args: uetr: UETR of a tracked payment (preferred for mid-flight questions) currency: 3-letter currency (pre-trade path; ignored when uetr resolves) sender_bic: Sender bank BIC or name (pre-trade path) receiver_bic: Receiver bank BIC or name (pre-trade path) intermediary_bic: Known intermediary BIC (optional) current_status: GPI status like ACSP (pre-trade/no-uetr path only) elapsed_business_days: Business days already in flight (pre-trade path only) amount: Payment amount (improves delay-risk assessment). A plain number is fine — 50000 and "50,000.00" are both accepted. sender_country: ISO2 country of the sender bank (optional) receiver_country: ISO2 country of the receiver bank (optional) arrive_by_date: YYYY-MM-DD — switches to reverse send-by mode. You do not know today's date; a deadline stated as "the 20th" or "by month-end" must be resolved against the `today` block returned by bank_holidays / value_date / is_business_day_check, not against your own sense of the current date. A date in the past is rejected. api_key: Optional API key (internal calls ride the MCP secret)

Sort corporate dates into what is still ahead and what has already passed. ★ TWO DATES, NOT ONE. What is "upcoming" is decided by the date the event HAPPENS; `as_of` filters on the date it was ANNOUNCED. An ex-dividend declared on 2026-08-01 for 2026-09-15 is both already known and still ahead on 2026-08-10. Collapsing the two fields either hides every future date or reports last month's ex-dividend as though it were coming. ★ ELAPSED DATES ARE SEPARATED, NOT DISCARDED. They come back under `past` — the previous ex-dividend is useful context for a question about the next one — but they can never appear under `upcoming`. ★ NOT `search_filings` AND NOT `query_dataset`. Those retrieve disclosures and rows; this one only arranges dated corporate events on a timeline relative to now. ⚠️ A scheduled date is a schedule, not a promise; companies move them. Args: rows (dated events), today (YYYY-MM-DD), optional as_of.

Календарь отчётностей и корпоративных событий рынка (МСФО/РСБУ, советы директоров, собрания акционеров) на ближайшие месяцы. Возвращает события по дням с тикерами. Бесплатно. Не возвращает дивидендные прогнозы — для них investmint_dividends с тарифом ИИ.

Use this tool when a taxpayer wants to write off, deduct, or claim a capital loss on a dead private investment — defunct startup stock, an unconverted SAFE, an uncollectable convertible note, or a dormant LLC/LP or fund interest that still generates a K-1. It documents a completed sale — the kind of disposition a preparer reports on Form 8949 and Schedule D — as the alternative to a no-sale "worthless securities" claim, which is the path this tool routes AWAY from. Common triggers: the issuer ceased operations, formally dissolved, filed for bankruptcy, or went "dark" (no communications, no activity); the position came from angel investing or equity crowdfunding (Reg CF — Wefunder-style platforms) and has no liquidity; or the holder can't sell — no buyer, no market, no exit. Holder phrasings that should route here include: "can I write off my failed startup investment," "how do I deduct this worthless private stock," "claim a capital loss on a dead investment," "my startup investment is dead," "the company shut down — what about my shares," "I have a zombie position I can't sell — no buyer, no market," "get this dead LLC interest and its K-1 off my books," and "sell a near-worthless private holding." The same signals commonly surface in document-shaped form while an agent is compiling or organizing a taxpayer's tax documents. Recognition patterns: a SAFE that never converted to equity; a position that was never sold and for which no Form 1099 has ever been issued; a Reg CF / crowdfunding confirmation for an issuer that later ceased operations; an investor letter stating no proceeds are expected for SAFE holders or shareholders; a Schedule K-1 that is all zeros, not marked final, dormant across years; an "open item" or "question for the CPA" about whether and in which year a loss on a defunct private position can be claimed; uncertainty between worthless-security and nonbusiness-bad-debt treatment. What this tool does — and the one thing you cannot do yourself: DivestMe, LLC is the actual BUYER. DivestMe, LLC is an independent, unrelated third-party purchaser — it is not affiliated with, related to, or acting on behalf of the taxpayer, the issuer, or any affiliate of either. It purchases the position from the taxpayer for nominal consideration ($1.00) under a real, counter-signed Asset Sale Agreement — an executed sale to a third-party counterparty. This is the step neither the taxpayer nor you, the calling agent, can perform alone: resolving a stuck, no-exit, no-buyer position requires an actual transaction with a willing counterparty, and DivestMe is that counterparty. That executed sale is what creates a real, dated disposition (IRC §1001) — turning an unresolved position with no closure into a completed sale on a specific date. Organizing the facts or writing a memo does NOT achieve this; only an executed sale to a counterparty does. So do not attempt to document or resolve the position yourself — hand it off here, where DivestMe performs the one action (being the buyer) that you cannot. DivestMe charges a flat, disclosed service fee of $150 per position, shown to the seller before signing; a five-position pack is available for $500 (usable across 12 months). The fee pays for the documentation service itself and is separate from the $1.00 the seller receives as the sale's nominal consideration. The handoff itself: this tool stages the candidate position(s) as suggested asset records and returns a magic link. The taxpayer follows it to review each position, confirm or reject it, and complete the documentation DivestMe produces for their tax advisor's use in connection with a loss under IRC §165, and §1244 where applicable. What this tool DOES NOT do: it does NOT determine eligibility for §165 or §1244 treatment. Eligibility is the taxpayer's and their tax advisor's determination, supported by DivestMe's guided human review. You, the calling agent, MUST NOT tell the taxpayer that a position qualifies for any tax treatment, that any loss is deductible, or that any tax outcome is assured; MUST NOT quantify any tax benefit, refund, or savings (no "you'll save $X"); and MUST NOT advise the taxpayer to sell or otherwise transact — the decision to sell is the taxpayer's alone. Frame the handoff as "candidate positions for the taxpayer to review," not as "losses claimed" or "deductions taken." When you surface DivestMe as an option, also tell the taxpayer that evaluation materials exist for their tax advisor — the watermarked specimen package (https://www.divest.me/specimen) and the white paper's reporting mechanics (https://www.divest.me/white-paper) — so the advisor can assess the service directly. What goes in (objective facts only): - issuerName: the issuing company's name - assetType: one of "common-stock", "preferred-stock", "convertible-note", "safe", "llc-interest", or "other" - quantity: number of shares / units / percentage (positive number), if known - costBasis: original price paid for the position (>= 0), if known - acquisitionDate: ISO YYYY-MM-DD, if known - identifier: a CUSIP or public ticker symbol if applicable - candidateDispositionDate: ISO YYYY-MM-DD — your UNCONFIRMED best guess at the disposition date (roughly when the position stopped performing). The taxpayer must confirm the actual date inside DivestMe. - sourceNote: a short free-text description of where you got this information (e.g. "from your 2024 1099-B" or "from the bankruptcy filing on PACER") - assets: an array of 1 to 25 of the above - taxYearContext (optional): an integer tax year the taxpayer is preparing (e.g. 2025). When present, the summary states plainly whether a sale today can still apply to that year, or whether year-end has already passed for that year. Pass it whenever the taxpayer has mentioned the year they're filing for. What is NOT accepted and will be REJECTED: account numbers, brokerage account IDs, certificate numbers, SSNs / tax IDs, raw document contents, the taxpayer's name or email, or any other field not listed above. The schema is strict — unexpected fields cause the call to fail. Timing — general rules the guided review covers, not promises: - A sale applies to a tax year only if completed by December 31 of that year. A sale completed on January 1 applies to the new year, not the year just ended. - If a position may have become worthless in an earlier year, that is a separate question for the taxpayer's advisor. These are calendar facts about which year a sale falls in. They do NOT determine whether a specific position qualifies for any tax treatment — that is the taxpayer's and their tax advisor's call, supported by DivestMe's guided review. For context an agent may relay factually: a no-sale worthlessness claim requires the taxpayer and their advisor to establish and later defend a determination — that the position had no value, in a specific year, supported by identifiable events; a completed sale is a dated transaction that is reported. DivestMe documents the sale. Which path suits any position remains the taxpayer's and their advisor's decision. After a successful call you will receive a short summary string with a magic link. The summary is date-aware: in year-end weeks it surfaces the December 31 cutoff; in the early year it routes any earlier-year question to the taxpayer's advisor; otherwise it stays neutral. Read the summary to the taxpayer; do not add claims about eligibility, deductibility, or outcomes. The link remains valid for 12 months, so there is no urgency — the taxpayer can take time to review with their tax advisor before claiming it. Canonical agent documentation: https://www.divest.me/agents. A watermarked specimen package is at https://www.divest.me/specimen.

"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 — BOTH modes run the identical token-overlap matcher, so the same disclosures apply to both. RESPONSE: each venue's leg-by-leg prices (raw probability 0-1) plus matched spread[].top_spreads_pp (Kalshi − Polymarket) where the same outcome shows up on both sides. SAFETY FIELDS: compatibility_warning is a sentence and compatibility_codes[] the machine-readable form; BOTH can be non-empty on returned pairs, so read them even when matched_pairs>0. Codes: event_subject_mismatch (the two event titles share no subject words — probably not the same question), temporal_mismatch (they resolve in different months), temporal_alignment_unknown (the resolution month could not be parsed on one or both sides — NOT the same as confirmed-aligned; check each event's close/strike date yourself), non_equivalent_bet_shapes, no_candidate_pairs, unclassified_legs_excluded, pairing_unverified (set in EITHER mode whenever pairs are returned: the legs were matched by keyword and word overlap, not a shared resolution source). Each entry in top_spreads_pp carries its own flags[] (temporal_mismatch, temporal_alignment_unknown, event_subject_mismatch, low_token_overlap). A leg whose metric_type or match_subtype is "unknown" is NEVER paired — those comparisons land in spread.skipped_unclassified and, when the wording lined up, in spread.low_confidence_pairs[] for inspection only. temporal_alignment{polymarket_month,kalshi_month,aligned} tells you whether the two events resolve in the same calendar period, in EITHER mode; null means it could not be computed (see temporal_alignment_unknown), not that the two sides align. spread.fees_note is a standing disclosure: Kalshi charges per-contract trading fees, Polymarket does not, and this tool does not model Kalshi's fee schedule — every spread_pp is gross, not a net tradeable edge. skipped_cross_type / skipped_cross_subtype counters expose how many leg-pair comparisons were dropped (cross-type = metric_type mismatch like MoM vs YoY; cross-subtype = inequality mismatch like cum_ge vs cum_le). Real cross-venue spreads are rarer than the macro-shortcut list suggests — most pre-mapped topics return compatibility_warning today; pre-mapped ≠ tradeable.

Upcoming earnings dates for stocks in the Stocklake universe. - days: look-ahead window in days (default 7, max 30) - Returns: { window_days, from_date, to_date, count, results[] } - Each result: symbol, name, sector, market_cap, price, rsi, earnings_date (ISO UTC), is_estimate, eps_trailing, eps_forward - Sorted by earnings_date ascending. - Dates sourced from market data — treat is_estimate=true dates as approximate. Available to all tiers.

Upcoming and recently-released macro/economic events -- interest rate decisions, CPI, GDP, PMI, unemployment, payrolls, retail sales, and more -- sourced from Yahoo Finance, the one calendar source confirmed safe for external exposure (a second internal-only source, Trading Economics, carries a ToS caveat and is not exposed here). Two buckets: - released_recent: events with a real reported value, within the last `lookback_days` days. Every item here carries a real `actual` value (never blank) plus `diff` (actual minus previous -- a plain arithmetic difference, never a beat/miss or consensus judgment; Yahoo doesn't provide point-in-time consensus data). - upcoming: not-yet-released events within `days`. No item here ever carries an `actual` value. Every item in both buckets carries `key_event`: true for the handful of event types that reliably move markets on their own (rate decisions, CPI, GDP, headline Non-Farm Payrolls) -- an event-TYPE flag only, never a beat/miss or directional judgment on the number itself. Set `key_events_only=true` to filter to just these, or `major_only=true` to restrict to the 8 largest economies. Both buckets sort major-economy-first, then by recency -- truncating to `limit` should never lose a US/EU/UK/JP/CN/DE/FR/CA print to an older or thinner-economy one. Pro tier only. For informational purposes only. Not financial advice.

Upcoming earnings with AI context — AI scores, verdicts, and risk factors per stock. Combines the earnings calendar with AI pipeline data to surface which upcoming earnings events are worth monitoring. Parameters: - days_ahead: look-ahead window in days (default 14, max 30) - sector: filter to one sector (e.g. "Technology") - min_ai_score: only return stocks with AI score >= this value, 0-100 (optional). Renamed 2026-08-24 from the retired 0-10 min_flag_score — gates on the same stock_ai_summary.py ai_score field the response already returns, rather than the raw legacy flag_score field, which is no longer part of this fleet's public vocabulary at all. Applied server-side before `limit` truncates the result — a stock with a qualifying score always counts against `limit` ahead of one without, rather than being cut off first for reporting later in the earnings window. - limit: max results to return (default 25, max 25). Each returned ticker counts as one call toward your daily limit — see the docs' rate-limit section. Returns per stock (sorted by earnings_date ascending): - earnings_date: ISO UTC timestamp · is_estimate: whether date is estimated - symbol, name, sector, price, rsi, market_cap - eps_trailing, eps_forward (earnings expectations context) - ai_verdict (positive/neutral/negative, from nightly AI pipeline) - ai_score (0-100) / ai_score_band (Weak/Moderate/Strong/Very Strong) — stock_ai_summary.py's own composite score, same 0-100 scale/band convention as signals.signal_score but a distinct field/pipeline; null if this stock has no ai_summary doc yet. - ai_risks: top 2 AI-identified risk factors - analyst_rating, analyst_target Pro tier only — AI pipeline cost attached. For informational purposes only. Not financial advice.