ToolMint

Inspiration

We provided small and medium businesses assistance with various no-code tools, such as site creators, form builders, and tools for automating processes over the years.
What makes these tools work is simple: users don’t need to write detailed technical specifications. They show or explain the tool what they want, or build it visually(drag n drop editors), and the tool handles the technical work. That’s how a shop owner can create a booking form without needing to call a developer.

When we explored WebMCP, we noticed a clear gap. Making a website agent-ready required writing tool definitions in code. But avoiding code is exactly why people choose no-code tools in the first place. This meant that many of the businesses that could benefit most from agents were also the least likely to adopt them.

We started thinking about what a no-code approach to WebMCP might look like and built a workflow that feels familiar.A website owner records themselves performing an action on their site. ToolMint’s SDK converts that recording into a draft WebMCP action, along with a clear, human-readable description of what the tool does, what inputs it requires, and what action it performs - all in simple, non technical terms.The owner reviews and approves the draft. Once published, the action becomes available for visitors to use through their agents.

What it does

ToolMint lets a site owner perform a task once, like booking an appointment. It records the workflow and turns it into an approved WebMCP tool that agents can use.

How we built it

ToolMint runs as a single Node.js service on Render. It serves the demo website, SDK and a control-plane API , with SQLite storing approved tools and their versions.

It has four main parts:

Recorder (part of sdk) — Runs inside the website and observes the task performed by the owner. It captures meaningful form changes, actions, page outcomes and the structure of related same-origin network requests. Compiler — Converts the recording into a versioned capability. It identifies the successful workflow, determines possible agent inputs, builds a replay recipe, and creates success and failure checks from what actually happened on the page. SDK — Loads approved capabilities for the current website and user surface, then registers them as native WebMCP tools. Tools can be updated or revoked without changing the website’s application code. Runtime — Executes a tool inside the live authenticated page. It validates inputs, resolves the correct record, follows the recorded steps, respects confirmation policy, and verifies that the expected page state and network operation occurred. Individual tool calls do not pass through the ToolMint backend.

OpenAI helps improve names, descriptions and input recommendations. It does not generate selectors, execution steps, permissions or success proofs. Those come from observed evidence, are reviewed by the owner, and are compiled deterministically before publishing.

Challenges we ran into

Knowing whether the task really worked was harder than replaying the clicks. A success message was not enough. Every write capability needs evidence that the page actually changed, together with the expected network response when available. If ToolMint cannot produce a reliable proof, it will not publish the capability.

People make mistakes while recording. Our first version treated the entire recording as one script, so a typo followed by a retry became part of the generated tool. We had to split recordings into attempts, compile only the path through the final success, and preserve earlier failures as known failure conditions.

Deciding what should become an agent input. Real pages contain many fields that have nothing to do with the task. ToolMint considers what the owner changed, what appeared during the workflow and what the success proof depends on. The owner makes the final decision, but cannot remove an input required to verify the result.

Accomplishments that we're proud of

We built the complete record-to-tool loop. A site owner can perform a real task, review the inferred inputs and policy, publish it, and see a new native WebMCP tool become available without writing a handler or building another API. The generated tools work across user sessions. A workflow recorded with one customer’s vehicles can be invoked with another customer’s vehicles because account-specific choices are rebuilt from the current authenticated page. The tools verify their own results. A write is not reported as successful just because the final button was clicked. ToolMint checks the observed page state and related network response before returning success.

We kept AI assistance within clear boundaries. OpenAI can improve names, descriptions and recommendations, but it cannot invent selectors, execution steps, permissions or proofs. The final capability is compiled deterministically from recorded evidence and approved by the owner.

What we learned

A recorded workflow is evidence, not a finished tool. Raw clicks include mistakes, temporary state and values that only belong to the person recording. They need to be interpreted before they can become a reusable capability.

Reliable agent tools need clear success conditions. Executing the final action is not enough. The tool must know what changed and whether it changed for the right record.

What's next for ToolMint

Tell the owner when a tool breaks. We already record every execution; right now that data stays in the browser. Sending it back gives us health status, drift detection at registration, and a reason to pause a capability automatically. Wider Capture - autocomplete widgets and shadow-DOM component libraries are all invisible to the recorder today.

Built With

• codex
• openai
• render
• webmcp