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-onlyList 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_caseCreate 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-onlyReturns 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 changesSend 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-onlyPoll 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 changesAnswer 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 effectsStart 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-onlyPoll 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-onlyRead 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.