Collection of MCP-AQL adapter examples wrapping various services (AirPods head-tracking, GitHub API, Playwright browser automation, Shortcut remote control) via the MCP protocol
This repository contains 24 tools across 5 MCP adapters (AirPods, GitHub, Playwright, Shortcut). Critical issues: (1) All tools use generic operation-dispatch patterns (mcp_aql_read, mcp_aql_create, etc.) rather than verb_noun naming. Four tools share identical names across different domains, making them indistinguishable to LLMs. (2) Parameter schemas are severely underdeveloped: 'operation' is an enum but 'params' is a bare object with no type, properties, or required fields defined. This violates JSON Schema best practices and leaves LLMs unable to understand what parameters each operation accepts. (3) Descriptions are domain-specific but lack operation-level detail. The mcp_aql_read for AirPods lists 8 operations in the description but provides no per-operation guidance on parameters, return types, or when to use each. (4) No output schemas documented anywhere. (5) No error handling guidance. The generic dispatch pattern hides implementation details from the LLM, forcing it to reason about operation names and parameter structures without schema support.
CREATE operations for Shortcut remote control via HID
CREATE operations for GitHub API
CREATE operations for AirPods Pro head-tracking on macOS. Supported operations: start_sidecar, capture_calibration_point
CREATE operations for Playwright browser automation
CREATE operations for GitHub API (all toolsets)
DELETE operations for Playwright browser automation
DELETE operations for AirPods Pro head-tracking on macOS. Supported operations: stop_sidecar, clear_calibration, clear_offsets
Tool naming violates verb_noun pattern. Four tools named 'mcp_aql_read', 'mcp_aql_create', 'mcp_aql_update', 'mcp_aql_delete' are repeated across AirPods, GitHub, Playwright, and Shortcut domains. LLMs cannot distinguish which tool operates on which domain. Should be: 'get_airpods_pose', 'list_github_repos', 'execute_playwright_script', etc.
Parameter 'params' is defined as bare object type with no properties, required fields, or type constraints. LLMs cannot infer what parameters each operation accepts. Schema must enumerate properties for each operation variant (e.g., 'list_devices' vs 'get_pose' have different param structures).
No output schemas documented. Tool descriptions list operations but do not specify what each operation returns. LLMs cannot plan downstream tool calls or extract required fields (e.g., does 'get_pose' return {x, y, z} or {yaw, pitch, roll}?).
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 29 | 2025-06-18+ | v2 |
DELETE operations for GitHub API
DELETE operations for GitHub API (all toolsets)
DELETE operations for Shortcut remote control via HID
EXECUTE operations for Playwright browser automation
EXECUTE operations for Shortcut remote control via HID
EXECUTE operations for GitHub API
EXECUTE operations for GitHub API (all toolsets)
READ operations for GitHub API (all toolsets). Supported operations include introspection and various GitHub queries with extended toolset support
READ operations for Shortcut remote control via HID
READ operations for AirPods Pro head-tracking on macOS. Supported operations: list_devices, is_streaming, get_pose, wait_for_pose, get_recent_poses, get_calibration, get_offsets, introspect
READ operations for GitHub API. Supported operations include introspection and various GitHub queries
READ operations for Playwright browser automation
UPDATE operations for Shortcut remote control via HID
UPDATE operations for AirPods Pro head-tracking on macOS. Supported operations: recenter, set_offsets, apply_calibration
UPDATE operations for GitHub API (all toolsets)
UPDATE operations for Playwright browser automation
UPDATE operations for GitHub API
Generic operation-dispatch pattern hides implementation. Tools accept 'operation' enum and 'params' object, but descriptions do not document per-operation parameter requirements, error conditions, or return types. This forces LLMs to guess operation semantics.
No error handling guidance. Descriptions do not explain what errors each operation can raise, whether they are retryable, or what the LLM should do next. No recovery hints provided.