31 lines
2.5 KiB
Markdown
31 lines
2.5 KiB
Markdown
## ADDED Requirements
|
|
|
|
### Requirement: MCP tools expose capability layer without driver leakage
|
|
The system SHALL expose an MCP server whose tools (at minimum: `take_screenshot`, `tap`, `swipe`, `input_text`, `launch_app`, `find_text`, `find_icon`, `get_ui_tree`, `describe_screen`, `list_devices`, `device_status`) map directly to the capability/perception layer, with tool names, parameters, and return values containing no Appium/WDA/XCUIElement-specific concepts.
|
|
|
|
#### Scenario: MCP client calls a tool without framework knowledge
|
|
- **WHEN** an MCP-compatible LLM client (e.g. Claude Desktop) calls the `tap` tool with coordinates
|
|
- **THEN** the call succeeds by being routed through the capability layer to the underlying driver, and neither the tool schema nor its response exposes Appium/WDA-specific types or errors
|
|
|
|
#### Scenario: Tool list is stable across driver changes
|
|
- **WHEN** the underlying driver for a device changes (e.g. a future non-WDA driver is used) while the MCP tool set is unchanged
|
|
- **THEN** existing MCP tool calls continue to work without any change to tool names or parameter schemas
|
|
|
|
### Requirement: MCP tool errors are semantic, not framework-specific
|
|
The system SHALL translate driver/framework-level errors (e.g. WDA connection errors, element-not-found) into clear, semantic MCP tool error responses (e.g. "device offline", "element not found") rather than passing raw framework exceptions through to the LLM.
|
|
|
|
#### Scenario: Device offline surfaces a clear error
|
|
- **WHEN** an MCP tool call targets a device that is currently offline
|
|
- **THEN** the tool call returns a semantic error indicating the device is unavailable, not a raw connection-refused/stack-trace style error
|
|
|
|
### Requirement: REST API mirrors the same capability functions
|
|
The system SHALL provide a REST API (`GET /devices`, `POST /devices/{id}/tap`, `POST /devices/{id}/screenshot`, `POST /devices/{id}/launch`, `POST /agent/task`, `GET /task/{id}`) that calls the same underlying capability functions as the MCP tools, for manual testing and dashboard use.
|
|
|
|
#### Scenario: REST and MCP produce consistent results
|
|
- **WHEN** the same capability (e.g. `screenshot`) is invoked once via the REST API and once via the corresponding MCP tool for the same device
|
|
- **THEN** both calls exercise the same underlying capability function and produce equivalent results
|
|
|
|
#### Scenario: Starting a task via REST
|
|
- **WHEN** a caller POSTs a goal to `/agent/task`
|
|
- **THEN** the system creates a new task, returns its task id, and the task becomes queryable via `GET /task/{id}`
|