This STDIO-only MCP server has only 2 tools with minimal complexity. Both tools have basic schema definitions and descriptions, but lack critical context for LLM tool selection. The getComponentProps tool accepts a 'name' parameter with a string type but no description of what constitutes valid component names or where components are located. The getTokens tool has no input schema at all (empty input object). Descriptions are functional but generic (103 chars and 85 chars respectively), well below the 194-char baseline for A-tier tools. Neither tool documents output structure for LLM planning. Error handling exists but is minimal: getComponentProps returns isError=true with a text message, while getTokens lacks proper error categorization. The implementation uses ts-morph to parse TypeScript, but this internal complexity is never exposed to the LLM, it only sees the end result as JSON text. No pagination, no field constraints, no guidance on when to call which tool. Tool composition is straightforward (two independent read-only tools), but the interface does not match user intent patterns from the rubric (e.g., 'I want to see what props Button accepts' would need an intermediate lookup, since the tool requires a hardcoded filename format). STDIO transport caps the protocol readiness score at 50 regardless of other factors.

• Add a full schema to getTokens: 'server.tool('getTokens', {}, async () => {...})' should explicitly define the input schema, even if empty, using Zod (e.g., 'z.object({})').
• Expand getComponentProps description to 150 - 200 chars: 'Retrieves the TypeScript Props interface of a design system component (e.g., Button, Text). Accepts component name without path or extension. Returns prop names, types, and JSDoc annotations to help generate component examples or documentation.'
• Expand getTokens description: 'Loads all design tokens (colors, spacing, typography) from JSON. Returns an array of token objects. Call this first if you need to know available design values, or before getComponentProps if you want to show token usage in component examples.'
• Add parameter description for 'name': 'Component name without file extension (e.g., "Button", "Text"). Matching is case-sensitive. Must correspond to a .tsx file in the design-system/ui/ directory.'
• Document output schemas as part of tool descriptions: 'Returns: {name: string, props: [{name: string, type: string, description?: string}]}' for getComponentProps; 'Returns: array of token objects, structure depends on JSON files in design-system/tokens/' for getTokens.
• Add a third 'listComponents' tool that returns available component names, enabling discovery without hardcoding or guessing.
• Enhance error messages: instead of 'Component Button not found', return 'Component "Button" not found in design-system/ui/. Available components: Text, Label, Input.' This enables the LLM to self-correct.