I Made My App Agent-Friendly with WebMCP

For some time we have been using a Google spreadsheet to keep track of everything we plan on posting on social media. It worked, but it was never a particularly enjoyable experience, so I decided to build our team an internal tool for scheduling those posts, with a few extra features. But I wanted to do a bit more with it.

Most of our team already lives in Claude or ChatGPT for daily work, so opening yet another browser tab just to fill in a scheduling form felt kind of silly. I'd rather tell my agent "plan 5 posts for next week's launch" and have it do that. Even better, I want it to search our Slack conversations from the past week and schedule the things we discussed with the team.

That's what I wanted to try, and WebMCP made it pretty doable.

WebMCP lets a web app expose JS functions as tools, which AI agents that support it can discover and call. This means an agent can find drafts, read them, create posts and update schedules, all through the open browser tab. It's more effective than computer use, which has to navigate the page and figure out how to accomplish the task you gave it.

This is the planner. Each post has its own copy for LinkedIn and X, and a date when we want to publish it.

MCP and WebMCP

If you've used MCP, the idea of exposing tools will feel familiar. With MCP, an agent connects to a server that provides those tools, and it can use them without opening the related website. With WebMCP, the website registers tools with the browser, so they are available through the loaded page. Angie Jones explains how the two fit together in more detail.

For this planner, that means the app needs to be open and the user signed in. You can open it yourself, or the agent can navigate to it and go through sign-in, with your help where needed. It can then use the same session as you, and you can review its changes in the app. If you need a task to run without an open browser page, an MCP server is a better fit.

Registering a tool

The app doesn't publish anything (yet), so I started with four tools for managing the social media plan: list_posts, get_post, create_post and schedule_post. These are things the app already knows how to do. What we need to add is a way for the agent to discover them and pass in the right information.

Let's use reading a post as an example. Imagine the app has a getPost() function that loads a saved draft. We can expose it by registering a tool with the browser:

The description tells the agent when this tool is useful. The inputSchema describes what to send, which in this case is a post ID. And execute connects that request to our function. Registering the tool makes it available; the function only runs when the agent calls it.

Compared to classic MCP, the WebMCP registration happens in the browser. When an agent opens a page, it looks for registered tools. This is why it’s useful to call the registration after the sign-in.

Wiring up tools

The implementation was mostly wired to reuse the same API that the UI already uses.

The browser passes the agent's post ID to execute, which calls this function and returns the saved post. Because the request goes to the same site, it carries the user's session cookies. Passing along signal also lets the browser cancel the fetch if the agent stops the tool call.

The useful part is what you put in data. Returning the post's ID, copy and current schedule lets the agent check the post and use its ID in the next call. After scheduling, return the saved date and time so it can report what actually changed. Keeping the response format consistent across tools gives it a predictable way to find those results.

Errors should help it recover, too. The generic error above keeps the example short, but in your app you can distinguish "sign in again" from "this post no longer exists".

Using it from an agent

As a small bonus, I added an Agent connection panel so you can check whether the browser has registered the tools before asking an agent to use them. Here it shows all four ready:

With the planner open and signed in, you can ask a compatible agent something like "find my webinar draft and schedule it for next Tuesday at 9:30". It can use list_posts to find the draft's ID, get_post to check its copy, and schedule_post to save the date. This is why the result of one tool needs to contain the information required by the next.

Once an agent can make changes, you also want to see those changes in the UI. Have the scheduling tool save through the same app function as your scheduling form, then refresh the calendar. That way, you can check the new date or adjust it yourself without relying only on the agent's report.

For the Slack workflow I described at the start, the agent would also need access to Slack. Most of our team members already use Slack MCP or Granola MCP for meeting notes, so these make scheduling posts a breeze.

These tools cover the planner part: take the copy the agent has prepared, save it as a draft and put it on the calendar. The planner stays open during that work, so I can review the posts there before we publish anything.