The Blue Prince MCP server has 8 tools with basic schemas and descriptions, but exhibits significant quality gaps. Tool names follow the verb_noun pattern well (list_, create_, read_, update_, delete_, download_, analyze_). However, descriptions are minimal (averaging ~45 chars, well below the 194-char production baseline), parameter schemas lack detail, and error handling guidance is absent. The server accepts structured metadata objects but provides no documentation of their shape. Output schemas are undocumented, callers do not know what fields to expect from tools like analyze_screenshot or list_screenshots. Parameter descriptions are present but tersely worded and lack format constraints, ranges, or examples of valid values. For a production tool kit handling note-taking and file operations, these gaps create significant friction for LLM reasoning.
Tools (8)
analyze_screenshotread onlyauth50/100
Analyze a screenshot using Google's Gemini vision API
create_notewritesource verified57/100
Create a new note with metadata and content
delete_notedestructivesource verified60/100
Delete a note file from the vault
download_screenshotwriteauth50/100
Download a screenshot from Google Drive to the local vault
Descriptions are too brief (average ~45 chars vs 194-char production baseline). Most descriptions lack context about when to use the tool, what it returns, and how it differs from similar tools. E.g., 'List all notes in the vault' says WHAT but not WHEN or WHY.
Output schemas are completely undocumented. Callers do not know what fields list_notes, analyze_screenshot, or list_screenshots return. For analyze_screenshot in particular, the response structure (e.g., whether it returns text, structured analysis, confidence scores) is unknown.
Metadata parameter for create_note and update_note is defined as 'object' with no schema detail. LLMs cannot determine what fields are required, optional, or valid. Description says 'including title, category, tags, confidence, status' but provides no type info, constraints, or required field list.
Recommendations
Expand tool descriptions to 100-200 chars. Include: what the tool does, when to use it instead of similar tools, what it returns in outline form, and any prerequisites. Example: 'Create a new note in the vault with metadata and markdown content. Use this to add new ideas, research, or structured notes. Returns the note path and confirmation. Requires vault path to be configured.'
Document output schemas for all tools. For list_notes, specify: returns array of {path: string, title: string, category: string, tags: array[string], created: ISO8601, modified: ISO8601, total: number}. For analyze_screenshot, specify: returns {text: string, confidence: number, objects: array[{label, box}], suggested_category?: string}.
Replace 'metadata' object parameter with explicit required and optional fields: title (string, required), category (enum: architecture|character|location|plot|theme), tags (array[string], optional), confidence (number 0-1, optional), status (enum: draft|review|published, optional). Document which fields are mutable.
Add error handling guidance to each tool. Examples: 'Returns error if path contains invalid characters or traverses above vault root. Valid paths match ^[a-zA-Z0-9_/-]+\.md$.' For delete_note: 'Fails if file is locked or does not exist; suggests list_notes to verify first.'
Add pagination to list_notes and list_screenshots: limit (1-100, default 20), offset (0+, default 0). Return {items: [...], total: number, offset: number, limit: number}. Document in descriptions: 'Supports pagination; call multiple times with offset to fetch large vaults.'
Spec posture evidence
Inferred effective spec: <=2025-11-25.
Relies on Logging (deprecated) - log to stderr or use OpenTelemetry
Score history
Overall score trend
↑ 11 points across a rubric change (v1 → v2)
49/100
Scored
Grade
Overall
Spec posture
Rubric
2026-09-22
F
49
<=2025-11-25
v2
2026-03-09
F
38
-
v1
Update an existing note with new metadata and content
No error handling guidance. Tools do not document what errors can occur, whether they are retryable, or what the LLM should do next. E.g., delete_note offers no recovery path if the file does not exist or is locked.
No idempotency or confirmation mechanism for destructive operations. delete_note is DESTRUCTIVE but offers no dry-run, confirmation, or undo capability. An agent mistake causes unrecoverable data loss.
Path parameters lack format constraints or validation guidance. 'Path to the note file' does not explain valid characters, directory depth limits, or whether absolute vs relative paths are accepted. This invites path traversal or invalid values.
No pagination support for list_notes and list_screenshots. If vaults grow large, returning all notes/screenshots at once bloats the response and risks context window exhaustion. No limit, offset, or cursor parameters present.
analyze_screenshot does not document what model is used, response format, or error cases (e.g., corrupted image, unsupported format). The description 'Analyze a screenshot using Google's Gemini vision API' lacks implementation detail needed for LLM planning.
analyze_screenshot
Add a confirm_delete tool or a dry_run boolean parameter to delete_note. Example: 'Pass dry_run=true to preview deletion without executing. Destructive operations require explicit confirmation via confirm_delete_note(path) after dry_run.'
For download_screenshot and analyze_screenshot, document supported image formats (JPEG, PNG, WebP) and size limits (max 10MB). Example: 'Downloads file_id from Google Drive, saves as filename (supported: .jpg, .png, .webp, max 10MB). Fails if format unsupported or file corrupted.'
Add a batch variant for tools called in loops. E.g., create_notes accepting array of {path, metadata, content} instead of single create_note. Reduces token cost and latency.
Document dependencies: 'Call list_notes first to discover available paths before read_note. Call list_screenshots before analyze_screenshot to identify valid file_ids.'
Add validation rules to parameter descriptions. E.g., path parameter: 'Relative path (no leading /). Max 256 chars. Valid characters: a-z, A-Z, 0-9, _, -, /. No ../ or \ sequences. E.g.: architecture/house-layout.md.'
Audit Google Drive integration for secret leakage. Ensure tokens and credentials are not returned in responses or logged. Document scope requirements (e.g., 'requires Google Drive API with drive.readonly scope').