RokuHarness MCP Server

by miabilabs

Overview Schema Related Servers Score Discussions

JavaScript

Local

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation4/5
Most tools have clearly distinct purposes, but there is some overlap among find_element, verify_element_present, and verify_screen_loaded since they all deal with UI state. Descriptions clarify their different return types and use cases.
Naming Consistency5/5
All tool names follow a consistent verb_noun pattern in snake_case (e.g., create_webdriver_session, press_key, verify_element_present). No mixing of conventions.
Tool Count5/5
14 tools is well-scoped for a device automation server, covering session lifecycle, UI interaction, verification, and media state without being excessive.
Completeness5/5
The tool set covers the full lifecycle of device testing: session management, app control, UI inspection and interaction, verification, screenshots, and media state. No critical gaps for the stated purpose.
Average 3.6/5 across 14 of 14 tools scored. Lowest: 2.9/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It only names the action without stating side effects, requirements, return values, or failure behavior (e.g., what happens if the app is not installed).
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 single-sentence description is front-loaded and contains no fluff. However, it is extremely brief and omits details that could be included without hurting 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?
For a three-parameter tool with no output schema and no annotations, this description is under-specified. It does not explain return values, prerequisites, or behavioral outcomes, leaving the agent with significant ambiguity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% coverage with descriptions for each parameter, including examples. The description adds minimal context by labeling content_id and media_type as 'deep linking parameters,' which is a baseline contribution.
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 ('Launch') and the resource ('a specific app'), distinguishing it from sibling tools like get_installed_apps or navigate. The verb+resource 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 Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It does not mention prerequisites (e.g., an active webdriver session) or exclusions, leaving the agent to infer use cases.
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 return format (base64-encoded PNG) but omits other behavioral traits such as whether saving via save_path is alternative to returning, whether it requires an existing session, or potential side effects. The optional save_path introduces ambiguity about the tool's behavior.
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?
Two concise sentences, front-loaded with the main action. No fluff or redundancy. Every word contributes.
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, and the description covers the core function and return type. However, the behavior of save_path is ambiguous (does it save, return, or both?), and no context about session requirements or whether the screenshot is of the entire screen or viewport is given. This leaves gaps for a complete understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (save_path is documented). The description adds no extra meaning about the parameter or how it interacts with the return value. Baseline of 3 applies due to full schema coverage, and no misleading or confusing param info is present.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action ('Capture a screenshot') and the target ('current screen state'). It distinguishes itself from sibling tools like get_ui_source and verify_screen_loaded by specifying a visual capture and its return format.
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 context is provided. There is no guidance on when to use this tool versus alternatives like get_ui_source, nor any mention of prerequisites (e.g., an active session). The description only states what it does, not 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the burden of behavioral disclosure. It mentions 'Returns true/false,' which is helpful, but it fails to mention waiting behavior, timeout semantics, or whether the tool is read-only. It does not disclose how matching works or what happens when the element is not found. This is a significant gap for a verification tool.
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 concise, consisting of three short sentences. It front-loads the core purpose ('Verify that a specific element is present on screen'), states the return type, and adds a contextual note. The final sentence about acceptance criteria is somewhat filler but not harmful. Overall, it is efficient without unnecessary detail.
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 four parameters, one being a nested object, and no output schema. The description is too brief to be complete: it does not explain how the element is matched, what 'present' means in terms of waiting (e.g., does it wait for timeout_ms?), or what the return value represents in edge cases. The description lacks the depth needed for a tool with this complexity and no annotations or output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% coverage of the four parameters with descriptions. The tool description adds no additional parameter semantics; it only says 'specific element' without elaborating on tag, text, attributes, or timeout. Since schema coverage is high, the baseline of 3 applies.
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: 'Verify that a specific element is present on screen.' It uses a specific verb ('Verify') and resource ('element'), and distinguishes itself from siblings like find_element by noting it 'Returns true/false', indicating a boolean verification result rather than returning the element itself.
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 provides some usage context by stating 'Critical for acceptance criteria validation,' implying it is used for assertions. However, it does not explicitly contrast with alternatives like find_element or verify_screen_loaded, nor does it state when not to use this tool. The guidance is implicit rather than explicit.
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 only states "Returns element details if found," which omits critical behaviors such as what happens when not found (null? error?), whether it searches the entire visible screen, how matching works (exact/partial), or if it waits for the element. This leaves 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 one concise sentence that includes both the action and the return value. No filler or repetition, every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's role and the absence of an output schema and annotations, the description is under-specified. It does not explain the shape of returned element details, failure semantics, or matching rules. For an agent to invoke this tool reliably, more behavioral context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already describes all three parameters fully. The description adds "and/or", suggesting combinability, but does not clarify whether any parameter is required or how attributes are matched (exact string comparison). With 100% schema coverage, the description adds marginal value beyond the schema, so a baseline 3 is appropriate.
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?
"Find a UI element on screen using text, tag, and/or attributes" clearly states the verb and resource. It also notes that it returns element details, which differentiates it from verify_element_present (likely a presence check). The purpose is unambiguous and distinguishes this tool from siblings.
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 this tool is used when you need to locate a UI element by any of the given criteria. However, it does not explicitly mention when not to use it or name alternatives like verify_element_present or get_ui_source. Usage is implied but not explicitly guided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only restates the basic function without detailing important traits such as failure handling, waiting behavior, side effects, or whether the key presses are sent to the active element. This is a significant gap for a tool with no annotation safety information.
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 wasted words. It efficiently communicates the core function of the tool, making it appropriately sized for its simplicity.
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?
Despite the tool's simplicity, the description lacks usage guidance, behavioral details, and any mention of return values. With no annotations or output schema, the description fails to provide sufficient context for an agent to confidently invoke the tool, especially regarding edge cases and expected outcomes.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and both parameters (keys and delay_ms) are already described in the schema. The description adds no extra semantic meaning beyond the schema, so the 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/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 'execute' and a resource 'a sequence of key presses', adding the purpose 'for navigation flows'. This distinguishes it from sibling tools like press_key, which handles single key presses.
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 'for navigation flows' implies when to use this tool, but it does not explicitly state when to prefer it over press_key or other alternatives. No exclusions or alternative tool references are provided, so usage guidance is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose behavioral traits on its own. It mentions that it returns pass/fail results, but it does not disclose potential side effects (e.g., UI interactions that may modify state), session requirements, or failure behavior. This is insufficient for a tool that executes multi-step actions.
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, compact sentence that conveys the core purpose and result type without any redundant or filler content. It earns its place.
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 schema richly defines inputs, but there is no output schema and the description only vaguely mentions 'detailed pass/fail results.' It lacks information about the result structure, prerequisites (e.g., a webdriver session), or edge-case behavior. This makes it minimally viable but not comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for parameters, so the description does not need to add detailed parameter info. The phrase 'multiple verification steps' loosely maps to the 'steps' array, but the schema already fully explains each action type. Baseline of 3 is appropriate.
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 a specific action ('Run') on a specific resource ('complete acceptance test') and distinguishes it from sibling tools by noting 'multiple verification steps' and 'detailed pass/fail results.' This makes it evident that this is a high-level aggregate test runner rather than a single UI operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for multi-step acceptance testing, but it does not explicitly state when to use this tool versus the individual action tools (e.g., press_key, navigate, verify_element_present). No exclusions or alternative guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states the action and purpose but does not mention whether the text replaces existing content, appends, or requires an element to be focused. This leaves significant behavioral ambiguity for an agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the action and context. There is no extraneous information, making it appropriately sized and easily parsed.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has a single parameter, no output schema, and no annotations, so the description alone must convey all necessary context. It provides the basic purpose but omits any details about expected behavior or side effects, leaving it slightly incomplete for a fully autonomous agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage, with the parameter 'text' already described as 'Text to send'. The tool description adds no further semantic detail about the parameter, relying entirely on the schema. This meets the baseline for schema-backed 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 action ('Send text input') and provides context ('for search fields, forms, etc.'). This identifies the tool's purpose as entering text, but it does not explicitly distinguish it from sibling tools like press_key, which also handles keyboard input.
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 'for search fields, forms, etc.' gives clear context for when to use this tool, implying it is for text entry in UI fields. However, it does not explicitly mention when not to use it or list alternative tools, though the context is sufficient for a basic understanding.
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 behavioral disclosure. It implies a read-only operation via the verb 'get' but does not explicitly state safety, return format, or whether system apps are included. No additional behavioral context is provided.
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, clear sentence that front-loads the purpose without unnecessary words. Every word contributes to the meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no params, no output schema), the description is adequate but could be more explicit about what the returned list contains (e.g., app names, package IDs). It is not fully complete but sufficient for a straightforward query.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters, so the baseline of 4 applies. There is no parameter information to add, and the description does not need to compensate for schema gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb ('Get') and resource ('list of all installed apps') with a scope ('on the device'). It distinguishes itself from sibling tools like launch_app or get_ui_source, which serve different purposes.
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, no exclusions, and no context about use cases. It simply states what the tool does without helping the agent decide among the sibling tools.
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 fully disclose behavioral traits. It does list the return contents (position, duration, state, buffering info), which provides some transparency. However, it does not mention side effects (or lack thereof), assumptions about a running media player, potential errors, or output format, leaving the agent with only partial insight.
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: 'Get current media player state (position, duration, state, buffering info).' It includes the verb, resource, and key data points with no redundancy or unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the core function and return fields, but it does not provide context about the required environment (e.g., media player must be running), return value types or units, or when this tool is applicable relative to the UI automation workflow. Given no annotations and no output schema, more context would improve completeness, but the basic getter function is adequately described.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, so there are no parameter semantics to clarify. Per the rubric, a 0-parameter tool receives a baseline of 4. The description appropriately omits parameter information since none exist.
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: 'Get current media player state' and specifies the exact data returned (position, duration, state, buffering info). This is a specific verb+resource and is distinct from all sibling tools, which focus on UI automation elements like webdriver sessions and element finding.
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 any alternative. It simply states what it does, with no mention of context, prerequisites, or exclusions. No sibling tool is referenced, so the agent is left without explicit usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states what action is performed, but does not disclose side effects, whether the press is synchronous, what happens on invalid keys, or any post-press behavior. This leaves the agent guessing about important runtime behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence followed by a useful list of common keys. It is front-loaded with the primary action and contains no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter action, the description is reasonably complete: it states what the tool does and provides example values. However, it does not mention timing or synchronization behavior (e.g., whether it waits for the resulting UI state), which could be relevant in an automation context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers the parameter with a generic 'Key to press' description. The tool description adds meaningful context by listing common accepted keys (Home, Back, etc.), which clarifies expected values beyond the schema's minimal description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: 'Press a remote control button.' It clearly distinguishes from sibling tools like navigate (which implies navigation) and send_text (which sends text input). The list of common keys further clarifies the tool's domain.
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 a remote control button needs to be pressed ('Press a remote control button'), but it does not explicitly state when to avoid this tool or provide alternatives. No exclusions or comparisons to sibling tools are given.
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 disclosure. It clearly states the blocking wait behavior and the return value on both success and timeout ('Returns true when screen loads or false on timeout'). This is useful behavioral context beyond the schema, though it does not detail polling behavior or error conditions.
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 sentences, front-loaded with the primary action, and contains no redundant or vague wording. Every word contributes to understanding what the tool does.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a relatively simple tool, the description covers the essential behavior. However, without an output schema or annotations, it could say more about edge cases (e.g., invalid selectors), what constitutes 'loaded' (visible vs. present), and how it relates to sibling verification tools. The lack of this context leaves some ambiguity for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides descriptions for both parameters: timeout_ms ('Maximum time to wait for screen') and screen_marker ('Element query that uniquely identifies the screen'). The description adds no additional parameter-level meaning, so with 100% schema coverage, a baseline of 3 is appropriate.
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?
Description clearly states the action: 'Wait for a specific screen to load by checking for a marker element.' This distinguishes it from sibling tools like verify_element_present, which focuses on a single element rather than a screen-level condition.
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 ensure a screen is ready before proceeding, but it provides no explicit guidance on when to use this tool versus alternatives like verify_element_present or find_element. No comparisons or exclusion criteria are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It correctly implies a read-only getter operation via 'Get,' and adds the useful context that it's foundational for element queries. However, it doesn't mention potential edge cases or output size, leaving some gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no filler: the first states the core behavior, the second explains why it matters. It is front-loaded and efficiently worded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one optional parameter and no output schema, the description covers the primary return type (SceneGraph XML) and its main use case (writing element queries). It is sufficiently complete without needing to restate the parameter documentation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% because the 'parsed' parameter has a clear description. The tool description adds no extra semantic meaning to the parameter, but none is needed since the schema already explains its effect on output format.
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 (get), the resource (current UI hierarchy), and the format (SceneGraph XML). It also emphasizes its role in understanding screen elements and writing queries, which distinguishes it from siblings like take_screenshot and find_element.
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 says the tool is 'essential for understanding what elements are on screen and writing element queries,' providing clear context for when to use it. It does not explicitly name alternatives or exclusions, but the implied usage is strong enough.
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 a session is created and requires the server to be running, and it notes the ordering constraint. However, it does not describe what the session represents, whether it is destructive, idempotent, or what happens on failure. This leaves gaps in understanding the operational impact.
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 concise and front-loaded: the first sentence states the action, and the second adds usage guidance and prerequisites. Every word earns its place, with no redundant content.
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 there is no output schema, so the description would need to explain the return value or session behavior. It does not mention what the session returns or how it is referenced later, though it implies it is needed for subsequent commands. This gap prevents a higher score.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all parameters are already well-documented in the schema. The description adds no additional parameter semantics, so the 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/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 ('Create') and resource ('Roku WebDriver session'). It also distinguishes this tool from siblings by noting it must be called before any other commands, making its role as the session initializer explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit when-to-use guidance: it must be called before any other commands. It also states the prerequisite that the Roku WebDriver server must be running, which is essential context. There are no alternative tools for this purpose, so exclusions are unnecessary.
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 full transparency burden. It adds 'clean up resources' as a behavioral detail, but does not disclose side effects such as session invalidation or behavior when no active session exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no redundant information. It is well-structured and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple tool with no parameters and no output schema. The description adequately covers its purpose and cleanup behavior, making it sufficiently complete for an agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the description does not need to add parameter details. The baseline for zero-parameter tools is 4, which applies here.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'End' and resource 'Roku WebDriver session', clearly stating the tool's purpose. It distinguishes from the sibling tool 'create_webdriver_session' by being the inverse 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 when to use the tool (to end a session), but does not explicitly mention when not to use it or name alternatives. Context is clear and no exclusions are stated.
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:

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

Score Badge

Copy to your README.md:

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

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