How Do I Let AI Agents Take Actions on My SaaS Dashboard?
For SaaS product teams and dashboard builders · Based on Rachel Lee's Agentic Web Publishing Framework
// TL;DR
If you build a SaaS dashboard — project management, analytics, CRM — this framework lets in-browser AI agents take actions on behalf of users without relying on screenshot-based navigation. Register Web MCP tools on each dashboard page using the imperative model, calling the same internal API functions your UI already uses. Agents call create_item, filter_by_status, or get_summary directly, bypassing DOM traversal. This reduces token cost, improves reliability, and makes your product AI-agent-native from within the browser.
Why Should My SaaS Dashboard Support AI Agents?
Your users are already experimenting with in-browser AI agents to automate repetitive dashboard tasks — creating items, pulling reports, filtering views. Without Web MCP, these agents rely on screenshot-based DOM traversal: taking screenshots, running visual models to identify buttons, and clicking through your UI pixel by pixel. This is slow, token-expensive, and breaks whenever your layout changes.
Rachel Lee's Agentic Web Publishing Framework gives agents structured access to your dashboard's capabilities. The agent calls your functions directly instead of guessing from pixels.
How Do I Register Web MCP Tools on Dashboard Pages?
Use the imperative Web MCP model. On each dashboard page, register tools that map to the actions users take:
```javascript
if (navigator.modelContext) {
navigator.modelContext.registerTool(
'create_item',
'Create a new item with a title, description, and assignee',
{
type: 'object',
properties: {
title: { type: 'string' },
description: { type: 'string' },
assignee: { type: 'string' }
},
required: ['title']
},
(params) => api.createItem(params)
);
navigator.modelContext.registerTool(
'filter_by_status',
'Filter the current view to show only items with this status',
{
type: 'object',
properties: {
status: { type: 'string', enum: ['open', 'in_progress', 'done'] }
}
},
(params) => dashboard.filterByStatus(params.status)
);
navigator.modelContext.registerTool(
'get_summary',
'Get a summary of current project metrics including item counts and overdue items',
{ type: 'object', properties: {} },
() => dashboard.getSummary()
);
}
```
The critical insight: the callback functions are the same internal API calls your dashboard UI already uses. You're not building new functionality — you're exposing existing functionality to agents through a structured interface.
How Does This Reduce Cost Compared to Screenshot-Based Agents?
Screenshot-based agents must: (1) capture a screenshot, (2) send it to a visual model for interpretation, (3) identify the correct UI element, (4) simulate a click, (5) wait for the page to update, and (6) repeat. Each step consumes tokens and introduces failure points.
With Web MCP, the agent calls `create_item` directly. One tool call, one API function, done. No screenshots, no visual model inference, no DOM traversal. For a SaaS dashboard where users might chain 10-20 actions in a session, the token savings and reliability improvements are substantial.
Should I Also Build an HTTP MCP Server for My Dashboard?
It depends on your use case. Web MCP handles in-browser agents — agents that operate within the user's authenticated browser session. If you also want users to interact with your dashboard from inside Claude Desktop or similar agent harnesses, add an HTTP MCP server at an endpoint like `/mcp`. This server would expose the same tools but requires authentication handling since the user isn't in a browser session.
For most SaaS dashboards, start with Web MCP on your existing pages. It's lower effort (you're adding tool registration to pages you already build) and leverages the user's existing authentication. Add an HTTP MCP server later if there's demand for out-of-browser agent access.
What Pitfalls Should Dashboard Teams Watch For?
Don't over-expose tools. Register the actions users actually perform on each page, not every internal function. A project board page needs `create_item`, `move_item`, `filter_by_status` — not `update_database_index` or `recalculate_cache`.
Always wrap registration in `if (navigator.modelContext)` so your dashboard works normally in non-agent browsers. Test with the MCP B browser extension to verify tools are registered, visible, and callable.
Don't confuse Web MCP with full MCP spec compliance — they may diverge. Build for the functional abstraction of exposing structured tools to agents.
Next step: Pick one dashboard page and register three Web MCP tools for its most common actions. Test with MCP B. That's your proof of concept.
// FREQUENTLY ASKED QUESTIONS
Does Web MCP work with my dashboard's existing authentication?
Yes. Web MCP tools run inside the user's browser session, so they inherit the user's existing authentication context. The callback functions call your internal APIs with the same session cookies or tokens the dashboard UI uses. No separate auth flow is needed for in-browser agents.
What if my dashboard uses a JavaScript framework like React or Vue?
Web MCP registration works regardless of your frontend framework. Call navigator.modelContext.registerTool in your component's mount lifecycle (useEffect in React, onMounted in Vue) and clean up on unmount. The callbacks invoke the same state management functions or API calls your components already use.
Can I restrict which agent actions are allowed on my dashboard?
Yes. You control which tools you register on each page. Only register tools for actions you want agents to perform. Your callback functions can include the same permission checks and validation your UI already enforces. If an action requires admin privileges, the callback returns an error just as it would for an unauthorized UI click.