browser-mcp

by ywleeo

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

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

Latest release: v0.8.0
Disambiguation4/5
Most tools are cleanly separated by domain prefix and action (e.g., browser_*, zhihu_*, xhs_*), making them easy to distinguish. However, browser_read and browser_snapshot both load URLs with different output types, and browser_read_page vs site_read_page could initially cause confusion.
Naming Consistency4/5
All tool names use lowercase_with_underscores and a clear domain prefix, which is very consistent. The pattern is not always verb_noun (e.g., browser_status, zhihu_invitations), mixing action and noun forms, but the prefix-based scheme makes the set predictable.
Tool Count3/5
With 24 tools, this server is on the heavy side, though the breadth of domains (browser control, platform-specific reads for five sites, and three search engines) argues for a larger surface. Some consolidation could reduce the count, but most tools earn their place.
Completeness4/5
The server covers the core browser lifecycle (load, view, click, type, scroll, select, press) plus a solid set of reads for major platforms and search engines. Missing advanced interactions like hover or multi-step workflows, but no obvious dead ends for the stated purpose.
Average 3.9/5 across 24 of 24 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 33 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 passing
This repository is licensed under MIT License.
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.
This repository includes a glama.json configuration file.
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

Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds a useful behavioral trait: it operates 'through the user's current Chrome session', implying dependency on browser state/login. No contradictions with 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 sentence of 14 words, front-loaded with the core purpose. Every word adds value—it names the resource, the action, and the key contextual detail (Chrome session). No unnecessary elaboration.
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?
For a simple search tool, the description covers the essential purpose and a key context (Chrome session). However, it lacks usage guidance relative to other search tools, and parameter semantics are undocumented. Output schema and annotations provide additional structure, but the description alone is not fully complete for an agent to use it confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% (no descriptions for keyword, sort, or limit in the main properties). The tool description does not explain these parameters at all, failing to compensate for the schema gap. The sort enum has a brief description in the schema, but keyword and limit remain unexplained.
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 a specific verb and resource: 'Search X (formerly Twitter) posts'. It also adds context about using the user's Chrome session. However, it does not explicitly differentiate from sibling search tools like google_search or zhihu_search, though the platform-specific resource makes the purpose fairly unambiguous.
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 when to use this tool: when you need to search X posts, particularly via the user's existing Chrome session. It does not mention alternatives, exclusions, or prerequisites (e.g., being logged in), so guidance is minimal but not absent.
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?
The description adds context beyond annotations by revealing that searches occur through the user's real Chrome session, implying the use of the user's logged-in state and potential personalization. This complements the readOnlyHint and idempotentHint annotations. No contradictions with 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, front-loaded sentence that efficiently conveys the tool's core purpose. Every word contributes meaning without redundant details.
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?
The tool is relatively simple, and the output schema exists, so return format need not be described. However, given the presence of many sibling search tools, the lack of usage guidelines limits completeness. The description covers the core functionality but leaves the selection context unaddressed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, and the tool description does not explain the 'keyword' or 'limit' parameters. While the parameter names are self-explanatory, the description fails to clarify how 'limit' behaves (e.g., max results) or any constraints on 'keyword'. The description does not compensate for the missing schema descriptions.
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 tool searches the public web using Bing, with the distinctive detail of using the user's real Chrome session. This differentiates it from sibling search tools like google_search or sogou_search by specifying the engine and session context.
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?
No explicit guidance is provided about when to use this tool versus alternatives. While the description implies using it for Bing searches, it does not mention sibling tools or provide criteria for choosing Bing over other search engines.
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?
Annotations already mark the tool as read-only and non-destructive, and the description adds that it returns "the new screenshot and references" after scrolling, as well as the element-bringing behavior. There is no contradiction with 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, front-loaded sentence with no redundant filler. Every clause contributes meaning: the action, the target, the two modes, and the return value.
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?
It covers the core function and return value but leaves parameter semantics undefined and "references" vague. Given the absence of an output schema, more detail about the returned screenshot/references and the two scrolling modes would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description only hints at direction and element reference without explaining amount, wait_ms, or how element_id functions. It adds minimal value over the raw schema.
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 provides a specific verb ("Scroll") and target ("managed page"), and explains two operation modes: directional scrolling and bringing an element into view. This clearly differentiates it from sibling tools like browser_click or browser_read.
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?
No explicit when-to-use or when-not-to-use guidance is offered. It does not mention alternatives or indicate when element-scrolling is better than directional scrolling, leaving the agent to infer from the sibling tool list.
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?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false. The description adds valuable behavioral context by noting comments are 'bounded', implying the max_comments parameter limits the output size. This goes beyond what annotations say.
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 concise sentence that front-loads the core action and resource. Every word earns its place with no redundancy or filler.
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 simplicity, the description is adequate but leaves gaps: it does not specify the expected URL format, the nature of the 'bounded set' (e.g., whether max_comments is exact or cap), or how comments are ordered. The output schema and annotations fill some context, but the description could be more complete for a new agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for param semantics. It hints at the bounded comments but does not explain the url format or how max_comments controls the bounds. The parameter names are self-explanatory but the description adds little meaningful 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 uses the specific verb 'Read' and clearly identifies the resource as 'one Reddit post' plus 'a bounded set of comments'. This distinguishes it from search tools like reddit_search and browser navigation tools.
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?
No explicit guidance on when to use this tool versus alternatives (e.g., reddit_search or browser_read). The usage is implied by the description but no exclusions or alternative scenarios are mentioned.
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?
Annotations already cover safety with readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds that results are 'normalized post metadata and links,' giving some output behavior context, but no details on pagination, sorting defaults, or rate limits. With annotations covering the safety profile, a neutral score is appropriate.
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 concise sentence that immediately states the tool's purpose and output. No wasted words or repetition of structured information.
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?
An output schema is present, so return values need not be explained. However, the description is very brief and leaves parameter usage unspecified, especially given the input schema lacks property descriptions. It is minimally viable for a simple search tool but not richly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% per context signals, and the tool description does not elaborate on the 'keyword,' 'limit,' or 'sort' parameters. The description adds no meaning beyond the schema's property titles and defaults, so it fails to compensate for the lack of schema descriptions.
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 tool's action: 'Search Reddit posts' and the output: 'return normalized post metadata and links.' It distinguishes from sibling tools like reddit_post (which likely fetches a specific post) and other site-specific search tools (zhihu_search, xhs_search).
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?
Provides clear context: it is for searching Reddit posts. However, it does not explicitly mention when not to use it or point to alternatives (e.g., reddit_post for a specific post), so it misses the highest bar for usage guidance.
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?
The description adds the constraint that the element must be from the current browser_snapshot and that coordinates are viewport-based, which complements the annotations. However, it does not disclose post-click behavior (e.g., navigation, page changes) or the meaning of wait_ms, leaving some behavioral aspects undocumented beyond the destructiveHint annotation.
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 two concise sentences, front-loaded with the action and resource, and every word adds value. No redundancy or filler.
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?
The tool has no output schema, and the description does not mention what the tool returns or what observable effect occurs beyond clicking. Given the destructive annotation and the need to coordinate with browser_snapshot, more detail about wait_ms and post-click state would be necessary for complete understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must explain all parameters, but it only clarifies element_id and x/y. The wait_ms parameter is not described at all, leaving the agent to infer its purpose from the default value alone. This is a significant gap for a 4-parameter tool.
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 uses a specific verb 'Click' with a resource 'a current browser_snapshot element_id', clearly distinguishing it from sibling tools like browser_type or browser_scroll. It also clarifies the coordinate fallback, leaving no ambiguity about the tool's core function.
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?
It explicitly instructs to use viewport coordinates only when no semantic element reference is available, providing a clear when-to-use rule for the two input modes. However, it does not compare against sibling tools like browser_select or browser_press, so it stops short of full alternative guidance.
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?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, covering the safety profile. The description adds context about the logged-in account and date scoping, but does not disclose behaviors like pagination limits, rate limits, or handling of missing login, which are partially covered by the schema and 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, front-loaded sentence that clearly states the verb, resource, and scope with no superfluous words. It is optimally concise for a simple read operation.
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 low complexity (2 optional params), presence of an output schema, and rich annotations, the description covers the core purpose adequately. Minor gaps remain around parameter semantics and explicit usage guidance, but overall the description is sufficiently complete for a read-only tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 0% description coverage, and the description only implicitly references the 'day' parameter via 'one Asia/Shanghai date'. The 'max_pages' parameter is completely unexplained, leaving the agent to infer its purpose from the name alone. The description adds minimal value beyond the schema.
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 uses the specific verb 'Read' with a clear resource: 'the logged-in Zhihu account's answer invitations'. It also provides scope with 'for one Asia/Shanghai date', distinguishing it from sibling tools like zhihu_search and zhihu_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 for checking answer invitations on a specific date, but it does not explicitly state when to use this tool versus alternatives or when not to use it. There is no mention of alternatives like search functions, so guidance is inferred rather than explicit.
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?
Annotations already disclose destructiveHint=true and readOnlyHint=false, so the mutation risk is known. The description adds useful context by stating that it returns the new visual state and can focus on an element, going beyond the annotations. However, it does not elaborate on potential side effects like navigation or data deletion, which the destructive hint implies.
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 sentence, front-loaded with the core action ('Press one supported non-text keyboard key') and includes essential modifiers compactly. No redundant phrasing or filler.
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?
The tool is simple, and the description covers the main behavior (key press, optional element focus, return of visual state). Since there is no output schema, explicitly stating the returned visual state is helpful. Minor gaps remain (e.g., wait_ms, error cases), but annotations supply safety context and the schema supplies defaults.
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 description clarifies that 'key' refers to non-text keyboard keys and that element_id references a current element, adding meaning beyond the schema's bare property names. However, wait_ms is not mentioned, and with schema description coverage at 0%, the enumeration of key values is the only schema-based help. The description partially compensates but leaves gaps.
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 uses a specific verb ('Press') and resource ('one supported non-text keyboard key'), and further clarifies scope with 'optionally focused on a current element reference' and 'return the new visual state.' This clearly distinguishes it from sibling tools like browser_type (text input) and browser_click (mouse click).
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 non-text keyboard keys, but it does not explicitly state when to prefer this over browser_type or browser_click, nor does it provide exclusions or mention specific scenarios like form submission or navigation. There is no direct alternative guidance.
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?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds context beyond these: 'Unicode-safe' indicates handling of non-ASCII content, 'next' implies stateful pagination, and 'immutable' reassures that the snapshot does not change. No contradiction with 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, front-loaded sentence with no redundancy. Every word adds meaning, and the structure is clean and easily scannable.
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?
The description covers the core action and mentions 'existing immutable snapshot,' but it lacks guidance on how to obtain the snapshot_id, how pagination works with offset/max_chars, and how this tool differs from browser_read. Since an output schema exists, return values are likely covered, but usage context is incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not compensate by explaining parameters like snapshot_id, offset, or max_chars. It only hints at pagination with 'next page,' but leaves parameter semantics to the user's inference from names. This falls short for a low-coverage schema.
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 uses a specific verb ('read') with a clear resource ('page from an existing immutable browser snapshot'). It distinguishes itself from siblings like browser_read by specifying 'snapshot' and 'next page', indicating pagination from a saved state.
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: read a page from an already-created snapshot, but it does not explicitly state when to prefer this over similar tools like browser_read or site_read_page, nor does it mention any prerequisites beyond having a snapshot. Clear context but no exclusions or alternatives are provided.
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?
The description adds meaningful behavioral context beyond annotations: it specifies matching by exact value or visible label and states the tool returns the new visual state. It does not contradict annotations (readOnlyHint false, idempotentHint true).
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, concise sentence that front-loads the action and includes no unnecessary words. It is highly scannable.
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?
For a simple tool, the description covers core behavior and the return value, but lacks parameter details, edge cases, and error conditions. Given no output schema and zero schema descriptions, more context would be needed for fully autonomous use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description only partially explains the 'value' parameter via 'exact value or visible label', leaving element_id and wait_ms unexplained. This is insufficient for a 3-parameter tool.
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 uses a specific verb 'Choose' and resource 'native select option', and clearly states it operates by exact value or visible label, returning the new visual state. This distinguishes it from sibling tools like browser_click and browser_type.
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 use for native select elements but does not explicitly state when to use it over alternatives or provide exclusions. No alternatives are mentioned, so guidance is only 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?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, covering the safety profile. The description adds 'local' and 'installation and connection status' but offers no extra behavioral context, such as behavior when the bridge is missing or connection fails.
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, focused sentence that conveys the essential purpose without redundancy. It is appropriately sized for the tool's simplicity.
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?
For a zero-parameter status check with an output schema, the description is largely adequate. However, it could explicitly note that this should be used before other browser tools to verify the bridge connection, but this is not critical given the tool's 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?
The tool has zero parameters, so the description need not elaborate on parameter semantics. The 100% schema coverage and empty properties make this a baseline 4.
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 tool's function: returning the local Chrome extension bridge installation and connection status. It uses a specific verb ('Return') and resource, distinguishing it from sibling browser tools that perform actions.
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?
No guidance is provided on when to use this tool versus alternatives. It does not mention checking bridge status before using browser tools or any prerequisites, leaving the agent without context for invocation.
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?
Annotations already declare readOnlyHint and idempotentHint, so the description need not repeat safety. It adds useful context about the snapshot being 'immutable' and the action being reading 'the next page', disclosing the pagination-focused behavior. It does not, however, describe error conditions such as missing snapshot or end-of-data behavior, which would increase transparency further.
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 sentence that is front-loaded with the verb, and every word contributes meaning. It is succinct and well-structured without filler.
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?
The description is minimal and does not define what a 'site-specific document snapshot' is or how to acquire a snapshot_id, which is important since there are no parameter descriptions. The output schema covers return values, but the description lacks context on prerequisites and pagination mechanics. It is adequate for a simple read tool but has clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate, but it only mentions 'next page', which loosely hints at offset semantics. It does not explain the meaning or role of snapshot_id, offset, or max_chars. The parameter names are self-explanatory to a limited degree, but the description adds no concrete detail about their usage.
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 uses a specific verb 'Read' and clearly identifies the resource as 'an existing immutable site-specific document snapshot'. It distinguishes from sibling tools like browser_read_page by emphasizing 'site-specific' and 'snapshot'. The phrase 'next page' clarifies its pagination role.
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 implicitly indicates the tool requires an existing snapshot and supports pagination ('next page'), but it does not explicitly state when to choose this tool over alternatives such as browser_read_page or browser_snapshot. No alternatives or exclusions are mentioned, leaving usage guidance only 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?
Annotations already declare read-only and idempotent behavior. The description adds that it returns media URLs rather than the media files themselves, and that it handles a single post. No contradiction with 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?
One sentence that front-loads the action ('Read one X post') and lists the return content concisely. No unnecessary words.
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?
For a simple read tool with strong annotations and an output schema, the description conveys the core purpose and return content. However, it lacks parameter guidance and any usage exclusions, so it is only moderately complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has a single 'url' parameter with no description (0% coverage). The description does not explicitly explain that the URL should point to an X post, leaving the parameter's semantics under-specified.
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 uses the specific verb 'Read' with a clear resource 'one X post' and enumerates the included data (author, text, metrics, links, media URLs). This clearly distinguishes from sibling tools like x_search (search) or browser_read (generic page reading).
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 for reading a specific X post, which is distinct from searching (x_search) or browsing pages. However, it does not explicitly state when to use it versus alternatives or mention any exclusions.
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?
Annotations already declare the tool read-only, idempotent, and non-destructive. The description adds meaningful context by noting reliance on the current Chrome session (implying session/login requirements) and output normalization ('normalized results'). This goes beyond what annotations provide, with no contradictions.
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 sentence that front-loads the action, contains no filler, and conveys the essential function efficiently. It is an example of under-specification, not verbosity.
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?
The tool has an output schema and strong annotations, so return values are covered. However, the description omits search_type options and offset behavior, and lacks any usage guidance. It is minimally viable but leaves gaps for a tool with 3 parameters and 0% schema coverage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage for its three parameters, and the description itself does not explain keyword, offset, or search_type. The only parameter hint is the search_type enum's description in the schema, but the main description adds no meaning to any parameter, failing to compensate for low schema coverage.
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 uses the specific verb 'Search' with the resource 'Zhihu', and adds 'using the current Chrome session' and 'return normalized results' to clarify scope. This clearly distinguishes it from sibling search tools for other platforms like xhs_search and x_search.
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?
There is no explicit when-to-use or when-not-to-use statement, but 'Search Zhihu' unambiguously indicates the intended context, and 'using the current Chrome session' implies a prerequisite session dependency. No exclusions are given, so it is clear context without exclusions.
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?
The description discloses that the tool can optionally clear content and submit (pressing Enter), and that it returns the new visual state. However, it does not mention the wait_ms behavior, failure modes (e.g., non-editable element), or side effects beyond the optional submit. Annotations provide readOnlyHint=false, which aligns with the write nature, but the description adds only modest behavioral context.
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, front-loaded sentence that communicates the core purpose and key options without unnecessary detail. Every phrase contributes meaning, making it highly efficient.
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?
The description provides the essential action and return state, which is helpful given no output schema. However, it is incomplete for a 5-parameter tool: it omits wait_ms, does not explain how to obtain the element reference, and lacks clarity on the 'current' aspect. This leaves room for agent confusion in real usage.
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?
With 0% schema description coverage, the description compensates by implicitly covering most parameters: text (text to type), clear (optionally replacing contents), submit (pressing Enter), and element_id (current editable element reference). The wait_ms parameter is not mentioned, leaving a gap for timing behavior.
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 tool's action ('Type text'), the target resource ('current editable element reference'), and optional behaviors ('replacing its contents and pressing Enter'). It distinguishes from sibling tools like browser_press (key presses) and browser_select (selection) by focusing on text input.
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 on editable elements ('current editable element reference') but does not explicitly state when to use this tool versus alternatives or when not to use it. It also lacks guidance on prerequisites, such as how the element reference is obtained.
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?
Annotations already establish read-only, idempotent, non-destructive behavior. The description adds meaningful context by noting the search runs 'through the user's real Chrome session,' which implies results may be personalized or dependent on browser state. It also scopes to 'public web,' clarifying that private resources are out of scope.
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, front-loaded sentence: 'Search the public web with Google through the user's real Chrome session.' Every word adds value, with no redundancy or filler. It is appropriately concise.
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?
For a simple tool with only two parameters, a clear output schema, and safety annotations, the description covers the essential operation. It lacks explicit parameter documentation, but the parameter names are apparent, and the output schema likely handles return specifics. The description is sufficiently complete for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description provides no information about the `keyword` or `limit` parameters. While names are self-explanatory, the description does not clarify that `limit` likely caps the number of results, nor does it explain any relationship between the parameters. The description fails to compensate for the lack of schema descriptions.
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 states a specific verb and resource: 'Search the public web with Google.' It also adds a distinguishing detail ('through the user's real Chrome session') that sets it apart from sibling search tools. The purpose is unambiguous.
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 general Google web searches via 'public web,' but it does not explicitly compare with sibling search engines like bing_search or sogou_search. It lacks clear when-to-use or when-not-to-use guidance, though the 'public web' qualifier provides some context against site-specific tools.
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?
Annotations already cover read-only, idempotent, and non-destructive behavior. The description adds the 'pageable normalized document' behavior, which sets expectations about pagination and normalization beyond what annotations provide, though it doesn't detail max_chars handling.
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 sentence with no redundant words. It is front-loaded with the primary action and resource, making it highly efficient.
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?
With an output schema and clear annotations, the description does not need to enumerate return values. It covers the resource scope and output type, and for a simple read-only tool, it provides adequate context. Minor gap: pagination mechanics are not fully explained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description does not explain either parameter. The name 'max_chars' hints at a character limit but its interaction with pagination is unclear, leaving the agent to infer semantics from the name alone.
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 tool reads a Zhihu question, answer, or article and returns a pageable normalized document. This uses a specific verb and resource type, distinguishing it from sibling tools like zhihu_search or browser_read.
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 reading Zhihu content directly, but provides no explicit guidance on when to choose this over alternatives like browser_read or zhihu_search. It does not mention exclusions or conditions for use.
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?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint. The description adds useful context: the tool returns a viewport screenshot and fresh element references, and can optionally navigate to a URL. There is no contradiction with 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 concise sentence with strong verbs and no redundancy. Every clause contributes meaning, and it is front-loaded with the primary action.
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?
With descriptive annotations and a clear statement of purpose/output, the description is adequate. However, it lacks parameter semantics and explicit usage guidance, and there is no output schema to fall back on. For a two-parameter tool, this is a noticeable gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% (no descriptions on url or wait_ms), and the tool description does not explain these parameters. While names are somewhat self-explanatory, the description does not clarify that url is optional (default null) or that wait_ms controls the wait time before snapshot. With low coverage, the description must compensate but does not.
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 action: 'Open a public URL or observe the managed Chrome tab' and specifies the output: 'returning a viewport screenshot plus fresh element references for visual interaction.' This distinguishes it from sibling tools like browser_read (text) and browser_status (status).
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 indicates when to use it: for visual interaction and obtaining fresh element references. It also implies two scenarios (open a URL or observe the current tab). However, it does not explicitly mention alternatives or exclusions, such as 'use browser_read for text content.'
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?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the description only needs to add context. It adds the session-bound behavior and default user, but lacks details like pagination or error handling. This aligns with the calibration baseline for annotation-covered read tools.
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?
A single concise sentence conveys purpose and usage with zero redundant words; no structural waste.
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 simple tool, strong annotations, and an existing output schema, the description covers the main usage and session context. It lacks explicit alternative guidance but is otherwise complete for the tool's complexity.
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?
With 0% schema coverage, the description compensates for user_id by explaining the logged-in account default, but max_pages is not mentioned beyond its name, leaving its semantics still implicit. A 3 reflects partial compensation.
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 uses the specific verb 'List' with a clear resource ('notes published by a Xiaohongshu account') and adds scope ('through the current Chrome session'), distinguishing it from siblings like xhs_note and xhs_search.
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?
Provides clear context via the current Chrome session and explicitly instructs omitting user_id for the logged-in account, but does not mention exclusions or alternatives.
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?
Annotations already declare readOnlyHint=true and openWorldHint=true, providing a safe read-only profile. The description adds a key behavioral trait: it uses the user's real Chrome session, which implies dependence on session state, cookies, or login. This goes beyond annotation information without contradicting it.
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, front-loaded sentence that conveys the essential purpose and context. Every word earns its place, with no filler or repetition of schema fields, making it highly concise and well-structured.
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 simplicity, the description provides enough context for an agent to select it appropriately, especially with annotations and an output schema present. The main gap is parameter semantics, but the core action is clear. The 'real Chrome session' detail adds valuable operational context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain either parameter. It mentions searching with Sogou but gives no meaning for 'keyword' or 'limit'. While 'keyword' is somewhat obvious, 'limit' is entirely undocumented, leaving the agent to guess how result counts are capped.
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 uses a specific verb "Search" with a clear resource "the public web with Sogou", immediately distinguishing it from sibling search engines like Google or Bing. The added detail "through the user's real Chrome session" further clarifies the unique execution context.
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 clearly implies when to use this tool: whenever a Sogou search is required. However, it does not explicitly mention alternatives or exclusions, though the sibling list makes it evident that other search tools exist for different engines. This meets the 'clear context, no exclusions' level.
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?
Annotations already declare the tool safe (readOnlyHint, idempotentHint, non-destructive). The description adds useful context about the dependency on an existing signed web request and the current Chrome session, which informs the agent about authentication and browser state requirements. This goes beyond the annotations without contradiction.
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, concise sentence that immediately states the action and key context. There is no filler or redundancy; it efficiently conveys both what the tool does and a critical operational requirement.
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?
For a simple search tool with three parameters, an output schema, and safety annotations, the description covers the core purpose and the main contextual dependency (the Chrome session). It does not mention result limits or failure modes, but the output schema likely handles return values, so the description is sufficiently complete for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description provides no explanation of the parameters (keyword, page, sort), and schema description coverage is 0%. While the parameter names are somewhat self-explanatory, the description does not compensate for the lack of schema descriptions, leaving the sort enum semantics and page behavior to inference. The verb 'Search' only implicitly hints at a keyword.
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 tool's purpose: 'Search Xiaohongshu' via a 'signed web request in the current Chrome session.' The verb 'Search' and resource 'Xiaohongshu' are specific, and the mention of the signed web request distinguishes it from generic search tools and indicates an authenticated context.
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 that this tool should be used when searching Xiaohongshu requires an authenticated browser session, as it explicitly references 'the current Chrome session.' However, it does not explicitly mention when not to use it or compare with sibling tools like xhs_note or xhs_user_notes, so it lacks full exclusion guidance.
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?
Annotations already declare readOnly, idempotent, and non-destructive behavior. The description adds useful context by specifying the scope ('current Chrome Profile') and explicitly stating no platform task is executed, which reinforces the read-only nature without contradicting 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, front-loaded sentence with no redundant content. Every word adds meaning, and it is appropriately sized for a simple check tool.
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?
The tool is simple with one parameter and an output schema, so the description need not detail return values. It covers the essential purpose and platforms, but could add a small note about typical usage before platform tasks to fully contextualize its role among the sibling tools.
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?
There is one parameter with a well-defined enum, but schema property description coverage is 0%. The description lists the platforms in prose, partially compensating for the missing parameter description; however, it does not explicitly link the 'platform' parameter to the listed sites, relying on inference from the enum and the $defs description.
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 uses a specific verb ('Check whether') and clear resource ('current Chrome Profile logged in to Zhihu, Xiaohongshu, X, or Reddit'). It distinguishes itself from sibling platform task tools (e.g., zhihu_search, x_post) by explicitly stating 'without executing a platform task.'
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 phrase 'without executing a platform task' implies using this tool as a preflight check before platform operations. It names the relevant platforms and signals a non-invasive context, but it does not explicitly name alternative tools or provide exclusion criteria.
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?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds 'one' to clarify the scope and mentions xsec access parameters, but provides no additional behavioral details about errors, rate limits, or response structure. This is consistent with annotations, so no contradiction.
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, front-loaded sentence of 10 words. Every word contributes meaning; no 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?
With one parameter, a rich annotation set, and an output schema present, the description covers the core purpose and input requirements. The only minor gap is a lack of clarification about error behavior or what constitutes a valid xsec URL, but overall it's sufficient for a simple read tool.
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 schema has one parameter 'url' with zero description coverage. The description compensates by specifying 'explore-note URL with its xsec access parameters', giving key semantic guidance about the expected URL format. However, it doesn't fully define the exact structure or require xsec, so a 4 is warranted.
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 uses the specific verb 'Read' and names the resource 'Xiaohongshu explore-note URL with its xsec access parameters'. It clearly distinguishes from sibling tools like xhs_search (search) and xhs_user_notes (user note lists) by focusing on a single URL-based read.
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 the use case: when you have a specific explore-note URL to read. It provides clear context but doesn't explicitly mention alternatives or exclusions. There is no statement like 'use xhs_search instead for queries', so it falls short of explicit when-not guidance.
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?
Annotations already provide safety hints (read-only, idempotent, non-destructive). The description adds context by mentioning the 'real Chrome session' and 'public HTTP(S)' scope, which tells the agent about the environment and what URLs are acceptable. This goes beyond the 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, well-structured sentence that front-loads the action and then lists extraction modes. It contains no redundant words or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity, the presence of an output schema, and strong annotations, this description is complete. It covers the purpose, the extraction outputs, and the scope without needing to describe return values.
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 coverage is 0%, so the description must compensate. It explains the extract parameter by mapping it to concrete output types (readability, text, HTML, XHR), which adds value beyond the schema. However, wait_ms and max_chars are not described and rely solely on their self-explanatory names.
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 uses specific verbs ('load', 'extract') and identifies a clear resource: a public HTTP(S) URL in the user's real Chrome session. It also enumerates the extraction modes (readability text, visible text, rendered HTML, XHR responses), which effectively distinguishes it from sibling tools like browser_read_page or browser_snapshot.
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 for loading public URLs and extracting page content, giving clear context. However, it does not explicitly state when not to use this tool or name alternatives, such as browser_read_page for the current page.
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:

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

Score Badge

Copy to your README.md:

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

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/ywleeo/browser-mcp'

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