An MCP server implementation for Android that exposes device information and system resources via HTTP/SSE transport with optional token-based authentication
This Android MCP server has critical definition quality gaps. Both tools lack proper input schemas (defined as empty objects {}), parameter descriptions are entirely missing, and output schemas are not documented. Tool descriptions are present but minimal (under 20 chars for get_current_time). The server defines tools via `server.addTool()` calls in McpServerManager.kt, but the definitions are incomplete for production use. Naming follows action-verb convention (get_*), which is positive, but the lack of schema structure, parameter documentation, and comprehensive descriptions makes these tools unsuitable for reliable LLM agent interaction. Baseline: 100% of A+ tools have documented return types and parameter descriptions; 0% of those conditions are met here.
获取当前时间
获取Android设备信息,必须使用原始数据回答
No input schemas defined for any tool. Both tools register with empty input objects ({}), violating the requirement that every tool must declare parameter types and constraints. This prevents LLMs from understanding what inputs are valid.
No output schemas documented. Tool responses are TextContent objects but LLMs have no formal schema indicating what fields or structure to expect. Without documented return types, agents cannot plan downstream calls or extract specific fields reliably.
Tool descriptions are minimal and lack actionable guidance. 'get_current_time' is only 7 words; descriptions should be 10-1024 characters and answer WHAT, WHEN to use, and any prerequisites. Current descriptions do not guide LLM tool selection effectively.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 33 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 0 | - | v1 |
Response content is plain text markdown rather than structured JSON objects. 'get_device_info' returns formatted text like 'Device Info: Manufacturer: ...' which requires LLM parsing. Should return structured JSON with typed fields (manufacturer, model, version, sdk) so agents can reliably extract and chain values.
No error handling or recovery guidance. Tools do not validate inputs, catch exceptions, or return actionable error messages. If a tool fails, the LLM receives no context on why or what to try next.
Hardcoded Chinese descriptions without parameter documentation. 'get_device_info' description '获取Android设备信息,必须使用原始数据回答' is not standard practice and provides no parameter guidance. Even translated, lacks detail on when/why to call vs similar discovery tools.