MCP tool-surface audit: small surface, but action tools may benefit from clearer trigger/safety wording

[silvermango9927]

Hi! I’m working on audit-mcp, a local CLI that reviews MCP tool surfaces for discoverability issues: overlapping tools, unclear primary vs follow-up actions, weak trigger language, and places where agents may not have enough signal to pick the right tool.

I ran it against the current Browserbase MCP tools/list surface from this repo. This is not a bug report, just a lightweight audit/share in case useful.

Summary

• Tools exposed: 6
• Default-visible tools: 6
• Average discoverability score: 80.8
• CI-style verdict: pass, with warnings
• Top recommendation: make navigate and the action tools more explicit about when to use them and what safety/session assumptions apply.

Findings that looked actionable

The tool surface is already compact, which is good. The main thing the audit noticed is that several tools are intentionally short, but may be underspecified for agent selection:

• navigate: description is short; url input could use clearer examples or constraints.
• act: action input could be clearer about when to use this versus observe or extract.
• observe: instruction input could be clearer about expected output and when it should precede act.
• start / end: these are lifecycle tools, but the descriptions do not say when an agent should call them automatically versus rely on session reuse.

A possible pattern:

Use when: the agent needs to inspect possible interactions before taking action.
Returns: actionable page elements / observations.
Do not use when: the task is only to extract page data or navigate to a known URL.
Safety: does not mutate the page; use before `act` when the next step is uncertain.

For example, observe and act are naturally a progressive pair, but the current descriptions leave more of that sequencing to the model.

Why I’m sharing

I’m trying to learn whether MCP maintainers find this kind of tool-surface feedback useful or noisy. If this is off-base, I’d love to know. If useful, I’m especially curious whether you’d want something like this as:

1. local CLI only
2. warn-only CI
3. PR comment
4. report artifact
5. something else

[denial123789]

This is a useful framing for browser MCP servers. One thing I would look for in the wording is whether each action tool makes three things explicit:

1. what browser state it can mutate
2. what preconditions should be true before calling it
3. what the runtime should expose afterward for traceability/debugging

We included Browserbase MCP in Awesome Agent Runtime under Browser Automation because this tool-surface / hosted-browser boundary is becoming a real production agent infrastructure concern:
https://github.com/sandbaseai/awesome-agent-runtime

If there is a better category or description for Browserbase MCP in that map, happy to update it.

[silvermango9927]

Hey, thank you so much!

For Browserbase specifically, I think the category in Awesome Agent Runtime is right as Browser Automation, but the description could maybe emphasize the hosted-runtime boundary more than just browser control. Something like:

“Hosted browser automation MCP for production agents, exposing session lifecycle, navigation, page action, observation, and extraction tools with managed browser infrastructure.”

The part I’m trying to understand better is exactly what you called out: once browser tools move from local automation to hosted runtime infrastructure, the MCP surface needs to help agents reason about state, preconditions, and debug traces.

I’m going to fold this into audit-mcp as a browser-specific check:

• action tools should say what browser/page/session state they mutate
• tools should state preconditions, e.g. session exists, page loaded, URL known, observation completed
• tools should say what trace/debug artifact is available afterward, e.g. session id, screenshot, observation result, console/network trace, extracted data

Appreciate the pointer to Awesome Agent Runtime too. That map is helpful context for how these MCPs are being categorized.

[denial123789]

Thanks, this wording is much better. I updated the Browserbase MCP entry in Awesome Agent Runtime to emphasize the hosted-runtime boundary: session lifecycle, navigation, page action, observation, and extraction on managed browser infrastructure.

The browser-specific check you listed also feels like the right direction for audit-mcp. For production agents, the useful distinction is not just "can this tool control a browser?", but "what page/session state can it mutate, what preconditions are expected, and what trace/debug artifact exists after the call?"

[silvermango9927]

Thanks a lot!

The “hosted-runtime boundary” framing is helping me clarify what audit-mcp should become: not just a generic description checker, but a set of domain-specific MCP surface audits.

For browser MCPs, I’m going to treat state mutation, preconditions, and trace/debug outputs as first-class checks. That feels much closer to what production agent infrastructure actually needs than a generic “write tool” warning.

If I add a browser-specific profile, would you be open to checking the rubric before I make it public? I’d mainly want to know whether the checks match how Browserbase thinks about production browser sessions.

ALSO, Do you think teams building production browser agents would pay for this kind of MCP surface audit, especially around state mutation, preconditions, and trace/debug outputs?

If yes, who is the buyer: MCP provider, agent infra team, internal platform team, or app team using the browser MCP?