Ghostlight
Server Quality Checklist
Latest release: v0.7.2
- Disambiguation3/5
Multiple tools have overlapping purposes (script vs browser_batch, file_upload vs upload_image, form_input vs form_fill), but descriptions include enough detail to distinguish them with careful reading. An agent may still hesitate on which to choose.
Naming Consistency1/5Tool names follow no consistent pattern: some are verb_noun (read_page, upload_image), some are noun_verb (file_upload, form_fill), some are single verbs (navigate, find), and some nouns (computer, dialog). The _mcp suffix appears on only two tab-related tools, while tab_control omits it. This mix makes the naming chaotic.
Tool Count3/5At 25 tools, the server is on the heavy side of the 16-25 borderline range. However, the broad scope of full browser automation justifies most tools, and each serves a distinct purpose within that domain.
Completeness5/5The tool set comprehensively covers the browser automation lifecycle: navigation, reading, interaction, form filling, waiting, tab management, JavaScript execution, network/console inspection, screenshots, dialogs, and even recording. There are no obvious dead ends; the presence of update_plan and explain covers agent coordination and discoverability.
Average 4.3/5 across 25 of 25 tools scored. Lowest: 3.4/5.
See the Tool Scores section below for per-tool breakdowns.
- 1 of 1 community issues answered or closed in the last 6 months
- 704 commits in the last 12 weeks
- Last stable release on
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under Apache 2.0.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
This repository includes a glama.json configuration file.
This server has been verified by its author.
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
- 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. It reveals that operations are coordinate-driven and require screenshots for positioning, as seen in the bullet about consulting a screenshot before clicking. It also hints at potential failure and recovery ('try adjusting your click location'). This is useful context, but it doesn't cover other behavioral aspects like how failed actions are returned, whether actions are asynchronous, or any 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately concise, with a high-level opening sentence followed by three focused bullet points that provide actionable tips. Each sentence earns its place, and the structure makes it easy to scan. It avoids redundancy with the schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (12 parameters, many actions, broad capabilities), the description provides a reasonable overview but leaves several aspects implied rather than explicit. It covers the core interaction pattern and prerequisite (tab ID), but doesn't discuss how to choose among actions or handle different scenarios. The presence of an output schema reduces the need to explain return values, so completeness is adequate but not rich.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the parameters are already well-documented in the schema. The description adds minimal extra parameter meaning beyond reinforcing the use of tabs_context for tabId and the need for coordinates when clicking. The baseline of 3 applies because the schema does the heavy lifting; the description doesn't need to compensate and doesn't add substantial value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's role: using a mouse and keyboard to interact with a web browser and take screenshots. It distinguishes itself from sibling tools like navigate or read_page by focusing on low-level input actions. However, it could be more explicit about the set of actions (click, type, scroll) rather than relying on the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides some guidance on when to use the tool, especially related to handling tab IDs: 'If you don't have a valid tab ID, use tabs_context first'. It also gives practical tips for click accuracy (consulting screenshots, adjusting click position, clicking centers). However, it doesn't explicitly compare to alternatives like act_on or form_fill, so the 'when vs alternatives' aspect is only partially addressed.
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 must carry the full burden of behavioral disclosure. It states that a new empty tab is created but does not disclose whether the tab becomes active/focused, what the return value contains (though an output schema exists), or any side effects. This is a significant gap for a browser automation 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single front-loaded sentence that says exactly what the tool does in 10 words. There is no redundancy or unnecessary detail; every word contributes to the meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (no params, output schema exists), but the description omits important behavioral context such as tab activation or focus behavior. It is minimally sufficient for an agent to invoke the tool, but not fully complete for understanding the post-conditions of that invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so parameter semantics are trivially satisfied. Per the rubric, a zero-parameter tool gets a baseline score of 4. The schema also reflects this with an empty properties object, so the description need not add parameter details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Creates') and identifies a clear resource ('a new empty tab') and location ('in the MCP tab group'). This clearly distinguishes it from sibling tools like tabs_context_mcp (context) and tab_control (manipulating existing tabs).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide any guidance on when to use this tool versus alternatives such as navigate or tab_control. It simply states what the tool does, leaving the agent to infer usage from sibling tool names. No exclusions, prerequisites, or alternative recommendations are given.
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 behavioral traits. It only states the action and the tab prerequisite, but omits any detail about side effects (e.g., whether setting values triggers change events, submit, or requires specific page states). For a mutation tool, 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, with the core action in the first and a conditional prerequisite in the second. No wasted words; all information is relevant.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has a simple structure with three well-documented parameters and an output schema (per context). The description covers the essential workflow – obtaining ref and valid tab ID – which is sufficient for an experienced agent. It lacks some behavioral nuance, but that is more transparency than completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides descriptions for all three parameters (100% coverage), but the description adds cross-references: ref comes from read_page/find, and tabId from tabs_context. This enhances understanding of how to populate the parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action: 'Set values in form elements using element reference ID from the read_page or find tools.' It also distinguishes the tool by specifying the required input source (ref from read_page/find), which differentiates it from broader form filling tools like form_fill.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear workflow guidance: use read_page/find to obtain a ref, and use tabs_context if a valid tab ID is not available. However, it does not explicitly compare itself to sibling tools like form_fill or act_on, nor does it state when NOT to use this tool.
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 must carry the full burden of behavioral disclosure. However, it only states the core action and does not disclose side effects like triggering 'Leave site?' dialogs, changing current tab state, or potential blocking. The force parameter in the schema mentions the dialog, but the description itself lacks this context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is exactly two sentences, front-loaded with the action, and contains no filler. It is concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity, the schema's thorough parameter documentation, and the presence of an output schema, the description is largely complete. However, it omits some behavioral context that might be important in browser automation (e.g., whether the current page state is lost). This is a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does 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 clearly. The description adds minimal value beyond the schema, only reinforcing the tabId prerequisite.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Navigate to a URL, or go forward/back in browser history.' This uses a specific verb and resource, and it distinguishes from sibling tools like read_page or tabs_context by focusing on navigation actions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit usage guidance: 'If you don't have a valid tab ID, use tabs_context first to get available tabs.' This names the alternative tool and indicates a prerequisite, which is more than most tool descriptions provide.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses important behavioral constraints: close is always explicit, never affects user-owned tabs, and never deletes the containing tab group. This adds value beyond the schema by highlighting safety semantics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (two sentences) and front-loaded with the main purpose. The additional safety note about close is essential and earns its place without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with only two parameters and an output schema, the description covers the core functionality and one important behavioral nuance (close safety). It omits edge-case handling or failure behavior, but the presence of an output schema compensates. Overall, it is sufficient but not exhaustive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with both parameters clearly described in the input schema. The description adds marginal behavior context (e.g., session ownership, explicit close) but does not meaningfully enhance parameter-level meaning beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does 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 ('Focus, reload, or close') and a specific resource ('one tab owned by this Ghostlight session'). It lists all three actions and differentiates from sibling tools like tabs_create_mcp (creation) and tabs_context_mcp (context) by focusing on tab control rather than creation or context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context by mentioning session-owned tabs and explicit close behavior, but it does not explicitly state when to use this tool over alternatives (e.g., tabs_create_mcp, tabs_context_mcp). It also lacks any 'when not to use' 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 full burden of behavioral disclosure. It transparently states the 20-match limit and the notification for more specific queries, as well as the prerequisite for a valid tab ID. It does not explicitly mention whether the operation is read-only or describe the format of the returned references, leaving some 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured paragraph that front-loads the purpose. It includes examples, return limits, and a prerequisite, with every sentence adding value. There is no redundancy or unnecessary filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple two-parameter schema and an output schema that likely defines return values, the description covers all essential context: what the tool does, how to query, result limits, and the prerequisite for tab IDs. No significant gaps are apparent for an effective selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% coverage with detailed descriptions and examples for both parameters (query and tabId). The description adds natural language examples and the tabs_context referral, but this primarily reinforces usage rather than contributing new parameter-level semantics. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly defines the tool's purpose: 'Find elements on the page using natural language.' It specifies search by purpose or text content, distinguishing it from sibling tools like act_on or form_input which interact with elements. The verb-resource pairing is specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use the tool (searching for elements via natural language) and provides refinement guidance when more than 20 matches exist. It also directs users to use tabs_context first if no valid tab ID is available. However, it does not explicitly exclude alternative tools for similar tasks, such as get_page_text for reading text content.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden. It discloses that requests are automatically cleared on page navigation to a different domain and that cross-origin requests are included, which are non-obvious behaviors. This adds valuable context beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is about four sentences and front-loads the purpose. There is slight redundancy between 'Read HTTP network requests' and 'Returns all network requests made by the current page,' but overall it is concise and each sentence contributes meaningful information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description provides sufficient context for an agent to select and invoke the tool: what it does, when to use it, the automatic clearing behavior, and how to obtain a valid tab ID. With an output schema present, return values need not be detailed. It lacks only explicit alternative comparisons, but that is not critical here.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers all 4 parameters with descriptions, so the description does not need to add parameter semantics. It only ties tabId to the tabs_context prerequisite, but this is already implied in the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool reads HTTP network requests (XHR, Fetch, documents, images) from a specific tab, which distinguishes it from sibling tools like read_console_messages or get_page_text. It also specifies scope (cross-origin included), making the 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 Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear use cases (debugging API calls, monitoring network activity) and a prerequisite (use tabs_context if no valid tab ID). However, it does not explicitly mention when not to use the tool or directly compare with alternatives, so it lacks exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that the action is a resize (a mutation) and that it operates on the current browser window, but it does not mention potential side effects, permission requirements, or behavior on failure. For a simple tool, this is adequate but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long and front-loads the primary purpose. The second sentence adds a use case and a practical prerequisite. Every word earns its place, with no redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with three well-described parameters and no output schema. The description covers the purpose, typical use cases, and a necessary prerequisite for obtaining a tab ID. This is complete for an agent to select and invoke the tool correctly without requiring further clarification.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description does not add any additional meaning beyond the schema; it even repeats the tabId guidance already present in the schema. No extra semantics are provided for width or height.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Resize the current browser window to specified dimensions.' This is a specific verb ('resize') with a clear resource ('browser window') and scope (current window). It distinguishes itself from siblings like navigate or tab_control by focusing on resizing rather than navigation or tab management.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context: 'Useful for testing responsive designs or setting up specific screen sizes.' It also gives a conditional prerequisite by advising to use tabs_context first if the user lacks a valid tab ID. However, it does not explicitly state when not to use this tool or mention alternative tools for resizing, so it lacks explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavior. It states that the tool returns tab IDs but only 'if [the group] exists,' leaving unspecified what happens when no group exists (e.g., empty result, error, or creation behavior). The description does not mention the createIfEmpty parameter that controls creation, which is a significant omission.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded with the main purpose. Each additional sentence provides critical usage rules (mandatory before other tools, new-tab policy) without waste. It is concise and impactful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (one optional parameter) and has an output schema. The description covers the core functionality and usage context well. The only gap is the ambiguous default behavior when no group exists and createIfEmpty is false, but the schema and output schema largely compensate for this, making the description nearly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage for the single parameter, with a detailed description of createIfEmpty and its effects. The description text adds no additional parameter semantics, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get context information'), the resource ('current MCP tab group'), and the output ('Returns all tab IDs inside the group if it exists'). It distinguishes itself from sibling tools like tabs_create_mcp by focusing on reading context rather than creating tabs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says when to use this tool ('before using other browser automation tools') and provides a clear alternative ('Each new conversation should create its own new tab using tabs_create') with an exception ('unless the user explicitly asks to use an existing tab'). This is definitive usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It discloses the approval requirement and session-level domain approval, which is key behavioral context. It doesn't cover rejection behavior or plan updates, but for a planning tool this is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with the core purpose, then explaining the approval flow. No wasted words, well-structured for quick comprehension.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple planning tool with two parameters and no output schema, the description covers the purpose, usage timing, and post-approval behavior. It doesn't explain failure/rejection handling, but that's not critical for this tool type.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds a bit of context (e.g., domains get approved for the session, approach should be high-level), but these are already in the schema parameter descriptions. No additional semantic value beyond that.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: to present a plan for user approval before actions. It specifies the resources (domains and approach) and the approval flow, distinguishing it from the sibling tools which are direct action tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly says to use 'before taking actions' and explains that after approval, actions proceed without additional prompts. This gives clear context, though it doesn't name alternative tools or state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It adds useful behavioral details: the narration is temporary, replaces the current one, and targets the controlled browser tab. It doesn't cover edge cases like invalid tab handling, but for a simple UI feedback tool, it provides adequate 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three tight sentences: purpose, usage guidance, and behavior. Every sentence earns its place with no redundancy or filler, and the most important info is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity, the rich schema (100% parameter coverage, output schema present), and the clear behavioral context, the description is complete enough. Return values are covered by the output schema, so no further explanation is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, with each parameter already well-described (e.g., text is 'one short, user-visible sentence'). The tool description adds no additional parameter-specific meaning, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Show a short, temporary narration ribbon in the controlled browser tab so the person watching understands the current workflow phase,' which specifies a clear verb, resource (narration ribbon), and purpose. This distinctly separates it from sibling tools like navigate or form_input, 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 Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly states when to use ('meaningful phase changes') and when not to ('not routine clicks or keystrokes'). However, it does not name alternative tools, so while the guidance is clear, it stops short of the 'alternatives' component required for a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the transparency burden. It discloses that results are limited to the current domain and warns about retrieving too many irrelevant messages without a pattern. These are meaningful behavioral traits beyond what the schema offers, though it doesn't discuss side effects of the 'clear' parameter (but that is covered in the schema).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core action, then adds use cases, a domain limitation, and a clear IMPORTANT note. It is concise with no redundant phrases, though the use case sentence could be seen as extra but is helpful rather than filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 5 parameters and an output schema, the description covers the essential context: what it does, when to use it, and critical constraints (domain filter, pattern requirement). The output schema handles return details, so the description is sufficiently complete for effective tool selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3, but the description enriches parameter understanding by emphasizing 'Always provide a pattern' and advising to use tabs_context for tabId. This adds practical usage context not explicitly in the schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does 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 'Read' and resource 'browser console messages', including examples of message types. It distinguishes itself from related tools like read_network_requests by focusing on console messages and specifying it reads from a specific 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear use cases (debugging JavaScript errors, viewing logs) and prerequisite guidance ('use tabs_context first to get available tabs'). It also gives a strong recommendation to always provide a pattern, which helps avoid overwhelming results. No explicit exclusions, but contextual guidance is solid.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the two behavioral modes, the prerequisite of a previously captured screenshot, and the mutually exclusive ref/coordinate constraint. It stops short of detailing side effects or failure behavior, but covers the essential traits for safe invocation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences that front-load the core purpose, then succinctly explain the two approaches and the exclusivity constraint. Every sentence earns its place, with no filler or redundant restatement of the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity, a 100% schema-covered parameter set, and the presence of an output schema, the description is complete enough: it specifies prerequisites, target types, usage modes, and a key constraint. The agent has sufficient context 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.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description reinforces the ref/coordinate distinction and the 'not both' rule, but does not add new semantic information beyond what the schema already provides for each parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Upload') and resource ('previously captured screenshot to a file input or drag & drop target'), clearly distinguishing it from sibling upload tools. It also outlines two concrete approaches, making the tool's scope unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear guidance on when to use 'ref' (hidden file inputs) versus 'coordinate' (drag & drop to visible locations like Google Docs), and explicitly warns not to provide both. However, it does not name alternative sibling tools or explicitly state when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It discloses that exactly one action is performed, a bounded observation receipt is returned, and ambiguity prevents action. However, it does not elaborate on side effects, permissions, or failure modes beyond ambiguity, which keeps it from a 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of three concise sentences, with the purpose front-loaded. Every sentence adds value—defining the action, usage context, and ambiguity behavior—with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 5 parameters, nested objects, an action enum, and an optional expect postcondition. The description covers unique targeting, ambiguity handling, and the bounded receipt, which are the non-obvious behaviors. The schema and output schema handle the remaining parameter and return details, so the description is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides 100% description coverage for all parameters, including detailed notes on target ('Exactly one of ref, query, or name') and expect. The description only reinforces the concept of 'ref or accessible meaning' without adding new parameter-level syntax or constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Resolve one visible element by ref or accessible meaning, perform one action, and return a bounded observation receipt.' It uses a specific verb (resolve, perform, return) and resource (visible element), and distinguishes itself from a separate find, action, and wait loop.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit guidance is given: 'Use this when the target should be unique and you want to avoid a separate find, action, and wait loop.' It also signals a when-not case by stating that ambiguous semantic matches are reported without acting.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full behavioral disclosure. It reveals that the tool can inspect or resolve dialogs, that dialogs 'block' a tab, and that acceptance/dismissal/response should only occur with task intent. This highlights the safety implications of the mutating actions, though it does not detail what status returns or what happens if no dialog is present.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, immediately front-loaded with the core functionality, and a follow-up safety guideline. There is no wasted wording, and every clause contributes either to purpose or proper use.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the moderate complexity (3 params, conditional text, no annotations) and the presence of an output schema, the description covers the essential use cases and safety rules. It could mention edge cases like absent dialogs or the standalone behavior of accept/dismiss, but it is sufficiently complete for an experienced agent to operate correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds semantic value by framing the action parameter: 'status' for inspection, and the other actions as explicit resolution steps requiring intent. This clarifies the enum values beyond their schema descriptions, even though the text parameter is not elaborated beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with specific verb and resource: 'Inspect or explicitly resolve the JavaScript dialog blocking one owned tab.' It distinguishes the tool from siblings by focusing on JavaScript dialogs and adds scoping ('one owned tab') that clarifies its domain.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidance: 'Use status when the dialog state is unknown' and 'Never accept, dismiss, or respond without intent from the current task.' This gives clear direction on when to use the status action vs. mutating actions, though it does not explicitly name alternatives or when not to use the tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does well. It discloses the default dual wait (condition + DOM mutation decay), the meaning of each state, the effect of min_ms and settle, and error behavior ('Times out with an error naming what WAS on the page'). It also mentions the returned diagnostics and element ref. This goes well beyond a bare statement of purpose.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is six sentences but each is dense with information. It front-loads the purpose and then procedurally explains parameters, return values, and failure mode. No fluff or repetition. The only slight drawback is length, but it remains immediately scannable due to clear grouping.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a wait tool with 7 parameters and no annotations, this description is remarkably complete. It covers all major usage modes, state semantics, default behavior, configurable conditions, timeout behavior, and return values. The presence of an output schema is acknowledged but the description already explains the key outputs (elapsed_ms, settle diagnostics, element ref). It leaves little unanswered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, giving baseline 3. The description adds value by clarifying semantic details beyond schema: it explicitly explains how min_ms and settle modify the wait, interprets state values in context, and reinforces the exclusivity constraint ('at most one of selector or text'). This additional context enhances parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a clear verb+resource ('Wait until the page is ready') and elaborates on the specific scopes (condition + settlement). It distinguishes itself from sibling navigation/action tools by detailing its waiting semantics (selector/text, states, settlement) and return diagnostics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides concrete usage patterns: 'Provide selector (CSS) or text (visible substring) with state visible|present|gone, or call with neither to wait for settlement alone.' It explains how to combine conditions with settlement ('settle:false gates on the condition only') and mentions the timeout behavior. It lacks explicit exclusions (e.g., when NOT to use), but the implied context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It reveals the key pitfall: clicking on file upload buttons/inputs opens a native dialog the agent cannot interact with, and that direct upload via ref is the intended method. It does not discuss other behaviors such as file size limits or event triggering, but the output schema covers return values.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the action, and every sentence contributes value. The first sentence states the function, the second gives essential guidance and a warning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given a 100% schema coverage and an output schema, the description sufficiently covers the tool's usage: it tells the agent how to obtain the ref, what to avoid, and how to perform the upload. It does not leave major gaps for the agent to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds no additional parameter semantics beyond what the schema provides; it only references 'ref' conceptually, which the schema already defines. The 'files' and 'paths' parameters are not elaborated in the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('upload') with a clear resource ('file input element on the page') and scope (one or multiple files). It also distinguishes from sibling tools by explicitly instructing not to click the file input button, which would open a native picker, and directing to use read_page/find to locate the element first.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides explicit when-to-use guidance: locate the file input with read_page or find, then use this tool with the ref. It also tells what to avoid (clicking), which is crucial for the agent. While it doesn't enumerate alternative upload tools, the context of file inputs makes the usage unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the output type (plain text), the default output limit (50000 chars), and the truncation behavior including the note with full size. It does not cover all possible edge cases, but it provides substantial behavioral context for a read operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact but information-dense: purpose, use case, prerequisite, and output limitation are each covered in a single sentence. No wasted words, and the most important information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a text extraction tool with an output schema and 100% parameter coverage, the description provides all essential context: what it does, when to use it, how to handle missing tab IDs, and output limits/truncation. It is fully sufficient 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.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds value beyond the schema by clarifying that tabId should be obtained via tabs_context if unknown and by explaining the truncation behavior for max_chars, which the schema only states as a default.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Extract raw text content from the page,' and adds a distinguishing feature, 'prioritizing article content' and 'without HTML formatting.' This clearly differentiates it from sibling tools like read_page and find.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly states when to use the tool ('Ideal for reading articles, blog posts, or other text-heavy pages') and instructs to use tabs_context first if no valid tab ID. It does not explicitly mention alternatives or exclusions, but the guidance is clear and practical.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses execution context ('runs in the page's context'), interaction capabilities ('interact with the DOM, window object, and page variables'), and return behavior ('Returns the result of the last expression or any thrown errors'). The schema further adds REPL semantics and top-level await support, providing comprehensive behavioral 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, front-loaded with the core purpose, followed by behavioral details and a practical prerequisite. Every sentence earns its place with no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity and the presence of a detailed schema and output schema, the description covers purpose, execution context, interactions, return values, and prerequisites. It is complete 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.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides extensive descriptions for all three parameters (100% coverage), including REPL semantics, tabId prerequisites, and the fixed action value. The description itself adds no information beyond the schema, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a precise verb+resource: 'Execute JavaScript code in the context of the current page.' It further specifies interaction with DOM, window object, and page variables, clearly distinguishing this from navigation or read-only tools. The return behavior is also stated, leaving no ambiguity about the tool's function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear prerequisite: 'If you don't have a valid tab ID, use tabs_context first to get available tabs.' This implies when the tool is appropriate (having a tab context) and directs the agent to a supporting tool. However, it doesn't explicitly contrast with alternatives like 'script' or state when not to use this tool, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and does well. It discloses that each step is 'validated, authorized, and audited exactly as if called individually,' explains the variable reference syntax, the literal '$' escape, and the restriction on referencing tools. It does not mention failure handling (e.g., onError behavior), but that detail is covered by the schema, and the description adds valuable behavioral nuance.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense and information-packed without redundancy. The first sentence states the core purpose, and subsequent sentences add necessary details about syntax, limitations, and a practical usage tip. Every sentence contributes meaningful content, and it remains concise given the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a complex meta-tool with five parameters and an output schema. The description explains the execution model, parameter reference syntax, tool restrictions, and includes a usage tip for dynamic pages. The schema covers parameter-level details, and the output schema covers return values, so the description is sufficiently complete for an agent to select and use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds significant value by giving concrete examples of the reference syntax (e.g., '$prev.results.0.ref after find') and the '$$' escape, which are not detailed in the schema parameter descriptions. It also clarifies which tools can be referenced, enhancing understanding beyond the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Run a sequence of tool calls in one request,' a specific verb and object that clearly defines the tool's function. It goes beyond a simple statement by explaining sequential execution and explicitly prohibiting nesting script itself, which distinguishes it from single-action sibling tools like navigate or find.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on when to use the tool (for multi-step sequences) and includes a specific tip: 'Use wait_for between navigate and reads on dynamic pages.' It also states constraints like which tools can be referenced and that script cannot be nested. However, it does not explicitly contrast this tool with sibling alternatives such as browser_batch, so it falls short of a full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does so well. It discloses that all elements (including non-visible ones) are returned by default, the 50000-character output limit, truncation at a line boundary, and the note about full size. These are non-obvious behaviors beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is moderately long (about five sentences) but each sentence carries necessary information: what it does, defaults, prerequisites, and output limitations. It is front-loaded with the core purpose, and the troubleshooting guidance is relevant and non-redundant.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given 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, and a rich output schema, the description covers all key operational aspects: purpose, default behavior, prerequisite steps, output size limits, and mitigation strategies. Return values are already represented by the output schema, so not repeating them is appropriate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds value by explaining practical parameter usage: default depth, default max_chars, truncation behavior, and how depth/ref_id can narrow focus when output is too large. It also clarifies the filter default ('all elements').
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: 'Get an accessibility tree representation of elements on the page.' It clearly distinguishes this from sibling tools like get_page_text by emphasizing how screen readers see the page content, not just raw text.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage guidance: it tells the agent to use tabs_context first if there's no valid tab ID, and offers strategies for when output is too large (increase max_chars or use depth/ref_id). It does not explicitly name alternative tools, but the accessibility-tree framing makes the intended use clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It clearly indicates this is a passive, read-only introspection tool by describing its output and stating it does not access web pages. It could be more explicit about not modifying anything, but the wording strongly implies a non-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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, consisting of two sentences that front-load the core purpose. The first sentence details the output, and the second provides usage guidance and a key distinction from sibling tools. Every word earns its place with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters and no output schema, the description fully explains what it returns (the action directory, capabilities, and definitions) and what it does not do. It is sufficient for an agent to select and invoke the tool appropriately without further clarification.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so there is nothing for the description to explain. The baseline score of 4 applies since no parameter information is needed. The description adds no parameter details, but that is appropriate for a parameterless tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns the server's action directory, including available actions, required capabilities, and short descriptions. It also explicitly distinguishes itself from web-content tools by stating it does not read, summarize, or explain web pages, which sets it apart from sibling tools like get_page_text or narrate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says to use it to learn what you are allowed to do in this session, providing a clear use case. It also gives an exclusion ('does not read, summarize, or explain web pages'), which implies when not to use it, effectively steering users toward alternative tools for web content tasks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and meets it: it discloses memory-only storage, auto-stop after 30s idle or 120s total, export stopping capture, and clear erasing immediately. This is far beyond typical tool descriptions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a compact 4 sentences that front-load the purpose and then systematically cover lifecycle and export options. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a complex, stateful tool with 5 actions, yet the description covers the full lifecycle, timeout behavior, and export paths. An output schema exists, so return-value documentation is unnecessary.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description repeats the action flow already in the schema and only lightly summarizes export/drag-drop semantics; it adds little beyond the schema's detailed parameter descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Create a short, memory-only GIF of browser work,' clearly stating the tool's purpose and key characteristic (memory-only). This distinguishes it from all sibling browser automation tools, none of which record GIFs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides an explicit workflow: 'Call start_recording, use browser tools normally, then call export' and clarifies that export auto-stops capture. It also explains when to use status, stop_recording, and clear, giving clear action boundaries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully carries the burden and excels. It discloses sequential execution, stopping on first error, per-item permission checks, interleaved image outputs, and the critical detail that coordinates refer to the pre-batch screenshot.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-organized paragraph. Every sentence conveys essential operational or usage information, and it is front-loaded with the core purpose before diving into details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity and absence of output schema, the description thoroughly covers operational semantics, usage context, error behavior, and image handling. It provides everything an agent needs to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaning beyond the schema by defining the input contract: each item is {name, input} where input is exactly what you'd pass standalone. It also adds the coordinate-reference caveat, which is not present in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Execute a sequence of browser tool calls in ONE round trip' and explains the item structure. This specific verb+resource combination distinguishes it from sibling tools like navigate or computer by emphasizing batching.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit guidance says 'Use this tool extensively to quickly execute work whenever you can predict two or more steps ahead' with examples. It also notes a key limitation ('browser_batch cannot be nested'), helping agents decide when to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and does so admirably: it discloses case-insensitive matching, specificity ordering, ambiguous-key handling, submit behavior, password masking, and the fallback behavior. This goes well beyond a basic 'fill a form' statement.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but every sentence earns its place. It front-loads the primary purpose, then covers matching, submit, security, and fallback in a logical order. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity, the description is complete: it covers prerequisites (tabId from tabs_context), input format, matching behavior, submit option, password masking, and fallback. It even mentions refs in the result for fallback, aligning with the output schema. No gaps identified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds substantial meaning beyond the schema: it explains the fields map semantics (labels, placeholders, name attributes), value types, matching logic (case-insensitive, specificity-ordered, ambiguous keys returned unmatched), and the result's refs for fallback. This enriches the schema's bare parameter list.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb+resource+method: 'Fill a form by field labels in one call.' It clearly distinguishes from sibling tools like form_input by describing the one-call batch-fill approach and the fallback to form_input for unmatched fields.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly names an alternative tool (form_input) for unmatched fields and instructs to use tabs_context first for a valid tabId. It also clarifies when submit:true is relevant and how the matching works, giving clear context for when to use this tool.
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:
Score Badge
Copy to your README.md:
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
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/sylin-org/ghostlight'
If you have feedback or need assistance with the MCP directory API, please join our Discord server