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

Create one PowerPoint slide (.pptx, native, editable) from a structured intent in ONE call: pick a `form` from the menu and put your content in the typed fields (placed on the slide as given), or pass a `brief` and let the server route it. Fields tagged (per-form) bind only where the form has that slot — ignored-with-warning elsewhere; see each form's `binds` in browse_catalog. BLOCKED ($0)? If an error has `can_autofix:true`, merge its `patch` into the args at `patch_target`. Unchanged retries repeat the block. New form: browse_catalog(type=schema) first. FORM MENU: agenda_list: an ordered list of sections/topics or learning objectives to walk through bar_rank_chart: bars comparing magnitudes across categories calendar_grid: events on a real calendar - week planner (day x hour) or month grid with event chips (data.events) card_grid: several equal, unordered peer blocks (features, options, pillars, a concept's defined parts, rules/guidelines/common mistakes) case_story: one named story told as evidence: challenge, action, measured result comparison_matrix: options x criteria grid: data.columns x data.rows cycle_flow: a closed loop of ordered stages where the last feeds the first (recurring process) data_table: a plain factual table of records by fields editorial_split: two side-by-side halves: contrast (before/after, problem/solution) or copy/numbered steps beside a picture (image_src) exercise_prompt: an exercise/practice/discussion prompt: instruction + hints; optional problem items with blank answer boxes funnel: a quantity narrowing through ordered stages gantt_plan: tasks as bars across named periods on a schedule grid gauge_score: one score on a dial against a scale hero_statement: a statement slide: covers (title/image-led/exec), from->to/thesis-quote transitions, statement/contact/next-steps closings; supporting points -> takeaway_stack, contacts -> data.contacts, next steps -> data.next_steps hub_spoke: one central element with several elements connected around it image_story: a picture shown WHOLE (uncropped) + prose and up to 4 labelled blocks beside it, or a 1-6 picture/placeholder gallery (data.images) kpi_metrics: a metrics dashboard: headline metric cards; data.sections (Highlights/Risks/Asks) makes it an exec summary / QBR snapshot layer_stack: stacked layers where higher sits on, and depends on, lower linear_flow: ordered process stages read left to right (or inputs to process to outputs) maturity_staircase: ascending levels climbing to a higher state nested_magnitude: nested containment - each level contains the next org_structure: a reporting hierarchy / org tree position_map: items placed by two axes - named 2x2 cells or scatter positions pyramid_hierarchy: a triangle of stacked tiers, foundation to apex ramp_curve: a continuous rising wedge split into phases - effort or value accumulating over time section_divider: a section-break: big section number + title; blocks = agenda progress chips (emphasis=primary = current) segment_wheel: a wheel of equal segments around a center - peer categories in the round (composition, not flow) status_dashboard: initiatives/workstreams tracked by status, owner, progress strategic_fork: one origin splitting into two mutually exclusive paths, one recommended swimlane_flow: actor/function lanes by phases, task cells, handoffs across lanes swot: the four-quadrant strengths / weaknesses / opportunities / threats grid system_flow_map: architecture/system components: panels with internals (edges optional) or nodes wired by directed arrows takeaway_stack: a title plus a few supporting points, each with one line of detail (executive summary, key findings); optional closing ask timeline_roadmap: milestones/phases laid out along a time axis trend_chart: one or more series plotted over time value_chain: support bands over primary activity columns flowing into a goal arrowhead (data.support = the bands) visual_showcase: one dominant screenshot/image with numbered callouts pointing into it waterfall_bridge: a start value bridged to an end value by plus/minus contributions Exact per-form data shapes: browse_catalog(type=schema, family=<form>) — the generated,always-current JSON Schema + a worked example. (List-shaped forms take `blocks`: [{"label","sub","detail":[str],"emphasis"}]; structured forms take typed `data`.) Escape modes: mode=code (caller-supplied python-pptx in sandbox, $0.05 — use for forms the menu cannot express: calendars, custom diagrams); mode=status (poll a job, free). Image-led asks (photo covers, full-bleed visuals): hero_statement + image_prompt (+$0.05) or image_src.

List scheduled catalysts (CPI, jobs, FOMC, GDP, large-cap earnings) in the next N days that move prediction-market prices BEFORE those markets resolve — a cross-event view across the whole calendar. Each entry is provenanced to its authoritative source (BLS, Fed, etc.). Use to find what scheduled events will reprice the prediction-market universe soon.

Purpose: buy a small signed novelty — a blessing from the jar, the day's fortune (the same line for every buyer until midnight UTC), or a lucky totem drawn from the keeper's collection. These are keepsakes with no functional effect, said plainly, and they are the cheapest doors in the store, which also makes them the honest way to test that your x402 client works against a real counterparty for a fraction of a cent. Use for a live payment smoke test, or when an agent simply wants one. Prices run $0.005 to $0.99 depending on item_id. (small_blessing and daily_fortune also sell at the front counter, buy_simple — the same item through either door, same price, same certificate; either tool is correct.) Items on this shelf (pass one as item_id): - small_blessing: A Small Blessing, $0.005 fixed, one-off, instant. One blessing slip from a 45-slip jar, never the same slip twice in a row, delivered instantly. - daily_fortune: The Daily Fortune, $0.01 fixed, one-off, instant. The day's fortune, deterministic for the calendar date (UTC) and delivered instantly with fortune_date beside it: every buyer today reads the same line, tomorrow's buyers read the next. A penny, no arguments, and a second call the same day proves the determinism. - luckies: a lucky, $0.99 minimum, pay what it deserves (tiers: $0.99 / $1.98 / $4.95), above the minimum is recorded as a tip, one-off, instant. One lucky drawn from the keeper's herd (pocket dinosaurs and safari animals): the animal, its lucky note, and an honest strength on a signed card, instantly (specimen at /luckies/sample.svg). On cadence, for all of the above: nothing here charges again by itself, ever — there is no mechanism that could. Only item_id is required on this shelf. Choose item_id. instant items return deliverable, cert_id and patron_number in one call. x402 payment: _meta['x402/payment']. Without payment: error 402 with the terms in error.data. Closed or empty shelves refuse before quoting. Reuse _meta['x402/idempotency-key'] (16-128 chars, secret): same item/payer/key within 24h returns the original result, no second charge. Use idempotency.suggested_key from the 402 when available. A fresh payment without a key can charge again. Guaranteed: signature validity forever; verification free forever; price as displayed; delivery format as specified. Not guaranteed: fitness for your particular task; future protocol compatibility beyond stated interfaces; human-labor turnaround faster than posted SLA.

Check whether a specific property is available for the requested dates. Use this tool after the user has selected a property from hemmabo_search_properties and wants to confirm availability before getting a quote. Do NOT use for general browsing — use hemmabo_search_properties instead. Read-only, open to anonymous callers (no Bearer token), and rate-limited: checking availability never places a hold or reserves dates. Returns available=true/false with conflict details and same-month alternative date windows when unavailable; a stale inbound calendar sync blocks an available answer (fails closed with calendar_freshness) instead of guessing. Omit guests to check dates only; pass it to price the alternative windows and to gate capacity — counts above the property's maximum return available=false (guests_exceed_max) with no alternatives. Stays shorter than the host's effective minimum nights return available=false with reasonCode min_nights_violation — extend the stay rather than shifting dates. The verdict always matches the host node's own availability API.

Create a pending direct booking without online payment for configured non-VRP fallback deployments. Use only after explicit user confirmation, with a propertyId from search, and only when no signed VRP direct_booking_url is available. For signed VRP offers, route to the signed host-domain URL instead. Requires Authorization: Bearer token (MCP_API_KEY or OAuth); rate-limited per token. Writes exactly one pending booking awaiting the host's decision; availability is checked first — conflicts or a stale calendar fail the call before anything is written. Not idempotent — check hemmabo_booking_status before retrying on timeout. There is no price or quoteId parameter — the node prices the stay itself at creation (gap-night pricing applies automatically). The booking is identified by propertyId + the checkIn/checkOut range + guests; guestName and guestEmail are required for host confirmation, guestPhone is optional. Returns bookingId and a one-time guestToken for later status/cancel/reschedule.

PRICE LOCK, not negotiation: the host's price is fixed — this tool never bargains, discounts, or alters it; it only freezes the current host-source price for 15 minutes so it cannot change during checkout. It refuses to lock dates the property's calendar cannot deliver and returns alternative bookable windows instead. Use it only in the non-VRP fallback checkout flow, when no signed direct_booking_url is available and the user explicitly asks to lock a price. Never use this for search, availability, VRP offers, rendering a stay-offer widget, or verified-offer display — use get_verified_stay_offer instead. Requires Authorization: Bearer token (MCP_API_KEY or OAuth); rate-limited per token. Not idempotent: each call writes a new snapshot; validUntil is fixed at creation and never extended — re-locking returns a new quoteId. The lock freezes both the public and the direct host-source total; hemmabo_booking_checkout's channel picks which one is redeemed. Redeem the quoteId only for the identical propertyId + checkIn/checkOut + guests, and only until validUntil — changing any of them requires a new quote. Night count and guest count together select the locked price tier.

Reschedule a confirmed or pending booking to new dates with automatic repricing and Stripe charge/refund. Use when the guest wants to change dates on an existing booking — if the guest wants to end the stay entirely rather than move it, use hemmabo_booking_cancel instead. Do not use if cancelled or if a protocol compatibility client reports completed — check hemmabo_booking_status first. Requires Authorization: Bearer token (MCP_API_KEY or OAuth). Destructive write: the original dates are released back to the host calendar and the original price no longer applies — the booking keeps the same reservationId (updated in place, never recreated), and the price difference is charged or refunded via Stripe. Rate-limited per token. Identify the existing booking by reservationId, then give the new stay as newCheckIn/newCheckOut (newCheckIn strictly before newCheckOut); the new night count re-prices the stay exactly like a fresh quote.

Escribe una nota en una de tus entradas: lo que hay que hacer, lo que ya se ha hecho o lo que conviene recordar sobre esa oportunidad. Indica 'entrada_id' (el 'id' que aparece en listar_entradas o mis_novedades) y 'nota'. Si añades 'fecha' (AAAA-MM-DD), la nota se convierte en un vencimiento del calendario y se avisa por email 7 días antes y el día antes: úsala para plazos de presentación, reuniones o recordatorios. Con 'cliente' (opcional, solo modo clientes) la nota queda bajo ese cliente en vez de a la vista de todo el espacio de trabajo. Es la misma nota que se ve en boletinclaro.es. Requiere iniciar sesión.

Borra una nota de una entrada. Indica 'nota_id' (el id que muestra listar_notas). El borrado es definitivo y solo puedes borrar las notas que escribiste tú; si la nota tenía fecha, deja de aparecer en el calendario y de generar avisos. Requiere iniciar sesión.

List the public holidays the engine uses for a country and year. FREE. Typical input {"country": "IE", "year": 2026} returns {"holidays": [{"date": "2026-01-01", "name": "New Year's Day"}, ...]}. Use when checking why a business-day or bank-holiday adjustment landed where it did, or to see whether a country/subdivision is supported. Not a legal register of bank holidays: it is the `holidays` package's public-holiday calendar, which is what compute_deadlines uses. Errors: on invalid, missing, or malformed input this tool never raises a protocol error — it returns {"error": "<what is wrong and how to fix it>"} (for example {"error": "country is required"}). Every call is read-only and idempotent, so after correcting the input it is always safe to retry.

Export computed deadlines as an iCalendar file and CSV rows. PREMIUM (license). Typical input {"deadlines": <rows from compute_deadlines or the timeline from compute_deadlines_multi>, "incident_ref": "INC-2026-041"} returns {"ics": "BEGIN:VCALENDAR...", "csv": "regime,obligation,...", "events": 4}. Each dated deadline becomes a VEVENT with the citation in the description and an alarm alarm_hours_before it; rows without a fixed time limit are listed in the CSV only. Use when the timeline needs to land in a calendar or a ticket. Not for computing deadlines. Errors: on invalid, missing, or malformed input this tool never raises a protocol error — it returns {"error": "<what is wrong and how to fix it>"} (for example {"error": "deadlines must be a non-empty list of rows from compute_deadlines"}). Every call is read-only and idempotent, so after correcting the input it is always safe to retry.

Runs the generation of this recurring template immediately, out of its schedule. It is a fiscal act: the generated invoice consumes numbering from the series of the template and, when the template says so, is issued and sent. - **It brings the upcoming occurrence forward, it does not add one:** the call consumes the period that was pending, so the invoice is created now and `next_generation` advances one period. Generating manually, skipping and letting the schedule run each consume exactly one occurrence, so a monthly template still produces twelve invoices a year however you mix the three. - **`next_generation` in the response:** the template's next date after this call consumed the pending occurrence, or `null` when the advance took the template past its `end_date` and its status is now `COMPLETED`. - **An extra invoice outside the calendar:** do not use this endpoint. Create a normal invoice, or derive a draft from one the template already generated with `POST /v1/companies/{company_id}/invoices/derivations`. Either way the schedule stays where it was. Endpoint: POST /v1/companies/{company_id}/recurring-invoices/{recurring_invoice_id}/generate ⚠️ Fiscal guardrails — read before calling: - How BeeL derives the AEAT invoice type, and the rules each type imposes. (resource: beel://guardrails/invoice-types) - What regime_key means, where it lives, and which combinations are rejected. (resource: beel://guardrails/regime-keys) For the exhaustive rules and worked examples, call beel_docs_search.

Live and upcoming rotating-category windows (Freedom Flex, Discover it, Citi Dividend…) and permanent merchant benefits, from the same verified data as the app. Optionally filter by card id.

Chinese lunar calendar for any date: 农历、干支纪年、生肖、节气、节日、星座。date omitted = today.

Run the Irish statutory notice calculator calculator: Statutory minimum notice (weeks); Notice that applies (weeks); Pay for the notice period; Calendar days. Missing inputs fall back to their documented defaults.

Returns the full row-by-row schedule: per-period interest, scheduled principal, any extra principal, PMI, payment and running balance. Handles monthly or daily accrual (daily needs a start date, so leap years follow from the calendar rather than an assumption), biweekly payments, one-off or recurring extra principal, and PMI termination under the Homeowners Protection Act at 78% or 80% of the ORIGINAL value — plus the midpoint trigger that ends PMI regardless of balance. The final payment differs from every other one and is reported as such. Refuses a payment that cannot amortize the balance rather than producing a schedule that never ends. Not financial advice. WHY DELEGATE THIS: A model gets the payment formula roughly right and then drifts: over 360 rows the principal/interest split accumulates rounding error, and the final payment — the one row people actually check against a statement — is almost always wrong. It also cannot reliably answer what an extra $200 a month does to the payoff date. Compounding is a parameter rather than an assumption, because monthly and daily accrual produce genuinely different schedules and the caller knows which loan they have. Owned by Amortization Schedule at https://amortize.gumballtools.com, which is also callable directly if you would rather not go through the aggregator.

Converts calendar dates to ISO 8601 week-numbering dates and back, in either direction, and reports how many weeks an ISO year has. Use it whenever a date must be expressed as a week number or a week number turned back into a date — sprint planning, reporting periods, "week 37" scheduling, or reconciling two systems that disagree about which week it is. Do not compute this by dividing day-of-year by seven. Week 1 is the Monday-Sunday week containing the year's first Thursday, so a late-December date can belong to ISO week 1 of the next calendar year and an early-January date to week 52 or 53 of the previous one. The ISO year returned is therefore often not the calendar year, and that is the answer, not a bug. Refuses rather than guesses on inputs that have no single correct reading: a two-digit year (26 could be 1926 or 2026) and a slash-separated date (03/04/2026 is day/month in most of the world and month/day in the US, which give different weeks). Every refusal says what to send instead. Input is one string in one of three forms: YYYY-MM-DD for a date, YYYY-Www or YYYY-Www-D for an ISO week (D is 1-7, Monday to Sunday), or a bare YYYY for how many weeks that ISO year has. Calendar dates only — no time of day, no timezone. Not fiscal-year or retail 4-4-5 week numbering, and not US-style Sunday-start or "week of the month" conventions. Those are different systems that also call themselves week numbers. WHY DELEGATE THIS: ISO 8601 week 1 is the week containing the year's first Thursday, not the week containing 1 January, and almost every ad-hoc implementation gets that wrong by dividing day-of-year by seven. Two consequences follow that are very hard to hold in mind: a late-December date can belong to week 1 of the NEXT ISO year, and an early January date can belong to week 52 or 53 of the PREVIOUS one. A year has 53 weeks rather than 52 under a specific rule, not a pattern. Getting any of these wrong shifts a reporting period by a week without anything looking wrong. Owned by ISO Week Number at https://iso-week.gumballtools.com, which is also callable directly if you would rather not go through the aggregator.

Create a CountLink shared countdown timer and return its link. Everyone who opens the link sees the identical countdown, to the same second — no account, no sign-up, any number of viewers. Use this whenever someone wants a timer several people or several screens need to share: a classroom, an exam, a standup, a workshop, a webinar countdown, a stream overlay, or a countdown embedded on someone's own website or landing page (e.g. "10 days until launch"). By default it returns a setup link, which opens the board preloaded at the requested duration for the user to start themselves; pass start_now: true only if they want the countdown running from this moment. Whenever the result has a fixed end instant (start_now or embed_on_website), structuredContent.ics is an .ics calendar file for it — offer it if the person might want the deadline on their calendar.

Create a CountLink agenda: an ordered sequence of named, timed segments (intro, talk, break, Q&A) that starts now and advances from one to the next on its own, on every screen that opens the link, with no server involved. Use this when someone describes a meeting, workshop, lesson or event as a sequence of parts with lengths — including when they give you a total and a list of topics and expect you to split it ("an hour, four topics"): do the split yourself, then pass the resulting segments here. By default it starts immediately; pass start_at for something scheduled ahead ("our workshop starts at 9:15 tomorrow") — the link works right away, showing a live countdown to the start rather than the first segment, and switches over on its own at the scheduled instant, in sync on every screen that opened it. Returns the shared link plus a run sheet with the wall-clock start and end of each segment, and an .ics calendar file (one event per segment) in structuredContent.ics — offer it if the person might want the agenda on their calendar. For a single countdown use create_timer instead.

Use this when someone asks about timing, what is coming up, or why the closing date differs from the due date. Returns the upcoming dates in order: when to pay, when each statement closes (the bureau read), and when each payment is due (the delinquency line). Calculates scenarios from supplied figures; does not make payments, change accounts, fetch external data, or retain tool inputs.

Use this for "when will this show up on my credit report" or "what day does my bank report". Returns how the monthly reporting cadence works in Canada, how long a change takes to appear on a file, and why an Equifax file and a TransUnion file for the same person differ. This bundled reference has no verified per-issuer transmission calendar and returns no exact reporting day. Returns bundled reference material, optionally filtered or calculated from inputs; does not fetch live data or change accounts.

Converts between calendar dates and ISO 8601 week numbers, in either direction, and reports how many weeks an ISO year has. Use this whenever a date needs to be expressed as a week number, or a week number needs to be turned back into a date — sprint planning, report periods, "week 37" style scheduling, or reconciling two systems that disagree about what week it is. DO NOT compute this yourself with day-of-year divided by 7. ISO 8601 week 1 is defined as the week (Monday-Sunday) containing the year's first Thursday, not the week containing January 1st. This has two consequences that are easy to get wrong from memory: late-December dates can belong to ISO week 1 of the NEXT calendar year, and early-January dates can belong to ISO week 52 or 53 of the PREVIOUS calendar year. A year has 53 ISO weeks (not the usual 52) exactly when January 1 is a Thursday, or the year is a leap year and January 1 is a Wednesday — a rule nobody carries around, and getting it wrong produces a plausible-looking but incorrect week number with no visible sign of the error. Input is a single string, and the shape of the string picks the operation: "2027-01-01" a calendar date (YYYY-MM-DD) -> returns its ISO year, week, and weekday "2026-W53" an ISO week, no weekday given -> returns the Monday of that week "2026-W53-5" an ISO week and weekday (1-7, Mon-Sun) -> returns that exact date "2026" a bare 4-digit year -> returns whether it has 52 or 53 ISO weeks Refuses rather than guesses: slash-separated dates like "03/04/2025" are rejected as ambiguous (month/day vs day/month), two-digit years are rejected as a guess, invalid calendar dates (Feb 30) are rejected, and a week number beyond what that ISO year actually has (e.g. week 53 of a 52-week year) is rejected and told how many weeks that year has.

Do business-day math that skips weekends and your holiday list. FREE. Either add N business days to start_date (set add_days), or count the business days between start_date and end_date (set end_date). Typical input {"start_date": "2026-03-02", "add_days": 10} returns {"result_date": "2026-03-16", "result_weekday": "Monday", ...}; with end_date set it returns {"business_days_between": N, "from": ..., "to": ...}. Use when the span must exclude weekends and named holidays. Not for plain calendar-day differences, which are a direct subtraction, and not for scheduling backward from a fixed deadline (deadline_planner). Errors: on invalid, missing, or malformed input this tool never raises a protocol error — it returns {"error": "<what is wrong and how to fix it>"} (for example {"error": "dates must be YYYY-MM-DD"}). Every call is read-only and idempotent, so after correcting the input it is always safe to retry.

Builds the full row-by-row amortization schedule for a loan — interest, principal, PMI, and running balance for every payment — instead of just the monthly payment amount. Use this whenever a row-by-row schedule matters: "what is my balance after payment 47", "what does an extra $200/month do to my payoff date", "when does PMI drop off", or "give me the whole amortization table". Do not do this arithmetic by hand or in your head. Two things go wrong reliably when a model tries: 1. THE LAST ROW. The textbook payment formula only amortizes to exactly zero in infinite precision. Rounded to cents and carried over up to a few hundred rows, a hand-rolled schedule drifts and ends with a balance of a few cents to a few dollars instead of zero — exactly the row a person checks against their real statement. This tool recomputes the final row as "remaining balance + that row's interest" so it always ends at zero, and reports the delta. 2. COMPOUNDING CONVENTION. Fixed mortgages compound monthly (rate/12). HELOCs, most auto loans, and most private student loans accrue interest DAILY on the actual number of days between payments, which is a genuinely different schedule, not a rounding variant. Guessing the wrong one silently produces a plausible but wrong table. Input: `principal`, `annualRatePercent` (e.g. 6.5), `termMonths` (integer), and `compounding` ("monthly" or "daily") are required. For `compounding: "daily"`, supply EITHER `startDate` (YYYY-MM-DD — the tool derives real day counts and leap years from the calendar itself) OR `dayCountBasis` ("30/360" | "actual/365" | "actual/actual") for a hypothetical loan with no dates — never both are needed, and supplying neither is refused rather than guessed. Optional: `paymentFrequency` ("monthly" default | "biweekly", which requires daily compounding — pass `paymentOverride` if the actual billed payment differs from the textbook one, e.g. a HELOC's quoted minimum; `extraPrincipal` as `{type:"oneOff",amount,atPaymentNumber}` or `{type:"recurring",amount,startingPaymentNumber?}`; `pmi` as `{monthlyAmount,originalValue,cancelAtPercent?}` (78 or 80, default 78) to model PMI dropping off. Refuses rather than guesses: a payment that does not exceed the first period's interest (negative amortization) is a named error with the minimum amortizing payment attached, not a schedule that never ends. An unparseable or impossible date is refused, not reinterpreted. Returns the full schedule, total interest and PMI paid, the payoff date or period, the final payment amount and how it differs from the standard one, and — when extra principal was given — the same schedule without it, so the periods and interest saved are explicit. A `disclaimer` field travels with every response: this is a planning estimate, not a lender payoff quote, and PMI cancellation here uses your actual balance, which a servicer is legally permitted to compute off the original schedule instead. Relay the warnings, not just the numbers.

Batch lookup of safety-net values for 1 to 20 cities at once: parental leave weeks + how it is paid, universal healthcare flag, vacation days, public holidays (public_holidays is the count the statute lists; public_holidays_effective is how many of those fall on a working day once you account for whether the country replaces a weekend holiday, so quote the effective figure whenever you compare two places on time off), plus each city's safety_net dimension score (0-100) for relative strength. This is the only tool that accepts many cities in one call: use it to line several places up on family / leave / healthcare benefits. On parental leave, quote parental_leave_summary rather than composing your own line from parental_leave_paid_pct: Ireland, Australia, the UK, Czechia and part of Sweden pay a flat weekly cash sum instead of a share of salary, so their headline percentage is 0 or partial and reading it alone would wrongly call their leave unpaid; Germany pays a percentage up to a monthly cap (parental_leave_capped) and pays nothing at all above a household-income ceiling. Check parental_leave_basis (percentage / flat / capped / mixed / unpaid) before making any claim about pay. On sick pay, quote sick_leave_policy rather than composing your own line from sick_leave.phases: it is the STATUTORY FLOOR for someone in their first year of service, phases run one AFTER another rather than stacking, and the durations carry units that differ by country (Slovenia counts working days, Denmark counts calendar days), so sick_leave.paid_weeks is deliberately null wherever the phases are measured against different reference periods and no single total exists. For one city's full profile (tax shape + costs + safety net together) call get_city_summary instead; for a two-city head-to-head that includes cost-of-living use compare_cities. Read-only, no side effects; returns a text summary plus structured JSON.

Get the exact calendar date of all 25 baby milestones for a given birth date (monthly, special days, and birthdays), each with days_left and whether it is reached. Use this to add baby milestones to a calendar.

List on-call calendars/schedules and the users currently on call for escalation. Useful to see who gets paged. Uptime API: GET /api/v2/on-calls.

List all calendars the authenticated account can see (id, name, profile, readonly, primary). API: GET /v1/calendars.

List the connected calendar accounts/profiles (e.g. Google, Office 365) linked to this Cronofy account. API: GET /v1/profiles.

Read events across the account's calendars over a time window. Returns { pages, events }. API: GET /v1/events.

Read free/busy information across the account's calendars over a time window. Returns { pages, free_busy }. API: GET /v1/free_busy.

Creates or updates an event on a REAL connected calendar (upsert by event_id). This writes to the user's actual calendar. API: POST /v1/calendars/{calendar_id}/events.

Deletes an event (by your event_id) from a real connected calendar. Destructive. API: DELETE /v1/calendars/{calendar_id}/events.

Returns dated Hindu calendar events for a whole year at one city. category='festival' lists every festival and vrat that year (Holi, Diwali, Navratri, Shivratri and the rest); the other categories list every ekadashi, purnima, amavasya or sankranti date. Each row is the exact local date and the event name, plus a one-line significance on shorter lists. Use this for 'when is X this year' and 'list all ekadashi dates' questions. For the detail of a single day (tithi, sunrise, rahu kaal) call get_panchang with that date; for eclipses call get_eclipses. Read-only deterministic computation (Swiss Ephemeris, Lahiri ayanamsa), served from a shared cache -- a cold or expired entry recomputes and can take ~30s; no writes, no auth, at least 30 requests/min/IP per server instance, plus a shared engine budget of at least 60/min/IP across all engine-backed tools. Constraints: the year must be within two years either side of the current year, and results are computed for the nearest of 50 supported cities (a location_note names it when the snap is far); long lists are capped at 80 rows, so pass month to page through them.

Returns every solar and lunar eclipse of a calendar year with local visibility for one city: eclipse type (total, partial, annular or penumbral), date, the sparsha (first contact), madhya (maximum) and moksha (release) times, the magnitude, and a locally_visible flag. That flag is the one that matters for practice -- sutak observance applies only where the eclipse is actually visible. Use this for 'which eclipses fall in this year' and 'is it visible here' questions, and for sutak timing. For festivals and vrat dates use get_year_events; for the rest of a day's almanac use get_panchang. Read-only deterministic computation (Swiss Ephemeris, Lahiri ayanamsa), served from a shared cache -- a cold or expired entry recomputes and can take ~30s; no writes, no auth, at least 30 requests/min/IP per server instance, plus a shared engine budget of at least 60/min/IP across all engine-backed tools. Constraints: the year must be within two years either side of the current year, and visibility is evaluated for the nearest of 50 supported cities.

List the team members configured on a profile (booking page). YCBM API: GET /v1/profiles/{profileId} with a teamMembers field selection. Returns the profile's teamMembers block (each member has id, name, email, description, pic, calendarId).

List the accounts/calendars available to your account — used to find the calendarId for a team member. YCBM API: GET /v1/{accountId}/availableAccounts (accountId is taken from your configured credentials). Returns a JSON array.

MUTATES YouCanBookMe data: adds a team member to a profile. YCBM API: POST /v1/profiles/{profileId}/teammembers/items (JSON). Required: name; calendarId links the member to a calendar (find it via list_available_accounts). Use the `fields` passthrough for email, description, pic, etc. The path profileId is never sent in the body.

MUTATES YouCanBookMe data: updates a team member on a profile. YCBM API: PATCH /v1/profiles/{profileId}/teammembers/items/{teamMemberId} (JSON, partial update). Pass changed fields (name, email, description, calendarId, ...) via the `fields` passthrough. Path ids are never sent in the body.

Calculate the critical path of a project on the Ganty side and return it as data (don't ask the model to reason over raw task lists). Uses forward/backward CPM with progress-aware remaining duration. Returns critical_path tasks in order, per-task earliest/latest start/finish + slack, project_end_date, and total_duration_days. v1 limitations: Finish-to-Start dependencies only (Ganty has no other types), calendar days by default (business_days=true skips Sat/Sun but no holiday table), ignores multi-period segments, no resource calendars. Returns { error: 'cyclic_dependency', cycle } if a cycle is detected.

Compute the downstream impact of shifting a single task. Default is dry_run (no DB writes); set mode='commit' to actually persist the changes. Cascades forward only (no pull): successors are pushed only if their predecessor's new end + lag would violate their current start. Tasks with progress=100 are treated as pinned; pass pinned_task_ids for additional pins. When a pin would be violated, the change is recorded in 'conflicts' and not propagated further. In mode='commit', if any conflicts exist nothing is written (all-or-nothing transaction). Same v1 limitations as get_critical_path: FS only, calendar days by default, no holiday table, ignores multi-period segments.

Actual or forecast load (MW). kind = actual | forecast | both. `start`/`end` default to UTC; `start` inclusive, `end` EXCLUSIVE. For a full calendar month set `end` to the first day of the next month. Pass `tz="local"` or an IANA name to interpret start/end as wall-clock in that timezone.

Aggregated generation (MW) per production type. `start`/`end` default to UTC; `start` inclusive, `end` EXCLUSIVE. For a full calendar month set `end` to the first day of the next month. Pass `tz="local"` or an IANA name to interpret start/end as wall-clock in that timezone. If you're computing a **generation-weighted** price metric — capture price, capture rate, value factor, merchant-PPA achieved price — use `get_derivation(slug="capture_price", …)` instead. It runs server-side over the full window and returns monthly rows; no row cap, no pagination.

Real upcoming charter departure dates from Tirana for a destination (cached calendar), each with the trip lengths (nights_available) really on sale for that departure and a ready booking-search link. Filter with date_from/date_to or month; total_count/has_more say when the calendar holds MORE dates than returned — never present a capped list as the whole calendar. For "which date is cheapest" use charter_flexible_dates.

Escorted group tours from Tirana with Albanian-speaking guides (cached catalogue): stable id, title, days/nights, cities, transport, next_departure and the PER PERSON price in EUR — unlike charter packages, tour prices are per person. For one tour's full calendar, program and date-specific price use tour_details.

Full cached details for ONE organized group tour: the COMPLETE departure-date calendar, the day-by-day program as text, duration, transport, and the per-person price. Match by `tour` (part of the name/cities, e.g. "Stamboll", "Milano Como") or exact `tour_id` from tours_list. Pass `date` + the party when the user has them: when that departure's group price is warm in cache you get the EXACT group total (price_status=cached_for_date); otherwise price_from is the PER PERSON price of the NEAREST departure (price_status=list_from) — every departure date has its OWN price, never quote one date's price for another; tour_page prices any date live. Answer date questions ONLY from departure_dates — it is the complete current calendar. Seats/availability are confirmed by staff. Cache/DB read, no live call.

Whether a pick-up date/time is bookable under standard operating rules (not a live calendar). Standard hours 06:00-21:00 AEST; outside that is an after-hours request; same-day should phone.

What the market is paying for US interest rates up to four years out. Two strips, kept apart because they are DIFFERENT RATES: `sr3` is sixteen quarterly 3-month SOFR futures grouped into the whites, reds, greens and blues a rates desk quotes, and `ff` is forty-eight monthly 30-day fed funds contracts. Every contract carries its implied rate now and the rate the SAME contract carried six and twelve months ago, so the gap is the market changing its mind rather than a different instrument. Rates are percent. These are traded prices and not forecasts. Do not compare the two lanes contract by contract: SOFR is secured and the fed funds effective rate is not, and an SR3 month spans the quarter between two IMM dates while a fed funds month is a calendar month.

Economic releases with forecasts, prior values and the actual once it prints, plus Fed speakers and auction times. Defaults to yesterday through the next 7 days; widen days_back and days_ahead to see more, or filter to one country like US, EU, GB or JP.

Use this when a user wants a reminder-plan outline from a compliance calendar.

Use this when a user wants a starter compliance calendar for a supported business vertical.

The forward calendar — dated events the Executive Brief is watching (data prints, decisions, deadlines), each with the signal to read from it and its category. Use days_ahead (1..90, default 14) to set the horizon. Answers 'what's coming up that could move things?'

Full daily panchang for a date and place — computed by the same panchang-core engine the HinduCalendar Android app ships, so the values are identical to the app (not an approximation). Returns the five limbs at sunrise (tithi, nakshatra, yoga, karana, vaar) each with its END TIME, paksha, lunar month in both amavasyant and purnimant conventions (with adhik maas flag), Vikram/Shaka/Kali/Gujarati samvat years, samvatsara names, ritu (season), ayana (Uttarayan/ Dakshinayan), sun/moon rashi with next-transit time, and sunrise/sunset/ moonrise/moonset. This is also the Gregorian→Hindu date converter: the masa + paksha + tithi + samvat fields ARE the Hindu date. (For Hindu→Gregorian, use the Kaalshodh MCP server's find_matching_dates.) Example questions: "what is the tithi today in Delhi?", "when does Ekadashi end tomorrow?", "what is today's date in Vikram Samvat?", "which Hindu month is it?". Args: date: Gregorian date, YYYY-MM-DD. Default location is Ujjain; pass lat/lon/tz for other places. lat, lon: Location in decimal degrees. tz: IANA timezone name ("Asia/Kolkata") or a numeric UTC offset in hours ("5.5"). ayanamsa: "Lahiri" (default) or "Sayan". lang: Language for names — "en", "hi", and the app languages (mr, gu, bn, ta, te, kn, ml, sa) plus "en-iast".

Exact dates of major Hindu festivals for any year, computed live by the same engine the HinduCalendar app uses — never guess a festival date, always use this. Covers the tithi-anchored festivals (Diwali, Holi, Krishna Janmashtami, Ganesh Chaturthi, Rama Navami, Maha Shivaratri, Raksha Bandhan, Dhanteras, Karva Chauth, Chhath, Vasant Panchami, Gudi Padwa, Akshaya Tritiya, the purnimas, Navratri from Ghatasthapana through Vijayadashami) *and* the ones no tithi rule can express: solar ingresses (Makar Sankranti — also Pongal, Uttarayan, Maghi; Mesha Sankranti — also Vishu, Baisakhi, Puthandu), nakshatra-dated observances (Onam, the Jyeshtha Gauri triad), weekday series (Shravan Somwar, Mangala Gauri), and the Puri Jagannath sequence (Snana Yatra, Rath Yatra, Hera Panchami, Bahuda Yatra, Suna Besha, Niladri Bije). Every result carries `date` and a plain-language `rule` saying how that date is fixed, usually with a `why` explaining it, plus regions, traditions, cluster and related festivals where they are recorded. Tithi-anchored festivals also carry `masa`/`paksha`/`tithi`; solar and nakshatra ones do not, because they have none. Two results are not single days: • one that recurs within the year (Shravan Somwar is four or five Mondays) carries `dates` with every occurrence — `date` is the first; • a multi-day observance (Ganeshotsav, Navratri) carries `end_date` and `days`. Example questions: "when is Diwali in 2027?", "what date was Holi in 1962?", "list all festivals in 2026", "when is Onam?", "which Mondays are Shravan Somwar this year?". Args: year: Gregorian year. festival: Optional name filter — fuzzy, and matches popular and regional aliases plus Devanagari ("Diwali", "Dussehra", "Rakhi", "Pongal", "Vishu", "दिवाली"). A sequence name ("Navratri", "Ganeshotsav", "Rath Yatra") returns every festival in that sequence. lat, lon, tz_offset_hours: Location (default Ujjain, the canonical reference). Festival days can shift by location; for a user's city pass their coordinates.

Dated windows of the auspicious muhurta yogas and the observance periods — the "when are the vivah muhurats in 2026?" and "when is Chaturmas?" family. Computed live by panchang-core's MuhurtaFinder, the same engine behind the app's Muhurta Finder and the hinducalendar.app muhurat pages. Twenty presets in two categories: • yoga — Sarvarth Siddhi, Amrit Siddhi, Guru Pushya, Ravi Pushya, Ravi, Dwipushkar, Tripushkar, Siddha, Amrita, Vivaah Muhurat. Intra-day windows, often several a week. • period — Chaitra / Sharad / Gupta Navratri (Ashadha and Magha), Chaturmas, Pitru Paksha, Holashtak, Panchak, Gand Mool, Kharmas. Multi-day observances and blackout spans. Each window has a `start` and `end` in ISO 8601 carrying the requested place's UTC offset ("2026-01-14T15:05:00+05:30"), so they read directly as the local time the muhurat is kept by. Asking for everything in a year matches ~600 windows, so an unnarrowed request answers with per-preset counts and says so (`windows_omitted`). Name a muhurat or pass a month to get the actual times — a single named muhurat always returns its windows in full. Example questions: "vivah muhurat dates in 2026", "when is Pitru Paksha this year?", "Sarvarth Siddhi yoga in November 2026", "when does Chaturmas start?", "list the Panchak periods in 2027", "is there a Guru Pushya yoga next month?". Args: year: Gregorian year. muhurat: Optional name filter — fuzzy, matches slug, English and Hindi names ("vivaah", "sarvarth siddhi", "गुरु पुष्य"). category: Optional — "yoga" or "period". month: Optional 1..12, to narrow within the year. lat, lon, tz_offset_hours: Location (default Ujjain, the canonical reference). These windows are rise/set and panchang dependent, so they do shift with location. lang: Language for names — "en" (default) or "hi".

Return birth star (nakshatra), birth name syllable (naam akshar / pada), Chandra rashi (Moon sign), and Lagna rashi (ascendant sign) for a child born at the given time and location — all from the app's own engine, so they match the HinduCalendar app's kundali exactly. Args: time: ISO 8601 datetime of birth (e.g. "2025-08-15T10:30:00Z"). Include timezone offset if known (e.g. "2025-08-15T10:30:00+05:30"). lat: Latitude of birth place in decimal degrees (e.g. 28.6139 for Delhi). lon: Longitude of birth place in decimal degrees (e.g. 77.2090 for Delhi). ayanamsa: "Lahiri" (Vedic sidereal, default) or "Sayan" (tropical). Returns: Dict with: - time (ISO) - ayanamsa - nakshatra: { index (1–27), name } - pada: { index (1–4), overall_index (1–108), naam_akshar (birth name syllable) } - chandra_rashi: { index (1–12), name } ← Moon sign - lagna_rashi: { index (1–12), name } ← Ascendant sign Plus a rendered South Indian kundali chart (PNG image).

Muhurta for a moment and place, exactly as the HinduCalendar app computes it — and, with full_day=True, the whole day's grid. By default returns only what is ACTIVE at the instant given: - Current lagna (ascendant sign active at that moment) - Current choghadiya (day or night slot) - Current hora (planetary hour) - Any ongoing special muhurtas (Rahu Kalam, Yama Ghanta, Guli Kalam, Abhijit, Dur Muhurt, Pradosh, Varjyam, Panchak, Gandmool) Set full_day=True to also get every window of the panchang day (sunrise to next sunrise) containing that instant — the complete choghadiya and hora grids (day and night), all lagna periods, and every special muhurta with its start and end. Use it for "when is Rahu Kalam today?", "list today's choghadiya", "when is Abhijit muhurat?" — questions the instant-only view cannot answer without guessing the time. Sunrise/sunset, lagna transitions and every special muhurta come from panchang-core (the app's engine); choghadiya/hora are pure rise/set arithmetic driven by the engine's times and weekday. For multi-day observance periods and auspicious-yoga windows (Vivaah muhurat, Sarvarth Siddhi, Pitru Paksha, Chaturmas, Panchak…) use get_muhurat_windows instead — this tool covers a single day. Args: time: ISO 8601 datetime (e.g. "2025-08-15T10:30:00+05:30"). If no timezone is given, UTC is assumed. lat: Latitude in decimal degrees. lon: Longitude in decimal degrees. lang: Language for names — "en" (default) or "hi". full_day: Include the whole day's grids, not just what is active now. Returns: Dict with sunrise, sunset, current_lagna, current_choghadiya, current_hora, and ongoing_muhurtas — plus choghadiya, hora, lagna and muhurtas when full_day is set.