Loading ToolBench
Native Windows Personal Context & Unified Cross-Device Model Context Protocol (MCP) Server for Gemini, Claude & ChatGPT
Windows Context MCP has 15 tools with consistent naming (all verb_noun pattern: get_*, search_*) and clear descriptions (avg 150 chars, all 50+ chars). However, critical gaps undermine production readiness: (1) Most tools accept zero parameters with empty properties objects, no input validation or flexibility. (2) Output schemas are completely undocumented, LLMs cannot plan downstream calls or extract structured data. (3) No error handling guidance visible in tool definitions. (4) Parameters that exist (query, date, startDate/endDate) lack type constraints, ranges, or format specifications. (5) No tool annotations (readOnlyHint, idempotentHint) despite all being read-only operations. The server reads well as a domain-specific context aggregator but lacks the rigor expected of production agent tools.
Returns the currently focused foreground window title, process name, and category on the Windows desktop.
Returns total combined screen time across both Windows PC and Android phone with device comparison.
Retrieves complete real-time Windows PC context including currently active window, top applications, screen time, CPU/RAM utilization, and battery state.
Lists all connected personal devices (Windows PC and synced Android devices) with battery and sync states.
Retrieves multi-day productivity stats, scores, and top applications over a specified date range.
Retrieves 24-hour hourly productivity timeline showing productive vs entertainment minutes per hour for today or a specific date.
Output schemas completely undocumented. No tool returns a documented schema, LLMs cannot infer what fields to expect, breaking downstream tool chaining and forcing agents to guess at response structure.
Parameter descriptions lack format constraints and ranges. 'date' in get_hourly_breakdown says 'YYYY-MM-DD format' but no regex or minLength/maxLength. 'query' in search_window_history has no length bounds or character restrictions. LLMs cannot validate inputs before calling.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 55 | 2026-07-28+ | v2 |
Returns whether the user is actively working on the PC or currently away/idle.
Retrieves real-time hardware telemetry: CPU load percentage, RAM usage (total, free, used %), battery percentage, and charging state.
Retrieves today's total PC screen time with categorized breakdown (Productive vs Entertainment vs Communication vs Browsing).
Calculates an automated PC productivity score (0-100), ratio, category balance, and top distracting applications today.
Returns the chronological sequence of recent window and application switches (e.g. VS Code -> Chrome -> Slack).
Checks overall system resource status including memory pressure, CPU load, and system uptime.
Pinpoints entertainment, gaming, or distraction applications that consumed the most time on PC today.
Combines real-time Windows PC context and synced Android phone telemetry into a unified personal context snapshot.
Searches application usage history today by process name or window title keyword.
No tool annotations despite all 15 tools being read-only. Missing readOnlyHint in inputSchema would signal to agents that these calls are safe to retry and have no side effects.
No error handling guidance in tool definitions. If a tool fails (e.g., no active window, invalid date range), LLMs have no recovery path documented. Descriptions do not explain failure modes or what to do next.
Most tools (13/15) accept zero parameters with empty properties objects. This limits flexibility, e.g., get_pc_screen_time could accept optional date parameter to retrieve historical data, but forces agents to call get_historical_usage instead.