Signal - Self-Extending Tools (Task Board)

• 

  Signal

Inspiration

Most task boards treat an AI agent like a slightly faster mouse it clicks buttons, scrapes text, guesses what a status means. WebMCP flips that: the site tells the agent exactly what it can do. I wanted to push past "agent checks tasks off a list" and ask a harder question what happens when the agent isn't just using the tools I built, but proposing new ones?

What it does

Signal is a task board with three layers of WebMCP tools:

Task management get_overdue_tasks, search_tasks, add_task, and a heuristic tool, suggest_completions, that scans each task's activity log for real completion signals ("deployed," "merged and closed," "confirmed receipt") and tells the agent which overdue tasks are probably already done. The only tool that writes, bulk_update_status, is rejected outright by the server unless confirmed: true is set which only happens after a human clicks Approve in the UI. The safety isn't a prompt asking the agent to be careful. It's the API contract.

Tool Forge the part I'm most proud of. An agent can call propose_tool to define a new tool, composed only from a small whitelist of existing read primitives (chain a call, then filter the result). This does nothing on its own it renders an approval card in the UI. Only when a human clicks Approve does document.modelContext.registerTool() actually fire, live, in that session. No tool's execute() function ever calls registerTool() on another tool's behalf registration is a function of a real UI click, not one tool triggering another, which follows guidance from the WebMCP spec's own design discussion.

Project files + sandbox a small in-memory workspace the agent can write to (write_project_file), patch surgically without rewriting the whole file (edit_project_file, which rejects the edit if the target text isn't uniquely identifiable), and execute (run_code) inside a hidden, network-disabled <iframe> sandbox with a 3-second timeout. Output streams back into the Agent panel.

How I built it

Plain Express backend, in-memory store, zero frontend build step the whole UI is vanilla JS calling document.modelContext.registerTool(). No React, no bundler, so it deploys to Render with no configuration. I wanted the WebMCP integration to be readable in a single file, not buried under abstraction.

Challenges I ran into

I built this solo under a 22-hour submission deadline. Most of the development started on my PC, but with no power for much of the deadline, I had to continue development and testing from my phone. Chrome's chrome://flags/#enable-webmcp-testing flag and mobile DevTools were enough to verify that document.modelContext was registering tools correctly before I had desktop access again The trickiest design decision was Tool Forge's safety model. My first instinct was to let the agent generate and run arbitrary code for new tools, then I realized that's exactly the kind of thing that looks impressive in a demo and terrible in a security review

So I deliberately constrained proposed tools to compositions of a fixed, whitelisted set of read primitives. A proposal can combine existing capabilities in a new way, but it cannot reach new data or perform writes. The same principle applies to the code sandbox: it is genuinely isolated with no network access and a hard timeout rather than simply being labeled safe. The larger version I have designed goes further, including stronger isolation and actual test execution. For this submission, I focused on shipping a working, enforceable slice of that architecture rather than pretending arbitrary code execution was safe.

Accomplishments

Built Signal solo in roughly 22 hours, from deciding to enter the challenge on September 2 to a deployed, working WebMCP submission. I implemented the WebMCP integration from scratch, including structured task tools, a server-enforced human approval gate for writes, and Tool Forge a constrained system where agents can propose new tools that only become registered after explicit human approval. I also built the supporting project workspace and isolated browser sandbox, then deployed and tested the whole thing under a very limited development environment, continuing from my phone when I didn't have access to power for my PC. The biggest accomplishment for me isn't the number of features it's that the core safety boundaries are actually enforced by the implementation rather than being claims made in the UI.

What's next

The sandbox here is JS-only. It's actually a small piece of a much larger AI agent I'm building separately, called Cipher, which has been in active development for a couple of months. This hackathon gave me a reason to ship one small, focused slice of it cleanly. If you're interested in what Cipher is building toward, I'm reachable at favourdev12@gmail.com or @favourdeve on Telegram.

Update

Devpost extended the challenge deadline after I'd already submitted. I used the extra time to add a real chat interface live tool-calling through the same tool contract described above, not a scripted walkthrough and used it to actually test every tool end-to-end, not just through the WebMCP browser path.

Built With

• express.js
• html/css
• javascript
• node.js
• render
• webmcp