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

List the open-source AI applications hosted and ready to run at AI NetCafé (ainetcafe.com). Each one normally requires local setup (Docker/Python + your own model API key); here they run pre-configured. Use this to find a tool for a task like translating a PDF with formulas intact, generating a PowerPoint file, polishing an academic paper, or running an autonomous research report. Do not call this first when the request already clearly matches compare_models, translate_pdf, deep_research, or make_slides; call that task tool directly. Example — GET https://ainetcafe.com/t/list_apps

Get the status or result of a job started by deep_research, translate_pdf, or make_slides. Poll every 15-30 seconds until status is "done" or "error". While work is pending, follow retry_after_seconds and next_action; when complete, prefer structured_result when present. Example — GET https://ainetcafe.com/t/check_job?job_id=<id-from-a-job-tool>

Translate text into another language, preserving formatting. Capped at 30,000 characters

Parse a CVSS v3.x vector string into a per-metric breakdown plus a recomputed base score. Returns the canonicalized vector, version (3.0 or 3.1), base_score, base_severity (NONE/LOW/MEDIUM/HIGH/CRITICAL), and the eight base metrics: attack_vector (NETWORK/ADJACENT_NETWORK/LOCAL/PHYSICAL), attack_complexity (LOW/HIGH), privileges_required (NONE/LOW/HIGH), user_interaction (NONE/REQUIRED), scope (UNCHANGED/CHANGED), and the three impact metrics confidentiality_impact / integrity_impact / availability_impact (NONE/LOW/HIGH each). When temporal/environmental metrics are explicit in the vector, temporal_score and environmental_score are populated separately. Use to translate raw CVSS strings into agent-friendly attributes without re-parsing the vector grammar yourself, and to verify upstream NVD scoring against the recomputed value. v2 vectors (AV:N/AC:L/Au:N/...) are rejected with 400 — read cvss_v2_vector from cve_lookup if you need v2 detail. Free: 30/hr, Pro: 500/hr. Returns {version, vector, base_score, base_severity, metrics: {attack_vector, attack_complexity, privileges_required, user_interaction, scope, confidentiality_impact, integrity_impact, availability_impact}, temporal_score, environmental_score, summary, verdict}.

RETURNS A LIST OF BOOKS (works on a topic) — NOT passages. PICK THIS to discover which works exist on a subject. → For quotable text use search_translations (exact words) or search_concept (by meaning); if the user already named an author/work, call get_book directly (or list_books to find the ID) — the AI summary + chapter outline is usually the right first answer. Searches titles, authors, subjects, and (as a secondary signal) translated text. Query tips: single distinctive words or short phrases work best ("memory palace", "ouroboros"); quoted phrases match exactly. Each result includes total_matches (full count) + returned (this page) + offset for pagination.

READ PIPELINE step 3 — CITE. Get the exact verbatim text of a single page plus its citation apparatus. ALWAYS use before putting text in quotation marks. The response headline is citation_link (the stable sourcelibrary.org/q/… shortlink) — present it to the user alongside the quote. Render as: > [exact translation text, verbatim] > — [Author], p. [N]. [citation_link] PAGE BREAKS: this corpus is paginated from physical leaves, and nearly one prose page-boundary in five has a sentence running across it — sometimes a word split by a hyphen ("…our move-" / "movements…"). A page that opens or breaks off mid-sentence still reads as complete prose and still carries a perfectly valid citation, so check the continuity field on every response BEFORE quoting: if continues_on_next or continues_from_previous is true, call again with context: true and quote the whole sentence. Quoting a fragment as though it were the author's complete thought is a misattribution even when the page number is right. NON-LATIN SCRIPTS: where the page is Greek, Hebrew, Arabic, Sanskrit, Cyrillic and so on, the response also carries romanized — the romanization of the original — so the citation can be shown in three layers: original → romanized → translation → citation_link. It is AI-generated reading apparatus, not a transcription; quote the source from original or translation, never from romanized. Absent on Latin-script pages and on non-Latin pages not yet romanized. ENGLISH ORIGINALS: where the leaf is already English there is no translation and none is needed — the response omits `translation`, sets `text_source: "ocr_original"`, and the verbatim text is `original` (with a `transcription_note`). Quote it as the source's own words, never as a translation, and expect period spelling and long-s (ſ) — it is an uncorrected transcription of the scan. `text_source` is on every response (`translation` otherwise), so branch on it rather than guessing from pages_translated, which is 0 for an English-original book by construction. TRANSLATED EDITIONS: `original` means the text printed on this leaf, which on a translated edition is the TRANSLATOR's language, not the author's. When the response carries `translation_note`, the chain is stated there — attribute the wording to the translator and do not offer the passage as evidence of what the author wrote in their own tongue. Call list_editions to find an original-language witness of the same work. For several pages of one book at once, use get_quotes.

Use this when you need to author a variable-section sweep along a spine. Insert a `variableSweep(spine, sections, opts?)` declaration into the user's .kcad.ts immediately before the last top-level return. The result is a Shape — chain `.translate(...)`, `.union(...)`, etc. via `add_feature`. `spine_binding` references an existing variable (Curve3D / Sketch / Vec3[]) in the source; each `sections[i].profile_binding` references an existing Sketch. Sections must be strictly increasing in `t` and span [0, 1]; first t=0, last t=1. Orientation is not exposed by this MCP tool until runtime orientation support is wired. Validates every binding exists in the source via regex before inserting (fast structured error vs capture-time stack). Returns the modified code + diagnostics. Side-effect-free.

Get players available to acquire in the specified fantasy league, optionally filtered by position. This is fantasy-league availability, not professional-contract status. Pass a requested count exactly from 1 through 100; for more than 100, state the limit and ask the user to narrow the request or accept 100. Prefer the canonical fields: every response carries leagueId, seasonYear, position, count, ordering, capabilities, and ownershipScope; entries carry team (real-life club, null when none) and id (platform player id as a string, when supplied) on every platform, and ESPN entries add acquisitionState ("free_agent", "waivers", or null when the platform cannot determine the subtype) plus waiverClearsAt (ISO time); legacy platform fields remain alongside for compatibility and should not be re-explained. ownershipScope "platform_global" means percentOwned/percentStarted cover all leagues on that platform — never ownership within the selected league. An ESPN-wide started rate is never conditional on the player being rostered. Label every reported percentage as an ESPN-wide roster/start rate or Yahoo-wide market rate. Translate ownership scope silently into that provider-wide wording; never print the ownershipScope key, platform_global enum, or get_free_agents tool name. If capabilities marks rates unavailable, write "[Provider] market ownership rate: not provided"; do not print a missing response field name or null value, call get_players, or offer a lookup. When acquisitionState is null or not present, call rows "available players," never specifically free agents or waivers, and do not promise an immediate add. A returned player is already confirmed available in that league. Use get_roster only when the current request separately asks who owns a player; never offer it after an available-player result. Do not include injuryStatus or any injury detail unless the user asks for it; when asked, verify current web evidence and translate provider codes into plain language. State acquisition status in plain language from acquisitionState ("a free agent", "on waivers"); never print raw codes — neither provider codes such as FREEAGENT or WAIVERS nor canonical values like free_agent verbatim. Use current web evidence before adding analysis or pickup recommendations. Use established session context (call get_user_session only if needed), then get_league_info for the selected league; fan out once per league for comparisons. Requires authentication on ESPN/Yahoo; Sleeper uses the public API. Read-only. Current date is 2026-09-09. Hard stop: after satisfying a returned-list or field-explanation request, end the answer immediately after the requested facts. Remove every closing question or offer to do more work, including roster checks, lineup-fit checks, comparisons, rankings, recommendations, role or health analysis, trends, or outlooks; never append "if you want", "tell me which player", or a similar invitation unless the user's current request explicitly asks for that additional work.

Search for medical conditions, diseases, and health problems in ICD-11 (International Classification of Diseases, 11th Revision). Use this tool to: - Find ICD-11 codes for diagnoses - Search for diseases by name or keyword - Look up conditions in multiple languages Set `language` for WHO's official translations — e.g. `language: "pt"` searches and returns the official Portuguese (pt-BR) ICD-11 labels. Never machine-translated. Returns matching entities with codes, titles, and relevance scores.

Search for MeSH (Medical Subject Headings) descriptors. Use this tool to: - Find MeSH terms for indexing medical literature - Look up subject headings for PubMed searches - Find controlled vocabulary terms Set `language` to request NLM's official translations where they exist (e.g. `language: "pt"` for Portuguese labels); content is never machine-translated. Returns matching descriptors with MeSH IDs and labels.

Translates audio into English.

Translate a document into another language with the original layout and formatting preserved (DOCX, PPTX, XLSX, PDF, TXT, MD, SRT, VTT). The job runs immediately and returns a FREE preview of the first pages plus a secure Stripe checkout link — the full translated file unlocks after payment ($4.99, one-time, no account needed). Provide EITHER source_url OR base64_content, plus a filename with extension.

Describe what you want done to a file in plain language — e.g. "translate this contract to German", "pull every table out of this PDF into Excel", "shrink this video to under 25MB", "convert this to PDF". The instruction is routed to the right job automatically; if the request is not supported yet you get an honest explanation of what is. Provide EITHER source_url OR base64_content, plus a filename with extension.

Check the status of a previously submitted file job (translate_file, extract_tables, compress_file). Returns the current status, preview + checkout link for completed paid jobs, or the download URL for completed free/paid-and-unlocked jobs.

Create a shareable Word Aligner diagram that shows which words match across two or more stacked lines of text (a translation and its source, an interlinear gloss, IPA, etc.). Returns a URL that opens the interactive diagram, plus a preview image. Use this when the user wants to translate a phrase and show word correspondences, align a translation with its source (including RTL scripts like Hebrew or Arabic, or vertically written ones like Japanese and Mongolian), or build a Leipzig-style interlinear gloss. Word indices are 0-based token positions. Tokenize each line the same way the tool does before assigning indices: - Whitespace always splits ("I have been going" -> I[0] have[1] been[2] going[3]). - The characters in settings.tokenSplitChars (default ".-|") also split and are then removed from the rendered text, so "go.PST.IPFV" becomes three tokens (go, PST, IPFV) and the dots disappear. For Leipzig glosses set tokenSplitChars to "-|" to keep the dots. - Punctuation stays attached by default ("Hello, world!" -> Hello,[0] world![1]). - In RTL lines, word 0 is the logically first word (rightmost on screen); index in reading order. - Japanese and Chinese are written without spaces and nothing is segmented for you: put spaces where the alignment units should be. For a vertically written script set settings.axis to "columns". Every line then becomes a vertical column and the connectors run sideways. Set orientation per line: "vertical" stacks the characters (Japanese, Chinese), "sideways" rotates the line a quarter turn (traditional Mongolian, and Latin runs inside vertical text), "upright" leaves a translation as horizontal word boxes. The first line is the leftmost column, so for Japanese and Chinese, whose columns read right to left, list the translation first and the script second. Each alignment is [lineA, wordA, lineB, wordB]; the two lines must be neighbours in the stack (|lineA - lineB| = 1), which means one above the other in rows and side by side in columns. To express many-to-one, list each target word as its own tuple. Tokens that share a connection group get the same color automatically.

Translate a PowerPoint (.pptx) deck preserving all formatting. $0.02/slide. Supports 32 languages (Latin, Cyrillic, Greek scripts). Provide job_id (from a previous create_slide/create_deck), pptx_url, or pptx_base64.

Upload assets for PowerPoint (.pptx) generation: company template, logo, image, or document — or AI-generate an image. Purposes: • logo — company logo for chrome (PNG/JPG/SVG, max 5MB) → logo_id • image — image for the Image component (max 10MB) → asset_id • theme — company template PPTX → theme_id; slides with it render NATIVELY on the template (masters/layouts/chrome) • generate_image — AI-generate via `prompt` → asset_id ($0.05) • translate — PPTX to translate → deck job_id ($0.02/slide; requires `target_language`) • pdf — PDF → editable slides; pass `target_language` to also translate • recreate — image OF a slide → editable PPTX slide ($0.10; honest annotate/preserve fallback, refusals free). Use `image` to just place a picture Files >3MB (pdf/translate/theme) — and recreate on chat hosts — omit `data`: a drop-zone appears in the result card; bytes never pass through the agent.

Fetch Chainstack's public pricing and return a normalized snapshot. Use this to answer pricing questions before quoting the user: plan fit, overage math, per-chain dedicated-node costs, and add-on pricing (Unlimited Node flat-fee tiers, Yellowstone gRPC streams, Warp transactions, dedicated-node base rates). This tool returns the menu, not the bill — the calling agent does the arithmetic. All prices are list prices in USD; disclaimers are surfaced in the `disclaimers` field. Design: we pass pricing.md through as raw markdown. Marketing owns that file and its structure changes freely; parsing it server-side would couple us to heading text and table column names we don't control. The LLM reads markdown natively, so handing the raw text to the agent keeps us correct regardless of how the page is restructured. pricing_current.json is parsed into `dedicated_catalog` because it has a stable engineering-owned schema, and the catalog benefits from filtering (to user-orderable SKUs only), unit conversion (cents → USD, milli-cores → cores), and region humanization (via `region_legend`). Per-method RU billing rules are NOT in these sources. Plan-level rates (Full Node = 1 RU, Archive Node = 2 RU) are in the markdown, but some EVM archive-state methods (eth_getBalance, eth_call, eth_getProof, eth_getStorageAt, eth_getCode, eth_getTransactionCount, eth_callMany, eth_createAccessList) and all debug_* / trace_* methods are billed at 2 RU on a full node when called against old blocks. For method-level detail, call `search_docs` with "request units" or `get_doc_page("docs/request-units")`. No API key required — sources are fully public. Each call fetches both sources fresh (no caching), so a stale result isn't possible. Returns: A dict with fields: - `pricing_markdown`: raw markdown from chainstack.com/pricing.md. Read this for plan tiers, feature matrix, add-on pricing, support levels, PAYG details, and provider comparisons. - `dedicated_catalog`: user-orderable per-chain dedicated-node SKUs with flavor, regions (as infra slugs like "sgp1"), hourly and monthly prices in USD. Already filtered to the ~87 orderable SKUs and unit-converted. - `region_legend`: slug → human city name map covering every region slug that appears in `dedicated_catalog`. Use `region_legend[slug]` to translate for display; `regions` keeps the slug as the canonical identifier. - `disclaimers`: list-price caveats (Enterprise "from" pricing, etc.). - `sources`: URL + ok/error per source; the JSON source carries its own `updated_at`. - `warnings`: populated when a source is unreachable or the JSON parser failed. The tool still returns best-effort results. - `fetched_at`: UTC timestamp of this call.

Search the Charity Commission register of England and Wales by name or keyword. Returns matching charities with registration number, status, and registration date. Use charity_profile for full details once you have the charity number. The upstream `searchCharityName` endpoint returns the full list in one shot — pagination is applied client-side via offset/limit. A query that matches nothing is a successful empty result (`charities: []`), not an error — the upstream endpoint signals "no matches" with an HTTP 404, which is translated back into an empty result here rather than surfaced as a not-found failure.

Anchor agentic tool for Cat-12. Translate AML/BSA program controls, TM rules, and customer risk policy into a structured Policy Mandate JSON for agentic payment sy Browser-based, client-side only. Zero PII. Link users to https://ainumbers.co/tools/131-ap2-aml-mandate-builder.html for interactive use. Renders the interactive AINumbers tool as a widget; inputs are applied via the AIN Bridge and the tool runs client-side (zero PII, zero network).

Translate a plain-language question into a candidate SQL query using pattern-matching against the live schema (no AI model — simple questions only: counts, averages, filtered selects on a named table). Returns the SQL without executing it, with a confidence score; low confidence means the table was guessed. Review the statement and tables_used, then run it with scalix_db_query. For complex questions, read scalix_db_schema and write the SQL directly.

Find the right ReefAPI engine for a task — pass ENGLISH keywords or a short natural-language use-case ("detect a website's tech stack", "company reviews", "check a package for vulnerabilities", "is this domain available"). The catalog is in English: if the end-user asked in another language, translate their INTENT into English keywords first (you are an LLM — do this inline). Ranks engines by how well the query matches each engine's name/title/category/ACTION descriptions (stem-matched, so plurals/word-forms still hit). Empty query = list all. Returns name/title/category/actions + match score. Call this FIRST, then get_engine_schema(engine) to pick an action. This is a fast keyword pre-filter — if the right engine isn't in the results (or you want to be sure), call get_catalog and pick from the full list YOURSELF (you semantically match any language/phrasing better than keywords).

Look up the geologic time scale — eons, eras, periods, epochs, and ages with their absolute-age boundaries in millions of years (Ma) and nesting. This is the reference that grounds every temporal filter on the other tools and translates a named interval like "Late Cretaceous" to its 100.5–66.0 Ma boundaries (and back). Filter by a name substring, a Ma range (overlap match), and/or a level; call with no filters to browse the full scale. Browsing and every name on the bundled ICS international-scale snapshot are answered offline. A name the snapshot does not carry — the sub-stage and regional names that occurrence and collection rows report, such as "Late Maastrichtian" or "Lancian" — costs one PBDB lookup across its other time scales; the response names which source answered and which scale the interval belongs to.

Convert a bank statement PDF into structured data or a spreadsheet. When the user attaches a PDF in the conversation, it arrives automatically as pdf_file — never encode it yourself. Otherwise, pass pdf_url for a public HTTPS link. If your host has no way to reference the attached file at all (no pdf_file/pdf_url equivalent), call request_upload first and pass its upload_id here instead. The base64 pdf parameter is a last resort only, for a caller with no other way to reference the file. To convert several statements in one call, pass upload_ids (the array from a single request_upload call made with count set) instead of pdf/pdf_url/pdf_file/upload_id — mutually exclusive with those four. This batch form only ADMITS each file (queues it, or reports an already-completed duplicate) and returns immediately with a compact per-file status list plus a summary — it never waits for conversion, so call get_statement per document_id once ready rather than expecting inline results here. Returns accounts, transactions, and metadata. output_format "json" (default) returns the data inline, renderable in chat. The other formats (csv, xlsx, qbo, xero) return a time-limited download link instead: present it as a normal link. Every response includes a "summary" field: use it as the single source of truth for what happened. If the conversation is not in English, translate it faithfully into the conversation language; never add details it doesn't contain. Never echo raw status values (e.g. "completed") or field names. Consumes credits (1 per page). Page limit depends on your plan.

Fetch the full converted data for a previously processed document. Use this after convert_statement returns a "processing" status, or to re-fetch results. output_format "json" (default) returns the data inline, renderable in chat. The other formats (csv, xlsx, qbo, xero) return a time-limited download link instead: present it as a normal link. data_mode selects which projection of the data you get: omit it for each output_format's existing default behavior. "normalized" is the cleaned, interpreted view; "original" includes each transaction's raw column values exactly as printed on the source PDF (originalData); "enhanced" is a reformatted view of the original columns (csv/xlsx only for now). Fetch data_mode: "original" when you plan to submit results to evaluate_benchmark — pass its originalData through verbatim; an absent originalData scores that benchmark's raw-fidelity dimension 0 for this document. Every response includes a "summary" field: use it as the single source of truth for what happened. If the conversation is not in English, translate it faithfully into the conversation language; never add details it doesn't contain. Never echo raw status values (e.g. "completed") or field names.

Register this agent on Agent Guild so others can find and vouch for you. Free, and you only need to do it once. Returns {id, did, api_key, capabilities, next_step}. SAVE the api_key — it is secret and signs every attestation you write. Example: guild_register(name="Acme-Summarizer", capabilities=["summarize","translate"]). If an offer led you here, pass its tag as `src` (e.g. src="passport_offer:mcp") so the follow is attributable. Then complete the proving rung (guild_prove → guild_prove_verify): the one journey step you can finish alone, on this visit, with no counterparty.

Translate identifiers across databases via UniProt's ID-mapping service — gene names to accessions, accession to PDB / Ensembl / RefSeq / ChEMBL / GeneID, and back. The job runs asynchronously; this tool submits it and polls within a budget. A running job returns status "running" with a ticket; pass that ticket alone to poll the same job. A completed call returns status "finished" with one results page; when continuation is present, pass it alone to fetch the next completed page without re-submitting or polling the job. A gene name often maps to one reviewed Swiss-Prot accession plus dozens of unreviewed TrEMBL ones, so target UniProtKB-Swiss-Prot (reviewed only) for the usual intent, or UniProtKB / UniProtKB_AC-ID to include TrEMBL. Pair a gene-symbol from_db with tax_id to disambiguate species. Chain the resulting accessions into uniprot_get_entry.

Get everything needed to make a monitor actually report: the ping URL, copy-paste check-in snippets, and the three MECHANISMS for reporting, returned together. Call this right after create_monitor. CHOOSE BY WHAT THE MONITORED THING IS — read `reporting_options` first and pick by that, rather than defaulting to the raw curl list: `how_to` — the manual protocol — is the UNIVERSAL path: it works in any agent, any language, any tool, with no prerequisite, so it is the default choice for any agent this applies to. Pair it with expect_every_s (the silence floor, set via update_monitor) so an agent that quietly stops reporting opens a detected incident instead of leaving its monitor reading healthy. If you ARE Claude Code specifically, `hook_install` is available as an OPTIONAL SHORTCUT, not a better tier: a one-time install that binds reporting to Claude Code's own hooks (UserPromptSubmit, Stop, StopFailure), automating how_to's exact same protocol so reporting becomes a property of your event loop instead of something you must remember — and it is the only mechanism that can send every state this product models, including blocked and note. hook_install is Claude Code specific: if you are a DIFFERENT AI agent — even one with its own hook or event system, Cursor, Windsurf, Codex, a custom framework — do NOT translate its steps into your own hooks; the event semantics differ and a translated install can pass its own verification while never reporting, so use `how_to` instead. If what you are monitoring is launched as a command instead — a cron job, a CI step, a script, or an agent started from a shell — use `run_wrapper`: wrap the command with `lastping run` and a separate process reports for you, so nothing has to be remembered; the tradeoff is that it reports the process's own lifecycle (start, success, fail, cancel) and has no way to send blocked or note. Whichever you choose, the underlying protocol is the same: the success ping at the END of the work, the fail URL if it failed, the start ping first for long or possibly-hung runs (this enables overrun / never-finished detection), and a step (curl_step) as each stage completes so a run that wedges mid-way is caught by name rather than only when its whole budget expires. Also read `expectations_how_to`: before you start work, use declare_run_expectations to say how THIS run should be judged when it closes — a one-time, unchangeable commitment that replaces the run grading itself. And `discovery_how_to`, which is about the OTHER jobs on this host or in this repo: how to find the scheduled work nobody is watching yet and propose it, rather than monitoring only the one thing you were asked about.

Create a Lightning invoice to pay for one AI service call. Returns JSON: { paymentId, invoice (BOLT11), amount (sats), expiresAt }. Each payment covers exactly one tool call — call this once per operation. Typical flow: list_models → create_payment → check_payment_status → call tool. The invoice expires in 10 minutes. Call list_models first to discover modelId values. modelId is optional — omit it to use the default (best) model. Some tools require extra params at payment time because pricing depends on them: generate_text requires prompt (price = f(char count)); text_to_speech requires text (price = f(char count) by tier); transcribe_audio / transcribe_translate take durationMinutes (10 sats/min — declare your audio length, default 1); send_sms, place_call, ai_call require phoneNumber; generate_video and animate_image require duration, and take an optional resolution (250-400 sats/sec by resolution — quote with the SAME duration and resolution you will execute with); edit_image requires resolution (1K=200, 2K=300, 4K=450 sats); epub_to_audiobook requires characterCount (total text characters in the book — price is per-character by voice tier, minimum 500 sats). If required params are missing, the response includes an error with the missing field names.

Compound endpoint — one payment turns audio in any of 13 source languages into both a transcript AND a translation in any of 119 target languages. Perfect for WhatsApp voice messages in a language you don't speak (Yoruba → English), or recording a meeting in another language and reading it in yours. Auto-detects source if omitted. Async — returns requestId, poll with check_job_status(jobType='transcribe-translate'). Flat price covers STT + translation. Cheaper than calling transcribe_audio + translate_text separately for typical voice messages. Pay with Bitcoin Lightning — no API key or signup needed. Requires create_payment with toolName='transcribe_translate'.

Translate a whole EPUB into another language and get an EPUB back. Every chapter is translated with its markup intact — headings, emphasis, footnote links, images and code stay where they were — the package language is retargeted and the table of contents is translated. 119 target languages; the target language picks the engine and the engine's row carries the price (same per-character rate as translate_text for that language, min 50 sats). Async — returns requestId, poll with check_job_status(jobType='translate-epub'), then get_job_result for the download url (temporary, 6h). Pay with Bitcoin Lightning — no API key or signup needed. Requires create_payment with toolName='translate_epub', characterCount (visible characters of the book) and targetLanguage; the real file is re-priced at execution and a short-pay is refunded with the exact amount to re-pay.

Translate text across 119 languages with high accuracy. The target language picks the engine: GPT-OSS 120B by default, or a higher-scoring model (Gemini) where one measurably beats it. Auto-detects source language. Privacy-preserving: no data stored. Pricing: 1 sat per 1,000 characters on the standard engine, minimum 1 sat per request; a routed language costs more. GET /api/languages returns the exact price, engine and measured chrF for every language, and the 402 always quotes the real amount before you pay. Language parameters accept English names ('Spanish', 'Chinese (Simplified)') or ISO-639 codes / locale tags ('es', 'en-US', 'pt-BR', 'zh-Hans'). Supported languages: Afrikaans, Albanian, Amharic, Arabic, Armenian, Assamese, Azerbaijani, Basque, Belarusian, Bengali, Bosnian, Bulgarian, Burmese, Catalan, Cebuano, Chichewa, Chinese (Simplified), Chinese (Traditional), Corsican, Croatian, Czech, Danish, Dari, Dutch, English, Esperanto, Estonian, Farsi, Fijian, Filipino, Finnish, French, Frisian, Galician, Georgian, German, Greek, Guarani, Gujarati, Haitian Creole, Hausa, Hawaiian, Hebrew, Hindi, Hmong, Hungarian, Icelandic, Igbo, Indonesian, Irish, Italian, Japanese, Javanese, Kannada, Kazakh, Khmer, Kinyarwanda, Korean, Kurdish, Kyrgyz, Lao, Latvian, Lingala, Lithuanian, Luganda, Luxembourgish, Macedonian, Malagasy, Malay, Malayalam, Maltese, Maori, Marathi, Mongolian, Nepali, Norwegian, Occitan, Odia, Pashto, Polish, Portuguese, Punjabi, Romanian, Romansh, Russian, Samoan, Scots Gaelic, Serbian, Sesotho, Setswana, Shona, Sindhi, Sinhala, Slovak, Slovenian, Somali, Spanish, Sundanese, Swahili, Swedish, Tajik, Tamil, Tatar, Telugu, Thai, Tigrinya, Tongan, Turkish, Turkmen, Ukrainian, Urdu, Uzbek, Vietnamese, Welsh, Wolof, Xhosa, Yiddish, Yoruba, Zulu. Pay per request with Bitcoin Lightning — no API key or signup needed. Requires create_payment with toolName='translate_text' and prompt (the text to translate).

Ask a frontier AI a question in your OWN language and get the answer back in that same language, in ONE payment. We translate the question to English, answer it with a frontier model, then translate the answer back. Two engines behind one endpoint: 119 mainstream languages use the LLM translate tier; anything those models do not serve falls through to MADLAD-400 on our own GPU (452 languages, 251 of which ChatGPT, Claude and Gemini do not support at all). So a Wolaytta, Tiv or Q'eqchi' speaker gets frontier reasoning in their own language, which no other API offers. Rare-language quality is uneven and published per language - GET https://sats4ai.com/api/languages. Priced from question length plus a fixed 2000-character answer allowance at the chosen tier's rate; the rare-language path costs more (GPU both ways). Requires create_payment with toolName='multilingual_ask' AND the `language` you intend to use - the quote depends on it.

Translate into 452 languages, 251 of them NOT supported by ChatGPT, Claude or Gemini (29 of those 251 measured at fair quality or better against human references) — including Bhojpuri (~50M speakers), Maithili (~34M), Egyptian Arabic (~100M), Moroccan Arabic (~30M), Chhattisgarhi, Magahi, Manipuri, Kashmiri, Shan, Kachin, Awadhi, Tamazight, Crimean Tatar, Quechua, Nuer, Sango, plus indigenous and minority languages with no callable API anywhere. Runs MADLAD-400 (Apache-2.0). QUALITY VARIES AND IS PUBLISHED PER LANGUAGE: every language carries a measured tier — good (chrF++ >= 45 vs human reference translations), fair (32-45), unverified (no benchmark exists, untested, may be poor), experimental (known weak). The response repeats the tier so you can judge how much to trust it. GET https://sats4ai.com/api/l402/translate-rare-language for the full language list with tiers, or GET /api/languages. Unsupported languages are rejected BEFORE payment. For mainstream languages use translate_text instead — it is cheaper and more fluent. Priced 50 sats base + 0.002 sats/char (GPU). Pay with Bitcoin Lightning — no API key or signup. Requires create_payment with toolName='translate_rare_language'.

Real-time solar wind measurements from the active spacecraft at L1: proton speed (km/s), density (n/cm³), temperature (K), and the critical Bz component (southward Bz = negative = storm driver). Returns the recent plasma and magnetic field time series within the requested window, oldest first, each record tagged with the reporting spacecraft. Bz < −10 nT for sustained periods is a primary geomagnetic storm trigger — use alongside noaa_spaceweather_get_kp_index to see whether elevated solar wind has translated into a geomagnetic storm.

Check Python source without running it: parse, lint (ruff), type-check (mypy), AST security policy, credential scan. Safe on code you do not trust. Use it on every Python file you generated or edited, before writing it to disk. Alternatives: repair_python to get the corrected source instead of the diagnosis; execute_python to prove the code runs. Auth: a key is required. A free key covers this call, 25 per day, then HTTP 429; get one with POST /v1/keys. Credits are bought without an account, 1 per call: GET /v1/pricing says where to send the xDAI. Or pay for this one call with no key at all: call it without one and the result carries x402 payment requirements ($0.01 in USD Coin on eip155:8453); sign them and repeat the call with the payment in _meta['x402/payment']. Arguments: code: the whole file, 1..200000 bytes of UTF-8 measured after encoding (empty is refused with 400, larger with 413); a fragment is fine, but line and column numbers in the answer count from 1 in what you sent. language: must be 'python'; anything else is 400, and the field may be omitted. Of options only transpile_to (e.g. 'javascript', which returns a translated copy in transpiled) acts here; timeout_s, max_iterations, optimize, examples and expected_output need a pass that rewrites or runs the code, so send code alone. Ignored options are not refused, so a call that sets them looks like it worked; and code that does not parse is answered rather than refused: valid=false with the syntax error located, which is the point. Returns valid, score 0..1, diagnostics (rule, message, line, column), security findings, fixes, fixed_code and runtime; see outputSchema. The code and its verdict are retained to improve the service.

Reposition an existing item to a new (x, y) without retyping its content. Works for every item kind: `text` and `link` set the top-left to (x, y); `line` translates every point so the stroke's bounding box top-left lands at (x, y); `image` sets the top-left like text. `kind` defaults to `text` for backward compat with older callers. Find the id + kind via `get_board`. Prefer `move` over re-creating an item when only the location changes — it preserves the id, content, author and avoids a round-trip of base64 bytes for images.

Returns the PDF templates a NIF can be rendered with. For each one, the `code` to send as `template_type` in `PUT /v1/companies/{company_id}/invoice-customization`, plus a name and a short description translated into the language of the user the credential belongs to. The accepted values are already in the `template_type` enum; what this operation adds are the readable labels, so you do not have to show `MODERN_TABLE` to a person. The catalogue is identical for every account and every NIF, so it is not nested under one. **Closed catalogue.** This collection is fixed and bounded: it carries no `pagination`, it takes no `page`/`limit`, and every response holds the whole set. Endpoint: GET /v1/invoice-customization-options

Writes the CAST for an AI Video Story series - named characters with a role and a one-line description each - and returns it as a DRAFT for the user to read. FREE: this call spends no tokens. It generates no portraits and saves nothing to the user's character library. WHAT IT ACTUALLY RUNS: a showrunner model reads the series and the idea you passed and answers with the cast that idea needs - who those people are, how they relate, what species the series casts them as. IT DOES NOT WRITE THE STORY. When you pass an `idea`, the response's `idea` field is the one you sent, unchanged (translated into the output language if it was in another one); the plot is written later, by `generate_story_video`. If you pass NO `idea`, the call authors a logline itself and the `idea` field is that logline - the only case where it comes back with something you did not send. Same call the webapp's cast step makes. Nothing is charged for any of it. WHEN: as soon as the episode idea is settled, on a series whose `cast.required` is true (or whose user wants custom characters). Do NOT ask permission first - it costs nothing, and the webapp writes this roster automatically at the same point. A series with `cast.writer_owned: true` casts itself at episode-write time; never call this for it. AFTER: show the user the names and roles, one short line each - the cast is the whole review. Do NOT present the `idea` field back to them as news when you passed one in: it is their own idea and saying otherwise invents a change that did not happen. The one exception is the no-idea call, where the `idea` you get back IS the logline the writer chose and the user has not seen it yet - show them that one and ask whether to keep it. If they dislike the roster, call this tool AGAIN with a sharper `idea` - a re-draft is free and replaces it, exactly like the webapp's 'Rewrite cast'. Never buy portraits for a cast the user has not accepted. THE PRICE OF THE NEXT STEP RIDES THIS RESPONSE: `portraits_needed` is how many faces are missing - it counts exactly the members whose `needs_portrait` is true, because a preset-bound member arrives photographed and costs nothing - and `portrait_models` lists every image model that can draw them, each with `per_portrait_tokens` and the roster's `total_tokens` on it (the `default: true` entry is what the series is tuned for). Use those numbers verbatim in the message where you ask for the go - do not multiply anything out yourself. THEN: `generate_cast_portraits` with this response's `draft_id` mints the portraits. That call is the money. The draft stays redeemable for about two hours; after that write a fresh one (free). NOT ON THIS SURFACE (the aicut webapp owns them today): renaming a cast member, adding your own character, and adding one from a photo. Say so if the user asks - do NOT re-draft the whole cast to work around a single member, and do not try to steer one member by rewording the idea. CHANGING what a member IS is available once the portraits are bought: `describe_cast_member` rewrites one member's look for one portrait's price. REFUSALS you act on, all 400 `invalid_request` except the last two - the message says which: the series is unknown or unavailable; the series SHIPS ITS OWN FIXED CAST, so there is no roster to write and none to buy; the series casts itself at episode-write time (`cast.writer_owned` on `list_series` predicts this one); or the series does not support a cast-first flow at all. In every one of those, go straight to `generate_story_video` without a cast rather than retrying with different wording. 429 `utility_rate_limited` / `utility_globally_limited` = this call is FREE but not unlimited - it spends a rate-limited AI-writing allowance shared with the webapp, and the answer is to wait the `retry-after` (about a minute for a burst, a rolling day for the account's daily cap), never to top up tokens. 503 `casts_unavailable` = transient, try again. BREVITY: lead with the ONE decision you need from the user, and keep at most one short paragraph before the question. Never re-explain the staged flow (cast -> frames -> fire -> render) once it has been explained in this conversation - after that, name only the next step. When suggesting episode ideas, offer at most 3, one line each. OUTPUT: this returns JSON for you to read. When you report back to the user, give them the media URL plus a one-line summary. Do not paste the raw JSON, job ids, or internal field names into the conversation.

CHANGES WHAT HAPPENS IN ONE SCENE of an AI Video Story episode parked at frames review, and redraws that scene's opening picture from the change. You pass a PLAIN SENTENCE saying what should be different - 'the kid should look super sad', 'move it outside at night', 'she should be holding the letter' - and aicut rewrites that scene's own setting / people / action text from it and draws the new picture. Costs ONE image generation. The change STICKS: the scene video generated at fire is made from the changed scene, not just the picture. WHAT IT CAN CHANGE, AND WHAT IT CANNOT - check the user's ask against this BEFORE you call. IT CAN change the scene's SETTING (where and when it happens), its ACTION (what happens) and WHO IS IN FRAME. IT CANNOT change the SPOKEN LINES / dialogue, the scene's LENGTH, or a scene pinned to a reference still - all three are the aicut web editor's (aicut.pro). An instruction that is ONLY about what somebody SAYS ('change her line to ...', 'he should say it differently', 'make the dialogue shorter') is REFUSED here: 400 `dialogue_only`, nothing written and nothing charged - tell the user the dialogue is edited in the aicut web editor and offer a visible change instead. An instruction that MIXES a line with a visible change ('change his line and move it outside at night') applies the VISIBLE half only, and the response says so - relay that; do not let the user believe the line changed. REPORT WHAT CHANGED, VERBATIM. The response carries `changed` - which of the scene's parts actually moved, and it can be `[]` - and a `report` sentence. RELAY THE `report` AS IT IS WRITTEN rather than narrating a success: an empty `changed` means this call moved NOTHING about the scene, and the new `image_id` on that answer is not evidence that it did. This exists because it went wrong on a live episode: a spoken line was asked for, this tool answered with a fresh picture, the agent reported it as done, and the line was word for word what it had been. THIS IS THE TOOL FOR 'change scene 2, X should be Y'. It is NOT `regenerate_story_frame`, which draws the SAME scene again from the SAME text - another attempt at the picture that is already wrong - and it is NOT a reason to start the episode over. If the user does not like the PICTURE (bad hands, odd framing, a face that came out wrong) that is a redraw; if they do not like WHAT IS HAPPENING, it is this. YOU DESCRIBE THE CHANGE, AICUT WRITES IT (hard rule, the same one as everywhere else on this surface): you never author scene text, image prompts or episode JSON. There is no field here for a prompt, a setting or an action - only the sentence. Pass the user's own words, tidied into one sentence; do not translate them into scene-writing vocabulary, and do NOT read the rewritten text back to them - apply the change and show them the new picture. WHEN: `get_video` shows `story.stage: "frames_review"`. `scene_index` is that scene's `scene_index` from `story.frames`, zero-based - the card and the user count scenes from ONE, so 'scene 2' is the SECOND entry in `story.frames` and you pass THAT entry's `scene_index`. Each frame carries the scene's `summary` (what happens) and `dialogue` (what is said), which is what you check the user's ask against before you spend. AFTER: returns `image_id` with status `generating` and `changed` naming which parts of the scene moved. THIS CALL OPENS ITS OWN CARD, which shows the episode's scene rows with that scene marked as redrawing and fills the new picture in by itself - so do NOT call `show_generation` afterwards to put a fresh set of rows up, and do not narrate the wait. Poll `get_video` only if you need the outcome in your own answer: the lane's `regenerate` entry shows the redraw, and once it succeeds the frame's `url` IS the new picture. CHECK `attached`: if it comes back `false` the image still generates and is still CHARGED but will NOT replace the frame at fire - say so and redraw that scene before firing. IF THE PICTURE FAILS OR THE ACCOUNT RUNS OUT (402) THE SCENE HAS ALREADY CHANGED: the response carries `changed_text: true`. The episode HAS the new beat and is still showing its old picture - say that plainly, it is not lost work, and `regenerate_story_frame` draws the new one for one image's price. Do NOT send this tool again to 'fix' it, which would rewrite an already-correct scene and buy a second picture. IF THE ANSWER CARRIES `changed_text_unknown: true`, AICUT DOES NOT KNOW WHETHER THE SCENE CHANGED - and neither do you. It is NOT a success and NOT a confirmed change: the call failed somewhere aicut could not read the outcome. Never report it as done and never immediately re-send the change (that would apply it twice). Say plainly that it could not be confirmed, then CHECK: call `get_video` and read that scene's `summary` in `story.frames`. If it does not carry the change, send this tool again; if it does, the scene has the new text with its old picture, so `regenerate_story_frame` draws the new one. `changed_text: true` is the only field that means the change landed - its absence is never evidence either way. REFUSALS you act on (the common ones - always read the `code` you actually get): 400 `dialogue_only` = the ask was only about the spoken lines, which this tool does not own - nothing was written and nothing was charged; say that plainly and point at the aicut web editor. It comes back from an `estimate_only` call too, in place of a price. 409 `frame_regenerating` = this scene already has a redraw running, wait and poll `get_video`. 409 `already_fired` / `not_ready_to_fire` / `not_in_review` = the review window is closed or the frames are still generating; a fired episode's scenes are edited in the aicut web editor. 400 `invalid_request` = an invalid or REMOVED scene, an empty or over-long `change`, or a scene whose text cannot be changed here - a scene built from a reference still, and series that write their scenes from a fixed template, both refuse and the message says which. 402 = not enough tokens (see the line above - the text changed anyway). 429 `utility_rate_limited` = the rewriting allowance, not tokens: wait the `retry-after`. 503 `story_unavailable` = transient, try again. COST: one standard image generation, at the series' RESOLVED start-frame model - the same number `regenerate_story_frame` costs, which is the series' `pricing.frame_regen_tokens` on its FULL `list_series` entry (the `series_id` call). `estimate_only: true` is the exact figure and it spends no tokens and changes NOTHING - it does not rewrite the scene. PASS THE REAL `change` WITH IT: a quote that carries the change also checks the instruction and the scene, so an ask this tool cannot carry out comes back as its refusal (`dialogue_only`, or the `invalid_request` for a reference-built scene or a series that writes its own frames) BEFORE you ask the user to approve a spend, instead of after. A quote can still price an ask the paid call then refuses - the check is best-effort and never withholds a number - so a refusal after a go is not a contradiction. That check is a rewriting-allowance call, not a token spend, so a quote can answer 429 `utility_rate_limited`. State the figure before you ask for the go, every time. THE GO THIS ONE NEEDS: one change, one named scene, one priced ask - and the user has to say which scene and what should be different. A complaint ('scene 3 is wrong') is a reason to ASK what should change and OFFER this with its price, never a go to buy it, and a bare 'yes' counts only when your priced ask for THAT scene's change was the message immediately before it, nothing else was raised in between, and nothing the user asked for earlier is still outstanding. Never change more scenes than the user named. Changing a scene is also NOT firing. SPEND ETIQUETTE (the money grammar): in the webapp the priced button is the user's own finger; in chat YOUR tool call is not - so state the price IN THE SAME MESSAGE as the ask, and the user's explicit go is the button press. Never charge on inference: quoting is not asking, and after a price you wait for the yes. THIS APPLIES TO EVERY TOOL CARRYING THIS NOTE, including this one. A GO IS SCOPED TO ONE PURCHASE, AND IT MUST BE UNAMBIGUOUS. The user's instruction has to NAME the thing you are about to buy, or refer to it so plainly that it cannot mean anything else. A BARE AFFIRMATION - 'go', 'yes', 'ok', 'do it', 'just do it', 'sure' - counts ONLY when ALL THREE of these hold: the message immediately before it was YOUR priced ask for THAT EXACT action, nothing else was raised in between, and NOTHING THE USER ASKED FOR EARLIER IS STILL OUTSTANDING. That last one is the trap the others miss: if the user's OWN previous turn asked for something else - a refusal, a different scene, an edit, a redraw, a question - their 'just do it' may be answering THAT, and it is AMBIGUOUS even when your priced ask happens to be the last thing said in the thread. An ambiguous affirmation is not a go: ask WHICH one they mean and state that price again. WHEN IN DOUBT ABOUT WHAT A 'GO' REFERS TO, ASK. A wrong guess spends the user's money on something they never asked for, and nothing on this surface can undo it or give it back - asking costs one sentence. An episode's STAGES - cast portraits, episode create, fire, render - are each their own priced ask. A STANDING GO IS NOT UNLIMITED: 'just make it' or 'go ahead with the whole episode' authorizes the stages you PRICED IN THAT SAME MESSAGE, in the order you named them, and nothing beyond them - so do not re-ask per stage while it holds, and do not stretch it over a stage whose price the user never saw. IT EXPIRES THE MOMENT THE USER RAISES ANYTHING ELSE - a change, a question, a refusal, a redraw, a new idea - and after that the next stage needs its own priced ask. ONE STAGE IS NEVER COVERED BY A STANDING GO AT ALL: the FIRE (`fire_story_video`) is irreversible and the biggest single charge in the episode, so it always takes a go that NAMES firing, whatever was said earlier - see that tool's own note. A REDRAW IS NOT A STAGE: `regenerate_story_frame` and `regenerate_cast_portrait` are extra spends the user asks for one at a time, so state that price every time, even under a standing go. A standing go never carries to a different episode, and never to `generate_video`, `generate_image` or `generate_audio` - each of those is its own ask. ACCOUNT FOR YOUR OWN CALLS: if the user says something happened that you did not intend - a charge they did not expect, a step they did not ask for - RE-READ YOUR OWN TOOL CALLS IN THIS CONVERSATION before you answer, and tell them plainly which tools you called and when. NEVER SPECULATE ABOUT A CAUSE YOU CANNOT OBSERVE: not a button on an aicut card, not the user's own click, not their client. The aicut cards CANNOT SPEND - the only tools they ever call are the reads (`get_video` / `get_image` / `get_audio`), and their buttons either save a file or send a VISIBLE user turn into the chat - none of them calls a spending tool - so saying a card might have generated or charged something is false, not a hedge. (If a spend followed one of those visible turns, it was still YOUR call, and the honest answer names it.) If your call history disagrees with what you told the user, say what you actually called and let them correct you; do not invent an explanation that makes the two agree. IDEMPOTENCY: `idempotency_key` is optional and makes a retry safe. Set it on the FIRST call, not only on a retry - the job is addressed by the key, so a key added afterwards cannot find a job that was created without one. Reusing a key REPLAYS the job that key already created and returns it unchanged - even if you send a different prompt or different settings, and even after that job has finished. A key is therefore spent permanently. Do NOT reuse one to make another generation: two deliberate generations are two jobs and need two different keys (or none). ONE EXCEPTION, on `render_story_video`: replaying a key whose render FAILED answers 409 `render_failed` rather than replaying the failure, because a spent key stays spent - retry that one with a NEW key or with none. A KEY IS NOT SCOPED TO A TOOL: it addresses a job on the whole account, so reusing the key you gave `generate_video` on `generate_story_video` replays that first video instead of starting an episode. One key, one thing you made. (`render_story_video` is the one door that namespaces its own, which is why an episode's key can be reused on its render without colliding - but there is no reason to reuse it there either.) Never derive the key from the request body. You do NOT need to pass one to be safe against a duplicated delivery: aicut already derives a per-call key server-side, so a retry the transport makes on its own replays rather than charging twice. Pass your own only when YOU want to retry a call whose answer you never saw. OUTPUT: this returns JSON for you to read. When you report back to the user, give them the media URL plus a one-line summary. Do not paste the raw JSON, job ids, or internal field names into the conversation.

CREATES an AI image story: a narrated script turned into a sequence of AI-generated images, read aloud with captions over it. aicut's most-used format for facts, history, horror, storytime and explainer shorts. YOU WRITE THE SCRIPT, AND ONLY THE SCRIPT. The `text` you send is the narration that gets spoken, verbatim, in that order - there is no writer behind this endpoint. Draft it yourself from what the user asked for, show it to them as plain text before spending anything, and change it until they like it. Iterating on the script costs nothing. What you must NOT write is the pictures: aicut segments your script and writes every image prompt itself. A WORKED EXAMPLE of `text`: `"In 1943 a Soviet pilot was shot down behind enemy lines. He walked eighteen days through the snow on two broken legs. When he reached his own trenches, they did not believe he was alive. Then he asked for his plane back."` That is the whole format: a narration script in plain prose, the way it should be READ ALOUD. No scene numbers, no image directions, no stage notes, no speaker labels - aicut cuts it into scenes and writes the picture for each one. Write it the way a good voiceover sounds: short sentences, a hook in the first line, one idea at a time. PRICE IS DRIVEN BY THE IMAGE COUNT, not by the words. `estimate_only: true` returns `scene_count` and `voice_provider` next to the money - say the count and the price. The three levers, in the order to reach for them: `seconds_per_image` (3 is the default; 5 buys fewer images for the same script and is the cheap direction, 2 is the busy/expensive one), `image_model` (`zit-realism` is the cheap default; `nano-banana-pro` is roughly fifteen times the per-image price - offer it only when the user wants the best-looking result and say what it costs), and `voice_provider` (ElevenLabs reads best and costs about four times openai/polly per character of narration). Re-quote after changing any of the three; never carry an older number across a change. STYLES ARE OPTIONAL AND THEY ARE NOT FREE. `list_image_story_styles` returns aicut's authored looks; passing one as `style_id` forces the expensive edit-capable image model, so re-quote with `estimate_only` after adding one. Without a style you get aicut's default photorealistic look, which is what most videos use. AFTER: the response carries the job id, `scene_count`, the price split (`generation_tokens` for the images and narration, `render_tokens` for the video file) and `renders_automatically: true`. If it ALSO carries `start_confirmed: false`, the job exists but aicut never saw its start confirmed - do not create it again, watch that job id and tell the user it may need a retry if it has not moved in fifteen minutes. THERE IS NO FIRE STEP AND NO RENDER STEP: this one call makes the finished video. Wait for it with `wait_for_generation`; when it is terminal, `get_video` carries the file url. It takes longer than a single image - every scene is generated. LANGUAGE: write `text` in the language you name. aicut detects the script's language and TRANSLATES it when it differs from `language`, and a translated script has a different length - so the quote is exact for the script you sent and only for that. Do not send English and ask for German expecting the quoted price; write the German. REFUSALS (the common ones, not all of them - always read the `code` you actually get): 400 = the script or a setting is not accepted, and the message says which (a script over the language's character limit, which aicut will NOT silently cut for you; a script that needs more images than one video can carry, where the fix is a longer `seconds_per_image`; an unknown style id, model, voice or language). 402 = not enough tokens for the whole video; the body carries `required` and `balance`. 503 `image_story_unavailable` = the video was not started and nothing was charged; retry the same call once. THE WATERMARK is decided by the account's plan, not by this call: free accounts get the aicut mark on the video. Say so if the user asks; there is no argument that changes it. DELIVERY: hand the user ONE thing - the finished video. Do not re-list the script back at them after it is made. SPEND ETIQUETTE (the money grammar): in the webapp the priced button is the user's own finger; in chat YOUR tool call is not - so state the price IN THE SAME MESSAGE as the ask, and the user's explicit go is the button press. Never charge on inference: quoting is not asking, and after a price you wait for the yes. THIS APPLIES TO EVERY TOOL CARRYING THIS NOTE, including this one. A GO IS SCOPED TO ONE PURCHASE, AND IT MUST BE UNAMBIGUOUS. The user's instruction has to NAME the thing you are about to buy, or refer to it so plainly that it cannot mean anything else. A BARE AFFIRMATION - 'go', 'yes', 'ok', 'do it', 'just do it', 'sure' - counts ONLY when ALL THREE of these hold: the message immediately before it was YOUR priced ask for THAT EXACT action, nothing else was raised in between, and NOTHING THE USER ASKED FOR EARLIER IS STILL OUTSTANDING. That last one is the trap the others miss: if the user's OWN previous turn asked for something else - a refusal, a different scene, an edit, a redraw, a question - their 'just do it' may be answering THAT, and it is AMBIGUOUS even when your priced ask happens to be the last thing said in the thread. An ambiguous affirmation is not a go: ask WHICH one they mean and state that price again. WHEN IN DOUBT ABOUT WHAT A 'GO' REFERS TO, ASK. A wrong guess spends the user's money on something they never asked for, and nothing on this surface can undo it or give it back - asking costs one sentence. An episode's STAGES - cast portraits, episode create, fire, render - are each their own priced ask. A STANDING GO IS NOT UNLIMITED: 'just make it' or 'go ahead with the whole episode' authorizes the stages you PRICED IN THAT SAME MESSAGE, in the order you named them, and nothing beyond them - so do not re-ask per stage while it holds, and do not stretch it over a stage whose price the user never saw. IT EXPIRES THE MOMENT THE USER RAISES ANYTHING ELSE - a change, a question, a refusal, a redraw, a new idea - and after that the next stage needs its own priced ask. ONE STAGE IS NEVER COVERED BY A STANDING GO AT ALL: the FIRE (`fire_story_video`) is irreversible and the biggest single charge in the episode, so it always takes a go that NAMES firing, whatever was said earlier - see that tool's own note. A REDRAW IS NOT A STAGE: `regenerate_story_frame` and `regenerate_cast_portrait` are extra spends the user asks for one at a time, so state that price every time, even under a standing go. A standing go never carries to a different episode, and never to `generate_video`, `generate_image` or `generate_audio` - each of those is its own ask. ACCOUNT FOR YOUR OWN CALLS: if the user says something happened that you did not intend - a charge they did not expect, a step they did not ask for - RE-READ YOUR OWN TOOL CALLS IN THIS CONVERSATION before you answer, and tell them plainly which tools you called and when. NEVER SPECULATE ABOUT A CAUSE YOU CANNOT OBSERVE: not a button on an aicut card, not the user's own click, not their client. The aicut cards CANNOT SPEND - the only tools they ever call are the reads (`get_video` / `get_image` / `get_audio`), and their buttons either save a file or send a VISIBLE user turn into the chat - none of them calls a spending tool - so saying a card might have generated or charged something is false, not a hedge. (If a spend followed one of those visible turns, it was still YOUR call, and the honest answer names it.) If your call history disagrees with what you told the user, say what you actually called and let them correct you; do not invent an explanation that makes the two agree. IDEMPOTENCY: `idempotency_key` is optional and makes a retry safe. Set it on the FIRST call, not only on a retry - the job is addressed by the key, so a key added afterwards cannot find a job that was created without one. Reusing a key REPLAYS the job that key already created and returns it unchanged - even if you send a different prompt or different settings, and even after that job has finished. A key is therefore spent permanently. Do NOT reuse one to make another generation: two deliberate generations are two jobs and need two different keys (or none). ONE EXCEPTION, on `render_story_video`: replaying a key whose render FAILED answers 409 `render_failed` rather than replaying the failure, because a spent key stays spent - retry that one with a NEW key or with none. A KEY IS NOT SCOPED TO A TOOL: it addresses a job on the whole account, so reusing the key you gave `generate_video` on `generate_story_video` replays that first video instead of starting an episode. One key, one thing you made. (`render_story_video` is the one door that namespaces its own, which is why an episode's key can be reused on its render without colliding - but there is no reason to reuse it there either.) Never derive the key from the request body. You do NOT need to pass one to be safe against a duplicated delivery: aicut already derives a per-call key server-side, so a retry the transport makes on its own replays rather than charging twice. Pass your own only when YOU want to retry a call whose answer you never saw. OUTPUT: this returns JSON for you to read. When you report back to the user, give them the media URL plus a one-line summary. Do not paste the raw JSON, job ids, or internal field names into the conversation.

Live SEPTA bus and trolley vehicle positions for a route in Philadelphia — each vehicle with direction, destination, next stop, minutes late, estimated seat availability (crowding), and lat/lon. Buses use route numbers ("23", "47"); trolleys use SEPTA Metro codes T1-T5, G1 (Girard), D1/D2 (Media/Sharon Hill) — legacy trolley numbers like "10" are auto-translated to T1. Example: septa_bus_positions({ route: "23" })

Find AINSOF music from a written brief — mood, scene, genre, energy, instruments. Example: 'lo-fi hip hop underscore, warm, no vocals'. Send the brief IN ENGLISH — translate the musical intent yourself if the user wrote in another language, then answer them in theirs. Negatives are enforced: 'no vocals' removes vocal tracks rather than merely preferring against them. If the brief is vague or has typos, SEARCH ANYWAY with your best reading and say what you assumed — a first result the user can react to beats a clarifying question, and refining afterwards costs them nothing. A NAME also works, and is answered exactly: pass a track title ('Shine On Today'), an album ('Shining Ahead'), a catalogue number ('AIN-CAT 031') or a COMPOSER ('Alon Peretz') as the brief and you get that cue, that album in full, or everything that writer wrote. A composer named inside an ordinary brief puts their cues first without narrowing it. NEVER tell a user we do not have a track until you have passed its name here.

Use this when you need to convert text to speech audio. Returns base64-encoded MP3 audio in JSON. Returns: 1. audio (base64 MP3 data) 2. language used 3. textLength (character count) 4. durationEstimate in seconds 5. format (mp3). Example output: {"audio":"SUQzBAAAAAAAI1RTU0UAAAAP...","language":"en","textLength":45,"durationEstimate":3.2,"format":"mp3"} Use this FOR generating audio narration, building voice assistants, creating audio versions of articles, accessibility features, and language learning apps. Do NOT use for language detection -- use text_detect_language instead. Do NOT use for text translation -- use text_translate instead. Do NOT use for OCR from images -- use media_extract_text_from_image instead.