Browserbase MCP Server

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.0.0
Disambiguation4/5
Most tools have distinct purposes, such as session management (create/close), navigation (navigate/get_url), and interaction (screenshot/act/extract/observe). However, 'browserbase_stagehand_agent' and 'browserbase_stagehand_observe' could cause some confusion as both involve autonomous or guided interaction, though their descriptions help differentiate them.
Naming Consistency4/5
The naming follows a consistent pattern with 'browserbase_' prefix and snake_case throughout. Most tools use descriptive verb_noun combinations, but there is a minor deviation with 'browserbase_stagehand_agent' which uses 'agent' as a noun instead of a verb, slightly breaking the pattern.
Tool Count5/5
With 9 tools, the count is well-scoped for a browser automation server, covering essential operations like session handling, navigation, interaction, and data extraction. Each tool serves a clear purpose without redundancy, making the set appropriately sized for the domain.
Completeness4/5
The tool surface provides comprehensive coverage for browser automation, including session lifecycle, navigation, interaction, and data extraction. A minor gap exists in lacking explicit tools for handling browser contexts like tabs or windows, but core workflows are well-supported and agents can work around this.
Average 3.4/5 across 9 of 9 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is failing
This repository is licensed under Apache 2.0.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions saving as a resource, which adds some context beyond the basic action, but fails to detail critical aspects like permissions needed, rate limits, error conditions, or what 'full-page' entails (e.g., scrolling behavior). This leaves significant gaps for an agent to understand operational traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—a single sentence that directly states the tool's function and an additional behavior (saving as a resource). It's front-loaded with the core action and wastes no words, making it efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (involving browser interaction and resource management) and the absence of annotations and output schema, the description is insufficient. It doesn't explain what 'full-page' means, how the screenshot is returned (e.g., format, size), or error handling, leaving the agent with incomplete operational context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for its single parameter 'name', so the description doesn't need to add parameter details. It doesn't provide extra meaning beyond the schema, but with high coverage, a baseline score of 3 is appropriate as the schema handles the parameter documentation adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('capture a full-page screenshot') and the resource (screenshot), with the verb 'capture' being specific. However, it doesn't explicitly differentiate from sibling tools like 'browserbase_stagehand_observe' which might also involve visual capture, leaving room for ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, such as when a full-page screenshot is needed over other capture methods or sibling tools. It lacks context about prerequisites or exclusions, offering only a basic functional statement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions session creation/reuse and activation but omits critical details like authentication requirements, rate limits, session lifecycle, or error handling. This is inadequate for a tool that likely involves resource allocation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core functionality without unnecessary words. Every part of the sentence contributes directly to understanding the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of session management, lack of annotations, and no output schema, the description is insufficient. It fails to explain what a 'session' entails, how activation works, or what the tool returns, leaving significant gaps for an AI agent to operate effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents the 'sessionId' parameter fully. The description adds no additional meaning beyond what the schema provides, such as examples or edge cases, but does not contradict it either.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Create or reuse') and resource ('Browserbase browser session'), and specifies the outcome ('set it as active'). However, it does not explicitly differentiate from sibling tools like 'browserbase_session_close', which handles session termination, leaving some ambiguity in scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, such as whether to prefer creating a new session over reusing an existing one, or how it relates to other session management tools. It lacks context on prerequisites or typical workflows.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions extraction but doesn't specify details like whether it requires a loaded page, how it handles errors, what formats the output might be in, or any performance considerations. This leaves significant gaps for an agent to understand the tool's behavior beyond basic functionality.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose without unnecessary details. It's appropriately sized for a tool with one parameter and no annotations, with zero waste or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a data extraction tool with no annotations and no output schema, the description is incomplete. It doesn't explain what the tool returns, how to interpret results, or any behavioral traits like error handling. This makes it inadequate for an agent to use the tool effectively in varied contexts.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, with the 'instruction' parameter well-documented in the schema. The description adds minimal value beyond the schema by reiterating the need for an instruction but doesn't provide additional semantic context or examples not already covered. Baseline 3 is appropriate as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Extract structured data or text from the current page using an instruction.' It specifies the verb ('extract'), resource ('structured data or text'), and context ('from the current page'). However, it doesn't explicitly differentiate from sibling tools like 'browserbase_stagehand_observe' or 'browserbase_stagehand_agent', which might have overlapping or related functionality.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools or contexts where extraction is preferred over other actions like navigation or observation. Usage is implied by the purpose but lacks explicit when/when-not instructions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It mentions that the tool 'optionally return an action,' which hints at behavioral output, but it doesn't disclose key traits like whether it's read-only or destructive, how it handles errors, or what the 'action' entails (e.g., format, conditions). This leaves significant gaps for a tool interacting with web pages.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the core purpose in the first sentence. The second sentence elaborates on the 'optionally return an action' aspect, which is relevant but could be slightly more integrated. Overall, it's efficient with minimal waste, though not perfectly structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of web interaction tools, no annotations, and no output schema, the description is incomplete. It doesn't explain what the tool returns (e.g., element details, actions), how it handles failures, or prerequisites (e.g., requires an active session). This leaves the agent with insufficient context for reliable use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, with the parameter 'instruction' fully documented in the schema. The description adds minimal value beyond the schema by reiterating the need for specificity (e.g., 'detailed instruction'), but it doesn't provide additional semantic context or examples not already in the schema. This meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Find interactive elements on the page from an instruction; optionally return an action.' This specifies the verb ('find'), resource ('interactive elements'), and scope ('from an instruction'), though it doesn't explicitly differentiate from sibling tools like 'browserbase_stagehand_extract' or 'browserbase_stagehand_act' beyond mentioning the latter. It avoids tautology and is not misleading.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by stating it's for finding interactive elements to later use with the 'act' tool, but it doesn't explicitly say when to use this tool versus alternatives like 'browserbase_stagehand_extract' or 'browserbase_screenshot'. It provides some context (e.g., for identifying elements for actions) but lacks clear exclusions or direct comparisons to siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions performing actions but omits critical details: whether this requires an active session, what happens on failure (e.g., if element not found), side effects, or error handling. This is inadequate for a tool that likely interacts with a live browser.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose with illustrative examples. Every word earns its place, and there's no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of browser automation (no annotations, no output schema), the description is insufficient. It doesn't cover session dependencies, error behavior, or result formats, leaving significant gaps for an agent to use this tool safely and effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents both parameters. The description adds no additional meaning about parameters beyond implying they're used for actions like 'click' or 'type'. This meets the baseline for high schema coverage but doesn't enhance understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('perform') and resource ('single action on the page'), with examples ('click, type') that illustrate the scope. It distinguishes this from sibling tools like 'screenshot' or 'navigate' by focusing on atomic page interactions, though it doesn't explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for atomic page actions, but provides no explicit guidance on when to use this versus alternatives like 'stagehand_agent' or 'stagehand_extract'. The context of 'single action' suggests it's for basic interactions, but lacks clear boundaries or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It mentions autonomous navigation and interaction but lacks critical behavioral details: whether this tool creates/destroys sessions, requires authentication, has rate limits, timeouts, or error handling. The description states what the tool does but not how it behaves operationally, leaving significant gaps for an agent to understand its traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is perfectly concise: two sentences that directly state the tool's function and method. Every word earns its place - 'Execute a task autonomously' establishes the core purpose, 'using Gemini Computer Use agent' specifies the mechanism, and 'navigate and interact with web pages' clarifies the domain. No wasted words or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given this is a complex autonomous agent tool with no annotations and no output schema, the description is insufficiently complete. It doesn't explain what the tool returns (success/failure indicators, results of task execution), doesn't mention session management implications, and provides minimal behavioral context. For a tool that presumably orchestrates multiple web interactions, more completeness is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already fully documents the single 'prompt' parameter with examples. The description adds no additional parameter semantics beyond what's in the schema. According to scoring rules, with high schema coverage (>80%), the baseline is 3 even with no param info in the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Execute a task autonomously using Gemini Computer Use agent' with the specific action of navigating and interacting with web pages. It distinguishes from siblings like 'browserbase_screenshot' or 'browserbase_stagehand_navigate' by emphasizing autonomous task execution rather than single operations. However, it doesn't explicitly contrast with 'browserbase_stagehand_act' which might have overlapping functionality.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for autonomous web-based task completion, with an example prompt provided in the schema. However, it lacks explicit guidance on when to use this tool versus alternatives like 'browserbase_stagehand_act' or 'browserbase_stagehand_extract'. The context is clear but no exclusions or specific alternatives are mentioned in the description itself.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses the tool returns the current page URL, but does not mention behavioral traits like whether it requires an active session, potential errors (e.g., if no page is loaded), or rate limits. It adds basic context but lacks depth for a tool with no annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose ('Return the current page URL') and adds clarifying detail ('full URL with query/fragment') without waste. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (0 parameters, no output schema, no annotations), the description is minimally complete. It states what the tool does but lacks context on prerequisites (e.g., requires an active session) or output format details, which could be helpful despite the simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are 0 parameters, so the baseline is 4. The description does not need to compensate for any parameter gaps, and schema description coverage is 100%, making additional parameter semantics unnecessary.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Return') and resource ('current page URL'), specifying it includes the full URL with query/fragment. It distinguishes from siblings like browserbase_stagehand_navigate (which changes URLs) and browserbase_stagehand_observe (which might return page content).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when the current page URL is needed, but does not explicitly state when to use this tool versus alternatives (e.g., vs. browserbase_stagehand_observe for page content). No exclusions or prerequisites are mentioned, leaving usage context somewhat implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that the tool closes a session and resets context, which implies a destructive action (ending an active session) but does not detail effects like data loss, cleanup behavior, or error handling. This provides basic behavioral insight but lacks depth for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that is front-loaded with the core action ('Close the current Browserbase session') and adds necessary context ('and reset the active context'). There is no wasted verbiage, making it highly efficient and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (a mutation with no annotations and no output schema), the description is minimal but covers the essential action. It lacks details on what 'reset the active context' entails, potential side effects, or return values, which could be important for an agent using this tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description does not mention parameters, which is appropriate, and thus adds no value beyond the schema. Baseline is 4 for zero parameters, as it avoids unnecessary detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Close') and resource ('the current Browserbase session'), and distinguishes it from siblings by mentioning 'reset the active context' which is unique among the listed tools. It precisely communicates what the tool does without being tautological.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context by referring to 'the current Browserbase session,' suggesting it should be used when a session is active and needs termination. However, it does not explicitly state when not to use it or name alternatives, such as whether other tools might handle session management differently.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses behavioral traits: it performs a navigation action (implying it changes browser state), includes a caution about URL reliability, and suggests a fallback. However, it lacks details on error handling, timeouts, or session dependencies, which are relevant for a browser tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
It is appropriately sized with two sentences that are front-loaded (first states the purpose, second provides guidelines). Every sentence earns its place by adding critical context without redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (navigation with reliability concerns), no annotations, and no output schema, the description is mostly complete. It covers purpose, usage, and behavioral caution, but could benefit from mentioning potential outputs or errors. However, it adequately addresses core needs for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents the 'url' parameter. The description adds no additional meaning beyond implying the URL should be reliable, but this is more about usage than parameter semantics. Baseline 3 is appropriate as the schema handles the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Navigate to a URL in the browser') and resource ('URL'), distinguishing it from siblings like 'browserbase_stagehand_get_url' (which likely retrieves rather than navigates) and 'browserbase_screenshot' (which captures screenshots). It uses precise verb+resource language.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides explicit guidance on when to use ('Only use this tool with URLs you're confident will work and be up to date') and when not to use (implying unreliable URLs), with a clear alternative ('Otherwise, use https://google.com as the starting point'). This helps differentiate from other navigation or browsing tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![mcp-server-browserbase MCP server](https://glama.ai/mcp/servers/MesuterPikin/mcp-server-browserbase/badges/card.svg)](https://glama.ai/mcp/servers/MesuterPikin/mcp-server-browserbase)

Score Badge

Copy to your README.md:

[![mcp-server-browserbase MCP server](https://glama.ai/mcp/servers/MesuterPikin/mcp-server-browserbase/badges/score.svg)](https://glama.ai/mcp/servers/MesuterPikin/mcp-server-browserbase)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/MesuterPikin/mcp-server-browserbase'

If you have feedback or need assistance with the MCP directory API, please join our Discord server