Check whether the Live Tennis API is reachable and which plan the configured key is on. Useful for diagnosing why other tools are refusing data.

API version reported by the health check.

Whether a key was supplied with this call.

Human-readable summary. Identical to the text content, so either half can be used alone.

True when the call returned data. False for a tier wall, a missing or rejected key, or an empty result — all of which are normal states with a clear remedy, not failures.

True when the API answered its health check.

Detected plan: FREE, BASIC, PRO or ULTRA. Null when no key is configured.

API status and plan

One player's whole career over the results archive (1968–2022): W-L record overall and by surface/level/year, titles, and summed serve statistics with honest coverage — the corpus records serve stats from 1991 only, so matches_with_stats states how many matches the serve block covers. The name must resolve to one person; an ambiguous fragment returns the candidate list to choose from. Requires the BASIC plan or any History plan.

Player name fragment, min 3 chars — must resolve to exactly one person.

Per-season W-L.

The resolved player.

The W-L record.

W-L per source tier code.

W-L per surface.

Career losses.

Finals won (excluding abandoned finals).

Career wins.

Summed serve stats + derived ratios. matches_with_stats states the coverage; ratios are null where the denominator is zero.

Career span inside the archive.

First archive match date.

Last archive match date.

Archive career aggregates

One result from the results archive (1968–2022), with per-match serve statistics where the era recorded them — stats are null for most rows before 1991, honestly, never synthesised. Requires the BASIC plan or any History plan.

Archive match id, as returned by search_archive_matches.

The archive result.

The tournament START date — per-match dates do not exist in this era’s records.

Archive match id. Pass to get_archive_match for the detail read with stats.

Source tier code: G, M, A, F, D, C, O, or a futures category code.

The loser.

name country rank seed player_id hand height_cm age entry

completed, retired, walkover, default or abandoned — parsed, null when unparseable.

Round code: F, SF, QF, R16 … Q1-Q4.

The final score as published, e.g. "6-4 7-6(5)", "6-3 RET", "W/O".

Court surface.

atp or wta — the results archive covers those two tours.

Tournament name.

The winner — a stored field in the corpus, never an inference.

Age at the time of the match.

3-letter country code.

Draw entry where recorded (WC, Q, LL, …) — null for direct acceptances.

"R" or "L".

Height in cm, where recorded.

Player name as the corpus records it.

Corpus person id — pass to search_archive_players results to join bios. NOT a roster player id.

Rank AT THE TIME of the match, as published.

Seeding, where seeded.

id tour tournament event_date round level surface score outcome winner loser

Serve stats for the loser, where recorded.

Serve stats for the winner, where recorded.

Per-match serve statistics (aces, double_faults, serve_points, first_in, first_won, second_won, serve_games, bp_saved, bp_faced). Null for most pre-1991 rows.

Archive result detail

Every Match Charting Project stat family for ONE charted match, both players, with the per-set split (set 1, set 2, …, Total) exactly as charted. Charting ids are their own id space (1960–2026), mostly matches with no counterpart in the live tables. Requires the ULTRA plan.

Charting match id — its own id space, not a match_id.

The charted match.

Every stat family, per player, with the per-set split.

The Match Charting Project's own row identifier.

Human-readable summary. Identical to the text content, so either half can be used alone.

Both players as charted.

Charting: one match, every stat family

Career shot-level profile from the Match Charting Project: serve placement (deuce/ad × wide/body/T), return depth and outcomes, net play, clutch break/game/set-point serving, winners and errors by wing, rally-length tendencies — summed over the player's charted matches. COVERAGE IS CURATED (11,646 charted matches back to the 1960s, concentrated on the majors), not full-slate. An ambiguous name returns the candidates to choose from. Requires the ULTRA plan.

Disambiguates a name charted on both tours.

Player name fragment, min 3 chars — must resolve to one charted person.

A reminder that charting coverage is curated, not full-slate.

Per-family summed numeric columns — raw sums over the player's charted Total rows.

The sample every summed field covers.

The resolved charted player.

Charting: player career profile

Upcoming scheduled tennis fixtures, earliest first — the forward schedule.

Maximum fixtures to return (1-200).

Tour filter; each name covers its doubles variants. Exhibition/team events carry no tour and are excluded whenever the filter is used.

Scheduled fixtures, earliest first.

Scheduled start, ISO timestamp.

Name of player 1.

Name of player 2.

Round within the event.

Event name.

Fixture schedule

The all-time record between two players, across BOTH halves of the product: the results archive (1968–2022) plus our own completed matches (2023 onward). Names are the keys — an ambiguous fragment returns the candidate list to choose from rather than guessing. Totals count only meetings with a known winner; walkovers and retirements are part of the record and each meeting carries its outcome. Requires the BASIC plan or any History plan.

First player name (fragment, min 3 chars), e.g. "federer".

Second player name (fragment, min 3 chars), e.g. "nadal".

Decided wins per surface; keys are surface names plus "unknown".

Individual meetings, newest first, capped at 200.

Match date (current era) or tournament start date (archive era).

"archive" (results archive, 1968-2022) or "current" (our own completed matches, 2023 onward).

Our match id (current era rows) — pass to get_match.

completed, retired, walkover, … — exclude non-completed yourself if needed.

Round.

Final score (archive rows only — read current rows from get_match).

Court surface.

Tournament name.

1 or 2 OF THE REQUEST (player1/player2 as you passed them), not of the underlying match row.

era date tournament round surface score outcome winner match_id

Human-readable summary. Identical to the text content, so either half can be used alone.

Resolved name for player1.

Resolved name for player2.

The resolved names; null when no player matches the fragments.

The headline record.

Meetings with a known winner.

Wins for player1 (of the request).

Wins for player2 (of the request).

Meetings with no derivable winner — never counted in wins.

Head-to-head

List tennis matches currently in progress, with live scores. Covers ATP, WTA, Challenger, ITF and juniors. Use this for "what tennis is on right now".

Either participant's country — the lowercase 3-letter IOC-style code the Player object returns (e.g. ned, sui, gre), NOT ISO-3166. Players with no recorded country never match.

Maximum matches to return (1-200).

Player ids (from search_players), max 50 — keeps matches where ANY listed player is either participant.

The live matches, most relevant first.

How the match ended (or paused) when it did not run its course: Retired, Cancelled, Walk Over, Postponed or Interrupted. Null means completed normally OR never resolved. Branch settlement logic here.

Match id. Pass to get_match, get_match_score, get_match_events or get_match_odds.

True when played indoors.

Name of player 1.

Name of player 2.

Round within the event, e.g. "QF".

Round in the normalized vocabulary (F, SF, QF, R16 … Q); null when the label is unrecognised, never guessed.

Formatted score line, e.g. "6-4 3-6 2-1".

1 or 2 while a point is in play, otherwise null.

One of live, upcoming or completed.

Court surface, e.g. hard, clay, grass.

atp, wta, challenger, itf or juniors. Null when the feed never stated one (exhibitions, team events).

Event name, e.g. "Wimbledon".

Stable tournament id — pass to get_tournament. Null where uncatalogued.

Model probability that player 1 wins, 0-1. Requires the ULTRA plan; null otherwise.

1 or 2 once decided, otherwise null.

Completed matches only: which player retired or conceded the walkover, 1 or 2. Null means "not a withdrawal, or no evidence", never a guess.

Human-readable summary. Identical to the text content, so either half can be used alone.

Live matches

Full detail for one match by id: players, score, surface, round and status. Includes market prices on PRO and model analysis on ULTRA.

Match id, as returned by get_live_matches, get_upcoming_matches or get_recent_results.

Model analysis. Requires the ULTRA plan; absent otherwise.

Drivers behind the model view.

Model probability player 1 wins, 0-1.

Match-winner market. Requires the PRO plan; absent otherwise.

Current prices per player.

Best ask.

Best bid.

Mid price, 0-1, readable as implied probability.

Which player this price is for, 1 or 2.

When the price was observed.

The market being priced.

The match.

True when played indoors.

Name of player 1.

Name of player 2.

Round within the event, e.g. "QF".

One of live, upcoming or completed.

Court surface, e.g. hard, clay, grass.

Event name, e.g. "Wimbledon".

1 or 2 once decided, otherwise null.

Match detail

Model analysis for a match: predicted win probability, the model's thesis and the key factors behind it. Requires the ULTRA plan.

Quantitative view.

How close the model expects the match to be.

Drivers behind the model view.

Expected swing in the match state.

Model probability player 1 wins, 0-1.

Narrative view.

Model confidence, 0-1.

Player the model favours, 1 or 2.

Narrative reasoning.

Current state of the thesis.

Model analysis

Timeline of events for a match — breaks, games won, sets won, momentum runs. Requires the PRO plan.

Maximum events to return (1-200).

Events in chronological order.

Player the event belongs to, 1 or 2.

When the event occurred.

Event type, e.g. break, game, set.

Match timeline

Match-winner market prices for a match — implied probability per player, with bid, ask and mid. Requires the PRO plan.

Maximum price points to return (1-200).

The match-winner market.

Resting liquidity.

Recent prices, newest first.

Best ask.

Best bid.

Which player this price is for, 1 or 2.

When the price was observed.

The market being priced.

Market status, e.g. open or resolved.

24h traded volume.

Match market prices

Current score for one match — the fastest, lowest-latency read. Use this when you only need the score and already know the match id.

The current score.

Formatted score line.

True during a tiebreak.

Which player is serving, 1 or 2.

Sets won per player.

Model probability player 1 wins, 0-1. ULTRA only.

Match score

In-play (or final) statistics for one match, in TWO families kept deliberately separate: DERIVED is rebuilt from the point-by-point record (holds/breaks, break points, service/return points); MEASURED is counted upstream and includes what no point record can yield — aces, double faults, the serve split, winners/unforced errors. Measured coverage varies by tour; absent fields are omitted, never zero-filled. Requires the ULTRA plan.

The statistics.

When the underlying record was last updated (UTC).

live | final | stale | none | diverged — summarises the response.

Per-family coverage/as_of/age. The two ages use DIFFERENT clocks (derived: against the newest score row; measured: wall clock) and must not be compared. On diverged the measured values are withheld and measured_divergence says why.

Games the derived family covers (tiebreaks excluded, counted separately).

Rebuilt from the point-by-point record: service/return games and points, hold_pct, break_pct, break points faced/saved/converted. Null percentages mean a zero denominator, never 0.

Counted upstream — aces, double_faults, the serve split, winners/unforced errors where covered. Absent fields are omitted, never zero-filled. Quantities named in both families are computed two different ways: a cross-check, not a duplication.

Null when coverage is none — the match exists and holding nothing is the honest answer.

Match statistics

One player's profile: ranking, country, handedness, date of birth and cached stats.

Player id, as returned by search_players.

Human-readable summary. Identical to the text content, so either half can be used alone.

The player.

Date of birth, ISO date.

Country code.

"R" or "L".

Player id. Pass to get_player.

Player name.

Current singles ranking.

Recent movement in the rankings.

Ranking points.

ATP, WTA, Challenger or ITF.

id name country ranking ranking_points ranking_movement hand birthday tour

Player profile

Point-in-time ranking records for SPECIFIC players: per system, the newest record in force ON OR BEFORE as_of — never one dated after it. Every other ranking field in this API is the CURRENT value joined at read time; this is the historical answer. Systems are never collapsed: ATP/WTA and the ITF circuits carry rank+points, UTR a rating. ITF and UTR history begins 2026-07-29. Requires the ULTRA plan.

YYYY-MM-DD — the record in force on this date. Omit for the latest known.

Roster player ids, as returned by search_players. Max 50.

Restrict to one system. Omit for every system held for the player.

What resolved against what was asked (players_resolved, systems_resolved, oldest_available per system). Read before trusting an empty result.

One record per player × system held.

The publication week this record took effect, YYYY-MM-DD.

Roster player id — null on listing rows for players outside our roster.

Name as the ranking publisher printed it (listing rows).

Null for UTR.

Rank at the preceding snapshot week (ATP/WTA only; null elsewhere).

Null for UTR (a rating, not a ranking).

The circuit's own signed weekly movement (ITF systems only).

UTR only; null elsewhere.

atp, wta, itf_jt, itf_mt, itf_wt or utr. Systems are never comparable.

Player rankings as of a date

The FULL published ranking table in rank order for one system — the newest week at or before as_of. Rows carry player_name as published and a null player_id for players outside our roster, so the table has no silent holes. ATP/WTA history runs deep; the ITF circuits begin 2026-07-29. For point-in-time records of SPECIFIC players use get_player_rankings. Requires the PRO plan.

YYYY-MM-DD — serves the newest published week at or before this date. Omit for latest.

Maximum ranking rows to return (1-200).

Ranking system to list. utr has no listing — it is a rating, not a ranking.

The table in rank order.

Null for UTR.

Null for UTR (a rating, not a ranking).

UTR only; null elsewhere.

Rankings listing

Recently completed tennis matches with final scores and winners. Filterable by tour, player, nationality and play date. Requires the BASIC plan or any History plan.

Earliest play date: YYYY-MM-DD (a whole UTC day) or ISO-8601 datetime.

Maximum matches to return (1-200).

Latest play date: YYYY-MM-DD or ISO-8601; must not precede from.

Completed matches, most recent first.

Match id. Pass to get_match, get_match_score, get_match_events or get_match_odds.

True when played indoors.

Name of player 1.

Name of player 2.

Round within the event, e.g. "QF".

Formatted score line, e.g. "6-4 3-6 2-1".

1 or 2 while a point is in play, otherwise null.

One of live, upcoming or completed.

Court surface, e.g. hard, clay, grass.

Event name, e.g. "Wimbledon".

Stable tournament id — pass to get_tournament. Null where uncatalogued.

Model probability that player 1 wins, 0-1. Requires the ULTRA plan; null otherwise.

1 or 2 once decided, otherwise null.

Human-readable summary. Identical to the text content, so either half can be used alone.

Recent results

One tournament by its stable id — the tournament_id carried on match objects. Name, tour, surface, indoor, plus host city/country and category where curated.

Stable tournament id, as returned by search_tournaments or carried on a match as tournament_id.

The tournament.

Tournament category (grand_slam, masters_1000, tour_finals, atp_500, atp_250, wta_1000, wta_500, wta_250, wta_125, challenger, itf, juniors). Set only where the catalogues agree unambiguously — null otherwise, never derived from the name.

Host city, from a curated table — null where not curated.

Host country, ISO-3166 alpha-2 — null where not curated.

Stable tournament id — the same id match objects carry as tournament_id.

True when played indoors.

Tournament name.

Court surface: hard, clay or grass.

atp, wta, challenger, itf or juniors.

id name tour surface indoor city country category

Tournament detail

List tennis matches scheduled to start soon, with players and tournament.

Earliest play date: YYYY-MM-DD (a whole UTC day) or ISO-8601 datetime.

Maximum matches to return (1-200).

Latest play date: YYYY-MM-DD or ISO-8601; must not precede from.

Matches due to start, soonest first.

Match id. Pass to get_match, get_match_score, get_match_events or get_match_odds.

True when played indoors.

Name of player 1.

Name of player 2.

Round within the event, e.g. "QF".

Formatted score line, e.g. "6-4 3-6 2-1".

1 or 2 while a point is in play, otherwise null.

One of live, upcoming or completed.

Court surface, e.g. hard, clay, grass.

Event name, e.g. "Wimbledon".

Stable tournament id — pass to get_tournament. Null where uncatalogued.

Model probability that player 1 wins, 0-1. Requires the ULTRA plan; null otherwise.

1 or 2 once decided, otherwise null.

Human-readable summary. Identical to the text content, so either half can be used alone.

Upcoming matches

Search the results archive — completed-match RESULTS from 1968 through 2022: ATP and WTA, main draws, qualifying and the ITF/futures tiers. Winner/loser-shaped records with final score, seeds and ranks AT THE TIME of the match. Use this for historical questions ("Borg's Wimbledon finals"); the archive ends 2022-12-31 where our own results (get_recent_results) begin. Requires the BASIC plan or any History plan.

Earliest tournament START date, YYYY-MM-DD.

Source tier code: G=grand slam, M=masters, A=tour, F=finals, D=davis cup, C=challenger, O=olympics, or a futures category code (e.g. 15).

Maximum results to return (1-200).

Case-insensitive fragment of EITHER player's name, min 3 chars, e.g. "borg".

Round code, e.g. F for finals.

Latest tournament START date, YYYY-MM-DD.

atp or wta.

Archive results, newest tournament first.

The tournament START date — per-match dates do not exist in this era’s records.

Archive match id. Pass to get_archive_match for the detail read with stats.

Source tier code: G, M, A, F, D, C, O, or a futures category code.

The loser.

completed, retired, walkover, default or abandoned — parsed, null when unparseable.

Round code: F, SF, QF, R16 … Q1-Q4.

The final score as published, e.g. "6-4 7-6(5)", "6-3 RET", "W/O".

Court surface.

atp or wta — the results archive covers those two tours.

Tournament name.

The winner — a stored field in the corpus, never an inference.

Age at the time of the match.

3-letter country code.

Draw entry where recorded (WC, Q, LL, …) — null for direct acceptances.

"R" or "L".

Height in cm, where recorded.

Player name as the corpus records it.

Rank AT THE TIME of the match, as published.

Seeding, where seeded.

Results archive (1968–2022)

The people of the results archive (1968–2022): hand, date of birth, country, height, and career-high rank with the week it was first reached. Their ids are corpus person ids (the winner/loser player_id on archive results), not roster ids — for current players use search_players. Requires the BASIC plan or any History plan.

Maximum players to return (1-200).

Full or partial player name, min 3 chars, e.g. "navratilova".

atp or wta.

Human-readable summary. Identical to the text content, so either half can be used alone.

Matching archive people, ordered by name.

The earliest week the career-high rank was reached.

Career-high rank, from the corpus’s own weekly tables.

3-letter country code.

Date of birth, ISO date.

"R" or "L".

Height in cm.

Corpus person id — the id archive match rows carry as winner/loser player_id. NOT a roster id.

Player name.

atp or wta.

id tour name hand dob country height_cm career_high_rank career_high_date

Archive player bios

Search tennis players by name. Returns id, country, ranking and tour. Use the returned id with get_player.

Maximum players to return (1-200).

Full or partial player name, e.g. "alcaraz".

Matching players, best match first.

Date of birth, ISO date.

Country code.

"R" or "L".

Player id. Pass to get_player.

Player name.

Current singles ranking.

Recent movement in the rankings.

Ranking points.

ATP, WTA, Challenger or ITF.

Search players

Search the tournament catalogue — the stable id space that match objects carry as tournament_id. Returns surface, indoor, host city/country and category where curated.

Maximum tournaments to return (1-200).

Full or partial tournament name, e.g. "wimbledon". Omit to list all.

Restrict to one tour.

Matching tournaments, name order.

Host city, from a curated table — null where not curated.

Host country, ISO-3166 alpha-2 — null where not curated.

Stable tournament id — the same id match objects carry as tournament_id.

True when played indoors.

Tournament name.

Court surface: hard, clay or grass.

atp, wta, challenger, itf or juniors.

Tournament catalogue


Get the source code for a specific ReactBits component

Name of the component (e.g., "splash-cursor", "pixel-card")

Preferred styling method (defaults to available)

Get usage example and demo code for a ReactBits component

Name of the component

List all available component categories

List all available ReactBits components with optional filtering

Filter by category (e.g., animations, backgrounds, buttons)

Maximum number of components to return

Filter by styling method

Search for ReactBits components by name or description

Filter by category

Maximum number of results

Search query


Add slides

Append or insert slides written in Lore. Prefer archetype blocks (`== hero`, `== statRow`) — they produce designed layouts. Call list_layouts to see them, or language_reference for the full syntax.

0-based insert position; appends when omitted

One or more `== <archetype>` blocks, no frontmatter

Add slides

Apply a whole deck document

Replace the deck with a full document (frontmatter plus blocks). Only slides that actually changed are rewritten, so untouched slides keep their ids. Use for restyling or reordering everything at once.

Apply a whole deck document

Choreograph a slide's motion

Re-time one slide's element entrances as a coordinated sequence: cascade (role-ordered stagger), focus-pull (media lands first), rise-ensemble (everything rises together), or typewriter-lead (the title types itself out first). Timing follows the deck stylekit's motion personality; loop and exit clips the slide already carries are preserved.

Choreography pattern to apply

cascade focus-pull rise-ensemble typewriter-lead stagger-grid spotlight-trace split-reveal kinetic-word orchestral

Slide id from read_outline

Choreograph a slide's motion

Create a deck

Make a new deck, optionally from a template (list_templates) and optionally with its slides written in Lore.

Slides to start with, as `==` blocks

Template id, e.g. tpl_ember

Create a deck

Create a deck from a Style

Build a new deck by crossing a content skeleton (list_skeletons) with a Style (list_styles) — the deck's whole look: palette, fonts, spacing, shape language, decor, atmosphere, motion and transitions. A Style is a Style whether it was curated, generated from a described vibe, or imported from a .pptx / design system / website brand; styleId takes any of them. Generates real imagery matching the Style's art direction by default.

Default true

Skeleton id from list_skeletons, e.g. pitch

Style id from list_styles — a curated id like `riso-pop` or a saved-style uuid

Create a deck from a Style

Create a deck from a Style (deprecated alias)

DEPRECATED — use create_deck_from_style. Identical behavior; `personalityId` is accepted as an old spelling of `styleId`. Kept so existing callers keep working.

Default true

Deprecated spelling of styleId

Style id from list_styles

Invent a Style

Invent a NEW Style from a description — the catalog is not a fixed list of 19. Describe the look in words ("a cozy library", "1970s NASA telemetry", "a risograph zine") and get back a complete Style: palette, font pairing, shape language, decor, atmosphere, motion character, slide transitions, AND the policy axes that lean which composition, entrance and pose each slide draws — so an invented Style behaves differently, not just looks different. Say who the deck is for (persona) and what job it is doing (useCase) and both the look and those leanings follow the brief: a reference card comes back still and left-aligned, a portfolio comes back reaching. Every invented Style is verified before it is returned — palette contrast, body-font legibility, type-scale floors, plus a real probe build measured for contrast failures, collisions, off-slide elements and overflow — and one that fails is reported, never handed back. Saves by default and returns a styleId usable with create_deck_from_style, apply_deck or reroll_deck.

The look, in words — e.g. "sun-bleached surf shop, hand-painted signage"

Name for the saved Style (defaults to the invented one)

Who is speaking to whom

founder-to-investor consultant-to-exec teacher-to-students speaker-to-conference team-to-team creator-to-audience

The deck's voice, one short phrase

Save it to the Styles list (default true). false previews without keeping it.

The deck's subject matter, for context only

The job this deck is doing — decides how far the Style may reach

pitch report teaching keynote launch internal-update portfolio reference general

Invent a Style

Delete a deck

Permanently remove a deck. There is no undo.

Delete a deck

Delete a slide

Remove a slide by id.

Delete a slide

Edit a deck with the in-app AI edit loop

Run the same agentic "Edit with AI" loop the editor's panel uses: it reads the deck, can look at rendered slides (a vision pass), generate or edit images, add archetype slides, and emits operations — which this tool then applies through the live collaboration room, so open browsers update instantly and the whole edit is one undo. Use it for design-quality passes ("review every slide and fix what looks off"), content rewrites, or anything you'd type into the app's AI panel. Prefer replace_slide/apply_deck when you already know the exact change.

Pin these slides as context

Pin the theme as context

The slide the edit is 'on' (defaults to the first slide)

Export a deck

Get a download URL for the deck as native PowerPoint or PDF. PowerPoint exports as real editable shapes, text and charts — not pictures of slides.

Export a deck

Build a deck end-to-end with the AI pipeline

Stage 2 of the app's generation pipeline: assembles an approved outline into a saved deck — designed layouts, copy, AI/stock imagery, then the quality loop (a vision judge scores the rendered deck and the worst slides get a polish pass) before saving. This is the full in-app experience over MCP: use generate_outline first, then this. Returns the new deckId plus the quality report (initial → final score, revised slides). Style precedence: styleId > personalityId > templateId.

The design brief from generate_outline, echoed back unchanged

Outline slides from generate_outline, unchanged

The user's original ask, for the generation record

Generate all declared images in a deck

Fill in every AI-declared image in a deck at once. In the deck language, `image gen {prompt="misty harbor at dawn" x=… y=… w=… h=…}` places an image that renders as a placeholder until generated; this tool generates each one (honoring the theme's imageStyle) and wires the assets in. Run it after create_deck/apply_deck when the document declared `image gen` elements. Requires the server to have an image model key configured.

Generate all declared images in a deck

Generate an image

Create an image from a text prompt and return its asset id, for use as `image: asset:<id>` in a slot or `image asset:<id>` as an element. Requires the server to have an image model key configured.

Generate an image

Plan a deck outline with the AI pipeline

Stage 1 of the same generation pipeline the app's wizard uses: an art-direction pass plans the argument and look, then a writer produces one validated outline slide per archetype. Returns the outline slides and the design brief as JSON — pass both to generate_deck unchanged to build the deck. Prefer this over hand-writing an outline when the user gives a topic rather than finished content.

Free-form creative direction

What the deck is about — topic, audience, goal

Source material to outline from

Generation insights

How past AI generations were received: win-rates per style, archetype and choreography pattern, feedback-tag frequencies and trend, and the human and AI quality passes reported side by side (never averaged — they measure different things). Use this to decide what to change about generation, and to see which recurring complaints might deserve a curated prompt adjustment.

Generations to scan, newest first (default 50)

ISO datetime lower bound, e.g. 2026-07-01T00:00:00Z

ISO datetime upper bound

Generation insights

Extract a brand from a website

Fetch a public website, classify its CSS colors and fonts into a Lorem palette, and save the result as a reusable Style — the fastest way to make decks match a company's brand. Returns the styleId plus the extracted palette/fonts; use it with create_deck_from_style({skeletonId, styleId}) or apply the palette to an existing deck via apply_deck.

Name for the saved style (defaults to '<host> brand')

Public website URL, e.g. stripe.com

Extract a brand from a website

Import a deck file

Import a .pptx file (PowerPoint, or the PPTX export of Google Slides / Canva / Keynote) as a fully editable Lorem deck — every text run, color, image, table, chart and note mapped onto the native document model. Also extracts the file's visual style as a reusable Style (see list_styles), first-class next to the curated ones. Anything the model can't express is listed in the fidelity report. After importing, iterate with read_deck / replace_slide / apply_deck as with any deck.

Deck title override (defaults to the file's)

Absolute path to the .pptx file on this machine

Import a deck file

Import a design system

Import design tokens (W3C design-tokens JSON, Tokens Studio JSON, or CSS custom properties) — or any .pptx to mine its style — into a reusable Style: palette, fonts, type scale and radii become a Style that drives deck generation and restyling exactly like the curated ones.

Name for the imported style

Absolute path to the tokens .json / .css file (or a .pptx to style-mine)

Import a design system

Deck language reference

The full syntax of Lore, the Lorem deck language, generated from the layout schemas so it is never out of date. Read this once before writing anything non-trivial.

Deck language reference

List decks

List every deck with its id, title and slide count. Start here to find a deck to work on.

List decks

Browse the font catalog

Search the ~140-family font catalog by mood, theme or name — e.g. "horror", "kids playful", "elegant serif", "pixel arcade", "western". Every family is Google-hosted and loads automatically when referenced by name in a deck theme (`fonts:` frontmatter) or on a text run (`font="…"`). Use it to pick type that matches the content instead of defaulting to a generic sans.

Mood/theme/name keywords; omit to list the whole catalog grouped by category

Browse the font catalog

List slide layouts

Every designed layout (archetype) with the content slots it takes. Choosing a layout and filling its slots is how you get a professional-looking slide — never place elements by hand unless no layout fits.

List slide layouts

List Deck Personalities (deprecated alias for list_styles)

DEPRECATED — use list_styles, which lists the same curated Styles plus the user's own. Kept so existing callers keep working. Lists the 19 curated Styles only.

List content skeletons

Slide sequences a Style can be crossed with — what the deck contains, independent of how it looks. Pass one of these plus a styleId to create_deck_from_style.

List content skeletons

List Styles

Every Style available to this user, grouped by where it came from: 19 curated Styles, plus any generated from a described vibe or imported from a .pptx, design system or website brand. A Style is a complete look — palette, fonts, spacing, shape language, decor, ambient atmosphere, motion character, slide transitions — that cascades from one pick. Cross one with a skeleton from list_skeletons and pass both to create_deck_from_style.

List Styles

List deck templates (deprecated — a template is a skeleton × Style)

DEPRECATED — each of these 15 flat seed ids is nothing more than one content skeleton crossed with one Style, under a fixed name. Prefer list_skeletons + list_styles + create_deck_from_style, which reaches all 19 curated Styles (not just the 15 pre-paired ones) and generates real imagery. The ids keep working forever via create_deck's templateId; the listing names the pair behind each.

Read a whole deck

The entire deck as source, including its theme frontmatter. Expensive for large decks — prefer read_outline plus read_slide unless you need to restyle everything at once.

Read a whole deck

Read a deck outline

A compact index of a deck: one line per slide with its id, layout and title. Far cheaper than reading the whole deck — use this first, then read only the slides you need.

Deck id from list_decks

Read a deck outline

Read one slide

The full source of a single slide in Lore, the Lorem deck language, ready to edit and pass back to replace_slide.

Slide id from read_outline

Read one slide

Replace one slide

Rewrite a single slide, keeping its id so comments and collaborators' selections survive. Other slides are untouched, so this is safe while someone else is editing them.

One block replacing this slide

Replace one slide

Re-roll a deck's design

Redraw a deck's design without touching a word of its copy or regenerating a single image. Every slide is rebuilt from its own content with a new Style and/or a new seed: different composition, motion, crop, framing, type and colour. The text, the images, the speaker notes and each slide's layout ARCHETYPE are pinned, so this costs nothing to run and can be repeated freely — it is the tool to reach for when the words are right and the look is not. Distinct from applying a Style through apply_deck, which patches attributes in place and keeps the composition; a re-roll throws the composition away and draws a new one, discarding hand-positioned layout. Omit styleId to keep the current Style and just redraw; pass a seed to make the draw reproducible.

Reproducible draw; the same seed gives the same design.

A Style id from list_styles. Omit to redraw with the deck's current Style.

Re-roll a deck's design

Save a deck as a template

Promote a deck to the template gallery, so new decks can start from its design and structure. Use once a deck is worth reusing.

Save a deck as a template

Set or clear the deck soundtrack

Give a deck an AI-generated soundtrack that plays during Present mode. Generates audio from a musical brief — mode "instrumental" for pure music, "lyrical" to steer toward sung vocals about `lyrics` — then attaches it to the deck as one undoable operation (also expressible in the deck language as `music:` frontmatter). Generation runs roughly in real time, so expect ~30s. Pass remove:true to clear the soundtrack instead.

Set or clear the deck soundtrack

validate

Check Lore without applying it

Parse a document or fragment and report errors and warnings. Nothing is changed.

Validate against this deck's theme

Check Lore without applying it


Associate Memories

Create typed relationships between memories. This builds a knowledge graph that improves recall by surfacing related context. Supports single-pair mode or batch mode with associations[] (max 500).

**When to use:**
- After storing a new memory: link it to related existing memories
- When a bug fix relates to an original feature implementation
- When a new decision updates or invalidates a previous one
- To connect patterns with their concrete examples

**Authorable relationship types:**
- RELATES_TO: General relationship (default)
- LEADS_TO: Causal relationship (A caused B)
- OCCURRED_BEFORE: Temporal ordering
- PREFERS_OVER: Chosen alternative
- EXEMPLIFIES: Concrete example of a pattern
- CONTRADICTS: Conflicts with another memory
- REINFORCES: Strengthens another memory's validity
- INVALIDATED_BY: Superseded by another memory
- EVOLVED_INTO: Updated version of a concept
- DERIVED_FROM: Implementation of a decision/pattern
- PART_OF: Component of a larger effort

**Read-only/internal relations:**
- System/internal relations such as SIMILAR_TO, PRECEDED_BY, EXPLAINS, SHARES_THEME, PARALLEL_CONTEXT, and DISCOVERED may appear in recall results, but they are not valid inputs for associate_memories.

**Examples:**
- associate_memories({ memory1_id: "bug-fix-123", memory2_id: "feature-456", type: "RELATES_TO", strength: 0.9 })
- associate_memories({ memory1_id: "new-decision", memory2_id: "old-decision", type: "EVOLVED_INTO", strength: 0.8 })
- associate_memories({ associations: [{ memory1_id: "a", memory2_id: "b", type: "RELATES_TO", strength: 0.8 }] })

Batch mode. Up to 500 associations. Do not combine with top-level memory1_id/memory2_id/type/strength.

Relation-specific confidence for EXEMPLIFIES, EVOLVED_INTO, or DERIVED_FROM.

Relation-specific context for PREFERS_OVER or PART_OF associations.

ID of the source memory

ID of the target memory

Relation-specific observations for REINFORCES associations.

Relation-specific pattern label for EXEMPLIFIES associations.

Relation-specific reason for PREFERS_OVER, CONTRADICTS, INVALIDATED_BY, or EVOLVED_INTO associations.

Relation-specific resolution for CONTRADICTS associations.

Relation-specific role for PART_OF associations.

Relationship strength from 0 to 1

Relation-specific timestamp for INVALIDATED_BY associations.

Relation-specific transformation note for DERIVED_FROM associations.

Relationship type between the two memories

ID of the source memory (from store_memory response or recall results)

ID of the target memory to link to

Relationship strength: 0.9+ direct causation, 0.7-0.9 strong relation, 0.5-0.7 moderate

Batch mode: number of associations created.

Batch mode: failed association records with errors.

Batch mode: number of associations that failed.

Confirmation message

Batch mode: successful association records.

Whether every requested association was created. False for partial batch responses.

Batch mode: service summary.

Associate Memories

Check Database Health

Check the health status of the AutoMem service and its connected databases (FalkorDB graph + Qdrant vectors).

**When to use:**
- Before a session to verify the memory service is available
- When memory operations are failing unexpectedly
- To check storage statistics

**Example:**
- check_database_health({})

Backend type (automem)

Error message if status is error

Database statistics and diagnostics, including memory/vector counts, sync_status, vector_dimensions, and enrichment state when provided.

Overall health status. degraded means the service is reachable but a backend or sync check needs attention.

Check Database Health

Delete Memory

Delete a memory by ID (`memory_id`) or bulk-delete by tag (`tags`). Use sparingly — consider `update_memory` instead.

**Mode 1 — Single (default):** pass `memory_id` to delete one memory and its embedding. Idempotent: re-running on the same ID is a no-op.

**Mode 2 — Bulk-by-tag:** pass `tags: [...]` to delete ALL memories tagged with ANY of these tags. Tag matching is exact (case-insensitive), any-of mode. There is NO dry-run. This can delete thousands of memories in one call. NOT idempotent in practice — re-running may catch new memories that were tagged the same way after the first call. Verify with `recall_memory({ tags, exhaustive: true })` first if uncertain.

**When to use:**
- Memory contains incorrect information that can't be corrected (Mode 1)
- Memory is a duplicate (Mode 1)
- Cleanup of benchmark/test data scoped by tag (Mode 2)
- Removing all memories under a deprecated tag namespace (Mode 2)

**Examples:**
- delete_memory({ memory_id: "abc123" })  // Mode 1
- delete_memory({ tags: ["benchmark-test"] })  // Mode 2, bulk by tag

Single-delete mode (XOR with `tags`). ID of the memory to delete (from store_memory or recall results).

Bulk-delete mode (XOR with `memory_id`). Bulk-deletes ALL memories tagged with ANY of these tags. Exact match, case-insensitive. No dry-run.

Bulk-delete result: number of memories deleted.

Single-delete result: ID of the deleted memory.

Confirmation message

Bulk-delete result: tags that were used for the bulk delete.

Delete Memory

Recall Memory

Recall memories from AutoMem in one of three modes. The mode is selected by which params you pass.

**Mode 1 — ID fetch:** pass `memory_id` to retrieve a single memory by ID. All other params are ignored. Routes to GET /memory/{id} and updates last_accessed.

**Mode 2 — Tag enumeration:** pass `tags` + `exhaustive: true` for paginated exact-match listing (NOT ranked retrieval). Use this for cleanup/audit workflows where ranked retrieval silently undercounts large tag sets. Pair with `limit` (≤200) and `offset`. Returns `has_more`/`limit`/`offset` page metadata. Tag matching is exact, case-insensitive, any-of mode — `tag_match: "prefix"` and `tag_mode: "all"` are rejected in this mode.

**Mode 3 — Ranked retrieval (default):** hybrid search across vector, keyword, tags, recency, and optional graph expansion. The primary tool for finding relevant context. By default, ranked recall requests current active memories only; set `current_only: false` for audits.

**When to use ranked (mode 3):**
- At conversation start: recall context about the current project/topic
- Before making decisions: check for past decisions on similar topics
- When debugging: search for similar past errors and their solutions
- For complex questions: use `expand_entities` for multi-hop reasoning

**When to use enumeration (mode 2):** when you need to know *how many* memories carry a tag, or to walk all of them for cleanup/migration. Ranked recall ignores low-importance hits — enumeration does not.

**Examples:**
- recall_memory({ query: "database architecture decisions", tags: ["my-project"], limit: 5 })
- recall_memory({ memory_id: "abc123" })  // Mode 1
- recall_memory({ tags: ["benchmark-test"], exhaustive: true, limit: 50 })  // Mode 2 (add offset for later pages)
- recall_memory({ query: "auth", exclude_tags: ["deprecated"] })  // Mode 3 with exclusion
- recall_memory({ query: "What is Sarah's sister's job?", expand_entities: true })  // Mode 3 multi-hop

Current file path for language auto-detection (e.g., "src/auth.ts")

Ranked-mode only. Enable the service's adaptive score floor when filtering weak matches.

Auto-extract entities and topics from query to generate supplementary searches.

Context label (e.g., "coding-style", "architecture"). Boosts matching preferences.

Priority tags to boost in results (e.g., ["coding-style", "preferences"])

Priority memory types to boost (e.g., ["Style", "Preference"])

Ranked-mode only. When true, server suppresses archived, not-yet-valid, expired, invalidated, or superseded memories from active context.

Optional embedding vector for direct similarity search

ISO timestamp upper bound

Ranked-mode only. Tags to exclude from results (any match excludes). Independent of `tag_match` — supports both exact and prefix matching internally on the server.

MODE: tag enumeration. When true, requires non-empty `tags`. Routes to GET /memory/by-tag for paginated exact-match listing — NOT ranked retrieval. Use for cleanup/audit workflows where ranked recall undercounts. `limit` is clamped to 200. `tag_match: "prefix"` and `tag_mode: "all"` are rejected in this mode.

Enable multi-hop reasoning via entity expansion. Finds memories about people/places mentioned in seed results. Use for "What is X's sister's job?" type questions.

Minimum importance score for expanded results. Filters out low-relevance memories during graph/entity expansion. Recommended: 0.3-0.5 for broad context, 0.6-0.8 for focused results. Seed results are never filtered, only expanded ones.

Minimum relation strength to follow during graph expansion. Only traverses edges above this threshold. Recommended: 0.3 for exploratory, 0.6+ for high-confidence connections only. Does not affect entity expansion.

Follow graph relationships from seed results to find related memories.

Ranked-mode only. When true, graph/entity expansion stays within the original tag scope; when false, expansion may include related context outside the tags.

Max total expanded memories (default: 25)

Output format: text (default), items (one block per memory), detailed (adds type/confidence/metadata keys/relation stubs), json (raw per-memory fields incl. full content/metadata/relations; whole-response token budget still applies). text/items/detailed show a content preview (default 400 chars) and keep any stored summary as an additive field — fetch a full record via memory_id.

Programming language hint (e.g., "python", "typescript"). Prioritizes language-specific memories.

Max memories to return. Schema allows 1–200; in enumeration mode (`exhaustive: true`) the server honors up to 200, while ranked mode is typically clamped server-side to ~50. Default 5.

MODE: ID fetch. When set, fetches the single memory by ID and IGNORES all other params. Routes to GET /memory/{id}; updates last_accessed.

Ranked-mode only. Minimum final score threshold before results are returned.

Result offset for pagination

Per-query result limit when using queries[] (default: 5)

Specific memory IDs to ensure are included in results

Multiple queries for broader recall. Results are deduplicated server-side.

Semantic search query (natural language). Describe what you're looking for.

Ranked-mode only. Controls service recency boosting: auto lets the service infer, on forces boosting, off disables it.

Max relations to follow per seed memory (default: 5)

Ranked-mode only. Allow fallback outside the requested tag scope when scoped recall has weak evidence; diagnostics report tag_scope and outside_tag_scope.

Result ordering (use time_* for chronological recaps)

ISO timestamp lower bound (alternative to time_query)

Ranked-mode only. Include state-filter suppression/replacement IDs and reasons when current_only is true.

Ranked-mode only. `current` returns active memories; `history` allows superseded/invalidated memories for audit timelines. Prefer this over current_only for new clients.

"exact" for exact tag match (default), "prefix" for starts-with matching

"any" matches memories with any tag (default), "all" requires all tags

Filter by tags. Use project name as first tag for scoping.

Natural language time filter: "today", "yesterday", "last week", "last 30 days"

Number of memories returned

Number of duplicate results removed (when using multiple queries)

Entity identity diagnostics injected by the service.

Tags excluded from ranked recall.

Enumeration mode only: true if more pages exist past `offset + limit`.

Number of memories enriched inline during recall.

Enumeration mode only: page size used for this response.

Mode that produced the result.

Enumeration mode only: offset used for this response.

Query variants executed by the service.

Query text executed by ranked recall.

Service recall latency in milliseconds.

Recency bias mode applied by the service.

Array of matching memories with scores

Memory content (preview-capped in budgeted formats).

Original content length when content was previewed.

True when content is a preview; fetch the full record via recall_memory({ memory_id }).

Result IDs merged into this result during multi-query deduplication.

True when the service enriched the memory during recall.

True when scope_fallback admitted this result outside the requested tag scope.

ID of the suppressed memory this result replaced during current-state filtering.

Stored 1-2 sentence summary when the server provides one. Additive in budgeted formats; does not replace content.

True when recall allowed outside-scope fallback results.

Score filtering diagnostics such as min_score, adaptive_floor, and filtered_count.

Sort mode applied by the service.

Current-state filtering diagnostics. Includes aggregate counts by default and detailed IDs/reasons only when state_debug=true.

State mode applied by ranked recall.

Tag-scope diagnostics including whether scoped evidence was strong enough.

Present when trailing results were dropped to fit the response budget: { applied, omitted_results, reason }.

Vector-search diagnostics from the service.

Recall Memory

Store Memory

Store memory in one of two modes — single-memory (set top-level `content`) or batch (set `memories: [...]` for up to 500).

**Mode 1 — Single (default):** pass top-level `content` plus any optional fields (tags, importance, metadata, type, confidence, embedding, t_valid, t_invalid, etc.).

**Mode 1b — Supersede/correct:** pass top-level `content` plus `supersedes_memory_id`. The server stores the replacement, marks the old memory invalid with `t_invalid=now`, merges supersede metadata, and associates old → new with `INVALIDATED_BY` (default) or `EVOLVED_INTO`.

**Mode 2 — Batch:** pass `memories: [{ content, tags?, importance?, metadata?, timestamp?, type?, confidence? }, ...]` to store up to 500 memories in one request. Faster for bulk ingestion (imports, benchmark seeding). Batch mode does NOT accept `embedding`, `t_valid`, or `t_invalid` per-item — use single mode for those.

**Content size guidelines (per item):**
- Target: 150-300 characters (one meaningful paragraph)
- Maximum: 500 characters (auto-summarized if exceeded)
- Hard limit: 2000 characters (rejected)
- Format: "Brief title. Context and details. Impact/outcome."

**When to use:**
- After making a decision: store the reasoning and outcome
- When discovering a pattern: store the pattern and where it applies
- After fixing a bug: store the root cause and solution
- When learning user preferences: store what they prefer and why
- For bulk ingestion (imports, seeding): use batch mode

**Examples:**
- store_memory({ content: "Chose PostgreSQL over MongoDB for user service. Need ACID for transactions.", tags: ["architecture", "database"], importance: 0.9 })
- store_memory({ content: "User prefers early returns over nested conditionals.", tags: ["code-style"], importance: 0.7 })
- store_memory({ content: "User now prefers SQLite for small local tools.", supersedes_memory_id: "old-id", supersede_reason: "Correction from user" })

Single-memory mode. Classification confidence (0-1, default 0.9 when type provided)

Single-memory mode (XOR with `memories`). The memory content to store. Be specific: include context, reasoning, and outcome.

Single-memory mode only. Optional embedding vector for semantic search (auto-generated if omitted). Not supported in batch mode.

Single-memory mode. Importance: 0.9+ critical decisions, 0.7-0.9 patterns/bugs, 0.5-0.7 minor notes

Single-memory mode. ISO 8601 last-accessed timestamp

Batch mode (XOR with `content`). Up to 500 memory objects to store in one call. Each item supports content (required), tags, importance, timestamp, type, confidence, metadata. Batch mode does NOT support `embedding`, `t_valid`, or `t_invalid` per-item — use single-memory mode for those.

Decision Pattern Preference Style Habit Insight Context

Single-memory mode. Optional structured metadata (e.g., { files_modified: ["auth.ts"], error_type: "timeout" })

Single-memory supersede mode. Optional reason stored on the old memory's metadata.

Single-memory supersede mode. Relationship to create from old memory to new memory.

Single-memory supersede mode. Existing memory ID that this new memory replaces or corrects.

Single-memory mode only. ISO 8601 timestamp when the memory expires. Not supported in batch mode.

Single-memory mode only. ISO 8601 timestamp when the memory becomes valid. Not supported in batch mode.

Single-memory mode. Tags to categorize the memory (e.g., ["project-name", "bug-fix", "auth"])

Single-memory mode. Optional ISO timestamp (defaults to now)

Single-memory mode. Memory type for classification

Single-memory mode. ISO 8601 last-updated timestamp

Supersede-mode result: whether old → new association was created.

Batch-mode result: enrichment status from the server.

Single-mode result: unique ID of the stored memory (use for associations)

Batch-mode result: IDs of the stored memories.

Confirmation message

Batch-mode result: Qdrant indexing summary from the server.

Batch-mode result: server-reported execution time in milliseconds.

Batch-mode result: number of memories stored.

Supersede-mode result: ID of the old memory marked invalid.

Store Memory

Update Memory

Update an existing memory's content, tags, importance, or metadata. Use this to correct or enhance memories rather than storing duplicates.

**When to use:**
- To correct inaccurate information in a memory
- To add tags that were forgotten
- To adjust importance based on new understanding
- To add metadata after the fact

**Examples:**
- update_memory({ memory_id: "abc123", importance: 0.95 })  // Increase importance
- update_memory({ memory_id: "abc123", tags: ["project-x", "critical", "auth"] })  // Add tags
- update_memory({ memory_id: "abc123", content: "Updated: PostgreSQL chosen for ACID + team expertise" })

Confidence score for the memory

New content (replaces existing)

New importance score

Last access timestamp

ID of the memory to update (from store_memory or recall results)

New metadata (merged with existing)

ISO 8601 timestamp when the memory expires or was superseded

ISO 8601 timestamp when the memory becomes valid

New tags (replaces existing)

Override creation timestamp

Memory type classification

Explicit update timestamp

ID of the updated memory

Confirmation message

Update Memory


Render Mermaid diagram syntax into a PNG, SVG, or PDF — or convert it to an editable draw.io (.drawio) file. Returns the result as base64-encoded data (drawio: XML text), or writes it to output_path if given. drawio format supports flowcharts only.

Background colour (CSS colour string or "transparent").

Output format. Defaults to png. drawio produces an editable draw.io XML file (flowcharts only).

Absolute file path to write the result to. When given, the file is written to disk and no base64 data is returned — useful for documents destined for printing or formal submission.

Scale the PDF page to fit the diagram (PDF only).

Mermaid diagram definition (e.g. flowchart, sequenceDiagram, etc.)

Visual theme for the diagram.

Canvas width in pixels (PNG only).


列出用户在 GFT 的全部思维脉络：图名、判断条数、各线新鲜度（哪条线最后什么时候喂过图）。
什么时候调用：本场还没链接任何脉络、需要帮用户选图时；或用户问"我有哪些脉络"。
轻查询,不含节点内容——选定后用 read_thinking_map 读取。

读取用户在 GFT（gitforthought.com）里逐条确认过的思考资产——他的「思维脉络」：已经想通的判断、还悬着的问题、已经否决的方向。
什么时候调用：用户提到他之前的判断/想法/正在纠结的问题时；或你要给出建议、而这个建议应该建立在他已有的思考之上时；或他直接说「读一下我的脉络」时。
一场会话拉一次即可——内容不会在对话中途改变，反复调用只是浪费用户的 token。
选图：本场聊过哪张就继续用哪张；语境不明且用户没指名时，把返回里列出的可选项目报给用户挑，**不要赌"最近更新的那张"**——那可能是用户在别的 session 里喂的图。
若用户要把这场对话的新判断存进脉络，用 for_update=true 再调一次：会额外返回抽取规则和旧图别名，按那份规则抽完再调 submit_map_update。

要往脉络里补新判断时传 true，会附带抽取规则与旧图别名。默认 false。

按项目名模糊匹配指定读哪张脉络。不传 = 最近更新的那张（多数情况不用传）。

把这场对话里长出来的新判断增量并入用户的思维脉络。
**必须先调 read_thinking_map(for_update=true)**，拿到抽取规则和旧图别名，按那份规则抽出 <node/> / <edge/> 标签后，原样传进 tags。
规则由 GFT 定，你只出算力：只抽用户真说了的判断，你自己的分析除非他明确接住否则不上图；旧节点一律不重输出；没有新东西就传 <noop/>。

你这条对话线的稳定标识（如工作目录名或话题名）。同一张图可能被多个 session 喂,水位按此分开记,别省略。

本次抽到哪的标记，下次接着走。例："2026-08-05 关于 MCP 外接的讨论，至第 40 轮"。

写进哪张脉络，同 read_thinking_map。不传 = 最近更新的那张。

按规则抽出的标签原文，一行一个，如：<node id="m1" title="..." body="..."/> 与 <edge from="n2" to="m1"/>。没有新东西时传 <noop/>。


Obtener la documentación pública, especificación técnica y guía de integración del API Animus Engine / Bralidus RaaS (NO REQUIERE AUTENTICACIÓN NI API KEY). Úsalo primero si el usuario pregunta por documentación o cómo integrar.

Obtener el catálogo completo multi-proveedor de series económicas almacenadas en base de datos (CMF, SII, BCCh, FRED).

Obtener indicadores macroeconómicos chilenos normalizados en tiempo real (UF diaria de la CMF, UTM, TPM, etc.).

Consulta en lenguaje natural al Grafo de Conocimiento MoE (Mixture of Experts) de Animus Engine (ej: "¿Cuál es la Tasa de Política Monetaria en Chile?")

Consulta en lenguaje natural al Grafo de Conocimiento MoE (ej: "¿Cuál es la Tasa de Política Monetaria fijada por el Banco Central en Chile?")

Ficha completa de UNA oportunidad. Usar después de `animus_mp_oportunidades`, cuando ya se identificó cuál interesa y hace falta el detalle que el listado no trae.
TRAE: cronograma completo (publicación, cierre, foro de preguntas, publicación de respuestas, apertura técnica y económica, adjudicación estimada), comprador con RUT, región, comuna, dirección y encargado, monto con su visibilidad, e ítems por línea.
COBERTURA REAL — no asumir que un campo vacío es un error:
· Ítems: presentes en el 87,7 % de las compras ágiles pero sólo en el 21,3 % de las licitaciones (medido 2026-08-12).
· `attachments`: los documentos NO SON DESCARGABLES por API en ninguna vía, y el campo lo declara con `descargable: false`. En Compra Ágil hay 31.906 fichas con la LISTA de documentos (`id` y `nombre`, `url` en null); 936 de las 1.162 abiertas la traen. En licitación hay 5.584 con `url`, pero ese enlace devuelve una página con captcha, no un archivo — y ninguna de las 2.273 abiertas lo tiene. Para leer las bases hay que abrir la ficha web (`official_url`): no ofrezcas descargar un adjunto ni digas que el enlace sirve.
· `amount_estimated = 0` NO significa que no haya presupuesto: mirar `amount_is_public` (false = el organismo lo ocultó) y `amount_estimation_type` (3 = no estimable).
· Contacto SÍ disponible en licitación: contacto del comprador 100 %, dirección 92 %, nombre del responsable de contrato 90 %.
· Visita a terreno, entrega de antecedentes y EMAIL del responsable: MP devuelve la clave pero nunca la llena — 0 de 15.983 fichas. No es un fallo de ingesta, la fuente va vacía.
NO EXISTEN en esta fuente, no los inventes ni los busques en otra herramienta: criterios de evaluación con ponderación, garantías exigidas y requisitos de habilidad de los oferentes.

Código externo tal como lo devuelve el buscador en `external_code` (ej: "4429-45-L126" para licitación, "1233619-464-COT26" para compra ágil).

La COMPETENCIA real de las compras del Estado: quién cotizó, por cuánto, quién ganó y con qué argumento se declaró inadmisible al resto. Requiere `codigo` (para ver quiénes compitieron por una compra) o `rut` (para ver cómo le va a un proveedor, con su tasa de adjudicación).
COBERTURA (medida 2026-08-12): 16.919 ofertas de 3.990 proveedores sobre 3.122 compras, con 2.633 adjudicaciones y 2.583 motivos de inadmisibilidad.
LÍMITE: sólo compras ágiles concluidas. Licitaciones, convenios marco y tratos directos no publican oferentes en esta fuente, y las compras aún abiertas todavía no los muestran: hay datos de 3.122 de las 44.545 compras ágiles (7 %). Un `codigo` sin ofertas casi siempre significa que el proceso sigue abierto o no es compra ágil, no que nadie se haya presentado.

external_code de una compra ágil. Devuelve TODOS los que cotizaron por ella.

Default 20.

RUT del proveedor, con o sin puntos. Devuelve su historial y su tasa de adjudicación.

Sólo las ofertas que ganaron.

Buscador UNIFICADO de compras del Estado de Chile (Mercado Público). Es la puerta de entrada a las cuatro vías por las que el Estado compra, en una sola consulta. Usar siempre que no se sepa de antemano por cuál se publicó lo que se busca.

Monto estimado máximo. OJO: filtrar por monto EXCLUYE los procesos con presupuesto oculto (amount_is_public = false), porque su 0 no es un cero real.

Monto estimado mínimo, en la moneda del proceso.

Nombre del organismo, coincidencia parcial.

RUT del organismo comprador, exacto.

Cierre desde (ISO 8601, ej: 2026-08-20).

Cierre hasta (ISO 8601).

asc | desc. Por defecto desc.

Default 20, máximo 100. Cada ítem es voluminoso.

Término de búsqueda libre sobre el título.

Coincidencia parcial. Ej: "Biobío", "Metropolitana".

closing_at | published_at | amount_estimated. Por defecto published_at. Para "las que cierran primero": sort=closing_at con order=asc.

publicada (32.146) | cerrada (16.293) | adjudicada (8.483) | revocada (1.804) | desierta (1.802). Coincidencia exacta.

Vía de compra. Omitir para buscar en las cuatro. tender = licitación tradicional (15.669). agile_purchase = compra ágil, monto menor y proceso rápido (44.545). convenio_marco = compra contra catálogo ya licitado (274). trato_directo = adjudicación SIN competencia, por excepción legal (40) — es la vía con menos competencia y la de mayor interés para auditoría. Total 60.528 al 2026-08-12.

Órdenes de compra del Estado de Chile: quién COBRÓ efectivamente, cuánto y contra qué licitación. Es la etapa siguiente a la adjudicación — `animus_mp_ofertas` dice quién ganó, esta dice quién terminó facturando.
COBERTURA (medida 2026-08-12): 124.868 órdenes con contenido, 21.621 proveedores y 1.129 organismos, entre 2016-09-22 y 2026-08-11. Es el dataset más profundo de Mercado Público: las ofertas cubren 16 días, esto cubre 10 años.
CRUCE CON LA LICITACIÓN: posible, pero en pocos casos. `licitation_code` nunca es null y eso engaña: 72.708 de las 124.868 vienen como cadena VACÍA, sólo 52.160 traen un código, y de esos apenas **3.159 corresponden a una licitación que tengamos**. La causa es el desfase de ventanas: estas órdenes arrancan en 2016 y la tabla de licitaciones cubre lo reciente. Comprobá que `licitation_code` no venga vacío antes de intentar el cruce, y no interpretes un cruce fallido como que la orden no tuvo licitación.
PENDIENTE DE ENRIQUECIMIENTO: hay 43.961 órdenes más que todavía sólo tienen identificador. NO se devuelven —serían un código con forma de dato— y su cantidad viaja en `meta.enriquecimiento_pendiente`. Se completan solas: el job drena ~5.000/día. Un total que no cuadra con otra fuente casi siempre es esto, no un error de tu consulta.

Código del organismo comprador.

Código numérico, no texto: 12 = Recepción Conforme (76.827) · 6 = Aceptada (41.611) · 4 = Nueva orden (3.672) · 9 = Cancelada (1.797) · 11 = No aceptada (562) · 5 = En proceso (399). El nombre legible viene en `supplier_state_label`.

Emitidas desde (ISO 8601, ej: 2026-01-01).

Emitidas hasta (ISO 8601).

Default 20, máximo 100.

RUT del proveedor que cobró. Devuelve todo lo que le compró el Estado.

Directorio de entidades compradoras del Estado de Chile: 1.786 al 2026-08-12. Una fila por RUT comprador, con `nombre`, `region`, `compras`, `compras_abiertas`, `ultima_publicacion`, `vias` (por qué canales compra) y `codigos_organismo` (los identificadores internos que aparecen en la ficha oficial de Mercado Público).
Ordenado por volumen de compras, no alfabéticamente. Buscar por `nombre` parcial o `rut` exacto. `meta.total` cuenta organismos, no compras.

Búsqueda parcial por nombre. Ej: "MINEDUC", "MUNICIPALIDAD".

Default 20, máximo 100.

RUT del comprador, exacto. Ej: "60.910.000-1".

Precios de referencia por producto: cuánto se paga en el Estado, según lo que realmente cotizaron los proveedores.
CÓMO LEER EL RESULTADO: usa `mediana` junto al rango `p25`–`p75`, nunca mínimo/máximo. Cada fila trae `fiabilidad` y `ratio_p75_p25`: si el ratio es alto, ese código UNSPSC agrupa productos distintos y la mediana NO es un precio, es el promedio de cosas que no se comparan. No presentes un número sin mirar antes esa señal.

Código UNSPSC exacto, si ya se conoce.

Mínimo de cotizaciones para incluir un código. Default 5.

Búsqueda por nombre de producto. Ej: "guantes", "toner", "papel".

Historia completa de UNA causa de la Corte Suprema. Devuelve un ARREGLO: la misma causa puede figurar como ingresada, en inventario y con más de un término, con distinto resultado cada vez. No asumir que la primera fila es la definitiva.

Año del rol.

Ej: Reforma, Civil, Criminal, Familia.

Número de rol.

Causas individuales de la Corte Suprema con rol, libro, tipo de recurso, sala y fechas. Usar para revisar los casos concretos detrás de una cifra agregada.

Coincidencia EXACTA, no parcial: Confirmados, Revocados, Rechazados, Inadmisibles, Acogidos, Desistidos. La lista no es exhaustiva y un valor inexistente devuelve 0 filas sin error.

Máximo 200.

Coincidencia parcial.

terminos_suprema_detalle (falladas) | ingresos_recursos_suprema_detalle (ingresadas) | inventario_suprema_detalle (pendientes). Otro valor devuelve 400.

Coincidencia parcial.

Series AGREGADAS del Poder Judicial: presupuesto, dotación, adquisiciones y cuenta pública. Distintas de las causas individuales — acá no hay roles ni fallos, son totales institucionales.

Coincidencia parcial. Ej: "cuenta-publica", "presupuesto", "adquisiciones".

Totales de la Corte Suprema por año, serie, libro, tipo de recurso, sala y grupo de término. Usar para ver la distribución global antes de pedir el detalle.

Año a consultar. Sin esto agrega los seis años.

terminos_suprema_detalle (falladas) | ingresos_recursos_suprema_detalle (ingresadas) | inventario_suprema_detalle (pendientes). Sin esto mezcla las tres.

Serie por año de la Corte Suprema de Chile (2020-2025): causas falladas, % confirmados, % revocados y duración media entre ingreso y fallo. Filtrable por libro, tipo de recurso y sala. OJO: cubre SOLO causas ya falladas; no mide causas pendientes ni permite restar ingresos menos términos del mismo año, porque una causa ingresada un año puede fallarse en otro.

Civil, Criminal, Familia, Reforma Laboral, etc.

Coincidencia parcial. Ej: "CONSTITUCIONAL", "PENAL", "MIXTA".

Coincidencia parcial. Ej: "Protección", "Amparo", "Casación".

Búsqueda semántica (Vector RAG) en la Base de Conocimiento con síntesis en Markdown y citas fehacientes de leyes y normas chilenas.

Búsqueda semántica en el Knowledge Base normativo con síntesis markdown y citas fehacientes (ej: "Regulación Ley Fintech 21.521 en Chile")


Extract every URL from a document, with its protocol and 1-based line and column. Reads any text document. Markdown, HTML, CSS, JavaScript, TypeScript, JSON, YAML, Properties, TOML, INI and XML know what to exclude — code fences, comments, non-string tokens; everything else is scanned whole, and `fileType` says which happened.

The document text to scan.

Collapse repeated URLs to their first occurrence.

Filename used to infer the format when `format` is absent, e.g. "README.md".

Document format. Provide this or `filename`. Common extensions and aliases are accepted; anything else is scanned as plain text rather than refused.

markdown html css javascript typescript json yaml properties toml ini xml csv plaintext

Cap on returned URLs (default 500). meta.truncated reports whether any were dropped.


Take a snapshot of the project's database (and storage files) before risky data changes — schema migrations, bulk updates, deletions. The user can restore or download it from Settings → Backups.

Create a new Plyo project and link the current folder to it. Existing files stay untouched; use save_checkpoint afterwards to store them.

Human-friendly project name, e.g. 'Sunrise Yoga'

Get the most recent build's status, and if it failed, the plain-English error and the fix guidance.

Fix instructions the user queued for you from Plyo (they pointed at problems on their site). Call once at session start. Returns each task once.

Show the project's recent checkpoints (the timeline) with what changed in each.

Link the current folder to an existing Plyo project by slug.

The project slug, from list_projects

List the user's Plyo projects (name, slug, live URL).

publish

Publish the project's latest checkpoint to its live URL. Waits for the result; on failure, returns a plain-English cause plus a fix you can act on.

restore

Restore the project to an earlier checkpoint. Never destructive: a new checkpoint is created and everything stays on the timeline.

Checkpoint id from get_timeline

Save the current state of the project as a checkpoint on the user's Plyo timeline. Call this after completing a piece of work.

One sentence summarizing what the user actually asked for, in their own words, e.g. 'Make the pricing page feel more premium and add a yearly toggle'. Always pass this — it becomes the project's memory of why changes were made.

One plain-English sentence describing what changed, written for a non-technical user, e.g. 'Added a pricing page with three plans'

Start a Draft — a safe copy of the project to try changes without touching the live version. Switches this folder to the draft. If the user already started a draft in Plyo, pass its exact name and this folder joins it instead of creating a new one.

What this draft tries, e.g. 'Trying a new pricing page'


attachMedia

Attach media by URL

JSON request body.

Product id.

bulkCreateProducts

Bulk-create products — Accepts up to 500 products and processes them asynchronously. Poll the returned job for progress.

JSON request body.

Custom attributes by handle. Native/category/variant handles are rejected (422).

Brand name (auto-created). null clears it.

Category names (auto-created) or ids.

Convenience price for the default variant (create only).

Defaults to a slug of the title if omitted.

Optional inline variants to create with the product (create only).

Vendor name (auto-created). null clears it.

clearProductOverrides

Clear store-specific overrides

JSON request body.

Targets a store context. Provide `channel` OR `group` (omit both for canonical), plus optional `locale`.

Product id.

createAttribute

Create a custom attribute

JSON request body.

Whether the attribute can hold per-locale values.

Attribute type id (defaults to 1 = single-line text). Restricted to safe text-ish types; variant-option type 13 is never allowed.

createBrand

Create a brand

JSON request body.

createCategory

Create a category

JSON request body.

createProduct

Create a product

JSON request body.

Category names (auto-created) or ids.

createVariant

Add a variant

JSON request body.

Product id.

createVendor

Create a vendor

JSON request body.

createWebhookEndpoint

Create a webhook endpoint — The signing `secret` is returned **once** in this response and never again. Store it to verify signatures.

JSON request body.

Defaults to all events if omitted.

deleteAttribute

Delete a custom attribute

Resource id.

deleteBrand

Delete a brand

Resource id.

deleteCategory

Delete a category

Resource id.

deleteMedia

Remove media from a product

Product id.

deleteProduct

Delete a product

Product id.

deleteVariant

Delete a variant

Variant id.

deleteVendor

Delete a vendor

Resource id.

deleteWebhookEndpoint

Delete a webhook endpoint

getJob

Get job status

Resource id.

getProduct

Retrieve a product

Channel (store) id — layers that store's overrides on top.

Channel-group id — layers the group's overrides on top.

Locale code (e.g. `fr`). Returns/writes that locale's values, falling back to the primary.

Product id.

getVariantInventory

Get a variant's inventory

Variant id.

getVariantPrices

List a variant's market prices

Variant id.

getWebhookDelivery

Retrieve a delivery

getWebhookEndpoint

Retrieve a webhook endpoint

listAttributes

List custom attributes — Returns custom product attributes only (native/category/variant-scope excluded).

Opaque cursor from a previous response's `meta.next_cursor`.

Items per page for reference lists (1–200).

listBrands

List brands

listCategories

List categories

listChannelGroups

List channel groups

listChannelMarkets

List a channel's markets

listChannels

List channels (stores)

listLocales

List locales

listProducts

List products

Free-text search across SKU, variant SKU/name, and attribute values.

Substring match on SKU.

Filter by status.

ISO-8601 timestamp — only products updated at/after this time.

Comma-separated extra relations to embed (`variants`, `media`).

Items per page (1–100).

listVendors

List vendors

listWebhookDeliveries

List webhook deliveries

Items per page (1–100).

pending success failed exhausted skipped

listWebhookEndpoints

List webhook endpoints

ping

Health/diagnostic check — Confirms the key authenticates and returns the resolved organization.

redeliverWebhook

Redeliver an event

setProductOverrides

Set store-specific overrides — Override native fields (title/description/seo) for a specific channel or
channel-group, optionally for one locale. Omitted fields are untouched.

JSON request body.

Product id.

setVariantInventory

Set a variant's inventory — Update per-location quantities and/or the variant's tracking settings.

JSON request body.

Allow overselling when out of stock.

A channel-location id (see GET inventory). Unknown/cross-org locations are ignored.

Per-state quantities to write. Keys are inventory states;
only the writable states are applied (`committed` is
read-only — it is set by orders). Any other key is ignored.

Whether Apimio tracks this variant's quantity.

Variant id.

setVariantPrices

Set a variant's market prices — Upsert prices per market. A price of `0`/`null` deletes the override so that market inherits the canonical price.

JSON request body.

Market id. Unknown/cross-org markets are ignored.

Per-market price. 0/null clears the override (inherit canonical).

Variant id.

testWebhookEndpoint

Send a test (ping) event

updateBrand

Update a brand

JSON request body.

Resource id.

updateCategory

Update a category

JSON request body.

Resource id.

updateProduct

Update a product — Only the fields you send are changed. Send `null` to clear a relation.

JSON request body.

Category names (auto-created) or ids.

Product id.

updateVariant

Update a variant

JSON request body.

Variant id.

updateVendor

Update a vendor

JSON request body.

Resource id.

updateWebhookEndpoint

Update a webhook endpoint

JSON request body.

Defaults to all events if omitted.


Analyze video

Ask a question about a video (POST /v1/analyses). Provide video_id (video_…) and a free-text prompt like "Is there a person in this video?". Analysis runs asynchronously — use wait_for_analysis to block until done. The result contains answer (yes|no|indeterminate), confidence (0-1), clip timestamps, detected_count (count queries), and indeterminate_reason. Recommended: call validate_analysis first to confirm the prompt is assessable and preview the cost before spending credits. For 2–10 prompts on the same video, use create_analysis_batch (each prompt after the first is billed at 50%).

Optional key-value metadata to attach.

Model id (see list_models). Defaults to the current default model.

Free-text question about the video, e.g. "Is there a person in this video?"

The video to analyze (video_… id from create_video_from_url).

Compiled interpretation of the prompt (subjects, conditions, query_type, search_terms, prompt_intent, original_prompt, …). Transparency feature: shows how the question was understood.

Count-intent queries only. 0 = assessable but nothing found. confidence applies to the count itself.

Present when answer is indeterminate. low_confidence: retry with a more specific prompt. nothing_detected: genuinely empty. unsupported_query_form: rephrase as yes/no or count. duration_mismatch: result untrusted.

object action compound attribute open_ended

Null when the source duration could not be determined.

queued preparing analyzing rendering completed failed canceled

Terminal only. Immutable snapshot of the balance after THIS analysis settled.

id object livemode origin status video_id prompt query parse_mode model options progress queue_position result narrative artifacts error usage created_at started_at completed_at

Analyze video with multiple prompts (batch discount)

Run 2–10 prompts against the SAME video in one call (POST /v1/analyses/batch). Pricing: the first prompt is billed at full price, each additional prompt at 50% — always cheaper than separate create_analysis calls for multi-question workloads. Returns an analysis_batch with every analysis resource plus a pricing summary; poll each analysis id individually with get_analysis or wait_for_analysis. To check assessability of individual prompts first, use validate_analysis (free).

Optional key-value metadata attached to every analysis in the batch.

2–10 free-text prompts. First is full price; each additional is billed at 50%.

The video to analyze (video_… id).

Compiled interpretation of the prompt (subjects, conditions, query_type, search_terms, prompt_intent, original_prompt, …). Transparency feature: shows how the question was understood.

Ingest video from URL

Register a video from a public https URL for analysis (POST /v1/videos, URL-ingest mode). The API fetches the video asynchronously — the returned video starts in status "processing" and becomes "ready". Supports video/mp4 and video/quicktime, max 2 GiB. Returns the video resource with its id (video_…).

Optional key-value metadata to attach.

Public https URL of the video to ingest (https only, port 443).

awaiting_upload uploading processing ready failed

id object status filename size_bytes duration_s width height fps content_type source upload error expires_at created_at

Get analysis result

Fetch an analysis by id (GET /v1/analyses/{id}). While running, shows live progress and queue_position. When status is "completed": result.answer (yes|no|indeterminate), result.confidence (for count queries this is confidence in the count itself), result.clips, result.detected_count (count-intent queries only; 0 = assessable but nothing found), result.indeterminate_reason (low_confidence — retry with a more specific prompt; nothing_detected — genuinely empty; unsupported_query_form — rephrase as yes/no or count; duration_mismatch — result untrusted), and result.video_duration_s (null when duration could not be determined). usage is {billed_seconds, credit_balance_after} — an immutable post-settlement snapshot.

The analysis id (an_…).

Compiled interpretation of the prompt (subjects, conditions, query_type, search_terms, prompt_intent, original_prompt, …). Transparency feature: shows how the question was understood.

Get credit balance & transaction history

Get the credit balance and transaction ledger for this API key (GET /v1/credits). Returns balance_seconds (the authoritative balance, in billable seconds), grant_seconds, used_seconds, and a paginated transaction list where each debit carries the analysis/stream id it came from (source_id, source_type). Use this to audit what each analysis cost, check the balance before a batch job, or diagnose an insufficient_credits error.

Cursor — return transactions older than this id.

Transactions per page (default 20).

Seconds of analysis remaining. The authoritative balance.

e.g. signup_grant, analysis_debit, stream_debit, purchase.

Signed: negative debits, positive credits.

The analysis/stream id a debit came from.

Get test fixture

Get the stable test fixture (GET /v1/test-fixture): a video URL + prompt + expected answer for verifying an integration end-to-end without burning quota. Test-mode (pv_test_) keys return deterministic canned results.

Get usage & credit balance

Get credit balance and period usage meters for the current API key (GET /v1/usage). Use this after an insufficient_credits error to report the balance. For the per-analysis transaction ledger (what each analysis cost, with source ids), use get_credits instead.

Authoritative usage meters (credit_seconds balance, period meters).

List analysis models

List available analysis models (GET /v1/models) with status (stable | preview | deprecated) and capabilities. Use the model marked default:true unless you have a reason not to.

id object status default capabilities sunset_at created_at

Validate prompt & preview cost (free)

Dry-run a prompt WITHOUT creating an analysis or spending credits (POST /v1/analyses with validate_only: true). Compiles the prompt and returns an analysis_preview: the compiled query, assessable (false means the model cannot score this query form — rephrase as a yes/no or count question), estimated_seconds, and estimated_cost_usd (both null when the video duration is not yet known). Recommended before create_analysis to catch unassessable prompts and preview cost.

Free-text question to validate, e.g. "How many people are walking?"

The video the analysis would run against (video_… id).

False means the model cannot score this query form — rephrase as yes/no or count.

Null when the video duration is not yet known.

Wait for analysis to finish

Block until an analysis reaches a terminal state (completed | failed | canceled), polling GET /v1/analyses/{id}. Returns { analysis, retry }: retry is null when the analysis reached a terminal state, or carries timeout guidance when the wait expired (call again). Default timeout 120s (test-mode analyses complete in seconds). On completion, see get_analysis for the full result field semantics (detected_count, indeterminate_reason, nullable video_duration_s, usage snapshot).

The analysis id (an_…).

Max seconds to wait (default 120).

Compiled interpretation of the prompt (subjects, conditions, query_type, search_terms, prompt_intent, original_prompt, …). Transparency feature: shows how the question was understood.

Null when the analysis reached a terminal state. Set when the wait timed out — call wait_for_analysis or get_analysis again.


Call an API from the apipay catalog by slug (find slugs with search_apis). The cost in prepaid credits is deducted automatically and returned with the result.

Params object per the API's manifest, e.g. {"q": "latest AI news"}

API slug from search_apis, e.g. "web-search"

Check the remaining apipay prepaid credit balance (1 credit = $0.01) and get the top-up link.

Get a secure one-time link where the user can save their OWN API key for a provider (BYOK). Use when the user wants to use their existing key (e.g. their fal.ai key) with apipay, or when an API says it is not configured. Never ask the user to paste an API key into the chat — always use this link instead. BYOK calls cost a flat 0.1 credits; the user's own provider account pays the provider.

API slug from search_apis, e.g. "fal"

Search the apipay catalog of ready-to-call APIs (web search, scraping, weather, and more). Returns each API's slug, params, and per-call price in prepaid credits. Every miss is logged so missing APIs get added.

What kind of API you need, in plain words, e.g. "search the web"


ask-claude

Ask Claude

Send a prompt to Anthropic Claude Code CLI for an independent second opinion, code review, or architecture critique. Defaults to opus with sonnet fallback. Claude runs in safe mode with only Read, Glob, and Grep tools, so it can inspect context but cannot edit files or execute commands. Supports native sessions via sessionId and returns a structured AskResponse.

Additional relative directories Claude may read alongside the working directory. Claude remains restricted to Read, Glob, and Grep tools.

Do not set this parameter unless the user explicitly requests a Claude model. Defaults to opus, with sonnet as the CLI fallback.

The question, code review request, or analysis task to send to Anthropic Claude Code CLI

Optional Claude conversation ID to resume. Pass the [Session ID: ...] value from a previous response to continue with native Claude session context.

gemini codex claude grok ollama antigravity

get-usage-stats

Get Usage Stats

Get the current MCP server's session usage stats: total LLM calls, token totals (input/output/thinking/cached), wall time, and breakdowns per provider and per model. No data leaves your machine — counts are tracked in-memory for the lifetime of the server process. Returns both human-readable markdown and a structured JSON snapshot via outputSchema.

calls inputTokens outputTokens cachedTokens thinkingTokens durationMs fellBack

totalCalls totalInputTokens totalOutputTokens totalCachedTokens totalThinkingTokens totalDurationMs fallbackCount byProvider byModel

ping

Ping

Test connectivity with the Claude MCP server and check whether Claude Code CLI is installed

A message to echo back while testing Claude CLI availability


Create a new entry in a collection type. 'data' must be a JSON object matching that content type's fields.

Field values as a JSON object, e.g. { "title": "Hello", "body": "..." }

Plural API ID, e.g. 'pages', 'articles'

Strapi v5 draft and publish status (default: 'published' or draft)

Create Strapi Entry

Permanently delete an entry by id or documentId. This cannot be undone.

The entry's id or documentId

Plural API ID, e.g. 'pages', 'articles'

Delete Strapi Entry

Fetch a list of entries for a collection type. Use the PLURAL API ID (e.g. 'articles', 'pages', 'products'). Supports pagination, filters, populate, sorting, and draft/published status.

Optional raw Strapi filter query string, e.g. 'filters[title][$contains]=hello'

Page number (pagination)

Results per page

Plural API ID of the collection type, e.g. 'pages', 'articles'

Optional relations/media to populate, e.g. '*' for all, or 'author,image'

Optional sort string, e.g. 'createdAt:desc' or 'title:asc'

Strapi v5 draft and publish status: 'draft' or 'published' (default is published)

Get Strapi Entries

Fetch a single collection entry by its numeric ID or documentId (Strapi v5).

The entry's id or documentId

Plural API ID, e.g. 'pages', 'articles'

Strapi v5 draft status: 'draft' or 'published'

Get Single Strapi Entry

Fetch data for a Single Type (e.g. 'homepage', 'navigation', 'footer', 'global').

Optional populate parameter, e.g. '*'

Singular API ID of the single type, e.g. 'homepage', 'footer'

Strapi v5 status: 'draft' or 'published'

Get Strapi Single Type

Execute a direct GET, POST, PUT, or DELETE request against any Strapi API endpoint (e.g. '/users', '/custom-route').

Optional JSON payload for POST/PUT requests

The API path relative to /api, e.g. '/users' or '/pages?populate=*'

Raw Strapi API Request

Checks that this MCP server can reach your Strapi instance. Always run this first.

Test Strapi Connection

Update fields on an existing collection entry by documentId or id.

Only the fields you want to change, as a JSON object

The entry's documentId (or numeric ID)

Plural API ID, e.g. 'pages', 'articles'

Update Strapi Entry

Update data for a Single Type (e.g. 'homepage', 'navigation', 'footer').

Field values to update as a JSON object

Update Strapi Single Type