BrainRoad Ships 70+ MCP Tools in Every Hosted Agent — Here Is What You Get on Day One

Most hosted AI agents give you one thing: a chat endpoint. You send a message, you get a response. That’s it.

What ships in a BrainRoad-hosted agent is structurally different. When your agent comes online, it exposes an MCP server — the standardized tool-calling protocol Anthropic introduced in late 2024 — over HTTP. That server has two distinct layers, and understanding the split is what separates developers who get full use out of the platform from those who use 10% of what they’ve got.

I’ll get to the annotated screenshot trick in the browser section. It’s the kind of detail that makes coordinate-hunting feel embarrassing in hindsight. But first — the architecture.

If you’re still evaluating whether a hosted agent is the right deployment model for your use case, the AI agent platform comparison covers the tradeoffs in detail. This article assumes you’ve already chosen hosted — now you want to know what’s in the box.

Two Layers, Not One

Here’s the thing most documentation glosses over. When people talk about MCP tool counts, they’re usually describing a flat list. BrainRoad’s architecture isn’t flat — it has a management plane and a task plane. Mixing them up causes confusion about what you’re actually controlling.

The management plane is the gateway. It’s the 63 RPC methods you call to manage, configure, and observe the agent runtime itself. Think: start a chat session, schedule a cron job, read usage logs, inject a secret, spawn a new node. You’re talking to the infrastructure.

The task plane is what the agent calls while it’s doing work. Bash execution, file read/write, web search, WhatsApp send, PDF parse, subagent spawn. The agent is talking to the world on your behalf.

Knowing which layer you’re on tells you who the caller is. You call the gateway. The agent calls its tools. They compose into a complete system — but they’re not the same thing.

The 63 Gateway RPC Methods: What You Control

The gateway is your management surface. It’s what Claude Code, Cursor, or your own MCP client talks to when it connects to the hosted agent over HTTP. Here’s how the 63 methods break down by category.

Thirteen categories. Sixty-three methods. Every one of them available over HTTP the moment your agent is live.

The Agent Tool Set: What Your Agent Can Do

Now the task plane. These are the tools your agent calls while it’s executing work. The distinction matters: you’re not calling these directly — you’re configuring an agent that uses them autonomously.

AI agents are increasingly expected to do real things in the world — query databases, send messages, create files, make decisions. What ships here is the toolkit that makes that real, not theoretical.

Why the Browser Layer Is More Interesting Than It Looks

Here’s the annotated screenshot detail I mentioned earlier.

Standard browser automation breaks in two predictable ways: the agent guesses wrong coordinates, and it gets lost mid-task with no recovery path. Both of those are solved problems in this tool set.

The annotated screenshot tool overlays numbered bounding boxes on every interactive element on a page and returns a legend alongside the image. The agent sees “button 4 is the Submit button” and references it by number. No CSS selectors. No pixel-coordinate guessing. The agent doesn’t need to know where the submit button is in absolute terms — it just needs to know it exists.

Full-page capture handles scroll offset automatically. When you ask for a full-page screenshot, the tool resizes the viewport to the entire document height and captures everything in one image. When the agent clicks coordinates from that full-page image, the tool scrolls to the right position before dispatching the event. No scroll math required.

And when the agent gets confused mid-task — which it will — there’s a ring buffer of the last 20 screenshots with full metadata. The agent can call back to what the page looked like 3 actions ago. There’s also a session log with a timestamped record of every action taken, and a session summary tool that condenses the full history to re-orient the agent. That last one has quietly saved more workflows than I can count.

Connecting Claude Code, Cursor, or Any MCP Client

This is the part that makes the tool count meaningful. Because the gateway is an MCP server over HTTP, any compliant MCP client can connect to it without any custom integration work.

Claude Code, Cursor, your own Python script using the MCP SDK — they all speak JSON-RPC over HTTP. Your BrainRoad agent speaks the same language. The connection is a URL and an auth token. That’s it.

What this means practically: you can use Claude Code as your development environment and have it call your hosted agent’s gateway methods as tools in its context. Schedule a cron job from a Claude Code session. Query usage logs. Inject a secret. Spin up a subagent to run parallel research. All from whatever client you prefer, without leaving it.

For the broader picture of what a hosted agent actually costs to run once you’re connected and making calls, the real monthly cost breakdown is worth reading before you scale up usage.

A Day-One Example: Web Research to WhatsApp Summary

Here’s a concrete workflow that uses tools from both layers on the first day your agent is live.

Scenario: you want your agent to research a competitor’s pricing page every Monday morning, compare it against last week’s data, and send you a WhatsApp summary with any changes.

From your MCP client (say, Claude Code), you call the gateway’s cron methods to schedule the workflow for 7 AM Monday. The agent wakes up, uses its browser tool to navigate to the pricing page, captures an annotated screenshot to identify the pricing table elements, and uses web fetch to pull the raw content. It reads last week’s data from its persistent file storage, compares the two, and uses the message tool to send you a WhatsApp notification with the diff. If nothing changed, it still writes a timestamped log entry via its write tool so you have a clean audit trail.

You set this up once. It runs every week. You never open a browser to check that page again.

That workflow touches the gateway (cron scheduling), the browser tool, web fetch, file read/write, memory, message, and logs. Six tool categories. Zero ongoing input from you after the initial setup.

Where This Setup Falls Apart

A few failure modes worth knowing before you build on top of this.

• Phone calls require human approval. The agent can trigger a phone call using Twilio and a text-to-speech voice, but every call goes through an approval gate before it executes. You can’t build a fully autonomous phone outreach flow without a human in the loop for each call. Design for that.
• The stealth browser isn’t magic. It passes most bot detection, but some enterprise-grade WAF configurations will still block it. If a site is actively hostile to automation, expect occasional failures and build retry logic.
• Subagent sprawl is real. The subagent tool makes it easy to spawn child agents for parallel work. It also makes it easy to spawn too many and burn through your context budget faster than expected. Start with 2-3 parallel subagents, not 20.
• Secrets management has a write boundary. You can inject secrets at runtime via the gateway, but secrets you write programmatically don’t automatically sync to the UI dashboard. If you’re rotating credentials, do it from one place consistently.
• Session state doesn’t persist across agent restarts by default. In-flight session context is different from the persistent file storage and memory tools. Long-running workflows that survive an agent restart need to use file write or memory explicitly — don’t rely on session state for durability.
• The annotated screenshot tool increases token consumption. Each annotated screenshot returns an image plus a legend. For tasks with many browser interactions, this adds up. For cost-sensitive workflows, use standard screenshots and fall back to annotated only when the agent is stuck.

How to Know Your Agent Is Actually Using Its Tools

Beacon says: 70 tools, ready before you even ask. That’s not a head start — that’s a running start.

Don’t assume the tools are working because the agent says they are. Verify.

• Check the logs via the gateway’s log methods. Every tool call the agent makes should produce a structured log entry. If you scheduled a cron job and it ran, you’ll see the execution record with a timestamp.
• Query usage after a workflow run. The usage gateway methods return token consumption and API call counts. If a web search ran, you’ll see it in the usage data. If the numbers don’t move, the tool didn’t fire.
• Inspect the session log inside a browser workflow. The session log tool returns a timestamped record of every browser action. Navigate, click, type, screenshot — all present if the browser tools are working.
• Look for files in persistent storage. If your workflow writes output files, check that they exist and have the expected timestamps. A missing file means the write tool either didn’t run or failed silently.
• Trigger a test WhatsApp message. The fastest way to verify the message tool is working is to ask the agent to send itself a test message and confirm receipt. Takes 30 seconds.
• Check subagent status via the agents gateway methods. If you spawned subagents, their status should be queryable. An orphaned subagent that never terminated is a common source of unexpected usage charges.

Your First-Deploy Checklist

Your agent is live. Here’s how to spend the first 30 minutes productively.

1. Connect your MCP client to the gateway. Get the HTTP endpoint and auth token from the BrainRoad console. Paste them into Claude Code, Cursor, or your script. Issue a test chat call to confirm the connection. This should take under 5 minutes.
2. Run a usage baseline query. Before you build anything, call the usage gateway methods and note your starting token count and API call count. This gives you a clean baseline to measure against after your first real workflow.
3. Test the browser tool with a low-stakes page. Navigate to a public site, take an annotated screenshot, and read back the element legend. Confirm the numbered bounding boxes are returning. If this works, your browser toolchain is healthy.
4. Schedule one cron job. Pick something simple — a daily log query, a web fetch of a page you care about. Schedule it for 5 minutes from now, wait, and confirm it executed via the logs. This validates your cron setup end-to-end.
5. Inject your first secret. If your workflows will need API credentials, inject them now via the secrets gateway methods. Test that the agent can reference the secret in a live call without it appearing in plaintext logs.
6. If you’re spawning subagents: cap the initial limit at 3 parallel agents. Check their status after the first run. Confirm they terminated cleanly before increasing the count.
7. Budget $50-100 for the first month of active workflow testing. Token costs for typical workflows run $8-15/month at steady state — but active development with frequent browser sessions and subagent spawning can spike costs early. Set a usage alert at your monthly budget threshold before you start building.

If you’re still setting up the underlying OpenClaw infrastructure, the BrainRoad Console Guide walks through the initial configuration in detail — including where to find the gateway endpoint and how to manage your agent’s settings from the UI.

The tools are all there on day one. The question is which ones you wire together first — and whether you’ve verified they’re actually running before you build a real workflow on top of them.

What This Means for Your Agent Builds

• Every BrainRoad-hosted agent ships with 70+ MCP tools on day one — split across 63 gateway RPC methods for runtime management and a separate agent tool set for task execution.
• The gateway has 13 categories: chat, agents, browser, cron, sessions, config, skills, nodes, models, usage, text-to-speech, secrets, and logs. Any MCP client connects over HTTP with no custom integration work.
• The agent tool set includes bash execution, file read/write, three browser engines (including a stealth browser that bypasses bot detection), web search, messaging to WhatsApp and Slack and email, subagent spawning, PDF parsing, and more.
• The browser layer includes an annotated screenshot tool that eliminates coordinate guessing, a 20-screenshot ring buffer for state recovery, and automatic scroll-offset handling for full-page captures.
• Phone calls require human approval via an approval gate — design any voice automation workflow with that constraint in mind.
• Start your first-deploy verification with a usage baseline, a browser tool test, and a cron job scheduled 5 minutes out. Confirm all three before building anything complex on top.

Frequently Asked Questions

What MCP clients can connect to a BrainRoad-hosted agent?

Any MCP-compliant client that supports HTTP transport. Claude Code and Cursor are the most common in practice. You can also write your own client using the MCP SDK — the protocol is JSON-RPC over HTTP, so any language with an HTTP library can connect. You need the gateway endpoint URL and an auth token from the BrainRoad console.

What is MCP and why does it matter here?

MCP stands for Model Context Protocol — a standardized way for AI models to call external tools, introduced by Anthropic in late 2024. It uses JSON-RPC as its wire format, which means any tool or client built to the spec can interoperate. BrainRoad exposes its agent runtime as an MCP server, so your existing tools connect without custom integration work.

What is the difference between the gateway RPC methods and the agent tools?

The gateway methods are what YOU call — they control the agent runtime (scheduling, configuration, secrets, logs, usage). The agent tools are what YOUR AGENT calls while executing work — browser navigation, file writes, web search, messaging. You interact with the gateway from your MCP client. The agent interacts with its tools autonomously during task execution.

Can the agent send WhatsApp messages autonomously?

Yes. The message tool supports WhatsApp, Slack, email, and Telegram. The agent can send messages as part of any workflow without waiting for you to trigger it. The exception is phone calls — those require human approval via the approval gate before the call executes.

How does the stealth browser differ from standard Playwright?

Standard Playwright is blocked by many modern bot detection systems including Cloudflare and DataDome. The stealth browser is configured to pass these systems. For sites with active bot protection, use the stealth browser. For sites without it, standard Playwright is faster and lower cost. There’s also a third option — Chrome DevTools Protocol (CDP) — which attaches to your real Chrome browser instance if you need to work with sessions or authentication that’s already established.

Does tool access persist across agent restarts?

The tools themselves are always available — they’re part of the agent’s configuration, not its runtime state. However, in-flight session context does not persist across restarts. If you need workflow state to survive an agent restart, write it to persistent storage using the file write tool or the memory tool. Don’t rely on session state for anything you can’t afford to lose.

Sources

• 204 MCP Tools in One Server — DEV Community
• vscreen deep dive: 63 MCP tools for browser automation — DEV Community
• MCP Gateways in 2026: Top 10 Tools for developers — Medium