Five tools with acceptable naming (verb_noun structure) and present schemas. Descriptions are adequate but brief (18-70 chars). All parameters have type definitions and descriptions. Zod schemas provide runtime validation. However, critical gaps exist: no output schema documentation, no error guidance for recovery, no parameter value ranges/constraints, and missing natural identifiers (e.g., accepting usernames alongside IDs). The tools follow basic patterns but lack the production-grade polish expected for A-grade servers. Response handling is minimal (JSON stringification with no field documentation).
get current authenticated user qiita articles
get a specific Qiita article by its ID
get Qiita markdown syntax rules, cheat sheet
create a new article on Qiita
update an existing Qiita article
No documented output schemas. Tools return JSON-stringified API responses without documenting which fields the LLM should expect. This forces agents to parse unstructured output and wastes tokens on metadata irrelevant to chat interactions.
No error recovery guidance. Error responses are generic (e.g., 'Error: <message>') with no hints on what the LLM should do next. Per pattern:recovery-guide, errors must tell the agent whether to retry, ask the user, or abort.
Numeric parameters (page, per_page) lack constraints. No minimum/maximum specified, inviting out-of-range values. Rubric requires 'Specify minimum and maximum for numeric parameters.'
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 54 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 44 | - | v1 |
Tool descriptions are under 100 characters and lack WHEN/WHY context. Per pattern:tool-description, descriptions should explain What, When, and prerequisites. Current descriptions are purely definitional.
item_id parameter accepts string but no format/length constraint documented. LLMs cannot infer valid ID format without explicit guidance.
Destructive operations (post_qiita_article, update_qiita_article) have no dry-run or confirmation step. Per pattern:confirmation-request, irreversible ops should support pre-execution verification.
No tool annotations. Tools lack readOnlyHint/destructiveHint metadata. post_qiita_article and update_qiita_article should declare destructiveHint=true (per current MCP spec 2026-07-28).
API token validation (validateToken) is called only at service instantiation, not at each tool invocation. If token is missing at runtime, errors surface late with no actionable message.