shade-mcp demonstrates competent tool engineering with consistent schema definitions and reasonable descriptions across 18 tools. However, significant gaps in error handling guidance, parameter validation documentation, and LLM-optimized descriptions prevent a higher score. All tools have JSON Schema input definitions with types and descriptions, which is the baseline for competence. Most tools are READ_ONLY with clear names following verb_noun pattern (compile, render, describe, benchmark, test, search, analyze, list, generate). Tool descriptions average ~140 chars, which is acceptable but could be more specific about WHEN to call each tool vs. alternatives. Parameter descriptions exist but often lack actionable constraint guidance (e.g., uniform values are documented as 'object' with no format hints). Output schemas are not explicitly documented in the source provided, and error handling directions are minimal, tools return generic JSON but offer little recovery guidance. The server architecture is well-organized (tools split into browser/, analysis/, knowledge/, utility/ modules), suggesting deliberate design, but this doesn't translate to visible schema documentation or error classification.
Uses AI to analyze branching complexity and performance implications in shader code
Uses AI to provide detailed analysis of an effect's purpose, technique, and implementation
Measures the frame rate of a shader effect under sustained rendering
Uses AI to verify mathematical equivalence between two shader algorithms
Validates the structure and configuration of an effect definition
Analyzes differences between two shader implementations
Compiles a shader effect to verify syntax and detect errors
Output schemas not documented in source. Tools return JSON but the structure of results (fields, types, pagination info) is not visible. LLMs cannot plan multi-step workflows or extract chaining IDs without explicit response schemas.
Error handling lacks recovery guidance. tool-result.ts wraps payloads as JSON with optional isError flag, but does not classify errors (retryable vs user-fixable vs fatal) or provide actionable next steps. LLMs receive 'error: true' with no hint about what to do.
Parameter constraint documentation is incomplete. 'backend' enum is clear, but 'uniforms' accepts an arbitrary object with no format guidance. 'limit' parameter in search tools has no min/max bounds specified. LLMs may pass invalid or extreme values.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 54 | 2026-07-28+ | v2 |
Analyzes a rendered frame using AI to describe visual content and detect anomalies
Generates a manifest document describing all effects and their capabilities
Lists all available shader effects, optionally filtered by namespace
Renders a single frame of a shader effect and returns pixel data
Executes a domain-specific language program for effect configuration and manipulation
Searches the effect library by name, description, tags, or content similarity
Searches knowledge base for shader techniques, patterns, and best practices
Searches shader source files by pattern or keyword to locate implementations
Verifies that the effect does not pass through unmodified input
Compares pixel output between two shader backends for consistency
Verifies that shader uniforms properly affect the rendered output
No pagination parameters visible for list/search tools. searchEffects and searchShaderKnowledge accept 'limit' but no 'offset', 'page', or 'cursor'. Large result sets risk blowing context windows without explicit pagination support.
runDslProgram accepts arbitrary 'program' source code with no validation hints or safety boundaries documented. If this allows arbitrary code execution, it poses a security risk. If it's sandboxed, that should be explicit.
Descriptions for analysis tools (checkAlgEquiv, analyzeBranching, compareShaders) are brief (~60 chars) and lack context on WHY an LLM would call them or HOW they differ from related tools. No guidance on when to use checkAlgEquiv vs compareShaders.