agentic windows mcp

Setup prompt to copy

---
name: agentic-windows-mcp-tool-tester
description: >
  Automated testing skill for Agentic Agentic Windows MCP tools. Use this skill whenever the user wants to test,
  validate, benchmark, or evaluate any Agentic Agentic Windows MCP tool (App, PowerShell, Screenshot, Snapshot,
  Click, Type, Scroll, Move, Shortcut, Wait, MultiSelect, MultiEdit, Clipboard, Process,
  Notification, FileSystem, Registry, Scrape). Triggers on phrases like "test the Click tool",
  "benchmark Screenshot", "validate FileSystem", "run QA on Registry", "check if PowerShell works",
  "evaluate tool performance", or any mention of testing/validating a Agentic Agentic Windows MCP tool.
  Each invocation tests exactly ONE tool.
---

# Agentic Agentic Windows MCP Tool Tester

An automated testing skill that generates comprehensive test cases for a single Agentic Agentic Windows MCP tool,
executes them, and produces a structured test report with pass/fail results, performance metrics,
and actionable recommendations.

## Core Principles

- **One tool per invocation.** If the user doesn't specify which tool to test, ask them before proceeding.
- **Black-box testing only.** Derive test cases exclusively from the MCP tool description and parameter schema — never read source code. Silence in the schema is a documentation gap, not a testing hint.
- **Auto-generate test cases** from the tool's MCP description and parameter schema. Cover common scenarios, edge cases, parameter combinations, and error handling paths.
- **Measure two dimensions**: correctness (return value matches expectations) and response time (end-to-end, including MCP overhead).
- **Mandatory side-effect verification**: every tool call that may modify system state MUST be independently verified — no exceptions, no sampling.
- **Safe cleanup**: track process PIDs spawned during testing; only kill those specific PIDs during teardown, never kill by process name alone.
- **Safety first**: Agentic Agentic Windows MCP has full system access with no sandboxing. Tests involving
  destructive tools (FileSystem delete, Registry set/delete, Process kill, PowerShell) can
  modify or destroy data. Running in a **VM or Windows Sandbox** is strongly recommended.
  Before executing destructive test cases, confirm the user accepts the risk. See `SECURITY.md`.
- **Produce a structured report** at the end (see Step 4).

---

## Step 0: Identify the Target Tool

If the user hasn't specified a tool, present the full list and ask them to pick one:

> App, PowerShell, Screenshot, Snapshot, Click, Type, Scroll, Move, Shortcut, Wait,
> MultiSelect, MultiEdit, Clipboard, Process, Notification, FileSystem, Registry, Scrape

Once a tool is confirmed, proceed to Step 1. Do NOT test multiple tools in one session.

---

## Step 1: Analyze the Tool

Read the tool's MCP description and parameter schema via the MCP server's tool listing. Identify:

1. **All parameters** — name, type, required/optional, default value, allowed values (enums)
2. **All modes** (if the tool is mode-based, e.g., FileSystem has read/write/copy/move/delete/list/search/info)
3. **Return value structure** — what the tool returns on success vs. failure
4. **Side effects** — does it modify system state? (important for test isolation)
5. **Dependencies** — does it require a running app, an open window, existing files, etc.?

Use this analysis to inform test case generation. If the description is ambiguous or silent on a
behavior, note it as a documentation gap and design a test to probe it. The tool's response is
the ground truth.

---

## Step 2: Generate Test Cases

Design test cases that cover the following categories. Not every category applies to every tool —
use judgment based on the tool's nature.

### Category A: Basic Functionality (Required)
Test the tool's primary purpose with standard, well-formed inputs.
- One test per mode/operation type (e.g., for FileSystem: read, write, list, etc.)
- Use realistic parameter values

### Category B: Parameter Variations (Required)
- Test each optional parameter individually to verify it takes effect
- Test enum parameters with every allowed value
- Test boolean parameters in both true and false states
- **For `anyOf` union types**: The schema advertises all listed types as valid, so the tool must handle each correctly.
  - `anyOf: [boolean, string]` (e.g., `drag`, `use_vision`): test boolean `true`/`false` AND string `"true"`/`"false"` — both must produce the same behavior.
  - **Caveat:** MCP transport layers may silently coerce `"true"` (string) to `true` (boolean)
    before the tool sees it. To genuinely probe the string path, also test non-standard truthy
    strings like `"yes"` or `"1"` — if those fail while `"true"` passes, the tool likely only
    receives booleans and the string branch is untested.
  - `anyOf: [<type>, null]` (nullable): test with a valid value AND explicit `null`. An unhandled TypeError on null is a FAIL.
- Test with default values (omit optional params) vs. explicit values

### Category C: Edge Cases (Required)
- Empty strings, zero values, negative numbers where applicable
- Boundary values (e.g., very long text for Type, timeout=0 for PowerShell)
- Unicode / special characters in string parameters
- Very large or very small numeric inputs

### Category D: Error Handling (Required)
- Missing required parameters
- Invalid parameter types or out-of-range values
- Referencing nonexistent resources (files, windows, processes, registry keys)
- Operations that should fail gracefully (e.g., deleting a non-existent file)

### Category E: Parameter Interaction (When Applicable)
- Combinations of parameters that might interact (e.g., Click with both `loc` and `label`)
- Mutually exclusive parameters
- Mode-specific parameter requirements
- **Cross-mode parameter applicability**: For mode-based tools, pass parameters meant for one
  mode while calling another (e.g., `window_loc` in `launch` mode). Silently ignoring them is
  a documentation gap worth

.claude/skills/agentic-windows-mcp-tool-tester/SKILL.md from the repo, Apache-2.0 licence. Read it before pasting. Muse asks before it acts.