Skip to main content
Glama
Tikous

MCP Browser Text Reader

by Tikous
OverviewSchemaRelated ServersScoreDiscussions
JavaScript
Local

MCP Browser Text Reader

一个强大的 Model Context Protocol (MCP) 服务器，用于控制真实的Chrome浏览器并读取页面文字内容。支持多种文本提取方式和灵活的配置选项。

功能特性

  • 🌐 真实Chrome浏览器控制: 直接控制系统中的Chrome浏览器，可见窗口操作

  • 📝 灵活的文本提取: 支持可见文本、所有文本、innerText、textContent等多种提取方式

  • 🎯 精确元素选择: 使用CSS选择器精确定位需要提取的元素

  • ⏱️ 智能等待机制: 支持等待特定元素加载完成

  • 🔍 详细的元数据: 提供字符数、词数、提取时间等详细信息

  • 🛡️ 错误处理: 完善的错误处理和资源清理机制

  • 🔄 智能连接: 自动连接现有Chrome实例或启动新实例

  • 👀 可视化操作: 实时观察浏览器操作过程

Related MCP server: MCP Fetch Page

安装

1. 克隆项目

git clone <repository-url>
cd mcp-browser-text-reader

2. 安装依赖

npm install

3. 确保Chrome浏览器已安装

确保系统中已安装Google Chrome浏览器：

  • macOS: /Applications/Google Chrome.app/

  • Windows: C:\Program Files\Google\Chrome\Application\chrome.exe

  • Linux: /usr/bin/google-chrome

4. 编译 TypeScript

npm run build

使用方法

作为 MCP 服务器运行

npm start

在 Cursor 中配置

在 Cursor 的 MCP 配置文件中添加以下配置：

位置: .cursor/mcp.json

{
  "mcpServers": {
    "browser-text-reader": {
      "command": "node",
      "args": ["/absolute/path/to/your/project/dist/index.js"]
    }
  }
}

在 Claude Desktop 中配置

位置: ~/Library/Application Support/Claude/claude_desktop_config.json (macOS)

{
  "mcpServers": {
    "browser-text-reader": {
      "command": "node",
      "args": ["/absolute/path/to/your/project/dist/index.js"]
    }
  }
}

可用工具

1. get_page_text

获取指定URL页面的文本内容

参数:

  • url (可选): 要读取的网页URL

  • selector (可选): CSS选择器，用于选择特定元素

  • waitForSelector (可选): 等待特定元素出现的CSS选择器

  • timeout (可选): 超时时间（毫秒），默认10000

  • includeHidden (可选): 是否包含隐藏元素，默认false

  • textType (可选): 文本提取类型，可选值：visible、all、innerText、textContent

示例:

{
  "url": "https://example.com",
  "selector": "article",
  "textType": "visible",
  "timeout": 15000
}

2. get_current_page_text

获取当前浏览器页面的文本内容

参数:

  • selector (可选): CSS选择器

  • includeHidden (可选): 是否包含隐藏元素

  • textType (可选): 文本提取类型

3. navigate_to_page

导航到指定URL

参数:

  • url (必需): 要导航到的网页URL

  • waitForSelector (可选): 等待特定元素出现

  • timeout (可选): 超时时间

4. get_page_info

获取当前页面的基本信息（标题、URL等）

5. launch_chrome_manually

手动启动Chrome浏览器（可见窗口）

6. get_browser_status

获取浏览器连接状态

7. close_browser

关闭浏览器实例或断开连接

文本提取类型说明

  • visible (默认): 只提取用户可见的文本

  • all: 提取所有文本内容，包括隐藏元素

  • innerText: 使用 element.innerText 提取文本

  • textContent: 使用 element.textContent 提取文本

使用示例

在 AI 助手中使用

  1. 读取网页内容:

    请使用 get_page_text 工具读取 https://news.ycombinator.com 的内容

  2. 提取特定元素:

    请读取当前页面中所有 h2 标题的文本

  3. 等待动态内容加载:

    请访问 https://example.com 并等待 .content 元素加载完成后提取文本

直接测试

运行测试脚本来验证功能：

npm run build
# 运行Chrome浏览器测试
node dist/test-chrome-server.js

测试将会：

  1. 启动可见的Chrome浏览器窗口

  2. 导航到测试网页

  3. 提取页面文本内容

  4. 演示各种功能

开发

项目结构

src/
├── index.ts                # MCP 服务器主入口
├── chrome-browser-manager.ts # Chrome浏览器管理器
└── test-chrome-server.ts   # Chrome测试脚本

dist/                       # 编译后的 JavaScript 文件
package.json               # 项目配置
tsconfig.json             # TypeScript 配置

开发模式

# 监听文件变化并自动重新编译
npm run dev

构建

npm run build

故障排除

常见问题

  1. Chrome浏览器未安装或路径错误 确保系统已安装Chrome浏览器，并且路径正确。

  2. 权限问题 确保有足够的权限运行浏览器，在某些环境中可能需要额外的参数。

  3. 超时错误 增加 timeout 参数值，特别是对于加载较慢的页面。

  4. 内存使用过高 定期调用 close_browser 工具来释放资源。

调试

启用详细日志输出：

DEBUG=* npm start

技术栈

  • Node.js: JavaScript 运行时

  • TypeScript: 类型安全的 JavaScript

  • Puppeteer: Chrome浏览器自动化

  • MCP SDK: Model Context Protocol 官方 SDK

  • Zod: 运行时类型验证

许可证

MIT License

贡献

欢迎提交 Issue 和 Pull Request！

更新日志

v1.0.0

  • 初始版本

  • 支持基本的页面文本提取功能

  • 支持多种文本提取类型

  • 完整的 MCP 协议支持

Available Tools

7 tools
close_browserC

关闭浏览器实例

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

C2.8/5.0
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 states the action (close) but doesn't describe what happens—e.g., whether it gracefully shuts down the browser, kills processes, affects other tools, or has side effects like losing unsaved data. This is a significant gap for a potentially destructive operation.

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 a single, efficient sentence ('关闭浏览器实例') that directly states the purpose without waste. It's appropriately sized for a simple tool, though it could be slightly more informative without losing conciseness.

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 potential complexity (closing a browser could involve cleanup, state changes, or errors) and lack of annotations and output schema, the description is incomplete. It doesn't address behavioral aspects, return values, or error conditions, leaving gaps for an AI agent to understand its full context.

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 0 parameters, and schema description coverage is 100%, so no parameter documentation is needed. The description doesn't add parameter semantics, but that's acceptable here. Baseline is 4 for zero parameters, as there's nothing to compensate for.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description '关闭浏览器实例' (close browser instance) states a clear action (close) on a resource (browser instance), but it's vague about scope—it doesn't specify whether this closes all browser windows, a specific instance, or just the current tab. It distinguishes from siblings like 'navigate_to_page' or 'get_browser_status' by being a termination action, but lacks precision.

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. For example, it doesn't mention if this should be used after completing tasks, to free resources, or as part of cleanup, nor does it reference sibling tools like 'launch_chrome_manually' for context. The description alone offers no usage context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_browser_statusB

获取浏览器连接状态

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

B3.2/5.0
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. While '获取' (get) implies a read operation, the description doesn't specify what 'connection status' entails (e.g., whether it returns active/inactive, connection details, error states), whether authentication is required, or if there are rate limits. For a tool with zero annotation coverage, this leaves significant behavioral gaps.

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 phrase that directly states the tool's purpose with zero wasted words. It's appropriately sized for a simple status-checking tool and is front-loaded with the essential 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?

Given the tool's simplicity (0 parameters, no output schema, no annotations), the description is minimally adequate. However, for a status-checking tool, it could benefit from clarifying what 'connection status' specifically returns (e.g., boolean, detailed object, error messages). Without annotations or output schema, the agent lacks context about the return format.

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 0 parameters, and schema description coverage is 100% (empty schema is fully described). The description doesn't need to compensate for any parameter documentation gaps. A baseline of 4 is appropriate since there are no parameters to explain beyond what the schema already provides.

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 '获取浏览器连接状态' (Get browser connection status) clearly states the tool's purpose with a specific verb ('获取' - get) and resource ('浏览器连接状态' - browser connection status). It distinguishes itself from siblings like close_browser, get_page_info, and navigate_to_page by focusing on connection status rather than page content or navigation. However, it doesn't explicitly differentiate from all siblings in terms of 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. There's no mention of prerequisites, when this tool is appropriate, or when other tools like get_page_info or launch_chrome_manually should be used instead. The agent must infer usage from the tool name alone.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_current_page_textC

获取当前浏览器页面的文本内容

ParametersJSON Schema
NameRequiredDescriptionDefault
selectorNoCSS选择器，用于选择特定元素的文本（可选）
includeHiddenNo是否包含隐藏元素的文本，默认false
textTypeNo文本提取类型，默认'visible'

TDQS

C2.9/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries full burden for behavioral disclosure. It states what the tool does but lacks critical behavioral details: it doesn't specify if this requires an active browser/tab, what happens if no page is open (error/empty result), whether it returns structured data or raw text, or any performance/rate limits. For a tool with potential dependencies and no annotation coverage, this is insufficient.

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, direct sentence in Chinese that states the core functionality without any fluff. It's front-loaded with the essential action and resource. Every word earns its place, making it highly 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 (interacting with browser state, 3 parameters) and lack of both annotations and output schema, the description is incomplete. It doesn't cover behavioral aspects (e.g., dependencies, error cases), output format, or usage context relative to siblings. The agent lacks sufficient information to use this tool reliably without trial and error.

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%, with clear parameter descriptions in the schema itself (e.g., selector as CSS selector, includeHidden for hidden elements, textType with enum options). The description adds no parameter-specific information beyond the schema. According to guidelines, with high schema coverage (>80%), the baseline is 3 even without param details 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 verb ('获取' - get/retrieve) and resource ('当前浏览器页面的文本内容' - current browser page text content), making the purpose immediately understandable. It doesn't explicitly differentiate from sibling tools like 'get_page_text' (which might be for different pages), but the 'current' qualifier provides some distinction. The purpose is specific and actionable.

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 like 'get_page_text' (from the sibling list) or other text extraction methods. There's no mention of prerequisites (e.g., requires an active browser session), exclusions, or comparative context. The agent must infer usage from the tool name and parameters alone.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_page_infoB

获取当前页面的基本信息（标题、URL等）

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

B3.3/5.0
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 states it retrieves information (implying a read-only operation) but doesn't disclose behavioral traits such as whether it requires an active browser session, potential errors if no page is loaded, or what specific fields are returned beyond 'title, URL, etc.' For a tool with zero annotation coverage, this is a significant gap.

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 a single, efficient sentence in Chinese that directly states the tool's purpose. It's appropriately sized and front-loaded with the core action, though it could be slightly more structured by explicitly listing all return fields.

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 adequate. It covers the basic purpose but lacks details on return values (beyond 'title, URL, etc.'), error conditions, or dependencies on browser state. Without annotations or output schema, the description should do more to compensate.

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 parameters need documentation. The description doesn't add parameter details, which is appropriate here. Baseline is 4 for 0 parameters, as the description doesn't need to compensate for any schema gaps.

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 ('获取' meaning 'get') and resource ('当前页面的基本信息' meaning 'basic information of the current page'), specifying what information is retrieved (title, URL, etc.). It distinguishes from siblings like get_current_page_text (which gets text content) and get_page_text (which gets text from a specific page), but doesn't explicitly mention these distinctions.

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 context ('当前页面' meaning 'current page'), suggesting it should be used when the browser is on a page and basic metadata is needed. However, it doesn't provide explicit guidance on when to use this versus alternatives like get_current_page_text or navigate_to_page, nor does it mention prerequisites like needing an active browser session.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_page_textC

获取指定URL页面的文本内容

ParametersJSON Schema
NameRequiredDescriptionDefault
urlNo要读取的网页URL（可选，如果不提供则读取当前页面）
selectorNoCSS选择器，用于选择特定元素的文本（可选）
waitForSelectorNo等待特定元素出现的CSS选择器（可选）
timeoutNo超时时间（毫秒），默认10000
includeHiddenNo是否包含隐藏元素的文本，默认false
textTypeNo文本提取类型，默认'visible'

TDQS

C2.9/5.0
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 states the tool gets text content but doesn't mention critical behaviors like whether it launches a browser, handles errors, requires internet access, or has rate limits. For a tool with 6 parameters and no annotations, this is a significant gap in transparency.

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 in Chinese that directly states the tool's purpose without any fluff or redundancy. It's appropriately sized and front-loaded, making it easy to parse quickly.

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 (6 parameters, no output schema, no annotations), the description is incomplete. It doesn't explain return values, error handling, or behavioral nuances like browser interaction. For a tool that likely involves web scraping or browser automation, more context is needed to guide effective 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 input schema has 100% description coverage, providing detailed documentation for all 6 parameters. The description adds no additional parameter semantics beyond what's in the schema, so it meets the baseline of 3 where the schema does the heavy lifting without compensating value.

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 ('获取' meaning 'get') and resource ('指定URL页面的文本内容' meaning 'text content of specified URL page'), making the purpose evident. However, it doesn't explicitly differentiate from sibling tools like 'get_current_page_text' or 'get_page_info', which reduces the score from a perfect 5.

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 like 'get_current_page_text' (for current page) or 'get_page_info' (which might return different information). There's no mention of prerequisites, context, or exclusions, leaving the agent with minimal usage direction.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

launch_chrome_manuallyB

手动启动Chrome浏览器（可见窗口）

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

B3.1/5.0
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 states the tool launches Chrome with a visible window, but doesn't cover critical aspects like whether it requires user permissions, what happens if Chrome is already running (e.g., opens new window or reuses existing), error conditions, or platform dependencies. This leaves significant gaps 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, efficient sentence in Chinese that directly states the tool's function without any fluff. It's front-loaded with the core action and includes a useful detail (visible window) that adds value without verbosity.

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 (a mutation that launches an external application) and the lack of annotations and output schema, the description is insufficient. It doesn't explain what happens on success (e.g., returns a process ID or status), failure modes, or integration with sibling tools, 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.

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 appropriately doesn't discuss parameters, and the baseline for 0 parameters is 4, as it avoids unnecessary information.

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 ('手动启动' - manually launch) and target resource ('Chrome浏览器' - Chrome browser), with the additional detail of creating a visible window. It doesn't distinguish from sibling tools like 'close_browser' or 'get_browser_status', but 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 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 prerequisites (e.g., Chrome must be installed), when it's appropriate versus automated launches, or how it relates to sibling tools like 'navigate_to_page' which might require a browser to be running first.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

navigate_to_pageC

导航到指定URL

ParametersJSON Schema
NameRequiredDescriptionDefault
urlYes要导航到的网页URL
waitForSelectorNo等待特定元素出现的CSS选择器（可选）
timeoutNo超时时间（毫秒），默认10000

TDQS

C2.9/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries full burden for behavioral disclosure. It states the action ('navigate') but doesn't describe what this entails (e.g., opens a new tab/page, reloads current page, handles redirects), potential side effects (e.g., page loading delays, authentication prompts), or error conditions. This is inadequate for a tool with mutation implications.

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 in Chinese ('导航到指定URL') that directly states the tool's purpose without any wasted words. It is appropriately sized and front-loaded, making it easy to parse quickly.

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 (navigation with optional waiting and timeout), lack of annotations, and no output schema, the description is insufficient. It doesn't cover behavioral aspects, return values, or error handling, leaving significant gaps for the 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 all parameters (url, waitForSelector, timeout) with descriptions and constraints. The description adds no additional meaning beyond the schema, such as explaining interactions between parameters or typical use cases, meeting 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 '导航到指定URL' (Navigate to specified URL) clearly states the verb 'navigate' and the resource 'URL', making the purpose immediately understandable. However, it doesn't differentiate from potential sibling tools like 'get_page_info' or 'get_current_page_text' that might also involve page navigation, so it doesn't reach the highest score.

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 prerequisites (e.g., browser must be launched), exclusions, or comparisons to sibling tools like 'launch_chrome_manually' or 'get_page_info', leaving the agent to infer usage context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. 7 tool updatesv1.0.0
    • First observedclose_browser
    • First observedget_browser_status
    • First observedget_current_page_text
    • First observedget_page_info
    • First observedget_page_text
    • First observedlaunch_chrome_manually
    • First observednavigate_to_page
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

B3.4/5.0
Disambiguation4/5

Most tools have distinct purposes, such as launching, navigating, getting text, and closing. However, 'get_current_page_text' and 'get_page_text' could cause confusion: the former targets the current page, while the latter targets a specified URL, but their names and descriptions are similar enough that an agent might misselect them without careful reading.

Naming Consistency5/5

All tool names follow a consistent snake_case pattern with clear verb_noun structures (e.g., 'close_browser', 'get_page_text'). There are no deviations in naming conventions, making the set predictable and easy to parse for an agent.

Tool Count5/5

With 7 tools, this server is well-scoped for its purpose of reading text from a browser. It covers essential operations like launching, navigating, retrieving text and info, and closing, without being overly sparse or bloated, which is appropriate for the domain.

Completeness4/5

The tool set covers core workflows for browser text reading, including launching, navigation, text retrieval, and cleanup. A minor gap is the lack of tools for interacting with page elements (e.g., clicking, inputting text) or handling errors, but agents can still perform basic text extraction tasks effectively.

Maintenance

ActivityInactive
ResponsivenessSyncing

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Related MCP Servers

  • MCPBrowser

    cherchyk
    A
    license
    Not graded
    quality
    A
    maintenance
    Fetches content from authenticated web pages by driving your signed-in Chrome/Edge browser via DevTools Protocol, automatically handling login redirects and reusing sessions across domains.
    8
    MIT

  • MCP Fetch Page

    kaiye
    A
    license
    A
    quality
    C
    maintenance
    Enables browser-based web page fetching with automatic cookie management and CSS selector extraction, supporting JavaScript rendering and authenticated sessions through a Chrome extension.
    1
    7
    2
    MIT

  • monkeysee

    juliocesar
    A
    license
    Not graded
    quality
    B
    maintenance
    Enables MCP clients to drive a real, logged-in Chrome browser for web automation tasks like navigation, clicking, typing, and screenshotting.
    10
    1
    MIT

  • mcp-fetch-ux

    bxxd
    A
    license
    Not graded
    quality
    B
    maintenance
    Fetches web pages with JavaScript rendering, pierces Shadow DOM, and enables interactive actions like clicking and form filling using a real Chrome browser.
    2
    MIT

Appeared in Searches

Latest Blog Posts

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/Tikous/myMCP'

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