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

What this user should deal with right now, computed from their sent mail, their calendar and their LinkedIn export: people who went quiet after real correspondence, people they are meeting this week, who they write to most, invitations nobody answered, and the shape of their network. Each item carries the reason and where the numbers came from. Call this for 'what needs my attention', 'who am I forgetting', 'who should I follow up with', 'what should I do today' and anything else that asks who to deal with without naming one person. Then show an attention_list card and never write the items out yourself. `readiness` says whether the mailbox has finished being read: when it is 'pending' or 'partial', say so rather than presenting a short list as the whole picture.

List events from the user's connected Google Calendar, ordered by start time — summary, start/end, location, organizer, attendees and their RSVP status, and a meeting link when there is one. With no time range it returns upcoming events from now. `time_min` and `time_max` are RFC3339 timestamps ('2026-08-19T00:00:00Z'), so 'what's on my calendar tomorrow' is time_min/time_max spanning that day; past ranges work too. `query` free-text matches event titles, descriptions, and attendees. For 'how many meetings…' questions over long ranges (a quarter, a year), set count_only=true — it sweeps the whole range and returns the total plus a per-month breakdown instead of the events themselves, so a 12-month count is one call. By default this reads the primary calendar; to read a named calendar ('my Family calendar'), first get its id from list_google_calendars, then pass calendar_id. If the result says no Google account is connected (or the account lacks calendar access), show the user the message and link them to /user/integrations/gmail.

List the calendars in the user's connected Google account(s) — name, id, whether it's the primary, and the user's access role. Use it to find a named calendar ('Family', 'Content schedule') before reading its events with get_calendar_events(calendar_id=…). If it says the account needs reconnecting, link the user to /user/integrations/gmail.

Create one new event on the user's Google Calendar — title (summary), start, and end are required; description and location are optional. Use only when the user asked for the event — it lands on their real calendar immediately. start/end are RFC3339 timestamps ('2026-08-25T19:00:00-04:00'). By default the event goes on the primary calendar; to use a named calendar, get its id from list_google_calendars and pass calendar_id. Attendees are deliberately not supported — Google would email them invites. If the result says the account needs reconnecting, link the user to /user/integrations/gmail.

Update one Google Calendar event — change its title (summary), description, location, or start/end times. Only the fields you pass change; everything else stays. Get the event's id (and its calendar_id, if it isn't on the primary calendar) from get_calendar_events first. Use only when the user asked for the change — edits land on their real calendar immediately, and other attendees can see them. start/end are RFC3339 timestamps ('2026-08-25T19:00:00-04:00').

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

Is a market open on a date, and why not if it isn't. view='next_session' finds the next open day; view='settle' computes a T+N settlement date skipping weekends and holidays; view='business_days' counts open sessions in a range; view='year' lists a calendar's whole year. Paid: call without x_payment to receive this call's exact terms (amount, asset, network), sign them, then call again with x_payment. The free `pricing` tool lists every price at once.

Read everything about the authenticated Kamy account in one call: profile, plan and plan status, the plan's limits (renders per month, API keys, seats, custom templates, overage pricing, priority queue), month-to-date render usage, and whether documents rendered on this plan carry Kamy's own watermark. This is the only tool that answers any of those questions — there is no separate quota tool. Call it before render_batch, create_schedule, or any long series of renders: usage.renders.remaining is how many the API will still accept, and every render tool fails with 402 QUOTA_EXCEEDED once it hits zero, a failure nothing can recover from within the same calendar month. quota and remaining are null on unmetered plans, which means unlimited, not zero. Also check watermarkPolicy.appliedToRenders before generating something the user intends to send on: it is true on the free plan and cannot be turned off per render. Read-only, spends nothing, and works with any valid API key regardless of its scopes.

Set up a recurring render: a cron expression, a template, and where each document goes. Use this instead of render_pdf when the user wants a document produced repeatedly on a calendar — a weekly report, a monthly invoice run — so nothing has to stay running. Delivery channel is 'email' or 'whatsapp' (recipients required) or 'download' (stored only; retrieve later with list_renders). The cron is evaluated in the given IANA timezone, and how often it may fire is plan-gated: at least 60 minutes apart on Free, 15 on Starter, 5 on Pro and above — a tighter expression is rejected with a validation error naming the limit. Every firing spends one render from the monthly quota, so a frequent schedule can exhaust a small plan on its own. Returns the created schedule including its id and next_run_at.