Static source inference · medium confidence · detected: Logging
Deprecated protocol patterns detected
Summary
Five vision analysis tools with solid parameter schemas but weak output documentation and generic descriptions. All tools have descriptions and input schemas, but lack output schema documentation, error handling guidance, and tool composition clarity. Naming is verb-forward (analyze_, compare_, detect_, audit_) but descriptions read as generic API docs rather than LLM-optimized guidance. Parameters are well-typed with enums and ranges, but descriptions often lack actionable context for agent decision-making. No tool annotations present (readOnlyHint). Error handling is implicit; no recovery guidance visible.
Tools (5)
analyze_imageread onlyauthsource verified65/100
Analyze an image using AI vision models. Supports URLs, base64 data, and local file paths.
analyze_videoread onlyauthsource verified58/100
Analyze a video using AI vision models. Supports URLs, file paths, and YouTube URLs.
audit_designread onlyauthsource verified65/100
Audit design compliance using AI vision models with pixel metrics analysis. Evaluates layout, spacing, typography, accessibility, and design system adherence.
compare_imagesread onlyauthsource verified65/100
Compare multiple images using AI vision models. Supports URLs, base64 data, and local file paths.
Output schemas not documented for any tool. LLMs cannot plan downstream calls or extract data without knowing what fields to expect. For a vision analysis tool, output structure is critical.
Descriptions are generic and lack LLM-optimized guidance on WHEN to use each tool. For example, 'Analyze an image using AI vision models' does not answer: what distinguishes this from detect_objects_in_image or audit_design? When should an agent choose one over another?
No error handling or recovery guidance. If an image URL fails to load or a video is unsupported, there is no indication what the error message will be or how the LLM should respond. Tools silently fail without actionable next steps.
analyze_imagecompare_imagesanalyze_video
Recommendations
Document the output schema for each tool. For analyze_image, specify: 'Returns {analysis: string, confidence?: number, metadata?: {model, tokens_used}}'. For detect_objects_in_image, specify: 'Returns {detections: [{object: string, location: {x, y, width, height}, confidence: number}], image?: base64_string (if outputFormat=annotated)}'.
Rewrite descriptions to differentiate tools. Example: 'analyze_image: Describe visual content, composition, colors, and design elements in a single image. Use for understanding layouts, UI design, or visual content.' vs 'compare_images: Highlight differences between 2-4 images. Use for UI consistency checks, design variations, or before/after comparisons.' vs 'detect_objects_in_image: Identify and locate objects with bounding boxes. Use for inventory, safety inspections, or spatial reasoning.'
Add error handling guidance. For each tool, document: 'Errors: Invalid image source (retryable, check URL/file path exists), unsupported format (user-fixable, convert to JPEG/PNG), rate limited (retryable, wait and retry), API failure (retryable, retry after 30s). Include recovery hints: 'If URL fails, try uploading base64-encoded image instead.'
Add readOnlyHint: true to all tool definitions. This signals LLMs that these tools are safe to retry and idempotent.
Replace inline prompt examples with enum modes. Change 'prompt' parameter to: mode: enum [general, palette, hierarchy, components] + a separate 'customPrompt' string param for additional instructions. This prevents LLM prompt injection and clarifies intent.
Spec posture evidence
Inferred effective spec: <=2025-11-25.
Relies on Logging (deprecated) - log to stderr or use OpenTelemetry
No tool annotations (readOnlyHint). All five tools are read-only (Risk: READ_ONLY in metadata), but this is not declared in the tool schema. LLMs cannot infer retry safety or idempotence without explicit hints.
analyze_image and compare_images have long, verbose prompt parameter descriptions with inline examples ('For front-end or UI comparison, the prompt you provide must be: ...') that risk being reused literally by LLMs. Should use enums for predefined modes and let the agent compose custom prompts.
Tool composition unclear. All tools accept generic 'prompt' parameters. No guidance on whether an agent should use analyze_image then compare_images, or if compare_images subsumes analyze_image functionality. Tools lack dependency hints.
Add composition guidance in descriptions. Example: 'compare_images subsumes single-image analysis for multi-image tasks. For comparing 2+ images, use compare_images. For a single image, use analyze_image. For object detection, use detect_objects_in_image.'
Document parameter dependencies and valid ranges. For compare_images.imageSources, state: 'Minimum 2, maximum determined by MAX_IMAGES_FOR_COMPARISON env var (default 4). Supported formats: JPEG, PNG, WebP, GIF. URLs must be publicly accessible or use data: URIs.'
Add parameter validation hints for LLM guidance. For mode parameter, state: 'Choose palette for design token extraction, hierarchy for visual layout analysis, components for UI catalog generation, general for open-ended analysis.'