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.

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.

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.

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.

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.