Chrome Course MCP

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation4/5
Most tools target distinct actions (open, navigate, click, type, screenshot, etc.), and the two Brightspace tools are clearly separate. Slight overlap exists between chrome_open_tab and chrome_launch, and between chrome_snapshot and chrome_extract_media, but descriptions resolve ambiguity.
Naming Consistency5/5
All tools follow a consistent pattern: domain_verb_noun (chrome_*, brightspace_*). Every name uses lowercase with underscores and a clear action verb, making the naming predictable and easy to learn.
Tool Count4/5
With 16 tools, the set is slightly above the ideal 3-15 range but still well-scoped for Chrome automation plus Brightspace-specific archiving. Each tool has a specific role, and the count feels justified rather than bloated.
Completeness4/5
The Chrome automation covers a full interaction lifecycle: tab management, navigation, reading, clicking, typing, selecting, pressing, evaluating, saving, downloading, and media extraction. Brightspace coverage is limited to collecting/archiving pages, which fits the apparent purpose but lacks other potential course-management operations.
Average 3.1/5 across 16 of 16 tools scored. Lowest: 2.4/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 1 commit 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?
The description discloses the key behavioral trait that the tool uses cookies from the selected Chrome tab, indicating it can access authenticated or authorized content. However, with no annotations provided, the description carries the full burden for behavioral transparency, and it does not mention side effects like writing files to disk, handling of existing files, or any rate limits. This leaves significant gaps for a tool that performs downloads.
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 appropriately concise—a single sentence with no redundant words. It front-loads the core action and context, making it easy to scan. However, its brevity comes at the cost of completeness on other dimensions, but for conciseness itself it is well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is far from complete for a tool with seven parameters, no annotations, and no output schema. It fails to explain the meaning of outputDir, tabId, debugUrl, overwrite, urlContains, and titleContains, and does not describe any return values or error behavior. The single-sentence overview is insufficient for an AI agent to safely and correctly use this tool.
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 description provides no explanation of the parameters beyond the generic phrase 'direct URLs.' With a schema description coverage of 0%, the description needed to clarify the roles of the seven parameters, especially required ones like urls and outputDir, but it does not. This makes it impossible to understand how to correctly invoke the tool.
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 uses the verb 'Download' and specifies the resource 'authorized direct URLs' with the context 'using cookies from the selected Chrome tab.' This clearly conveys the tool's function and distinguishes it from sibling tools like chrome_save_page or chrome_extract_media, which have different purposes. However, 'authorized direct URLs' is somewhat ambiguous about what constitutes a direct URL or download vs. simply fetching content.
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 instead of alternatives. No mention of prerequisites, limitations, or exclusions, such as when to prefer chrome_save_page or chrome_extract_media. The only implied context is that it relies on the selected Chrome tab's cookies, but it does not explicitly say when that is necessary.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It mentions the output format (PNG) but omits critical behaviors such as what 'selected page' means, how tab selection works, whether it captures full page or viewport, and what is returned (file path, etc.). The description is too vague for an agent to anticipate side effects.
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, compact sentence that is easy to parse and front-loaded. It wastes no words, but its brevity contributes to under-specification. As a concise statement, it earns a high score, though not perfect because it omits essential context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 6 parameters, no annotations, and no output schema, the tool is complex enough that a full description is necessary. This description provides only a minimal declarative statement, lacking any handling of parameter relationships, default behaviors, or return values. It is fundamentally incomplete for an agent to use reliably.
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%, and the description provides no explanation of any of the 6 parameters. It only hints at 'selected page' without clarifying the roles of tabId, urlContains, titleContains, fullPage, or outputPath. The description entirely fails to compensate for the missing parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action: 'Capture a PNG screenshot of the selected page.' It identifies a specific verb (capture), resource (screenshot), and format (PNG). However, it does not differentiate from sibling tools like chrome_snapshot, which may also involve capturing page content.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to use this tool versus alternatives, nor does it mention any prerequisites or exclusions. It is a single declarative statement without context for selection.
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 responsibility for disclosing side effects, permissions, or limitations. It only says 'extract', implying a read operation, but provides no details on whether it executes scripts, requires debugUrl, or what happens to the tab. This is a significant transparency 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 sentence with no redundant phrasing, making it concise and front-loaded with the core action. It efficiently lists the extraction targets. However, it is under-specified in other dimensions, but that is not a conciseness failure; it is appropriately sized for the limited information it conveys.
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?
For a tool with 4 parameters, no output schema, and no annotations, the one-sentence description is insufficient. It does not explain return values, how filtering works, what 'candidates' means, or how debugUrl is used. The agent would lack essential context to invoke the tool correctly in non-trivial scenarios.
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 coverage is 0%, and the description does not mention any of the four parameters (tabId, debugUrl, urlContains, titleContains). It alludes to a 'selected Chrome tab' but does not clarify which parameter controls that selection, nor what the filter parameters do. The description fails to compensate for the schema's lack of explanations.
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 identifies the tool's function: extracting media, document, iframe, and link candidates from a selected Chrome tab. It uses a specific verb ('extract') and resource ('selected Chrome tab'), and the content types listed help distinguish it from sibling tools like chrome_save_page or chrome_download_urls, though it does not explicitly compare itself to them.
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?
There is no guidance on when to use this tool versus alternatives, nor any mention of prerequisites like Chrome debugging being enabled or the tab being open. The description only states what it does, leaving the agent to infer usage context entirely.
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 disclosing behavioral traits. It states the action but does not mention side effects such as clearing the field by default (clear), submitting (submit), or waiting (waitMs), nor any failure or return behavior.
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, front-loaded sentence with no filler. It is appropriately sized for a simple purpose statement, though it lacks depth in other dimensions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (10 parameters, no output schema, no annotations), the description is severely incomplete. It does not explain return values, behavior of key parameters, or edge cases, making it inadequate for reliable tool invocation.
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. It partially explains the 'selector' and 'label' parameters by mentioning locator strategies, but leaves critical parameters like 'value', 'clear', 'submit', 'waitMs', 'tabId', 'urlContains', 'titleContains', and 'debugUrl' completely 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 the tool's purpose: 'Type into an input or textarea' and lists specific locator strategies (CSS selector, label text, etc.), making the verb and resource explicit. However, it does not differentiate from sibling tools such as chrome_click or chrome_press by naming alternatives or contrasting use cases.
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, nor does it mention any prerequisites or exclusions. It only states what the tool does, 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 must disclose side effects and behaviors itself. It only states that a manifest is created, but does not mention that the tool likely saves HTML/PDF files, interacts with the browser via debugging, or writes to the output directory. This is a significant transparency gap for a tool with savePdf, saveHtml, and outputDir parameters.
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, concise sentence that front-loads the primary purpose. There is no fluff or redundant wording. However, it is so brief that it borders on under-specification, which slightly reduces the score from a perfect 5.
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?
This tool has 8 parameters, no output schema, and no annotations, yet the description only provides a one-line purpose. It does not explain return values, file system changes, prerequisites, or how the parameters affect behavior. The description is inadequate for an agent to correctly invoke the tool in real scenarios.
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 8 parameters with 0% description coverage, so the description must compensate by explaining parameters. It does not explain outputDir, savePdf, saveHtml, courseCode, tabId, debugUrl, urlContains, or titleContains. Some names are self-explanatory, but key parameters like debugUrl and tabId are ambiguous, and the description adds no meaning beyond the tool's overall purpose.
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 identifies the tool's action—creating a Brightspace-oriented manifest—and its source (the selected course/module page). It gives a specific verb and resource, which distinguishes it from generic Chrome tools, though it doesn't explicitly contrast with the sibling brightspace_archive_links.
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?
There is no guidance on when to use this tool versus alternatives, nor any mention of prerequisites or exclusions. The phrase 'selected course/module page' implies a context but does not clarify whether it applies only to Brightspace, how to select the page, or when to choose chrome_save_page or brightspace_archive_links instead.
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, the description must disclose behavioral traits, but it only states a high-level save action. It does not mention that the tool writes files to disk, how the 'selected tab' is identified, whether it requires an active CDP connection (debugUrl), or whether it blocks for page completion. This leaves the side effects and requirements largely opaque.
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, front-loaded sentence with no filler words. It is easy to read, though its brevity means important contextual details are omitted (but that is a completeness issue, not a conciseness issue).
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 9 parameters, no output schema, and zero schema description coverage, this description is far too sparse. It leaves the user without information on mandatory arguments, file naming, tab selection, or filtering behavior. For a tool of this complexity, the description is minimally viable at best.
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 9 parameters and zero descriptions, so the prose must compensate; instead it only hints at the html/pdf flags. The required outputDir, tabId/baseName selection, landscape print option, and urlContains/titleContains filters are never mentioned. The description adds little beyond the schema's property names.
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 uses a specific verb 'Save' with a clear resource 'selected Chrome tab' and specifies output formats ('HTML and/or PDF'). This makes the core purpose immediately understandable. However, it does not mention how this relates to sibling tools like chrome_snapshot or chrome_screenshot, so a user might not know when to prefer this tool.
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 usage guidance is provided. The description does not state when to use this tool versus alternatives like chrome_snapshot or chrome_eval, nor does it mention prerequisites such as a running Chrome instance or the debug port. There are no exclusions or conditions.
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 must fully disclose behavior. It states navigation and saving but omits dependencies (Chrome debug URL, active tab requirement), the structure of the manifest, and side effects like file creation. It also fails to mention that delayMs, maxPages, and filtering parameters affect behavior, leaving significant behavioral ambiguity.
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 filler. It efficiently conveys the core action and output without redundant phrasing, earning full marks for 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 12 parameters, no output schema, and no annotations, the description is too sparse. It provides a high-level flow but leaves critical context undocumented: filtering behavior (urlPattern, urlContains, titleContains), navigation limits (maxPages), timing (delayMs), and the structure of the output manifest. The tool cannot be reliably invoked without additional information.
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. It provides minimal semantics: 'current tab' maps to tabId, 'URL list' maps to urls, and 'HTML/PDF' maps to saveHtml/savePdf. However, it does not explain outputDir, courseCode, urlPattern, urlContains, titleContains, delayMs, debugUrl, or maxPages, leaving most parameters semantically opaque.
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 navigates Brightspace links from the current tab or a URL list and saves each page as a categorized manifest plus HTML/PDF. This specific verb+resource+output distinguishes it from siblings like chrome_save_page or chrome_download_urls, which handle single-page downloads without manifest creation.
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 vs alternatives. It mentions two input modes (current tab, URL list) but does not discuss prerequisites such as a running Chrome debugger, nor exclusions like when to prefer brightspace_collect_current or chrome_save_page. The context is implied but not actionable.
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 exist, so the description must disclose side effects, permissions, and return behavior. It does list the content captured, but omits whether the page is modified, whether it requires a loaded page, or the output format. It also does not mention the debugUrl or other operational details.
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, succinct sentence that front-loads the core action ('Summarize') and lists specific content types without fluff. It is highly concise.
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 6 parameters, no output schema, and no annotations, the description lacks detail on how to use it correctly in an automation workflow. The phrase 'selected page' is vague, and there is no mention of return structure, limits, or preconditions. The description does not cover enough for a complete understanding.
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 coverage is 0%: none of the 6 parameters are described. The description does not explain tabId, debugUrl, maxElements, etc., leaving the user without guidance on how to configure the tool. This is a significant gap.
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: it summarizes the selected page's visible elements (text, links, buttons, inputs, selects, forms) specifically for automation planning. This differentiates it from sibling tools like chrome_screenshot or chrome_eval.
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 during the planning phase for automation ('for automation planning'), but does not explicitly specify when to use it versus alternative tools like chrome_navigate or chrome_click, nor does it provide exclusions.
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, the description must fully disclose behavioral traits, but it only mentions the targeting mechanism. It fails to explain behavior around tab selection, waiting, navigation side effects, or error handling—critical aspects for a browser automation tool with 8 parameters.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, consisting of two short sentences. Every word serves a purpose: the first states the core action, the second provides a practical use case. There is no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 8 parameters, no annotations, no output schema, and the description is only one line. It lacks essential information about return values, error behavior, tab selection, waiting logic, and how the various filtering parameters interact. This is severely incomplete for a tool of this 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%, so the description must compensate. It explains 'selector' and 'text' implicitly, but leaves six other parameters (exact, tabId, waitMs, debugUrl, urlContains, titleContains) completely unexplained. The added semantics are minimal and insufficient for the parameter count.
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 with a specific verb ('Click') and resource ('element'), and specifies two targeting methods (CSS selector or visible text). This distinguishes it from sibling tools like chrome_type, chrome_select, and chrome_press, which perform different actions.
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 phrase 'Useful for control panels and file-manager buttons' gives some contextual guidance on when to apply the tool, but it does not explicitly mention alternatives or exclusions. It provides a hint of appropriate scenarios but lacks clear comparison to sibling tools.
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, the description carries the full burden of disclosing side effects and execution context. It only says 'evaluate JavaScript' but does not state that scripts can modify the page, what the return value looks like, whether the evaluation is asynchronous, or how tab selection works. This leaves significant behavioral ambiguity for an agent invoking the 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 two short sentences, front-loaded with the core action. It provides just enough context in a compact form without extraneous detail. Each sentence adds value: the first states the primary function, the second clarifies the intended use case.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has six parameters, no annotations, no output schema, and a complex execution environment, the description is severely under-specified. It lacks any explanation of return values, parameter semantics, tab resolution logic, or side effects. For a tool of this complexity, the description is far from adequate.
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%, and the description mentions none of the six parameters (tabId, waitMs, debugUrl, expression, urlContains, titleContains). It does not explain what 'expression' means, how tab selection is performed, or the roles of waitMs or debugUrl. The description adds no parameter-level insight beyond the schema itself.
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 evaluates JavaScript in the selected tab, using a specific verb ('Evaluate') and resource ('JavaScript in the selected tab'). It also narrows the scope to 'small, explicit inspection or panel automation snippets,' which distinguishes it from sibling tools like chrome_click or chrome_type that perform direct UI actions.
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 provides a clear usage context: 'Use for small, explicit inspection or panel automation snippets.' This implies when the tool is appropriate, but it does not explicitly mention alternatives or when not to use it (e.g., for complex multi-step automation). Thus it stops short of a full when/when-not breakdown.
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, the description bears the full burden of disclosing behavior. It only says 'wait briefly for the page to load,' which is vague and does not mention failure handling, return values, timeouts, or whether the tool blocks until navigation completes. This is insufficient behavioral disclosure for a navigation 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, front-loaded sentence with no redundant information. Every word contributes to the core purpose, making it concise and easily scannable.
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 has 6 parameters, no output schema, and no annotations, the one-sentence description is far from complete. It omits crucial context about tab selection, debug connection, matching criteria, and expected return behavior, leaving significant gaps for the 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 by explaining parameters. It only vaguely maps 'url' and 'waitMs' ('wait briefly'), leaving tabId, debugUrl, urlContains, and titleContains entirely unexplained. The agent would not know how to set these parameters or what they do.
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 ('Navigate'), the target ('the selected Chrome tab'), and the objective ('to a URL'). It also distinguishes itself from siblings like chrome_open_tab by specifying the selected tab, so the agent can tell this is for changing an existing tab's URL rather than opening a new one.
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 phrase 'selected Chrome tab' implies this tool should be used when a tab is already chosen and needs to be navigated, but it does not explicitly state when not to use it or mention alternatives like chrome_open_tab. Usage guidance is present but only implied rather than directly articulated.
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, the description carries full burden. It discloses the optional focusing of an element but omits details such as how the selected page is determined (tabId, urlContains, titleContains), the effect of waitMs (default 250), and error behavior when the element or page is not found. This is insufficient for a tool with an input schema.
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 wording. The key action is stated first, and the optional focusing behavior adds useful context without excess.
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?
For a tool with 7 parameters, no output schema, and no annotations, the description is too sparse. It does not explain the selection of the target page, the reason for waitMs, or potential return/error information, so it is not complete enough for an agent to invoke with confidence.
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. It only clarifies the roles of 'key' (keyboard key) and 'selector' (element to focus), while leaving tabId, waitMs, debugUrl, urlContains, and titleContains largely unexplained. The term 'selected page' hints at tab selection but does not define the parameters.
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 sends a keyboard key to the selected page, with an optional element-focus step. This uses a specific verb and resource, and the sibling list (chrome_click, chrome_type, chrome_select) shows distinct functionality, making its purpose 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 when you need to press a key, but does not explicitly compare with alternatives like chrome_type or chrome_click. It mentions the optional focusing behavior, giving some context, but lacks explicit when-to-use or exclusion 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?
With no annotations provided, the description carries the transparency burden. It discloses key behaviors: enabling DevTools Protocol and conditionally opening a new tab if Chrome is already running. However, it omits side effects, prerequisites, or failure modes such as port conflicts or behavior when extraArgs are used. The provided details are useful but minimal.
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 that front-loads the main action. It contains no filler or redundant information, making it highly concise and appropriately structured for its length.
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 is complex with 6 parameters and no output schema, but the description only covers the basic launch/tab behavior. It does not explain return values, how to use the tool with respect to siblings, or edge cases like merging with an existing session. The description is too minimal for the tool's complexity, especially without annotations or schema descriptions.
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 6 optional parameters with zero description coverage, and the description does not explain any of them (e.g., debugUrl, waitMs, extraArgs). Although the context hints at debugUrl via DevTools Protocol, the description fails to compensate for the lack of parameter documentation, leaving most parameters underspecified.
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 identifies the tool's action: launching a Chrome window with DevTools Protocol enabled, or opening a new tab if already running. This is a specific verb+resource pair, but it does not explicitly distinguish from the sibling tool chrome_open_tab, which also opens tabs, creating some ambiguity.
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 provides clear context for when to use the tool: when you need a Chrome window with debugging enabled or want to open a tab in a running instance. However, it does not mention alternatives or when not to use it, especially given the existence of chrome_open_tab for tab opening.
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, the description carries the full burden. It discloses the matching strategy but omits behavioral traits such as whether the page must be loaded, what happens if the element is not found, side effects, or return values. This is similar to the 'update_drive' example, which scored 2 for lacking such detail.
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 verb and resource, with no unnecessary words. It is concise and easy to parse, matching the standard of the high-scoring example.
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 8 parameters, no output schema, and no annotations, yet the description only covers the core action and two targeting modes. It does not explain how to scope the operation to a specific tab or page, or what the wait parameter does. This leaves significant gaps for an agent to select and invoke the tool correctly.
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. It adds meaning to selector and label (the two targeting mechanisms) and hints at value semantics ('option value or visible text'), but it leaves tabId, waitMs, debugUrl, urlContains, and titleContains entirely unexplained. This is insufficient for a tool with 8 parameters.
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 ('Set a select dropdown'), the method ('by CSS selector or label text'), and the matching criterion ('matching option value or visible text'). It distinguishes this tool from siblings like chrome_click and chrome_type by specifying a select-specific operation.
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 the usage context: when you need to programmatically select an option in a dropdown. It doesn't explicitly mention alternatives or exclusions, but the context is clear enough relative to sibling tools that it earns a 4 rather than a 3.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. 'List' implies a read-only operation, and the CDP endpoint mention provides some mechanism context, but prerequisites, potential failures, and output format are not disclosed.
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, tightly crafted sentence that conveys the core functionality without any fluff or repetition. It is appropriately concise for a straightforward tool.
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 simple (one optional param, no output schema), but the description is minimal. It explains what is listed and the source, but lacks details about the return structure or operational requirements, making it barely adequate for reliable invocation.
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 0%, so the description must compensate. It indirectly references the endpoint (debugUrl) but does not explicitly explain the parameter's purpose or format, leaving the agent to infer the connection.
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 lists Chrome tabs via the local Chrome DevTools Protocol endpoint, using a specific verb ('List') and resource ('Chrome tabs'). This distinguishes it from sibling tools that perform actions like opening, navigating, or screenshotting.
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. The description does not mention prerequisites (e.g., Chrome must be running with a debug port) or any exclusions, 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden for behavioral transparency. It discloses that the tool reuses an existing endpoint rather than launching a new browser, which is useful. However, it omits details like whether the tab is focused, what happens on failure, or whether a return value is provided. This is adequate for a simple tool but not highly transparent.
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, information-dense sentence with no unnecessary words or repetition. It efficiently conveys the core function and the key prerequisite.
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 simple, but the description lacks important contextual details: it doesn't state what the tool returns (e.g., tab ID, success confirmation), nor does it mention that the Chrome instance must be launched with remote debugging enabled. Given the absence of an output schema and annotations, this leaves gaps in the agent's 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?
Schema description coverage is 0%, so the description must compensate for parameter explanations. It doesn't mention 'url' or 'debugUrl' at all, relying on the parameter names being self-explanatory. While the names are reasonable, the description adds no value beyond the schema structure.
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 new tab through an existing Chrome DevTools Protocol endpoint.' It specifies the verb (Open), the resource (a new tab), and the context (existing CDP endpoint). This distinguishes it from sibling tools like chrome_launch (starts a browser) and chrome_navigate (moves the current tab).
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 'through an existing Chrome DevTools Protocol endpoint' provides clear context that an already-running browser is required, implying this tool should be used when such an endpoint exists. It doesn't explicitly mention alternatives or when not to use it, but the context is strong enough to guide the agent.
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:

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

Score Badge

Copy to your README.md:

[![Chrome-MCP MCP server](https://glama.ai/mcp/servers/CrispyW0nton/Chrome-MCP/badges/score.svg)](https://glama.ai/mcp/servers/CrispyW0nton/Chrome-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/CrispyW0nton/Chrome-MCP'

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