MCP server

Malleable exposes an MCP (Model Context Protocol) server, so Claude and other MCP clients can list, build, edit, and run your workflows from outside the app.

Connecting

  • Endpoint: https://www.usemalleable.com/mcp (streamable HTTP)
  • Authentication: sign in with OAuth 2.0. Point your client at the endpoint and it walks you through a browser sign-in; no key to copy or store. Clients that support MCP's OAuth flow handle this for you.
  • Prefer a token? You can also pass a Malleable API key as a bearer token. Generate one from your account profile (the avatar menu in the top-right of the app).

Either way, tools act as you, so they see and edit the workflows your account can.

Connected, an MCP client can list your workflows, read a workflow's full configuration, build and edit workflows, and start and monitor runs: everything below, acting as your account.

Tools

list_use_casesread-only

List the use cases you can access — your own plus ones shared with your organization. Each entry has the latest published workflow version as publishedWorkflowId (what runs) and — when an in-progress draft exists — its draftWorkflowId. Edit the draft to change work-in-progress. Also returns name and whether the current version has a UI entry point you can run.

create_use_case

Create a new use case owned by you and start building its workflow from a plain-English description — the architect interprets the description and builds the first version. Returns the new useCaseId plus its workflowId; poll get_architect_status to watch it build. NB: a brand-new workflow stays hidden in listings until the architect's first edit promotes it from 'blank' to 'draft'.

describe_workflowread-only

Returns the workflow header and collected data schema, channels, and stages with summarized components (id, subtype, title, description, trigger, collected-data flow). The whole sub-workflow tree is included under subWorkflows. The text block is a markdown rendering; structuredContent carries the same data as JSON.

instruct_architectmakes changes

Send a natural-language instruction to the architect agent to inspect or edit a workflow (add/change stages, components, etc.). You can instruct against any version; an edit to a live (published) version opens a new draft and lands there. Returns immediately with a useCaseId — the architect works asynchronously, so you MUST poll get_architect_status with that useCaseId to read its reply and any pendingInteraction (an approval or question you answer with respond_to_architect).

get_architect_statusread-only

Poll a use case's architect by its useCaseId. Returns the architect's status (running/idle/waiting/error), recentActions (the latest turn's text + tool calls so you can see what the architect did), any pendingInteraction awaiting your response, and activeWorkflowId — the version the architect is working on, which is a new draft once it has edited a live version.

respond_to_architectmakes changes

Answer whatever the architect is waiting on for a use case (addressed by useCaseId). For an approval, pass approvalId and approved (with optional reason). For an interface tool / question, pass toolCallId (and toolName) plus output (an object holding the answer). Returns immediately — the architect resumes asynchronously, so poll get_architect_status for its next reply or pendingInteraction.

run_workflowmakes changestriggers real-world effects

Start an execution of a workflow from any of its entry points (form, timer, webhook, Slack, Teams, email, or agent entry point). Pass entryPointStableId (from describe_workflow) unless the workflow's only start entry point is a form; anything else is never started without being named. Returns an executionId immediately; poll get_execution_status for the result. Optionally pass an input message (the run's first message, written as the event that entry point expects) and/or collectedData.

get_execution_statusread-only

Poll a workflow execution by id. Returns its status, the user-visible screens (the same view the user sees in the UI — entry point + interactive forms/questions/confirmations + progress), currentScreenIndex (the screen the user is being asked to fill out, or null if everything is answered), collected data, and a URL to open the execution in the UI to respond.

read_fileread-only

Read a `malleable://` handle you can access: `fu:<id>` file uploads (chat attachments, workflow files), `to:<id>` stored tool outputs, `ex:<id>/webhook` webhook payloads, and `lm`/`lm:<id>` saved LLM messages. Modes: `raw` returns text contents (images come back inline; other binary files can't be attached over MCP — use `query`); `query` answers a natural-language question about the contents server-side; `grep` searches without returning the whole file; `expression` evaluates a CEL expression over a JSON value (bound to `value`); `overview` summarizes structure (sheet dimensions, PDF page count, image dimensions, JSON shape) without contents; `read-range` pages through xlsx/CSV sheets by A1 range, or saves a page range of a PDF as a new file and returns its handle (PDFs can't be attached over MCP — `query` or `grep` the slice); `sql` runs a SQLite SELECT over an xlsx/CSV's sheets or a JSON value's arrays and returns only the result rows.