clawtouch-mcp

by tinqiao-oss

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

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

Latest release: v0.4.6
Disambiguation5/5
Every tool has a clearly distinct purpose. Device tools are separate from HID tools, and within HID, each action (click, drag, hover, key press/release, etc.) has a unique tool with precise semantics, avoiding ambiguity.
Naming Consistency5/5
All tools follow a consistent 'domain.action' pattern with snake_case for compound action names (e.g., hid.key_press, hid.release_all). The naming is uniform and predictable.
Tool Count5/5
16 tools is well-scoped for a server focused on HID input. It covers a comprehensive set of operations without being excessive, and each tool serves a necessary role.
Completeness4/5
The HID toolset is thorough, covering click, drag, hover, keyboard, scroll, batch, and panic stop. Missing is a tool to explicitly connect/disconnect from the bridge, but the device.list and device.info tools imply an active connection is managed elsewhere.
Average 4/5 across 16 of 16 tools scored. Lowest: 2.9/5.
See the Tool Scores section below for per-tool breakdowns.
- 0 of 1 community issues answered or closed in the last 6 months
- 68 commits in the last 12 weeks
- Last stable release on June 7, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
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.
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?
No annotations are provided, so the description carries the full burden. It only states the basic purpose without disclosing behavioral traits such as what 'candidate' means, permissions needed, side effects, or return format. This is insufficient for a tool with no annotations.
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 very short (4 words) and front-loaded. No wasted words. However, it is slightly too terse for the lack of other context, but still efficient. Scores 4.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no output schema, no annotations, and minimal description, important context is missing (e.g., what 'candidate' means, whether the list is dynamic or static, blocking behavior). The description is incomplete for a tool that could benefit from more detail.
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?
There are zero parameters, and the schema coverage is effectively 100%. The description adds no parameter information beyond what the schema provides, which is nothing. Baseline is 3 per guidelines.
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 states a specific verb 'List' and a clear resource 'candidate Pico serial ports', which distinguishes it from sibling tools like 'device.info' and various HID tools. It clearly communicates 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 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 vs. alternatives, no prerequisites, or exclusions. The context signals indicate siblings, but no comparison is made, leaving the agent to infer usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries full burden. It notes the output nature (connection and sequence info) but fails to mention read-only nature, side effects, or permissions. This is insufficient for a tool with no annotations.
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?
Single sentence, zero waste, front-loads the purpose. Perfectly concise for a trivial tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema or annotations, the description should provide more context about the return value beyond 'connection + sequence info'. It is minimally complete but leaves ambiguity about what exactly is returned.
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?
No parameters are defined, and the description adds no additional semantic information. Per guidelines, with 0 parameters and full schema coverage, baseline is 4. The description is adequate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states it returns 'connection + sequence info' for an 'active bridge', implying a retrieval function, but lacks a clear verb like 'Get' or 'Retrieve'. It distinguishes from device.list (list devices) and HID tools implicitly, but could be more explicit about the resource.
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 provided on when to use this tool versus siblings. The description does not mention prerequisites or situations where it's appropriate, leaving the agent to infer from context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must shoulder the full burden. It states basic behavior (type a string as if on a US layout keyboard) but omits details about speed, special characters, key release handling, or layout limitations.
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: the first provides context for when to use, the second states the action. It is front-loaded and contains no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and one parameter, the description is adequate for basic use but lacks details on input limitations, integration with other HID tools, and error scenarios.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It mentions 'type a string' but adds no detail beyond what the parameter name implies, such as accepted formats, length restrictions, or encoding.
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 it types a string as physical keyboard input. It distinguishes from other automation paths but does not explicitly differentiate among HID sibling tools like hid.key for single keystrokes.
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 advises using this tool when other automation paths fail or when physical input is requested, providing clear context. However, it does not specify when to prefer other HID tools like hid.key for single keys.
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 the internal steps: absolute move to source, mouse_button_down, glided absolute move to destination, mouse_button_up. This gives insight into the sequence of events. However, it does not disclose potential side effects (e.g., cursor visibility, focus changes), safety considerations, or prerequisites (e.g., screen resolution). The disclosure is partial but sufficient for basic understanding.
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 front-loaded with a purpose statement and structured with internal step details. It is somewhat lengthy but every sentence adds value. It could be condensed slightly, but overall it is appropriately sized and well-organized.
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 7 parameters, no output schema, and no annotations. The description explains the drag gesture and internal steps but does not cover return values (presumably void), error conditions (e.g., out-of-bounds coordinates), or integration with other tools. It mentions relative coordinates and duration, which is helpful. Given the complexity, it is somewhat complete but lacks elaboration on edge cases and behavior under various conditions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 29% (only move_ms and relative have descriptions). The tool description does not add meaning to parameters beyond the overall drag process. For example, from_x, from_y, to_x, to_y are not individually explained, and button only has an enum but no description of its effect. The description mentions 'named button' but does not clarify the impact of choosing left, right, or middle. It does not compensate for the low schema coverage.
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: drag from (from_x, from_y) to (to_x, to_y) while holding a button. It distinguishes from siblings by specifying when to use this tool over other automation paths and mentions matching Anthropic Computer Use's left_click_drag action. The verb 'drag' and resource 'HID input' are 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says when to pick this tool: 'when other automation paths (file APIs, browser automation, OS APIs) cannot accomplish the task, or when the user explicitly requests physical keyboard or mouse input.' It also lists example workflows (design, spreadsheet, file-manager). However, it does not explicitly state when not to use it or mention alternatives among the sibling HID tools, though the context implies HID simulation.
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 must disclose behavioral traits. It adds the direction mapping for the delta parameter but omits details like scroll magnitude effects, speed, or units. The tool is nondestructive, but additional context would improve transparency.
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 relatively concise with two sentences. The first sentence is a longer preamble about when to use the tool, which could be separated but does not detract significantly. Overall, it is front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple tool with one parameter and no output schema, the description is fairly complete. It covers purpose, usage context, and parameter semantics. However, missing information about scroll behavior (e.g., lines vs pixels, limits) leaves gaps for an agent to fully anticipate the tool's effect.
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 schema provides no description for the delta parameter (0% coverage). The description adds meaning by explaining that positive values scroll up and negative values scroll down, which is essential. However, it does not specify units or magnitude effects, leaving some ambiguity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool scrolls the mouse wheel and defines direction with 'Positive=up, negative=down'. The preamble about selecting HID input adds context but does not directly define the tool's purpose, which is specific enough to distinguish from siblings like hid.click or hid.move.
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 explicitly advises using this tool when other automation paths fail or when physical input is requested, providing clear usage guidance. However, it does not explicitly state when not to use it, though the positive indication is strong.
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 provided, so description carries full burden. Describes the action sequence (press, wait, release) and duration range, but does not discuss potential side effects, permission requirements, or simulation fidelity beyond matching Anthropic's action.
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?
Three sentences, each serving a purpose: usage context, action description, and examples. No wasted words, though slightly longer than minimal. Front-loaded with critical usage instruction.
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?
Covers action and usage well, but lacks output specification and error handling. With no output schema, description should hint at return behavior. Parameter explanation is partial.
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 0%, but description adds meaning beyond schema: explains duration_ms as wait-then-release, mentions modifiers implicitly. Does not explain key values or modifiers enum. Examples help but not exhaustive.
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?
Clearly states it holds a key for a duration, specifically for physical HID input when other automation fails. Explicitly distinguishes from siblings by referencing alternative automation paths and matching Anthropic Computer Use's hold_key.
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?
Provides explicit when-to-use guidance (other automation fails, user requests physical input) and concrete examples (scrolling, panning). However, does not explicitly exclude sibling HID tools like hid.click or hid.key.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It only mentions 'Press a key or keyboard shortcut' but does not state whether it is a press-and-release or a press-hold, whether it blocks, or any side effects. This is insufficient for an agent to understand 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with a single sentence plus a usage guideline in brackets. It is front-loaded with the core action. However, it could be slightly more structured to separate the guideline from the action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (2 params, no output schema), the description provides a usage guideline but does not explain the life cycle of the key press (e.g., auto-release vs. hold) or the return value. This leaves gaps for an agent to fully understand the tool's behavior.
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 documentation coverage is 100%, so the description adds no extra meaning to parameters beyond what is in the schema. The description merely repeats the overall action, meeting the baseline for high coverage but not adding value.
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 tool name 'hid.key' and description 'Press a key or keyboard shortcut' clearly state the action and resource. The description also distinguishes from siblings by specifying it's for physical HID input when other automation paths fail, and references siblings like hid.type and hid.key_press.
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 explicitly states when to use this tool: 'pick this when other automation paths (file APIs, browser automation, OS APIs) cannot accomplish the task, or when the user explicitly requests physical keyboard or mouse input.' This provides clear usage context and implicitly suggests alternatives.
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 shoulders the transparency burden. It states idempotency (no-op for non-held button) and references Anthropic's standard, providing key behavioral traits. No mention of return or side effects, but sufficient for a simple release.
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 efficiently structured with a usage preamble and main action statement. Each sentence adds value, though the preamble could be slightly tighter. No wasted words.
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 tool with no output schema, the description covers purpose, idempotency, and usage context. It mentions matching an industry standard. Could note pairing with hid.mouse_button_down, but siblings cover that.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description should compensate by elaborating on the button parameter. It only says 'mouse button' generically, adding no value beyond the schema's enum. The parameter is simple, but the description fails to explicitly list options.
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 releases a previously-pressed mouse button, using specific verb and resource. It distinguishes from siblings by explicitly matching Anthropic's left_mouse_up and being the release counterpart to hid.mouse_button_down and hid.click.
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 preamble provides context on when to use HID tools (when other automation paths fail or explicit physical input is requested). The idempotency note guides safe usage, but does not contrast with alternatives like hid.click for combined press-release.
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 provided, so description carries full burden. States it releases all held keys/buttons, implying immediate effect. Does not mention behavior when nothing is held or any side effects. Adequate but not rich.
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?
Two sentences – a general usage prefix and the specific action. The prefix is somewhat boilerplate but concise overall. No wasted words.
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 no parameters or output schema, the description is sufficient to understand what the tool does. Sibling tools provide context. Could mention if it affects all HID devices or just current device, but not critical.
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?
No parameters in schema. Description adds no param info, but none is needed. Baseline for 0-param tool is 4.
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?
Clearly states 'Release every held key / mouse button (panic stop)' – a specific verb+resource. Distinguishes from siblings like hid.key_release (specific key) and hid.hold_key (hold action).
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?
Includes a general prefix recommending HID input when other automation paths fail or user requests physical input. For this tool, the name and description imply use as a panic stop, but no explicit when-to-use vs alternatives or exclusions.
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 burden. It states idempotency and that passing no arguments releases all held keys/mouse buttons (panic stop). However, it does not specify what happens if the key is not currently held or if only some modifiers are released.
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 mostly concise but includes a bracketed usage note upfront, which adds context. The main functional description is short, but the bracketed part could be considered extraneous. Overall, 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.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple parameter set and no output schema, the description covers when to use, idempotency, and panic stop. It lacks mentioning the return value, but that is minor. For a HID release action, it is fairly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description should explain parameters. It only implies that both key and modifiers are optional to release all, but does not describe what 'key' or 'modifiers' represent (e.g., which key to release, which modifiers to release). The schema has defaults but no description of their semantics.
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 releases a previously-pressed key or shortcut. It distinguishes from the sibling tool hid.release_all by noting that passing no arguments does the same thing, providing specific verb+resource with clear scope.
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 explicitly tells when to use this tool: when other automation paths fail or when the user requests physical input. It also mentions idempotency and the panic stop behavior with no arguments, guiding appropriate usage versus alternatives.
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?
Despite no annotations, the description explains idle timing, glide vs snap modes, references convergence semantics from hid.click, and discloses default behaviors. It is transparent about movement mechanics and closed-loop control, though relies on linking to another tool for full convergence detail.
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 front-loaded with purpose and usage context, then concisely explains parameters. It is slightly longer due to the preamble, but every sentence contributes value without 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?
With 4 parameters and no output schema, the description covers all necessary aspects: purpose, parameter behaviors, convergence reference, and usage context. It is sufficient for an agent to select and invoke correctly, though some missing details (e.g., return value) are minor.
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?
Schema coverage is 50% (x and y lack descriptions), but the description compensates by explaining them contextually. It adds significant detail for duration_ms and move_ms beyond schema descriptions, such as the idle timing and glide mode mechanics.
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 'Move mouse to (x,y) then idle for duration_ms (no click)', distinguishing it from siblings like hid.click (which clicks) and hid.move (likely without idle). The preamble also clarifies when to use physical HID input, making purpose 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly recommends this tool when other automation paths fail or when physical input is requested, providing good context. It does not explicitly list exclusions, but the sibling set and parameter details imply appropriate use cases.
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?
No annotations provided, so description carries full burden. It discloses that the key is pressed without releasing, pairs with hid.key_release, and gives a use case. Could add more about side effects or state.
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?
Front-loaded with purpose and usage guidance, then example. Slightly long but well-structured; every sentence adds value.
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?
Covers main use cases, distinguishes from siblings, provides example. Lacks error conditions or key format details, but overall complete for the complexity level.
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 0%, so description should explain parameters. It mentions modifiers list implicitly via example but doesn't detail 'key' values (e.g., special keys) or modifiers purpose beyond the enum.
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 it presses a key without releasing, and distinguishes from siblings like hid.hold_key and hid.key_release. It gives specific usage for multi-select patterns.
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?
Explicitly tells when to pick this tool ('when other automation paths cannot accomplish the task or user requests physical input') and contrasts with hid.hold_key for fixed-duration holds.
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?
Despite no annotations, the description discloses key behavioral traits: closed-loop convergence, snap vs glide mode, error condition when OS cursor query unavailable, and return fields. It references hid.click for more details on absolute mode behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with usage context, then provides specifics on coordinates, relative mode, return values, and glide mode. Each sentence adds value without redundancy, though cross-referencing hid.click could be considered a minor duplication.
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 complexity of 4 parameters, no output schema, and no annotations, the description covers key aspects: coordinate semantics, relative mode, move modes, error conditions, and return fields. It references hid.click for trade-offs, making it reasonably complete for a tool in a suite.
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?
With only 25% schema coverage, the description adds significant meaning: explains x,y as absolute screen coordinates under default semantics, relative flag for pixel deltas, and move_ms for glide mode. It compensates for the lack of schema descriptions on other parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Move mouse' and specifies absolute vs relative coordinates, distinguishing it from other HID tools. It explicitly indicates this is for physical HID input when other automation paths cannot be used.
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?
It provides explicit guidance on when to use the tool ('pick this when other automation paths... cannot accomplish the task, or when the user explicitly requests physical keyboard or mouse input'). It also references hid.click for more details, which helps in understanding context, though it doesn't explicitly say when not to use.
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?
Clearly states the tool presses without releasing. No annotations provided, so description carries the burden. Could mention behavior if button already pressed, but sufficient for a simple HID action.
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?
Concise, front-loaded with purpose, then usage context and sibling references. Every sentence adds value.
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?
Complete for a simple tool with one parameter and no output schema. Covers purpose, usage, behavior, and relationships to sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and description does not elaborate on the 'button' parameter beyond the schema's enum. The description adds no additional meaning for parameter selection.
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 presses a mouse button without releasing it, specifying verb and resource. It distinguishes from siblings like hid.mouse_button_up and hid.drag.
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?
Explicit guidance on when to use (physical HID input as fallback or user request) and how to compose with siblings (hid.mouse_button_up, hid.move, hid.drag) for dragging.
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?
Despite no annotations, the description fully discloses execution behavior: sequential ops, stop_on_error default with release_all on failure, delay defaults, cap at 10 ops, and no auto-release on clean completion. No contradictions.
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?
Well-structured with sections for usage, ops, delay, execution, return. Every sentence adds value, but could be slightly more concise. No fluff, but length might overwhelm some agents.
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?
Comprehensive: covers all op types, delays, error handling, return structure, and constraints. No output schema needed as return format is clearly 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?
Schema coverage is 100%, but the description adds meaningful context for each op type (e.g., click/move semantics identical to standalone tools, delay_ms defaults). Provides rationale for defaults, enhancing understanding beyond schema.
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 it runs a short, pre-planned HID sequence, distinguishing from individual HID tools by collapsing multiple calls into one. It specifies the scope (max 10 ops, strict order) and contrasts with orchestration workflows.
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?
Explicitly advises when to use: when other automation paths fail or user requests physical input. Also clarifies what it's NOT for (branching, reading results mid-sequence, looping), guiding the agent away from misuse.
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 fully bears the burden of behavioral disclosure. It exhaustively covers the coordinate system (absolute/relative), OS cursor query, convergence logic with iteration count and tolerance, glide mode, click-only-after-move guarantee, error handling on convergence failure, and platform-specific behaviors (Wayland, macOS).
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 long but well-structured with front-loaded usage guidance. Every sentence provides valuable detail, though some complexity could be streamlined. Given the intricate behavior (convergence, OS queries), the length is justified. It earns a 4 for efficiently packing essential information.
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?
Despite no output schema, the description thoroughly explains return values (x, y, target_x, target_y, converged, ok, residual_x, residual_y, hint) and error scenarios (convergence failure, absolute mode unavailability). It covers all critical aspects needed for correct invocation and handling, making it complete.
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?
Schema description coverage is 33% (only relative and move_ms have descriptions). The tool's description adds significant meaning to x/y (absolute vs. relative semantics, OS queries), relative (skip absolute), and move_ms (glide mode detail). However, button and double parameters are not elaborated beyond the schema, which already provides enum and defaults. Overall, the description compensates well for the low schema coverage.
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 performs a mouse click with physical HID input. It explicitly distinguishes this tool as the choice when other automation paths fail, and it details the coordinate system and modes. The verb 'click' and resource 'mouse' are unambiguous.
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 begins with explicit guidance on when to use this tool (when other automation paths cannot accomplish the task or user requests physical input). It explains absolute vs. relative modes and when to use relative (when absolute fails). It also advises on retrying after convergence failures, providing clear usage context.
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:

[![clawtouch-mcp MCP server](https://glama.ai/mcp/servers/tinqiao-oss/clawtouch-mcp/badges/card.svg)](https://glama.ai/mcp/servers/tinqiao-oss/clawtouch-mcp)

Score Badge

Copy to your README.md:

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

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