A Pixiv toolset for Large Language Models via MCP.
This server has solid structure with clear tool names, good descriptions, and explicit Pydantic schemas with ToolAnnotations. However, output schemas are undocumented (no structured response definitions visible), many optional parameters lack actionable constraints, and error handling is minimal. The tool names are action-oriented (search_, get_, download_, manage_) and follow verb_noun convention well. Descriptions are present and mostly 50-200 chars, which aligns with LLM optimization. Tool annotations (READ_ONLY_TOOL, MUTATING_TOOL, DESTRUCTIVE_TOOL) are correctly applied. The main gaps are: (1) no documented return schemas, (2) optional parameters (offset, limit, view) lack min/max constraints or detailed format guidance, (3) error responses appear minimal with no recovery guidance visible in the code shown, and (4) the 'update_setting' tool accepts free-form string keys/values with no enum constraint on valid keys despite RUNTIME_SETTING_KEYS being defined.
Download artworks by illust_id(s). Supports batch downloads with customizable filename and format options.
Get illustrations from users the authenticated user is following.
Get detailed information about an illustration by ID.
Get illustration rankings by mode (daily, weekly, monthly, etc.).
Get recommended illustrations (requires authentication).
Get illustrations related to a given illustration.
Get trending illustration tags.
No documented output/return schemas for any tool. LLMs cannot plan downstream calls or parse results without knowing the response structure. The code shows response construction and manipulation (e.g., ensure_json_serializable, format_illust_summary) but no formal schema documentation.
update_setting accepts free-form 'key' and 'value' strings with no enum constraint, despite RUNTIME_SETTING_KEYS being defined server-side. LLMs cannot self-validate input; they will pass invalid keys and get runtime errors. The tool should expose valid keys as an enum.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 68 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 47 | - | v1 |
Get a user's bookmarked illustrations.
Get a user's following list.
Query or cancel download tasks by action (status/cancel).
Paginate to the next page using a compact cursor.
Search for illustrations by keyword with filtering, sorting, and pagination support.
Search for users by keyword.
Update a runtime setting (download_path, filename_template, ugoira_format, or default_limit).
Pagination parameters (offset, limit) across 10+ tools lack min/max constraints and default values. 'limit' appears optional on every search/list tool but no guidance on the default (is it 20? 50? 100?) or the maximum accepted value. This invites LLMs to pass unbounded values that may break the API or exhaust memory.
Error handling is minimal. No error responses visible in the tool definitions showing recovery guidance, actionable messages, or error classification (retryable vs. user-fixable vs. fatal). The code references 'handle_api_error' utility but its implementation and response format are not shown.
download tool modifies filesystem (WRITE operation) but lacks a dry-run or confirmation step. If an LLM selects this tool by mistake, it could write large numbers of files to disk. A confirmation_request pattern or explicit user approval would prevent accidents.
Many parameters marked optional (e.g., 'gif_fps', 'duration', 'filter') lack guidance on when to use them or what the defaults are. Parameter relationships are underdocumented (e.g., when does 'webp_preset' apply vs. 'gif_preset'?). LLMs cannot reason about optional parameters without explicit dependency docs.