StocksBrew Decision Room

the problem

Stock research usually ends with more tabs, more scores, and no clean decision. Agents can do the comparison faster, but a financial workflow should never hide the rules or quietly turn a suggestion into an action.

what it does

StocksBrew Decision Room puts the whole handoff on one page.

You set the goal, time horizon, sector limit, risk limit, valuation limit, holdings, and any notes the agent should know. The agent reads those visible rules, compares two to five stocks, and renders the scores and portfolio trade-offs on the page. It can then draft one watchlist move with a rationale, evidence, and a price alert.

Then it has to stop.

At first the page exposes three WebMCP tools: read, compare, and draft. The fourth tool, commit_approved_plan, does not exist until the person reviews the exact plan and clicks approve. Editing the plan, rules, or comparison invalidates that approval and removes the tool. A successful save updates only this browser's local watchlist and alert, then the tool count drops from four back to three.

There is no login, broker connection, trade, or money movement.

why WebMCP matters here

This workflow works because the browser is shared ground. The person and the agent see the same rules, evidence, proposal, approval state, and activity trail. The safety boundary is enforced by the tool lifecycle itself, not by asking the model to remember a warning buried in a prompt.

The visible 3 → 4 → 3 tool transition is the product: compare and draft are always available; the final save capability is temporary, narrow, and earned by a specific human approval.

how it was built

• Native document.modelContext.registerTool WebMCP tools
• Dynamic registration and teardown with AbortController
• Exact proposal id plus short-lived approval token for the final tool
• Validation at every input boundary and stale-approval rejection
• Visible activity trail and browser-local state
• Public StocksBrew comparison data with a deterministic dated snapshot fallback
• Plain HTML, CSS, and JavaScript with no runtime dependencies
• Node's built-in test runner covering validation, mandate consequences, approval invalidation, local-only commit behavior, deterministic fixture data, and tool descriptor budgets
• GitHub Pages deployment with no account or secret required

the hard parts

The hardest part was making dynamic permissions behave correctly during real browser timing. Approval can change while a tool registration is still in flight, so teardown has to cancel the old registration and restore the three-tool state without leaving a stale save capability behind.

The other challenge was making the demo dependable for judges. GitHub Pages cannot run the optional proxy, so the app falls back to a bundled, dated StocksBrew snapshot. A fresh clone and the public URL still show the complete workflow without credentials or a live market dependency.

what I learned

WebMCP is strongest when a webpage already contains meaningful state and controls. The agent should not replace that interface. It should work through it, leave evidence behind, and gain sensitive capabilities only when the person has made the relevant choice.

For high-consequence actions, a missing tool is a clearer boundary than a powerful tool plus a paragraph asking the model to be careful.

what is next

The next step would be reusable approval gates for other consequential browser workflows: publishing, account changes, portfolio rebalancing drafts, and team approvals. Each integration should keep the same rule: show the exact proposed change, bind approval to it, expire the capability when context changes, and leave an audit trail.

Built With

• css
• github
• html
• javascript
• node.js
• pages
• stocksbrew