MCP server for fetching and managing dev.to challenge submissions from the Forem API
Server has 5 tools with basic verb-noun naming (get_*, fetch_*, update_*). All tools have descriptions (10-100 chars), but most are terse and lack actionable context for LLM selection. Input schemas are present and properly typed, but parameter descriptions are minimal or absent. Output schemas are not documented. Error handling exists but lacks recovery guidance. No tool annotations (readOnlyHint/destructiveHint). Overall structure is functional but falls short of production-grade quality.
Fetch fresh challenge submissions for a specific tag from dev.to API
Get all challenge submissions from all fetched tags
Get a list of all existing challenge tags that have been fetched
Get challenge submissions for a specific tag
Update existing challenge submissions or fetch all existing tags
Output schemas not documented. LLMs cannot plan downstream calls or extract required fields (e.g., submission IDs, article URLs, tag names). Responses are opaque.
Parameter descriptions missing or minimal. 'tag' parameter in get_tag_submissions and fetch_submissions lacks format/constraint guidance. No mention of case sensitivity, required suffix 'challenge', or valid examples.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint). LLMs cannot distinguish safe reads from destructive writes. fetch_submissions and update_submissions modify state but lack destructiveHint annotation.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 56 | 2026-07-28+ | v2 |
Error messages lack recovery guidance. validateTagName() throws generic errors ('Invalid tag...') without suggesting valid alternatives or next steps for the LLM.
No pagination support. get_all_submissions and get_tag_submissions return unbounded lists. Large result sets will exhaust context windows. No limit, offset, or cursor parameters.