its-just-mcp provides 9 tools with reasonable naming conventions (verb-first, clear intent) and present but generic descriptions. However, critical gaps emerge in schema completeness, parameter documentation, and error handling. Most tool descriptions are 50-100 characters but lack specificity about WHEN to use each tool or what the return structure is. Input schemas show type definitions and some enums (good), but parameter descriptions are minimal or missing. Output schemas are completely undocumented, the source provides no evidence of what these tools actually return, making it impossible for LLMs to plan downstream operations. Error handling is absent: no guidance on failure modes, recovery paths, or validation errors. The Dockerfile and package.json show production infrastructure but the actual tool implementation lacks the rigor needed for reliable agent integration.
Tools (9)
check_accessibilityread onlysource verified57/100
Get accessibility features and ARIA attributes for a component
compose_componentsread onlysource verified57/100
Create a composition of multiple its-just-ui components
configure_themeread onlysource verified58/100
Configure theme settings including colors, mode, and typography
create_formread onlysource verified63/100
Generate a form structure using its-just-ui form components
No output schemas documented. The source code provides no specification of what these tools return, no field names, types, or structure. This prevents LLMs from planning chains of tool calls or extracting data reliably.
Parameter descriptions are absent or minimal. Example: 'props' parameter in generate_component has only 'Props to pass to the component', what structure? Required fields? Defaults? The LLM must guess.
Tool descriptions are too generic and lack context about when to use them. 'Generate an its-just-ui component' does not explain: What is the difference from compose_components? When should I call this vs compose_components? What format do I pass for props?
Recommendations
Document output schemas for every tool. For generate_component, specify: {component: string, jsx: string, props: object, children: string, className: string, renderedHtml: string}. For list_components, specify: {components: [{name: string, category: string, description: string}], total: number}.
Expand tool descriptions to 100-200 characters, answering: What does it do? When use it vs similar tools? What does it return? Example: 'Generate JSX code for a single its-just-ui component with specified props, children, and Tailwind styling. Use this to render a single component; use compose_components for multiple components in a layout. Returns executable JSX and component metadata.'
Add detailed parameter descriptions for all object/array parameters. Example for 'props': 'An object containing component-specific properties. Common props include variant (enum: primary|secondary|danger), size (enum: sm|md|lg), disabled (boolean), onClick (function), className (string). See get_component_docs for component-specific props.'
Add error handling documentation in tool descriptions. Example: 'If component name is invalid, returns error with list of available components. Call list_components() first if you do not know the component name.'
Define what the 'values' parameter accepts in generate_tailwind_classes. Provide an enum or schema: spacing: {unit: 'px'|'rem', amount: 1-100}, colors: {name: string, hex: string}, typography: {fontSize: number, fontWeight: 100-900}, etc.
No error handling or recovery guidance. If a component name is invalid, the tool has no documented error response, no actionable guidance for the LLM (e.g. 'call list_components first'), and no validation examples.
'children' parameter in generate_component and compose_components is underspecified. Does it accept strings, JSX, or React components? Is it required or optional? The description alone cannot resolve this.
No pagination or result limits documented. 'list_components' returns all components, if the library grows to 100+ components, this response will bloat the context window. No limit, no pagination parameters, no guidance.
The 'values' parameter in generate_tailwind_classes is an untyped object. No schema for what keys it accepts, what values are valid, or what the field controls. LLM must infer from context.
No documentation of composition dependencies or chaining. If an LLM calls generate_component and then wants to wrap it in a layout, there is no documented way to reference the generated component in subsequent calls. Tool IDs or names are not returned or chained.
generate_componentcreate_responsive_layout
Document the relationship between generate_component and compose_components in both descriptions. Make it clear: generate_component makes one component; compose_components nests multiple components. Specify if generated component refs can be passed to compose_components.
Add constraint descriptions for enums. For example, 'mode: Light theme (light), dark theme (dark), or system default (system). Affects all component colors and backgrounds.'
Include a recovery example in descriptions for tools that do lookups. For get_component_docs: 'If component not found, the error will list available components. Suggest the closest match to the user or call list_components to browse all options.'
Clarify what 'children' accepts in generate_component and compose_components. Example: 'children (string): Text or HTML content to render inside the component. For complex structures, use compose_components instead of nesting children strings.'
Add examples in tool descriptions showing how outputs chain. Example: 'generate_component returns a componentId; use this with compose_components to nest it in a layout, or with configure_theme to override its theme.'
Document idempotency for generate_component, configure_theme, and create_form. If called multiple times with the same input, do they return identical output? Are side effects idempotent?