MCP Browser Text Reader

by Tikous

Overview Schema Related Servers Score Discussions

JavaScript

Local

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation4/5
Most tools have distinct purposes, such as 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.
Average 3/5 across 7 of 7 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It 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.
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.
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.
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.
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.
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.
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.

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:

[![myMCP MCP server](https://glama.ai/mcp/servers/Tikous/myMCP/badges/card.svg)](https://glama.ai/mcp/servers/Tikous/myMCP)

Score Badge

Copy to your README.md:

[![myMCP MCP server](https://glama.ai/mcp/servers/Tikous/myMCP/badges/score.svg)](https://glama.ai/mcp/servers/Tikous/myMCP)

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

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