Loading ToolBench
Query Z.ai GLM Coding Plan usage statistics including quota limits, model usage, and MCP tool usage
This OpenCode GLM Quota plugin exposes 4 query tools with identical schemas and shared parameter structure. While tool names follow verb_noun convention (query-*), critical issues emerge: (1) All 4 tools have nearly identical descriptions and parameter schemas, creating confusion about when to use each; (2) The timeWindow parameter description is present but vague, 'Optional 24-hour rolling time window' does not explain what queries return if the window is omitted, nor does it document the datetime format constraints beyond a bare format string; (3) No output schemas are documented in the visible code, the source snippet is truncated and does not show response structure, making it impossible for LLMs to reason about downstream tool composition or field extraction; (4) No error handling guidance is visible, API client calls (queryEndpoint) are wrapped but error recovery patterns are not evident; (5) The tool names themselves lack differentiation, all start with 'query-', and the descriptions use nearly identical phrasing ('Query ... statistics for Z.ai GLM Coding Plan'), which will confuse LLMs about which tool to invoke for which use case. Per-tool analysis shows all four tools score identically due to identical schema and description weaknesses.
Query model usage statistics for Z.ai GLM Coding Plan
Query quota limit and usage statistics for Z.ai GLM Coding Plan
Query MCP tool usage statistics for Z.ai GLM Coding Plan
Query combined usage statistics including quota limits, model usage, and tool usage for Z.ai GLM Coding Plan
All four query tools have nearly identical descriptions and schemas, making it impossible for LLMs to distinguish when to invoke query-quota-limit vs query-model-usage vs query-tool-usage. The descriptions should clearly state what each tool returns and when an agent should select it over the others.
No output schema is documented in the visible source code. The code snippet is truncated at the response processing functions, but the compiled tool definitions provided to the MCP client do not include return type documentation. Without knowing the output structure (fields, types, example values), LLMs cannot plan downstream tool calls or extract data confidently.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 41 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 24 | - | v1 |
The timeWindow parameter description says 'Optional 24-hour rolling time window for query (defaults to yesterday hour to today hour)' but does not specify: (1) what happens if startTime is provided without endTime; (2) whether the window must be exactly 24 hours or can be shorter; (3) timezone handling (UTC? local?); (4) behavior when the time window spans multiple quota reset cycles.
No error handling guidance is visible in tool descriptions. If an API call fails (invalid token, quota exceeded, network timeout), the tool description does not explain to the agent what to do next (retry? ask the user? check credentials?). The createCredentialError() function exists but is only shown for missing credentials, not for runtime API failures.
Tool names use generic 'query-*' prefix, which is action-oriented but not sufficiently specific. The naming does not clearly distinguish the scope of each tool. Consider: query-quota-limits (what is the difference from query-usage?), query-model-consumption, query-mcp-tool-consumption to make the scope explicit. Baseline: 90% of A+ tools have names under 27 chars and >18 chars on average, these are at 18-19 chars, which is borderline.