Skip to main content
Glama

design_component

Analyze user requirements and generate block-based component designs for Vue, React, and Angular. Breaks complex needs into manageable steps, supporting updates and detailed project generation.

Instructions

Analyze user requirements and develop a block-based design strategy. Use this when users ask to 'design component', 'create component', or 'component design'. For complex needs, it breaks down into multiple blocks with step-by-step guidance.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
componentNoExisting component information (optional, for updates)
promptYesUser business requirements or design description

Implementation Reference

  • Main handler function that executes the design_component tool logic: validates args, generates smart design strategy, determines next action, builds response content.
    export async function designComponentTool(args: any): Promise<ToolResponse> {
      try {
        const validatedArgs = validateAndNormalizeArgs(args);
        const request = buildDesignRequest(validatedArgs);
    
        // Use smart design strategy
        const designStrategy = await generateSmartDesignStrategy(request);
    
        const nextAction = generateNextAction(designStrategy, validatedArgs);
        const content = buildResponseContent(designStrategy, nextAction);
    
        return { content };
      } catch (error) {
        return buildErrorResponse(error);
      }
    }
  • TypeScript interface defining input arguments for the tool.
    interface DesignComponentArgs {
      prompt: Prompt[];
      rules?: any[];
      component?: {
        id: string;
        name: string;
        code: string;
      };
    }
  • MCP tool registration in listTools handler: defines name 'design_component', description, and input schema.
      name: 'design_component',
      description:
        "Analyze user requirements and develop a block-based design strategy. Use this when users ask to 'design component', 'create component', or 'component design'. For complex needs, it breaks down into multiple blocks with step-by-step guidance.",
      inputSchema: {
        type: 'object',
        properties: {
          prompt: {
            type: 'array',
            description: 'User business requirements or design description',
            items: {
              type: 'object',
              properties: {
                type: { type: 'string', enum: ['text', 'image'] },
                text: { type: 'string' },
                image: { type: 'string' },
              },
              required: ['type'],
            },
          },
          component: {
            type: 'object',
            description:
              'Existing component information (optional, for updates)',
            properties: {
              id: { type: 'string' },
              name: { type: 'string' },
              code: { type: 'string' },
            },
          },
        },
        required: ['prompt'],
      },
    },
  • Dispatch handler in callToolRequest that maps 'design_component' to designComponentTool execution.
    case 'design_component':
      return await designComponentTool(args);
  • Helper function to validate and normalize input arguments.
    function validateAndNormalizeArgs(args: any): DesignComponentArgs {
      if (!args || !Array.isArray(args.prompt)) {
        throw new Error('Missing required parameter: prompt is required');
      }
    
      return {
        prompt: args.prompt,
        rules: Array.isArray(args.rules) ? args.rules : [],
        component: args.component,
      };
    }
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries full burden. It discloses that the tool 'breaks down into multiple blocks with step-by-step guidance' for complex needs, which adds behavioral context beyond basic functionality. However, it doesn't cover aspects like permissions, rate limits, or what constitutes 'complex needs', leaving gaps for a mutation-like tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise and front-loaded, with two sentences that efficiently convey purpose and usage. Every sentence adds value: the first states the core function, and the second provides usage triggers and behavioral nuance. No wasted words, though it could be slightly more structured.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no annotations and no output schema, the description is moderately complete. It covers purpose and usage well but lacks details on behavioral traits (e.g., error handling, output format) and doesn't fully compensate for the absence of structured data. Adequate for a tool with 2 parameters but with clear gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents both parameters ('prompt' and 'component') thoroughly. The description doesn't add any parameter-specific details beyond what's in the schema, such as explaining the 'block-based' strategy in relation to inputs. Baseline 3 is appropriate when schema does the heavy lifting.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: 'Analyze user requirements and develop a block-based design strategy.' This specifies the verb ('analyze' and 'develop') and resource ('design strategy'), though it doesn't explicitly differentiate from siblings like 'design_block' or 'integrate_design' beyond mentioning 'block-based' approach.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear usage context: 'Use this when users ask to 'design component', 'create component', or 'component design'.' It also mentions handling 'complex needs' with breakdowns, but doesn't specify when to use alternatives like 'design_block' or 'query_component', nor does it provide explicit exclusions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server

Other Tools

Related Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/lyw405/mcp-garendesign'

If you have feedback or need assistance with the MCP directory API, please join our Discord server