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.

Looking for the other direction, the apps your workflows can connect to? See the integrations directory.

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.