Pletor

Showing 25 of 58 from the live probe.

• Search Workflows

  Search the user's workflows by name, tags, agent types, or visibility. Use when the user asks to find, list, or pick a workflow. **By default, search the user's own workflows: pass `visibility: ["private", "shared"]`. Only include `"public"` when the user explicitly asks for the public template/showcase gallery (workflows published by other organizations) — otherwise that gallery buries the user's own workflows.** Returns a paginated list of `{id, name, description, tags, visibility, agent_types

• Get Workflow Definition

  Fetch a workflow's full definition by id. Use when the user wants to inspect what a workflow does, see its variables, or share its structure. Returns `{name, description, inputs, dsl}` where `inputs` lists the workflow's user inputs with a `required` flag saying which ones a run must supply, and `dsl` is a compact textual representation of nodes and edges suitable for LLM reasoning. Pass the workflow `id` from search_workflows. After calling, surface the workflow's purpose and inputs to the user

• Run Workflow

  Start a workflow run asynchronously. Use when the user asks to run, execute, or generate with a specific workflow. Before calling, qualify the user's intent — running a workflow with a literal prompt the user mentioned in passing usually produces a bad output. First call `get_workflow_definition` to see the real input labels, then ask the user a short, scannable set of questions covering: (1) creative direction — style, mood, composition for visual outputs; tone, length, register for text; (2) t

• Prepare Batch

  Prepare a draft batch run for a workflow. The default run tool is `run_workflow` — only use `prepare_batch` when the user wants either (a) more than ~10 runs of the same workflow with varying inputs, or (b) an asset-review step in Pletor so they can keep/discard each row before downloading. For single runs and small counts (2–~8) always prefer looping `run_workflow`; never reach for batch on 2–3 generations. Before calling, qualify the user's intent — batches with the wrong rows waste time and c

• Run Batch

  Start a draft batch previously created with `prepare_batch`. Only draft batches can be started — once started the batch transitions out of draft and individual row runs begin asynchronously and consume credits. ALWAYS get the user's explicit confirmation before calling this tool — never start a batch on your own initiative. First show a short summary (row count, target workflow) together with the batch's `review_url` so the user can open it in Pletor AI to preview the inputs, then wait for an ex

• Search Pletor Docs

  Search the Pletor product documentation for information about nodes, models, workflows, and platform features. Use when the user asks how something works, what a node does, which models are supported, or for guidance on building workflows. Returns `{source, results}` where `results` is an array of relevant documentation excerpts. Pass a focused, natural-language `query`; specific terms (node name, model name, feature) work better than broad questions. After calling, summarize the relevant excerp

• Diagnose Run

  Diagnose a workflow run or single node run in one call. Use when the user asks why a run failed, what is happening with their run, or what went wrong with a node. Returns a flat report `{flow_run, diagnosis, node_runs?}` with a verdict (`succeeded` / `failed` / `in_progress` / `canceled` / `partially_completed`), optional `failed_node` detail, optional `last_successful_node`, and a `suggested_action` string. Provide exactly ONE of `flow_run_id` (for full-run diagnosis) or `node_run_id` (for deep

• Plan Image Generation

  Plan an image generation before spending credits — the intent-refinement gate. Use this BEFORE generate_image whenever the user's request is worth confirming (most non-trivial generations). First gather any missing details (subject, style, mood, composition, model, aspect ratio, how many) by asking the user; if intent is vague, ask clarifying questions rather than inventing a subject. Then write a richer `enhanced_prompt` from their request and call this tool. It returns an editable plan: the ch

• Get Flow Run Status

  Check the status of a workflow run. Returns the current status and node run summaries. Terminal statuses: 'completed', 'failed', 'canceled'. A run with status 'failed' may include `run_error` with the failure message.

• Get Node Run Result

  Get the full result of a node run including generated assets. Returns the run's current `status` — poll until it reads 'completed' before using the assets. A failed or canceled run returns an error with its failure reason and `terminal: true`; stop polling it — repeatedly polling a terminal run trips a circuit breaker (`poll_circuit_open`) that rejects further calls. When present, `truncations` reports any input silently trimmed to fit the model's limits (an over-long prompt or too many input as

• Upload Asset

  Upload a remote file to Pletor as an asset by providing a public http(s) URL the server fetches — a link the user pasted, an image hosted somewhere, an output of an external service. Not for a file on a local machine, which has no URL this server can reach: from a CLI or agent host, upload it yourself with `prepare_media_upload` → PUT → `confirm_media_upload`; in a chat host where the user must pick the file from their device, render the `upload_media` widget. Returns an asset_id ready for use i

• Find Models

  Verify one or more AI models by fuzzy name search, in a single call. Accepts partial names, abbreviations, or misspelled queries and returns, per query, the matching Pletor models ranked by confidence. A query with no matches means that model is NOT available on Pletor. Call this before telling the user about any model that is not in your curated platform guidance — pass every candidate name at once.

• Read Brain Playbook

  Read the playbooks for authoring a Pletor Brain well. Call it with no arguments to see what there is, then by name. If your host loads MCP skills, you already have these as `skill://` resources and don't need this tool — it is the same text. Read `brain-authoring` before your first write to any Brain: a Brain written without it comes out as a document dump rather than something a generation agent can use.

• List Brains

  List the Brains in the user's active organization. A Brain is the user's knowledge base — brand identity, guidelines, product facts — organized as Memories. Use this to find a `brain_id`, then `summarize_brain` to see what a Brain holds and `read_brain_memory` to read a specific Memory. Brains are scoped to the active organization: if the user expects a Brain that isn't listed, it may live in another workspace — call `list_my_organizations` / `switch_organization` first.

• Summarize Brain

  Get a Brain's shape: every Memory it holds as an indented tree, with each Memory's path, description, and asset count. This is the same index the Pletor agent works from. Call it once after picking a `brain_id` from `list_brains` and keep using that id for follow-up calls, then `read_brain_memory` with a printed `path` to read what a specific Memory actually says. `has_authored_content: false` means the Brain is still an empty scaffold — tell the user there's nothing in it yet rather than readin

• Create Brain

  Create a Brain in the user's active organization — one Brain per brand. It arrives with the standard empty skeleton (`identity`, `guidelines`, `knowledge`) and a root Memory, so never create those groups yourself. Pass the brand's website and any files here so the reading starts immediately rather than after a second call. Check `list_brains` first: iterating on the brand's existing Brain is almost always right, and a second Brain for the same brand splits its memory in two.

• Write Brain

  Rename a Brain or change its one-line description. The name is the brand's identity everywhere it appears, including the root Memory's title, so only change it when the brand itself changed or the user asks.

• Delete Brain

  Delete a whole Brain — every Memory, every product, every collection, every source. This is the most destructive thing you can do to this account's brand memory, it cannot be undone, and every workflow bound to the Brain loses what it reads. Only call it when the user has named the Brain and asked for it to be deleted; never as cleanup after a mistake of your own, where the fix is to correct the Memories.

• Read Brain Memory

  Read one Memory from a Brain — its full markdown (with frontmatter) plus any attached media, so images like logos or palettes come back inline. Pass a `path` printed by `summarize_brain`; omit `path` to read the Brain's root Memory, which is the overview to start from. A Memory of kind `brand_kit` carries its logo variants and colour palettes under `brand_kit` rather than `assets`. Read the specific Memories the user's question touches rather than the whole Brain.

• Write Brain Memory

  Create or update one Memory in a Brain. **An omitted field keeps what is stored** — attaching images to a Memory that already reads well costs `path` and `assets`, nothing else — so never re-send prose you did not change, and never send an empty `body` to mean 'leave it'. Read the Memory first (`read_brain_memory`) whenever you are editing rather than creating, and merge. Writing a nested path auto-creates its ancestors as empty Memories, so write a group before what goes inside it. **Changing `

• Move Brain Memory

  Move a Memory to a new parent, rename its slug, or reorder it among its siblings. Reparenting and renaming are one operation — the new slug is whatever `to_path`'s last segment says — and descendants follow automatically, with every `[[wikilink]]` into the subtree repointed. Reorder in place by sending the same path twice with a new `position`. The Brain's root Memory cannot be moved.

• Delete Brain Memory

  Delete Memories from a Brain. **Each target takes its whole subtree with it** — deleting `identity` deletes everything under it — and the deletion cannot be undone, so confirm the exact paths with the user before calling, and prefer rewriting a Memory over deleting it. Call `summarize_brain` first so you are deleting the path you think you are. The Brain's root Memory cannot be deleted.

• Write Brand Kit

  Write a brand kit — the Memory holding a brand's visual identity as logo variants and colour palettes, drawn as real tiles and swatches. Use this instead of `write_brain_memory` whenever you have logo files or colour values; prose about colours renders as text nobody can use. **This is a full replace of the blocks**: send the complete kit every time, so read the Memory first (`read_brain_memory`) and send its current contents plus your addition. **Never infer a colour** — only write a hex that a

• Search Brain Products

  Find products in a Brain's catalog. The catalog is built to hold a brand's whole range, so its rows are deliberately absent from `summarize_brain` — this is how you see what is already in it, and the only way to get a `product_id`. Always search before writing a product, so you edit the existing row instead of creating a near-duplicate. Rows come back without their long-form body; `read_brain_product` has that. A row's `price.amount` is an integer in the currency's smallest unit — `8900` with `E

• List Brain Product Tags

  Every tag the catalog already uses, most-used first with a count each. Call this before tagging a new product and reuse the vocabulary that is there — a catalog where the same idea is spelled three ways cannot be filtered.