MCP server for querying and managing Ruijie wireless access points
Single tool with partial schema and incomplete descriptions. The tool name 'query_access_point' is verb-noun compliant, but the description lacks clarity on when to use it vs alternatives. Input schema is present with types (array, integer) but parameter descriptions are truncated in the source (cut off mid-sentence: 'An array of key-'). The 'query' parameter uses a complex array-of-objects structure with free-form string values, inviting hallucinated keys. No output schema documented. No error handling guidance. No pagination despite returning a range of results. Baseline: 194 chars avg description (this one ~150 chars but incomplete), 72 chars avg param annotation (this one ~100 chars but cut off).
Query and return No.[start, end] wireless access points that meet all query parameters, end have to greater or equals start.
Parameter descriptions truncated/incomplete in source. 'query' param description cuts off mid-sentence ('An array of key-'). LLMs cannot infer the full constraint set for the 'key' field values.
No output schema documented. Tool returns results but LLMs have no visibility into the structure of returned access points (fields, types, pagination). Prevents downstream tool chaining.
Query parameter uses free-form string values for 'key' field. Should be an enum: ['name', 'mac', 'ip', 'location', 'state']. Free-form invites hallucinated keys like 'hostname' or 'status'.
No error handling guidance. Tool description does not explain what happens if 'end < start', if no results match, or if the range is out of bounds. LLMs cannot recover from failures.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 45 | <=2025-11-25 | v2 |
Pagination not explicit. Tool accepts 'start' and 'end' (1-based range) but does not document total count, whether results are sorted, or how to iterate large datasets. Violates paginated-result pattern.