- MCP is the connection. Your editor's coding agent builds the pipeline against WaveAssist's runtime primitives.
- response_model locks the shape. The model fills the content, the contract keeps every run the same.
- Tested before armed. The schedule arms only after a green run on live data.
- Runs as code, not full inference every tick. Less than a cent per run, stateful across runs, vendor-neutral.
Your coding agent is good at building things. Ask Claude Code or Cursor to write an agent that reads your ClickUp and emails you a Monday summary, and it will. The trouble starts after it works once. It lives in your editor. It reruns full inference on every tick. And the next run can drift from the last, because nothing pins the shape of the output.
WaveAssist closes that gap. It is the deterministic runtime your coding agent talks to over MCP. The agent builds the pipeline against WaveAssist's primitives, proves it on a live run, and hands it to a schedule in the cloud. Same code, same shape, same output, every run.
MCP is the connection, not the product
Model Context Protocol is how your editor's agent reaches tools outside the chat. WaveAssist exposes its runtime over MCP, so the agent you already use can design, test, and schedule a real pipeline without leaving the editor. You describe what you want. The agent writes the code. WaveAssist runs it.
Three steps to connect.
- Get an MCP token from app.waveassist.io.
- Connect your editor.
- Describe a pipeline in plain English.
Claude Code is a one-liner.
claude mcp add --transport http waveassist \
https://mcp.waveassist.ai/mcp \
--header "Authorization: Bearer YOUR_TOKEN"
Cursor takes the same endpoint as a JSON block, and any MCP host can point at https://mcp.waveassist.ai/mcp the same way. WaveAssist is vendor-neutral. Bring the editor you already have.
What the agent actually builds
Once connected, you can say something like:
Build an agent that reads my ClickUp and emails me a Monday morning summary.
The coding agent turns that into a deterministic Python pipeline with three phases:
- Fetch.
fetch_data()pulls external state in. - Transform.
call_llm()runs the structured model calls. - Post and persist. The result posts out, and
store_data()carries state to the next run.
This is plain code, versioned and readable, not a black box. You can open it, read it, and edit it.
Deterministic by contract
The part that makes a recurring agent trustworthy is the shape of its output. WaveAssist binds every model call to a schema.
review = waveassist.call_llm(
prompt=review_prompt(pr),
response_model=Review,
)
response_model is a Pydantic model. The model fills the content, the contract locks the shape. Whatever the LLM says, review comes back as a Review with the fields your pipeline expects. No parsing surprises, no drift between runs, no half-broken JSON at 9am on a Monday.
Tested before armed
Nothing goes live on a promise. Every agent proves itself on a live run first, and the schedule arms only after a green run. If the test does not pass, the agent does not go live, and you find out in your editor instead of in production.
This is the one line no editor-based scheduler offers. Tested before armed.
Runs as code, not inference every tick
Once armed, WaveAssist runs the pipeline as code on your schedule. It does not re-plan with a full-inference agent every time it wakes up. That is why a run costs less than a cent, and why the thousandth run behaves like the first. State persists across runs through fetch_data() and store_data(), so an agent resumes from its last checkpoint instead of starting cold.
Design the pipeline once. Run it forever, for a fraction of a cent.
Connect the MCP
New accounts start with $2 of runtime credit, enough to build something real and watch it arm. Working examples live at github.com/WaveAssist.
Build in your editor. Run in the cloud. Same output every time.
Connect the MCP at waveassist.ai.