desktop-touch-mcp

Server Quality Checklist

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

Latest release: v1.11.3
Disambiguation5/5
Each tool targets a distinct domain or action, with highly detailed descriptions that eliminate ambiguity. Even closely related tools (e.g., browser_click, click_element, mouse_click) are clearly differentiated by target context (browser DOM, UIA, screen coords).
Naming Consistency4/5
Browser tools follow a consistent 'browser_verb' pattern. Other tools use descriptive names, but some mixing occurs (e.g., click_element vs mouse_click vs keyboard). Overall, the naming is predictable and readable.
Tool Count4/5
With 29 tools, the set is large but justified by the extensive scope (browser, native UI, terminal, Excel, clipboard, etc.). Each tool serves a specific purpose, though some consolidation could reduce count slightly.
Completeness4/5
The tool surface covers core desktop automation tasks comprehensively. Minor gaps exist, such as the absence of a dedicated native text-reading tool (though OCR and terminal actions fill the gap) and no explicit file/process management, but these are not critical for the stated domain.
Average 4.7/5 across 29 of 29 tools scored. Lowest: 4/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 44 commits in the last 12 weeks
- Last stable release on July 15, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is failing
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.
This server has been verified by its author.
View related servers

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

Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that the successful response always includes a hints.verifyDelivery object with status 'unverifiable' and explains the reasons (Focus Assist, DND, consent UI). It also mentions the underlying technology (System.Windows.Forms) and that no external modules are needed. However, it does not clarify if the tool is blocking or asynchronous.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is moderately concise but includes Japanese text and a JSON literal that may hinder readability. The first sentence is clear, followed by technical caveats that are all relevant but could be more structured. Every sentence serves a purpose, but the mix of languages and technical jargon reduces conciseness.
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 that the tool has only 3 parameters, no output schema, and no nested objects, the description covers the key aspects: purpose, usage context, delivery verification behavior, and a suggested indirect observation method. It is complete enough for an agent to use correctly, though it does not cover behavior for multiple rapid calls or notification click handling.
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%, so the baseline is 3. The description does not add significant new meaning beyond what the schema already provides for the title, body, and include parameters. The description focuses on behavioral aspects rather than parameter details.
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 'Show a Windows system tray balloon notification to alert the user', providing a specific verb and resource. It distinguishes from sibling tools which are focused on browser interactions, desktop actions, and data processing, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use at the end of a long-running task so the user knows it finished without watching the screen', providing clear context for when to use. It also includes caveats about delivery verification and suggests indirect observation via wait_until, but does not mention alternative tools or explicitly state 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.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, description fully discloses behavioral traits: ShellExecute, window snapshot polling, HWND-based detection, localized title handling, timeout and detach behaviors, and single-instance caveat. 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 clear headings and front-loaded purpose. No fluff, but includes inaccurate parameter references that harm conciseness. Slight deduction for misleading details.
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?
Explains return format, gives examples, and covers caveats. However, the mismatch with actual schema parameters (timeoutMs vs waitMs, missing args and include) leaves gaps in accurate understanding. Adequate but imperfect.
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 100%, so baseline is 3. However, description introduces parameters 'timeoutMs' and 'detach' that do not exist in the input schema, and states a default timeout of 10000 while schema shows 'waitMs' default 2000. This inconsistency misleads the agent and reduces 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 description clearly states the verb 'launch' and resource 'application', and specifies the waiting behavior and return values. It explicitly distinguishes from sibling tool 'run_macro' by recommending use instead of manual combos.
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?
Provides explicit guidance: prefer over run_macro, follow with focus_window, and caveats for single-instance apps. Also covers detach=true scenario. No ambiguity about when 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?
No annotations provided, so the description carries full burden. It discloses that coordinates are captured at call time and may be stale after page reflow. Also lists specific error codes with explanations. Lacks explicit statement that the tool is read-only, but the caveat implies no side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: three sentences covering purpose, usage guidance, caveats, and error types. No extraneous words, well structured with important info 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 no output schema, the description explains the return type (physical screen coordinates) and compatibility. It also covers common errors. Could be more complete by specifying the exact format of coordinates (e.g., x, y integers), but overall sufficient for an agent to understand and invoke the tool.
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%, so parameters are already described in schema. The description adds the context that the output is screen coordinates compatible directly with mouse_click, which is not in schema. However, it does not add further detail to parameter meanings beyond what's in the 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 the verb 'Find', resource 'DOM element by CSS selector', and the output 'physical screen coordinates'. It distinguishes from sibling tools by noting compatibility with mouse_click and referencing alternatives like browser_click and browser_overview.
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 recommends alternatives: 'Prefer browser_click to find+click in one step' and 'Prefer browser_overview to discover selectors'. Also includes caveats about stale coordinates, guiding when to use this tool vs others.
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?
No annotations are provided, so the description fully handles behavioral disclosure. It explains what each field returns, notes that engine values are stable while health values change per call, and mentions a limitation (lastRpc only tracks stdio transport). 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?
The description is relatively long but well-structured with clear sections for engine, imageDiff, and health. It front-loads the purpose and each sentence adds value. Slight verbosity in health subfields but acceptable.
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?
Given the complexity (three main components with subfields), one optional parameter, and no output schema, the description is complete. It explains return value semantics, stable vs changing fields, and a transport limitation. All necessary context is provided.
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?
Only one parameter ('include') with 100% schema description coverage. The description does not add extra meaning beyond the schema; the schema already clearly explains the parameter. 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 starts with 'Return MCP server status.' which is a clear verb+resource. It then details the specific components (engine, imageDiff, health) and distinguishes the tool from siblings by being about server diagnostics, not UI automation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on when to use ('Diagnostic metadata — do not surface unless the user asks about performance/troubleshooting.'), implying a conditional use. However, it does not explicitly state when not to use or name alternatives.
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?
No annotations are provided, so the description fully discloses behavior: default dry run, safety gate, retention caps (maxCount, maxTotalBytes, maxAgeMs), orphan handling, and that only the screenshot cache is touched. It also explains that the newest capture is always kept.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single dense paragraph but well-organized: starts with purpose, then default behavior, then parameters. It is concise and front-loaded, though slightly packed. Every sentence adds value.
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, the description partially covers return values (candidates, count/size of orphans). However, it does not detail the exact structure of the response, which may leave the agent uncertain about what to expect from the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema coverage, the description still adds value beyond the schema: explains defaults, default behavior (dry run), retention policy nuances, and that `includeOrphans` is true by default. This enriches the agent's understanding.
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 and resource: 'Reclaim disk space from cached screenshots by retention policy.' This clearly distinguishes it from sibling tools like `screenshot` (which captures screenshots) and `screenshot_query` (which queries captures).
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 explains default dry-run behavior and the safety gate for actual deletion (both `dryRun:false` and `confirm:true`). It covers retention caps and scope. However, it does not explicitly state when not to use this tool or offer direct alternatives, but the context is clear for a cleanup tool.
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?
No annotations provided, so description carries full burden. It discloses all key behaviors: requires CDP active, excludes hidden inputs by default, value truncation at 200 chars, label resolution order, and exact return fields.
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?
Description is front-loaded with purpose and contains dense information. Every sentence adds value, though it is a single long sentence that could be broken for readability.
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?
For a tool with 7 parameters and no output schema, the description covers all essential context: purpose, when to use, prerequisites, caveats, and return fields. No gaps remain.
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 baseline is 3. Description adds marginal value beyond schema for parameters; it contextualizes selector usage and mentions default for includeHidden, but mostly repeats schema info.
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 verb 'inspect' and the resource 'form fields' within a container specified by CSS selector. It lists the fields returned, distinguishing it from sibling tools like browser_fill.
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 recommends using this tool before browser_fill to discover exact field selectors and avoid targeting wrong inputs. Also mentions prerequisites (browser_open) and caveats about hidden inputs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses result ordering (confidence descending), pagination, error behaviors, and scope limitations. However, it does not explicitly state that the tool is read-only or describe side effects, though it is implied.
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 well-structured and front-loaded with the core purpose and axes. It includes caveats and error details, but is slightly verbose. Every sentence adds value, though a minor reduction in length could improve conciseness.
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 11 parameters, no output schema, and no annotations, the description covers behavior thoroughly including error handling, usage guidance, and parameter interaction. It could elaborate slightly on the 'include' parameter, but overall it is sufficiently complete for an agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for all parameters. The description adds value beyond the schema by explaining how results[0].selector can be used with browser_click, pagination via offset/maxResults, and error codes. It also clarifies the 'by' axis options and the 'include' parameter's effect.
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 'Grep-like element search across the current page' and lists all search axes (text, regex, role, etc.), making the purpose unambiguous. It distinguishes itself from siblings like browser_overview and browser_click.
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 is given: 'Use browser_overview for broad discovery; use browser_search when you know specific text or role to target.' Additionally, error codes with actionable next steps are provided, helping the agent decide when and how to use the tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully carries the burden. It discloses all relevant behaviors: non-text clipboard returns empty string, overwriting on write, delivery verification with byte comparison, and detailed failure reasons. This exceeds the minimum required 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 somewhat long but front-loaded with the main purpose. Every sentence contributes useful information; however, details about byte-level verification could be simplified for brevity without losing clarity.
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?
Given three parameters and no output schema, the description covers return values, side effects, failure modes, and recovery. It also connects to sibling tools (keyboard) and provides examples. The tool is thoroughly documented for an AI agent.
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%, and the description adds value by explaining the action enum values, the text parameter's role in writing, and the optional include parameter for response shaping. It provides context beyond the schema's dry definitions.
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 that the tool reads or writes the Windows clipboard, with specific verb-resource pairs for each action. It distinguishes itself from siblings like keyboard by focusing solely on clipboard operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use each action and offers recovery strategies for write failures (retry or fallback to keyboard). It does not explicitly list alternatives but the guidance is sufficient for correct usage.
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 thoroughly explains behavioral traits: it is read-only, returns specific fields, has caveats (non-UIA elements, modal detection limitations, includeDocument requiring browser_open), and details Chromium-specific behavior. It also notes the absorption of former tools, providing full 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 well-organized into Purpose, Details, Prefer, and Caveats sections. While it is lengthy, every sentence adds necessary detail for effective tool use. It is minimally verbose given the complexity.
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?
Given the tool's complexity (7 optional parameters, no output schema), the description is highly complete. It covers default behavior, optional enrichments, caveats, integration notes with other tools, and Chromium-specific fallbacks. The agent can use this tool correctly without ambiguity.
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%, so baseline is 3. The description adds value by explaining the context and purpose of each include* parameter (e.g., absorbing former tools, default off) and the meaning of port and tabId. This goes beyond basic parameter descriptions.
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 purpose as 'Read-only observation of the current desktop state' and lists what it returns (focused window/element, modal flag, etc.). It distinguishes itself from sibling tool desktop_discover by noting it does not enumerate descendants, making its scope 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 advises using the tool after each action to confirm state and highlights it as the cheapest observation tool. It provides guidance on setting include* flags only when needed. However, it lacks explicit 'when not to use' instructions beyond the mention of desktop_discover for descendant enumeration.
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?
No annotations are provided, so the description carries the full burden. It discloses important behavioral traits: parallel execution, resetting the diffMode buffer, side effects on diff baseline and identity tracker. It also warns about thumbnail scaling and recommends tracking the reset point. This is thorough and transparent.
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 well-structured with headings (Purpose, Details, Prefer, Caveats) and each section adds value. However, it is somewhat verbose, especially the caveat referencing ADR-010. It could be slightly more concise without losing information, but it remains effective.
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?
Given the tool has 3 parameters, no output schema, and no annotations, the description is remarkably complete. It explains what is returned, side effects, usage patterns, and caveats. It fully equips the agent to use the tool correctly.
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% (all three parameters have descriptions in the input schema). The description does not add significant new meaning beyond the schema; it references 'includeUiSummary' indirectly and mentions thumbnail dimensions, but the schema already covers these. 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?
The description clearly states the tool's purpose: 'Orient fully in one call' and enumerates what it returns (display layouts, thumbnails, actionable element lists). It is a specific verb+resource combination and distinguishes from sibling tools like screenshot and screenshot variants.
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 usage guidance: 'Use at session start or after major workspace changes.' It also offers alternatives: 'Use screenshot(detail='meta') for cheap re-orientation' and 'screenshot(detail='text', windowTitle=X) for a single-window update.' This helps the agent decide when to use this tool versus others.
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, description fully discloses idempotency, preference for existing endpoint, return structure, per-process connection, and error codes. 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?
Single paragraph packs all info but is somewhat dense; front-loads key purpose. Every sentence adds value, but could be more scannable.
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?
No output schema, so description must explain return (tabs array) and errors, which it does. Missing details on envelope structure but coverable by parameter documentation.
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% (baseline 3). Description adds value by explaining 'idempotent' launch behavior, killExisting warning, and envelope/raw response shape.
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 purpose: 'Connect to Chrome/Edge running with --remote-debugging-port and return open tab IDs' and distinguishes it from siblings by noting it is required before all other browser_* tools.
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 this tool (before other browser tools), when to pass launch:{} vs omit, conditions for re-call (Chrome restart), and alternatives if browser lacks debug flag.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully carries the burden of disclosure. It details that selectors are CDP snapshots, input text reflects hint priority, non-matching scope silently falls back, modal detection logic, and error conditions like BrowserNotConnected.
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 each sentence adds value. It is front-loaded with main purpose and usage, followed by detailed sections on modal and caveats. Slightly verbose on modal detection but necessary for clarity.
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 8 parameters, no output schema, and complex behavior, the description covers return elements, modal detection, caveats, and error handling. It could explicitly list all output fields but the modal section is well specified.
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%, so baseline is 3. The description adds value by explaining scope usage and the purpose of the modal section, but most parameter details are already in the schema. Extra context like 'scope silently falls back' provides beyond-schema understanding.
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 the tool lists interactive elements on the page, differentiates from siblings like browser_click and screenshot by specifying use cases ('use before browser_click', 'prefer over screenshot when verifying button/toggle state').
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 recommends usage before browser_click and over screenshot for state verification. Mentions scope for subsection filtering and caveats like re-call after navigation. Alternative tools are implicitly given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses critical traits: sequential execution, max 50 steps, sleep pseudo-step limitation (max 10s), stop_on_error default, inability to inspect intermediate results, and per-screenshot token cost. This is comprehensive.
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 well-organized with labeled sections (Purpose, Details, Prefer, Caveats, Examples), making it scannable. It front-loads the core purpose. While a few sentences could be tightened (e.g., the token cost note), nothing is wasted.
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 (3 parameters, nested objects, behavioral nuances) and no output schema, the description covers nearly everything an agent needs to use the tool correctly. It could mention the format of the error output (e.g., partial results when stop_on_error=false), but the missing detail is 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?
Baseline is 3 because schema coverage is 100%. The description adds value by explaining the steps array structure, the sleep pseudo-step, the stop_on_error behavior, and the include parameter's influence on response shape. The examples further clarify usage. A minor gap: the 'include' parameter's envelope description could be clearer, but overall adds meaning.
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 opens with a clear verb and resource: 'Execute multiple tools sequentially in one MCP call'. It immediately distinguishes from individual tool calls by highlighting latency elimination, and the sibling context (many atomic tools) makes the differentiation obvious.
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: 'Prefer: Use for predictable fixed sequences... Do not use for conditional logic'. It tells the agent when to split a macro and provides caveats about conditional failures, making the usage boundary very clear.
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 bears full responsibility for disclosing behavior. It details error types (e.g., 'BrowserNotConnected', 'AutoGuardBlocked'), truncation behavior, readyState checks, and limitations like circular reference serialization. This fully informs the agent of 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 lengthy but well-structured with clear sections (Purpose, Details, Prefer, Caveats, Examples). It is front-loaded with the essential purpose and action list. While some redundancy could be trimmed, the structure and content are appropriate for the tool's complexity.
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?
Given the tool's complexity (12 parameters, no output schema), the description is thorough. It covers all actions, usage preferences, caveats, error handling, and provides examples. It addresses potential edge cases and integrates with sibling tools, ensuring completeness.
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%, so baseline is 3. The description adds significant value beyond the schema by explaining parameter interactions (e.g., 'withPerception' returns structured JSON, 'includeContext' appends context) and providing examples. It enhances understanding of parameter 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's purpose: inspect or operate on a browser tab via three distinct actions ('js', 'dom', 'appState'). It differentiates from sibling tools by specifying when to use each action and provides examples, making the purpose very clear.
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 usage guidelines, including a 'Prefer' section that advises when to use each action (e.g., use 'appState' before 'dom' or 'js' on SPAs). It also includes caveats for when not to use certain actions, such as avoiding direct DOM node return from 'js'. This thoroughly guides the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses CDP dependency, error codes (BrowserAmbiguousTarget, BrowserNoActionableTarget, BrowserFillNotDelivered), and false-positive case for controlled inputs. Also explains stopping behavior and verification via 'actual' in response. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Despite length, the description is well-structured: it starts with purpose, then targeting methods, usage comparison, caveats, and error handling. Every sentence serves a purpose with no redundancy. Front-loaded with the main use case.
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 complex tool with 11 parameters and no output schema, the description covers input semantics, targeting, error codes, and verification. It does not detail the full response shape, but mentions 'actual' and hints. Given the richness of other sections, it is nearly 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 coverage is 100%, so baseline is 3. The description adds significant meaning: explains the by-axis method (text, regex, role, ariaLabel), the mutual exclusivity of selector and by+pattern, and the optional role/scope filters. It also details error conditions tied to parameters, which the schema does not. Therefore, adds value 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 the tool fills form inputs via CDP, specifically for React/Vue/Svelte controlled inputs where browser_eval fails. It distinguishes from sibling browser_eval by naming the alternative and the condition. The verb 'Fill' and resource 'form input' are precise, and the scope is well-defined.
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 states when to use over browser_eval: 'Use this over browser_eval when setting a controlled input's value via JS does not update framework state.' Also explains when to use by-axis vs selector, and mentions prerequisites like browser_open. Provides clear context and exclusions.
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?
No annotations provided, but description fully discloses that navigation does not wait for page load, describes typed errors (NavigateFailed, BrowserNotConnected, AutoGuardBlocked), and explains the auto-guard mechanism. Exceptionally transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with clear sections: main action, caveats, error types. Every sentence adds value, no fluff. Front-loaded with 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?
Covers all aspects given complexity: return behavior, error handling, follow-up actions, and parameter details. No gaps despite lack of output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but description adds significant meaning beyond schema: explains waitForLoad default behavior, loadTimeoutMs timeout handling, lensId for pinned-tab workflows, and include parameter for response shaping.
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 the tool navigates a browser tab to a URL via CDP Page.navigate, distinguishing it from clicking the address bar (sibling browser_click). Provides specific verb and resource.
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?
Explains when to use (for URL navigation via CDP) and caveats (does not block until load complete, recommends follow-up with wait_until). Could be more explicit about when not to use alternatives like browser_click.
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?
No annotations provided, so description carries full burden. Explains auto-guarding mechanism, return of post.perception.status, typed error codes, and behavior with lensId. Comprehensive disclosure.
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 purpose and usage guidelines, then caveats. Every sentence adds value but could be more concise. Error details are thorough but lengthy.
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?
Handles 9 parameters, 1 required, no output schema. Explains return value, error handling, prerequisites (desktop_discover), and usage patterns. Complete for a complex tool.
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 100%, baseline 3. Description adds context for fixId (one-shot, 15s TTL), lensId (advanced use), include (response shape opt-in), and narrate (narration levels). Enriches 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 'Invoke a UI element by name or automationId via UIA InvokePattern — no screen coordinates needed.' It specifies the verb (invoke) and resource (UI element), and distinguishes from mouse_click (coordinates) and browser_click (browser).
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 says 'Prefer over mouse_click for buttons, menu items, and links in native Windows apps. Use desktop_discover first to discover automationIds.' Also provides caveats and fallbacks when InvokePattern is not supported.
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?
No annotations provided; description carries full burden. Discloses destructive nature (creates macros), required registry settings, trust location, error conditions, and serialization behavior due to STA. Highly transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with headings (Purpose, Details, Prefer, Caveats, Examples) and front-loaded purpose. Slightly verbose but necessary for the complex tool.
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?
Covers prerequisites, alternative actions, error handling, and provides multiple examples. No output schema needed given the examples. Complete for an AI 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?
Input schema has no properties; description compensates by explaining 'action', 'code', 'macroName', 'visible' parameters, including valid values and usage. However, no formal parameter definitions in 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?
Description clearly states purpose: author and run VBA macros via COM late binding. Distinguishes from similar tools like 'Claude for Excel' and sibling 'run_macro', with specific verb+resource.
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 recommends running 'check_access_vbom' first, provides remediation hints, and notes caveats like macroName format and STA threading. Offers clear when-to-use guidance.
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?
No annotations are provided, so the description carries the full burden. It discloses key behaviors: default scaling to maxDimension=768, by-ref resource links, coordinate math, diffMode requiring a baseline, background mode requirements, mode-detail compatibility, fullContent defaults, and fallbacks. Every important behavioral trait is documented.
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 sections (Purpose, Details, Prefer, Caveats, Examples). It is front-loaded with the overall purpose. Every sentence adds value given the tool's complexity (19 parameters). A slightly tighter edit could reduce redundancy, but it remains clear and organized.
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?
Given the tool's complexity (19 parameters, multiple modes, no output schema), the description is remarkably complete. It covers all modes, parameters, integration with sibling tools (desktop_discover, mouse_click), and provides examples for common scenarios. No gaps are apparent for an AI agent to correctly invoke the tool.
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%, so parameters are already documented. The description adds significant value: it provides examples for combining parameters, explains behavioral context (e.g., confirmImage interaction with detail='image'/'som'), and clarifies coordinate systems for region. This enriches understanding beyond the 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 the tool's purpose: 'Capture desktop, window, or region across detail levels (meta / text / image / som / ocr) and capture modes (normal / background).' It distinguishes itself from sibling tools by noting when to prefer browser_* tools for Chrome, and the examples cover common use cases. The specificity of verb+resource+scope is excellent.
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 'Prefer:' section explicitly provides when-to-use guidance for each detail level and mode, and gives alternatives (e.g., 'Use browser_* tools for Chrome', 'Use diffMode after actions to confirm state changed'). The 'Caveats' section clarifies restrictions and prerequisites. This is comprehensive and actionable.
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 explains pin survival across minimize/restore, need for explicit unpin, dock failure on elevated processes, override of Windows snap, and auto-restoration of minimized windows before docking.
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 well-structured with labeled sections (Purpose, Details, Prefer, Caveats, Examples), front-loads the purpose, and every sentence adds value. It is concise yet comprehensive, fitting all necessary information into a manageable length.
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 complexity (10 parameters, 3 actions) and lack of output schema, the description provides thorough coverage of usage and behavior, including examples. However, it does not describe the return value or error handling, which would improve completeness.
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%, and the description adds value beyond the schema by explaining defaults (480×360 bottom-right), the relationship between action and required fields, and the interplay between pin and duration_ms. However, the schema itself is already clear, so the description only slightly enhances understanding.
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 purpose with specific verbs (decorate, pin, unpin, dock) and resources (window), distinguishing it from sibling tools like focus_window. The three actions are explicitly listed and explained.
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 'Prefer' section advising when to use action='dock' versus action='pin' alone, and includes caveats about elevated processes and overriding snap arrangements, giving clear guidance on appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavior: how by-axis resolves to a single actionable element, handling of ambiguity and modal blocking, delivery verification signals, and scroll behavior. 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?
The description is lengthy but well-structured with clear sections. Some parts, like verifyDelivery details, could be more concise, but overall it earns its length given the tool's complexity.
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?
For a complex tool with 13 parameters and no output schema, the description is remarkably complete, covering return behavior, error states, boundary cases (modal, viewport), and parameter interactions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 100% schema coverage, the description adds significant meaning: explains by+pattern pairing, role/scope filtering, scrollIntoView effects, fixId, and verifyDelivery hints. All 13 parameters are meaningfully elaborated.
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 clicks a DOM element in Chrome/Edge and distinguishes two targeting modes (selector and by-axis), differentiating it from siblings like browser_locate (which only locates) and mouse_click (global).
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?
Provides explicit guidance on when to use each targeting mode, caveats (viewport, modal blocking), and alternative tools (browser_eval for scrolling). Also explains error codes and retry strategies.
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 discloses behavioral traits: auto-clipboard for non-ASCII, background input methods, focus loss detection, blocked keys, and detailed error contexts (e.g., 'FocusLostDuringType', 'BackgroundInputNotDelivered'). It explains per-action verification and edge cases like CJK IME handling.
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 clear sections (Purpose, Details, Prefer, Caveats, Examples). Every sentence adds value given the tool's complexity (19 parameters). Slightly verbose for a simple tool, but appropriate for this one.
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 comprehensively covers all actions, parameter interactions, error states, and security restrictions. It references internal context (e.g., 'context.typed', 'context.remaining') and provides examples covering common use cases. It handles all the complexity of a 19-parameter tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although schema coverage is 100%, the description adds significant meaning beyond the input schema. It explains the interplay between parameters (e.g., forceKeystrokes vs auto-clipboard, abortOnFocusLoss default behavior), provides examples for each action, and clarifies conditional requirements like 'Requires windowTitle or hwnd' for forceImeOff.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool sends keyboard input to a window with three distinct actions ('type', 'press', 'sequence'). It distinguishes itself from siblings like click_element and desktop_act by explicitly stating what each action does and when to use alternatives, e.g., 'Use desktop_act({action:"setValue"}) for UIA ValuePattern text fields.'
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use each action (e.g., 'Pass windowTitle to auto-focus and auto-guard...') and when not to use it (e.g., 'CJK IME composition — use use_clipboard=true or desktop_act'). It includes alternatives like 'Use desktop_act({action:"setValue"})' and covers caveats like blocked win+r combos.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden and covers all key behaviors: guarding mechanism, post-click status, fix approval, origin+scale conversion, double/triple-click priority, Win11 foreground restrictions, and verifyDelivery status values.
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 comprehensive and front-loaded with the core purpose, but is quite lengthy. However, every sentence adds value and it is well-structured with examples and caveats.
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?
Given 21 parameters, no output schema, and absent annotations, the description is remarkably thorough, covering usage, errors, recovery, and edge cases like multi-platform differences.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Adds significant meaning beyond the input schema, especially for `origin`+`scale` conversion, `fixId` expiration and one-shot nature, `lensId` usage, and `hints.verifyDelivery`. Required parameters `x`, `y`, `verifyDelivery` are explained in context.
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 immediately states 'Click at screen coordinates.' and distinguishes from siblings by recommending `click_element` for native apps and `browser_click` for Chrome, making it clear when to use this tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance on guarded vs unguarded clicks (with/without windowTitle), fixId workflow, and preferences over alternatives. Includes examples with expected response statuses.
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 covers behavioral traits: left button only, guarded start/end points, blocking cross-window drags by default, Win11 foreground refusal, and detailed hints.verifyDelivery status values.
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 but slightly verbose. Starts with core action and examples before diving into parameters and caveats. Every sentence is informative, but some repetition (e.g., block details) slightly reduces conciseness.
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?
Given 14 parameters, no output schema, and no annotations, the description is remarkably complete. Covers use cases, edge cases (cross-window, tab drag), Win11 restrictions, and hints response shape. No obvious gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Adds significant meaning beyond schema: explains lensId's advanced usage, verifyDelivery shape, allowTabDrag purpose, and homing behavior. Schema coverage is 71%, but description fills gaps with context and examples.
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 explicitly states the action ('Click and drag'), the resources (mouse coordinates), and specific use cases (sliders, drag-and-drop, canvas drawing, window resizing). It clearly distinguishes from sibling tools like mouse_click.
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?
Provides explicit when-to-use examples and when-not: cross-window drags blocked by default, tab drags blocked unless allowed. Includes examples and notes on optional parameters (lensId) and intentional overrides (allowCrossWindowDrag, allowTabDrag).
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, description fully discloses non-destructive behavior (no pixel read), response fields, ordering (newest-first), and a critical warning about token costs for reading bytes. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Compact ~120 words, front-loaded with core purpose and key differentiators ('WITHOUT re-reading'). Each sentence adds unique value, no fluff. Structured logically from behavior to filtering to caveats.
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, description enumerates response fields (captureId, uri, dimensions, size, timestamp, tag/window, cache totals) and covers all relevant aspects: behavior, filtering, pagination, ordering, and token-warning. Complete for a list operation.
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 covers 100% of parameters, so baseline is 3. Description adds value by specifying filter semantics (case-insensitive tag, epoch ms timestamps), default/limits (limit 50 max 500, offset 0), and response shape opt-in, which go beyond schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists screenshots from disk-cache without re-reading pixels, contrasting with sibling screenshot (capture) and screenshot_gc (reclaim space). It precisely describes the action and resource.
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 use (find/re-open captures, check cache, decide GC) and when not to (avoid opening by-ref links unless needed due to token cost). Mentions alternative screenshot_gc for reclaiming space.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully covers behavioral traits: scroll scaling details (UIA vs legacy), destructive mutations (expandHidden), OCR accuracy, image stitching size implications, typed errors, and delivery verification. It transparently explains all important side effects and constraints.
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 lengthy but well-structured with clear sections (Purpose, Details, Prefer, Caveats, Examples). Every sentence adds value for a complex tool. Minor redundancy could be trimmed, but the organization compensates for length.
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 having 32 parameters, no output schema, and no annotations, the description covers all necessary details: each action's mechanics, parameters, error codes, and usage contexts. It includes multiple examples covering all actions, making it complete for an AI agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds significant meaning beyond the schema. For example, it explains the 'action' parameter's sub-behaviors, the 'amount' parameter's effect across different app tiers, and the 'strategy' parameter's fallback order. This extra context is critical for correct parameter usage.
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 'Purpose: Scroll a window or page.' and details 5 distinct actions (raw, to_element, smart, capture, read), each with specific use cases. It effectively distinguishes from sibling tools like browser_* and mouse_click by focusing on scroll-specific operations.
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 'Prefer:' section explicitly states when to use each action (e.g., action='to_element' for click target recovery, action='capture' for reading long pages, action='read' for text extraction from native apps). Caveats further clarify limitations and alternatives, providing comprehensive guidance.
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 thoroughly discloses behavior: actions list, exit code handling (ok:false with specific error code for non-zero), ring buffer cap (1MB), concurrency limit (16 sessions), Windows powershell hidden nature, and that it does not open a visible window. 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?
The description is well-structured with sections (Purpose, Actions, Details, Prefer, Caveats, Examples) and front-loaded with essential distinctions. It is longer than minimal but each sentence adds value given the complexity and missing schema. Not excessively verbose.
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?
For a tool with no output schema and no annotations, the description is remarkably complete: covers all actions, error handling, limits, platform specifics, and provides multiple examples. Agent can correctly invoke and interpret results based on this description alone.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no parameters, but the description fully compensates by detailing each action's parameters (action, id, input, waitMs, shell, clear) with examples for exec, start, write, read, stop. Schema coverage is effectively 100% due to 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 clearly states it is a 'reliable background shell channel backed by a real OS process' and instructs to use it for 'installs, scripts, file ops, and any command that must actually finish'. It explicitly distinguishes from the sibling 'terminal' tool, making the purpose and scope 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?
Provides explicit guidance: prefer 'exec' for one-shot, 'start+write+read' for interactive sessions, and to use 'terminal' only when a visible console is needed. Also includes caveats about not using when the user needs to see the UI, with concrete alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully carries the burden. It details completion reasons, outputIntegrity, baseline_lost, file lock collisions, hidden-input prompts, and background/foreground method behavior. This comprehensive disclosure exceeds expectations.
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 well-structured with a clear top-down flow (purpose, details, prefer, caveats, examples). However, it is quite lengthy; some repetition could be trimmed without losing 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?
Given the tool's complexity (9 parameters, nested objects, no output schema), the description covers all necessary aspects: actions, return values, edge cases, and error handling. It provides enough context for an agent to use the tool correctly in various scenarios.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is high (89%), but the description adds significant value beyond the schema: it explains the 'until' parameter structure, illustrates with examples, clarifies the deprecated 'command' alias, and describes action-specific required fields. This greatly enhances parameter understanding.
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 is for interacting with a terminal window, with three specific actions (read, send, run). It distinguishes each action's role and scope, making it easy for an agent to understand what the tool does.
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 guidance on when to use each action, including preferring 'run' for command execution, using pattern mode for long-running commands, and avoiding screenshotting. It also advises on fine-grained control with read/send. This effectively helps the agent choose the correct action.
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?
Without annotations, the description fully discloses behavior: polling mechanics, return format ({ok:true, elapsedMs, observed}), timeout behavior (WaitTimeout with suggest hints), non-timeout failure modes (ToolError, BrowserNotConnected), and implementation details (UIA process per poll, interval clamping).
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 well-structured with clear sections (Purpose, Details, Prefer, Caveats, Examples) and front-loaded purpose. While verbose, each sentence adds unique value; minor redundancy in some examples could be trimmed.
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?
Given the tool's complexity (9 conditions, multiple error paths, prerequisites), the description is exhaustive: it covers all conditions, target requirements, error codes, and provides examples for various use cases. The lack of an output schema is compensated by clear return value documentation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema coverage, the description adds significant value by explaining each condition's target requirements, providing examples, and elaborating on optional parameters like intervalMs and include, making the tool far more usable than the schema alone.
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 purpose as a server-side poll for observable conditions, listing specific conditions (e.g., window_appears, url_matches) and distinguishing it from screenshot-polling loops by sibling tools like run_macro and screenshot.
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 this tool over alternatives (e.g., 'Use instead of run_macro({sleep:N}) + screenshot loops'), provides condition-specific guidance (use url_matches for SPA route changes), and includes caveats about prerequisites (browser CDP connection) and error handling with suggested actions.
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?
No annotations provided, but description fully discloses behaviors: returns WindowNotFound, caveats about focus being stolen back, Win11 foreground refusal behavior, forceFocus escalation algorithm, and handling of CDP unavailability. Completely transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is appropriately sized, front-loaded with core functionality. Every sentence adds value with no redundancy. Well-structured, starting with main action then adding details and caveats.
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?
Given 5 params, no output schema, and many sibling tools, description is extremely complete: explains return types, error conditions, recovery strategies, and integration with other tools (chromeTabUrlContains, desktop_discover, desktop_act, etc.). No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, baseline 3. Description adds significant context beyond schema: explains purpose of each parameter (title matching, cdpPort default, include response shape, forceFocus algorithm, chromeTabUrlContains usage). Adds 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?
Clearly states the verb 'bring to foreground', resource 'window', and mechanism 'partial title match (case-insensitive)'. Distinguishes from siblings by specifying when to use this tool vs alternatives like chromeTabUrlContains and other focus methods.
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 states when to use: when a tool does not accept windowTitle param, or when needing to switch focus before a sequence of actions. Provides clear when-not-to-use scenarios and alternatives (desktop_act, click_element, keyboard) for recovery from ForegroundRestricted errors.
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:

[![desktop-touch-mcp MCP server](https://glama.ai/mcp/servers/wangkang1133/desktop-touch-mcp/badges/card.svg)](https://glama.ai/mcp/servers/wangkang1133/desktop-touch-mcp)

Score Badge

Copy to your README.md:

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

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