Skip to main content
Glama
Sign In
windows2-mcp

windows2-mcp

by verisoft-ai
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

release_actions

Idempotent

Release all held keyboard keys and pointer buttons to reset input state after an interrupted automation sequence.

Instructions

Release all keys and pointer buttons currently held down by a prior perform_actions call. Call this to reset input state if a perform_actions sequence left keys/buttons stuck down (e.g. after an error mid-sequence).

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "release_actions"
  }
}

Input Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.0

TDQS

A4.9/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare idempotentHint=true and destructiveHint=false. The description adds specific behavioral context: it releases all held keys/buttons from a previous perform_actions call, which is valuable beyond the annotations. 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?

Two sentences, front-loaded with the primary action. Every sentence adds essential information with no waste. Highly concise and well-structured.

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 no parameters, annotations covering idempotency and destructiveness, and no output schema, the description is fully complete. It explains the purpose, when to use, and the triggering condition. Nothing essential is missing.

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?

There are zero parameters, so the schema coverage is 100% by default. The description does not need to add parameter details. According to the rubric, baseline for 0 parameters is 4, and the description meets that standard.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool releases all keys and pointer buttons held down from a prior perform_actions call. It uses a specific verb ('release') and resource ('keys and pointer buttons'), and distinguishes well from sibling input tools like perform_actions or send_keys.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly advises to call this tool to reset input state if perform_actions left keys/buttons stuck down, especially after an error. It gives both the context of use and the condition that triggers the need, making it clear when to use and when not.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Other Tools