MalleableMalleable

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://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_workflowsread-only

List the workflows (use cases) you own. Each entry has the current (live) workflow as workflowId, and — when a separate in-progress draft exists — its draftWorkflowId. Edit the draft to change work-in-progress; the current version is what runs. Also returns name, status, and whether the current version has a UI entry point you can run.

create_workflow

Create a new workflow (use case) owned by you and start building it from a plain-English description — the architect interprets the description and builds the first version. Returns the new workflowId plus a useCaseId; 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

Return a condensed view of a workflow that mirrors the UI's stage cards: workflow header, collectedData keys, and each stage with its components (id, subtype, title, description) plus next-stage links. Sub-workflows are nested the same way.

instruct_architectmakes changes

Send a natural-language instruction to the architect agent to edit a workflow (add/change stages, components, etc.). 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), and any pendingInteraction awaiting your response.

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 via its first-stage UI entry point. Returns an executionId immediately; poll get_execution_status for the result. Optionally pass an input message and/or collectedData for the entry point.

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.