Skip to main content
Glama
lyw405

mcp-garendesign

by lyw405
OverviewSchemaSourceRelated ServersScoreDiscussionsAdmin
TypeScript

🚀 GarenCode Design - AI驱动的智能组件设计平台

Version Status License AI Powered

🎯 从需求到代码，AI驱动的智能设计流水线
⚡ 让每个开发者都能成为组件设计大师

📋 目录导航

Related MCP server: MCP UI Glue Code Generator

🌟 项目介绍

🎯 核心理念

GarenCode Design 是一个基于 MCP (Model Context Protocol) 的 AI 驱动组件设计平台。我们致力于让每个开发者都能轻松创建高质量的前端组件，从需求分析到代码生成，全程智能化。

✨ 核心特性

🏆 技术优势

  • 🚀 开发效率提升 50%+ - 从需求到代码的自动化流水线

  • 🎯 设计一致性 - 统一的组件库和设计规范

  • 🔧 高度可维护 - 标准化的代码结构和API设计

  • ⚡ 多模型支持 - Claude、GPT、DeepSeek、Ollama 等主流AI模型

🎨 设计流程

🔄 核心工作流

graph LR
    A[🎤 用户需求] --> B[🔍 需求分析]
    B --> C[🧩 组件分解]
    C --> D[🎨 设计策略]
    D --> E[⚡ 代码生成]
    E --> F[🔗 模块集成]
    F --> G[🚀 最终交付]

    style A fill:#ff6b6b,stroke:#333,stroke-width:3px
    style B fill:#4ecdc4,stroke:#333,stroke-width:3px
    style C fill:#45b7d1,stroke:#333,stroke-width:3px
    style D fill:#96ceb4,stroke:#333,stroke-width:3px
    style E fill:#feca57,stroke:#333,stroke-width:3px
    style F fill:#ff9ff3,stroke:#333,stroke-width:3px
    style G fill:#5f27cd,stroke:#333,stroke-width:3px

📝 详细流程说明

1️⃣ 需求分析阶段 🔍

// AI 智能分析用户需求
const analysis = await analyzeRequirement({
  userInput: '创建一个用户管理页面',
  context: '企业级后台管理系统',
  constraints: ['Vue 3', 'TypeScript', '私有组件库'],
});

2️⃣ 复杂度评估 📊

// 自动评估组件复杂度
const complexity = await assessComplexity({
  requirements: analysis.requirements,
  businessLogic: analysis.businessLogic,
  uiComplexity: analysis.uiComplexity,
});
// 输出: { level: "complex", estimatedBlocks: 5, estimatedTokens: 8000 }

3️⃣ 智能分解 🧩

// 将复杂需求分解为可管理的设计块
const blocks = await decomposeToBlocks({
  requirements: analysis.requirements,
  complexity: complexity,
  designStrategy: 'block-based',
});
// 输出: [
//   { id: "user-list", type: "data-display", priority: "high" },
//   { id: "user-form", type: "form", priority: "medium" },
//   { id: "user-detail", type: "detail-view", priority: "low" }
// ]

4️⃣ 设计策略生成 🎨

// 生成详细的设计策略
const strategy = await generateDesignStrategy({
  blocks: blocks,
  componentLibrary: 'private-components',
  designSystem: 'garen-design-system',
});

5️⃣ 分块开发 ⚡

// 逐个设计块进行开发
for (const block of blocks) {
  const design = await designBlock({
    block: block,
    strategy: strategy,
    aiModel: getRecommendedModel('DESIGN'),
  });

  const code = await generateCode({
    design: design,
    framework: 'vue3',
    typescript: true,
  });
}

6️⃣ 智能集成 🔗

// 将所有设计块集成到完整页面
const integration = await integrateDesign({
  blocks: completedBlocks,
  layout: 'responsive',
  dataFlow: 'centralized',
});

⚙️ 项目配置

📁 配置文件结构

data/
├── config.json              # 🎯 AI模型配置（实际使用）
├── config.example.json      # 📝 AI配置示例（去除敏感信息）
├── codegens.json            # 🧩 私有组件库配置（实际使用）
└── codegens.example.json    # 📚 组件库配置示例

🔑 AI模型配置

1. 复制配置文件

# 复制示例配置文件
cp data/config.example.json data/config.json
cp data/codegens.example.json data/codegens.json

2. 配置AI提供商

编辑 data/config.json：

{
  "defaultModels": {
    "ANALYSIS": "claude-3-7-sonnet-latest",
    "DESIGN": "claude-3-5-sonnet-latest",
    "QUERY": "claude-3-5-sonnet-latest",
    "INTEGRATION": "claude-3-7-sonnet-latest"
  },
  "providers": [
    {
      "provider": "anthropic",
      "models": [
        {
          "model": "claude-3-5-sonnet-latest",
          "title": "Claude 3.5 Sonnet",
          "baseURL": "https://api.302.ai/v1",
          "features": ["reasoning", "creativity"],
          "apiKey": "sk-your-anthropic-api-key-here"
        }
      ]
    },
    {
      "provider": "openai",
      "models": [
        {
          "model": "gpt-4o",
          "title": "GPT-4o",
          "baseURL": "https://api.openai.com/v1",
          "features": ["vision", "reasoning", "creativity"],
          "apiKey": "sk-your-openai-api-key-here"
        }
      ]
    }
  ]
}

3. 支持的AI提供商

4. 验证配置

# 验证AI配置
node scripts/validate-config.js

# 测试模型连接
node scripts/test-model-recommendation.js

🧩 私有组件库配置

data/codegens.json 包含了完整的私有组件库配置：

[
  {
    "title": "Private Component Codegen",
    "description": "基于私有组件的代码生成器",
    "fullStack": "Vue",
    "rules": [
      {
        "type": "private-components",
        "description": "私有组件使用规则",
        "docs": {
          "组件名称": {
            "purpose": "使用目的",
            "usage": "项目中经常使用的场景描述",
            "props": {
              // props 参数相关
              "type": "",
              "size": ""
              ...
            }
          }
        }
      }
    ]
  }
]

🔧 IDE 集成

📝 MCP 配置文件

创建 mcp-config.json 文件：

{
  "mcpServers": {
    "garencode-design": {
      "command": "/bin/zsh",
      "args": ["-c", "cd /path/to/your/project && npm run mcp:dev"]
    }
  }
}

🎯 使用方式

1. 在 Cursor 中使用

// 在 Cursor 中调用 MCP 工具
const result = await mcp.callTool({
  name: 'design_component',
  arguments: {
    prompt: [
      {
        type: 'text',
        text: '创建一个用户管理页面，包含用户列表、搜索、新增/编辑功能',
      },
    ],
  },
});

2. 在 VS Code 中使用

// settings.json
{
  "mcp.servers": {
    "garencode-design": {
      "command": "node",
      "args": ["dist/mcp-server.js"],
      "cwd": "/path/to/garencode-design"
    }
  }
}

🚀 快速开始

1️⃣ 环境准备

# 克隆项目
git clone https://github.com/lyw405/mcp-garendesign.git
cd mcp-garendesign

# 安装依赖
npm install
# 或使用 pnpm
pnpm install

2️⃣ 配置设置

# 复制配置文件
cp data/config.example.json data/config.json
cp data/codegens.example.json data/codegens.json

# 编辑配置文件，填入您的API密钥
vim data/config.json

3️⃣ 启动服务

# 使用启动脚本
chmod +x scripts/start-standalone.sh
./scripts/start-standalone.sh

# 或手动启动
npm run build
npm run mcp:dev

4️⃣ 验证安装

# 验证配置
node scripts/validate-config.js

# 测试模型推荐
node scripts/test-model-recommendation.js

📚 使用指南

🎨 组件设计工具

design_component

设计前端组件：

{
  "name": "design_component",
  "arguments": {
    "prompt": [
      {
        "type": "text",
        "text": "创建一个产品卡片组件，包含图片、标题、价格和购买按钮"
      }
    ]
  }
}

design_block

设计复杂页面的单个块：

{
  "name": "design_block",
  "arguments": {
    "prompt": [
      {
        "type": "text",
        "text": "设计用户列表管理块，包含表格、搜索、分页功能"
      }
    ]
  }
}

query_component

查询组件详细信息：

{
  "name": "query_component",
  "arguments": {
    "componentName": "das-button"
  }
}

🔄 完整工作流示例

import { MCPClient } from '@modelcontextprotocol/sdk/client';

const client = new MCPClient({
  name: 'GarenCode Design Client',
  version: '1.0.0',
});

// 连接服务
await client.connect({
  type: 'stdio',
  command: 'tsx',
  args: ['src/mcp-server.ts'],
});

// 设计组件
const result = await client.callTool({
  name: 'design_component',
  arguments: {
    prompt: [
      {
        type: 'text',
        text: '创建一个登录表单组件，包含用户名、密码输入框和登录按钮',
      },
    ],
  },
});

console.log('🎉 组件设计完成:', result);

🔮 未来计划

🎯 当前能力

✅ 私有组件复用 - 完整的私有组件库支持
✅ 智能设计流程 - AI驱动的组件设计
✅ 多模型支持 - Claude、GPT、DeepSeek、Ollama
✅ 类型安全 - 完整的 TypeScript 支持
✅ 配置管理 - 灵活的AI模型配置

🚀 即将推出

1️⃣ 私有状态管理 🔄

// 未来功能：自动状态管理
const stateConfig = {
  globalState: {
    user: 'UserState',
    theme: 'ThemeState',
    language: 'LanguageState',
  },
  localState: {
    form: 'FormState',
    modal: 'ModalState',
  },
};

// AI 自动生成状态管理代码
const stateCode = await generateStateManagement({
  components: designedComponents,
  stateConfig: stateConfig,
  framework: 'pinia', // 或 vuex, zustand
});

2️⃣ 全局属性自动化 ⚙️

// 未来功能：全局属性自动注入
const globalProps = {
  theme: 'light | dark',
  language: 'zh-CN | en-US',
  permissions: 'admin | user | guest',
  device: 'desktop | mobile | tablet',
};

// AI 自动为组件注入全局属性
const enhancedComponents = await injectGlobalProps({
  components: designedComponents,
  globalProps: globalProps,
  injectionStrategy: 'automatic',
});

3️⃣ 智能代码优化 🧠

// 未来功能：代码性能优化
const optimization = await optimizeCode({
  components: generatedComponents,
  optimizationTargets: [
    'bundle-size',
    'runtime-performance',
    'memory-usage',
    'accessibility',
  ],
});

4️⃣ 设计系统集成 🎨

// 未来功能：设计系统自动同步
const designSystem = await syncDesignSystem({
  components: designedComponents,
  designTokens: {
    colors: 'design-tokens/colors.json',
    typography: 'design-tokens/typography.json',
    spacing: 'design-tokens/spacing.json',
  },
  syncStrategy: 'real-time',
});

📅 开发路线图

🏗️ 项目架构

📁 目录结构

mcp-garendesign/
├── 📁 src/
│   ├── 🚀 mcp-server.ts          # MCP 服务器入口
│   ├── 🛠️ tools/                 # MCP 工具实现
│   │   ├── design/
│   │   │   ├── component.ts      # 组件设计工具
│   │   │   └── block.ts          # 块设计工具
│   │   └── query/
│   │       └── component.ts      # 组件查询工具
│   ├── 🧠 core/                  # 核心业务逻辑
│   │   ├── design/               # 设计引擎
│   │   │   ├── complexity-analyzer.ts
│   │   │   ├── strategy/
│   │   │   ├── blocks/
│   │   │   └── integration/
│   │   └── query/                # 查询引擎
│   ├── ⚙️ config/                # 配置管理
│   │   ├── ai-client-adapter.ts  # AI 客户端适配器
│   │   ├── model-manager.ts      # 模型管理器
│   │   ├── config-validator.ts   # 配置验证器
│   │   └── types.ts              # 配置类型定义
│   ├── 🎨 utils/                 # 工具函数
│   │   └── formatters/           # 格式化工具
│   ├── 📚 resources/             # MCP 资源
│   └── 🏷️ types/                 # 类型定义
├── 📁 data/                      # 配置文件
│   ├── config.json               # AI 模型配置
│   ├── config.example.json       # 配置示例
│   ├── codegens.json             # 私有组件库配置
│   └── codegens.example.json     # 组件库配置示例
├── 📁 scripts/                   # 脚本文件
├── 📁 docs/                      # 文档
└── 📄 package.json

🔧 添加新工具

  1. 创建工具文件

// src/tools/design/new-tool.ts
export async function newTool(args: NewToolArgs): Promise<ToolResult> {
  // 工具实现逻辑
  return {
    content: [
      {
        type: 'text',
        text: '工具执行结果',
      },
    ],
  };
}

  1. 注册工具

// src/mcp-server.ts
import { newTool } from './tools/design/new-tool.js';

// 在工具列表中注册
tools: [
  // ... 其他工具
  {
    name: 'new_tool',
    description: '新工具描述',
    inputSchema: {
      type: 'object',
      properties: {
        // 输入参数定义
      },
    },
  },
];

📚 添加新资源

  1. 创建资源函数

// src/resources/index.ts
export function getNewResource() {
  return {
    contents: [
      {
        type: 'text',
        text: '资源内容',
      },
    ],
  };
}

  1. 注册资源

// src/mcp-server.ts
import { getNewResource } from './resources/index.js';

// 在资源列表中注册
resources: [
  // ... 其他资源
  {
    uri: 'garencode://resources/new-resource',
    name: 'new_resource',
    description: '新资源描述',
    mimeType: 'text/plain',
  },
];

🧪 测试

# 运行测试
npm test

# 验证配置
node scripts/validate-config.js

# 测试模型推荐
node scripts/test-model-recommendation.js

🤝 贡献指南

我们欢迎所有形式的贡献！

🐛 报告问题

如果您发现了问题，请 创建 Issue。

💡 提交功能请求

如果您有新功能想法，请 创建 Feature Request。

🔧 提交代码

  1. Fork 项目

  2. 创建功能分支 (git checkout -b feature/amazing-feature)

  3. 提交更改 (git commit -m 'Add amazing feature')

  4. 推送到分支 (git push origin feature/amazing-feature)

  5. 创建 Pull Request

📄 许可证

本项目采用 MIT 许可证。

⚔️ 以盖伦之名，铸就完美设计 ⚔️

🌟 GarenCode Design - 让每个组件都符合心意

GitHub stars GitHub forks GitHub issues

Available Tools

4 tools
design_blockB

Design a specific block. This is the second-stage tool in the block-based design strategy for detailed component design.

ParametersJSON Schema
NameRequiredDescriptionDefault
blockIdYesID of the design block to design
blockInfoNoDetailed information of the block (optional)
integratedContextNoIntegration context (optional): contains the overall strategy and completed block designs to return an updated integrated design snapshot
promptYesSpecific requirement description for the block

TDQS

B3.1/5.0
Behavior2/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 mentions being part of a 'strategy' and 'detailed component design,' but doesn't disclose critical behavioral traits such as whether this is a read or write operation, potential side effects, authentication needs, rate limits, or what the output looks like. For a tool with complex parameters and no annotations, this is a significant gap.

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 with two sentences that are front-loaded with the main purpose. Every sentence adds value by specifying the tool's role in a strategy, though it could be slightly more structured to highlight key usage aspects.

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

Completeness2/5

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

Given the complexity (4 parameters with nested objects), no annotations, and no output schema, the description is incomplete. It lacks details on behavioral traits, output format, and deeper context for usage, making it inadequate for an agent to fully understand how to invoke this tool effectively in a design workflow.

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 all parameters thoroughly. The description adds no specific parameter semantics beyond implying 'blockId' and 'prompt' are key (as required), but doesn't explain their roles or relationships. Baseline 3 is appropriate as the 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 action ('Design') and resource ('a specific block'), and mentions it's part of a 'block-based design strategy for detailed component design.' It distinguishes from siblings by specifying it's the 'second-stage tool' in a strategy, though it doesn't explicitly contrast with sibling tools like 'design_component' or 'integrate_design.'

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

Usage Guidelines3/5

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

The description implies usage context by stating it's the 'second-stage tool in the block-based design strategy,' suggesting it should be used after some initial step. However, it doesn't provide explicit when-to-use guidance, alternatives (e.g., vs. 'design_component'), or exclusions, leaving the agent to infer based on the strategic mention.

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

design_componentA

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.

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

TDQS

A3.6/5.0
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.

integrate_designC

Combine the overall DesignStrategy with completed blockDesigns and return IntegratedDesign (including props summary, private components used, and composition recommendations).

ParametersJSON Schema
NameRequiredDescriptionDefault
blockDesignsYesCompleted block design list: [{ blockId, component }]
strategyYesDesignStrategy object

TDQS

C2.9/5.0
Behavior2/5

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions the tool returns an IntegratedDesign with specific elements (props summary, private components, composition recommendations), which adds some context. However, it doesn't disclose critical behavioral traits such as whether this is a read-only or mutation operation, error handling, performance characteristics, or side effects. For a tool with no annotations, this leaves significant gaps.

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 a single, efficient sentence that front-loads the core purpose. It avoids redundancy and waste, though it could be slightly more structured (e.g., by separating usage notes). Every part of the sentence contributes to understanding the tool's function.

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 the complexity (2 parameters with nested objects, no output schema, no annotations), the description is moderately complete. It specifies the output structure (IntegratedDesign with props summary, private components, recommendations), which partially compensates for the lack of output schema. However, it doesn't fully address behavioral aspects or usage guidelines, leaving room for improvement in guiding an AI agent.

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?

The schema description coverage is 100%, with both parameters (blockDesigns and strategy) well-documented in the input schema. The description adds minimal value beyond the schema: it implies that blockDesigns should be 'completed' and strategy is 'overall', but doesn't provide additional syntax, format details, or constraints. This meets the baseline of 3 when the 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: 'Combine the overall DesignStrategy with completed blockDesigns and return IntegratedDesign'. It specifies the verb ('combine'), resources (DesignStrategy and blockDesigns), and output (IntegratedDesign). However, it doesn't explicitly differentiate from sibling tools like design_block or design_component, which appear to be related design tools.

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., that blockDesigns must be 'completed'), compare it to sibling tools like design_block, or specify scenarios where integration is needed versus creating individual designs. The usage context is implied but not explicitly stated.

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

query_componentC

Query detailed information of a component including documentation, API, and example code. Provide the component name to get all related information.

ParametersJSON Schema
NameRequiredDescriptionDefault
componentNameYesComponent name to query, e.g., 'das-action-more'

TDQS

C2.9/5.0
Behavior2/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool queries information, implying a read-only operation, but doesn't address critical aspects like authentication requirements, rate limits, error handling, or response format. For a tool with zero annotation coverage, this is a significant gap in transparency.

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, consisting of two clear sentences. The first sentence states the purpose, and the second provides basic usage. There's no wasted text, though it could be slightly more informative without losing efficiency.

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

Completeness2/5

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

Given the lack of annotations and output schema, the description is incomplete. It doesn't explain what the return value looks like (e.g., structure of documentation, API details, or example code), nor does it cover behavioral aspects like permissions or errors. For a query tool with no structured support, this leaves the agent under-informed.

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?

The schema description coverage is 100%, with the parameter 'componentName' well-documented in the schema. The description adds minimal value beyond the schema, only reiterating that a component name should be provided. It doesn't explain nuances like naming conventions or examples beyond what's in the schema, so the baseline score of 3 is appropriate.

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: 'Query detailed information of a component including documentation, API, and example code.' It specifies the verb ('query') and resource ('component') with details about what information is retrieved. However, it doesn't explicitly differentiate from sibling tools like 'design_component' or 'integrate_design', which might have overlapping functionality.

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

Usage Guidelines2/5

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

The description provides minimal guidance: 'Provide the component name to get all related information.' It doesn't specify when to use this tool versus alternatives like 'design_component' or 'integrate_design', nor does it mention prerequisites, exclusions, or specific contexts. This lack of comparative guidance leaves the agent uncertain about tool selection.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. 4 tool updatesv1.0.0
    • First observeddesign_block
    • First observeddesign_component
    • First observedintegrate_design
    • First observedquery_component
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

B3.4/5.0
Disambiguation4/5

The tools have distinct primary purposes: design_block for detailed block design, design_component for initial strategy and breakdown, integrate_design for combining designs, and query_component for information retrieval. However, design_block and design_component could be confused as both involve design stages, though their descriptions clarify their sequential roles.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern with snake_case: design_block, design_component, integrate_design, query_component. This uniformity makes the set predictable and easy to understand.

Tool Count5/5

With 4 tools, this server is well-scoped for its component design domain. Each tool serves a clear role in the design workflow, from strategy to integration and querying, without being overly sparse or bloated.

Completeness4/5

The tools cover the core design lifecycle: strategy (design_component), detailed design (design_block), integration (integrate_design), and information lookup (query_component). A minor gap is the lack of update or delete operations for designs, but agents can likely work around this given the focused scope.

Maintenance

ActivityInactive
ResponsivenessNo issues

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Related MCP Servers

  • Frontend Code Analysis MCP

    cmc12138
    A
    license
    Not graded
    quality
    D
    maintenance
    Analyzes frontend project code (React, Vue, Angular) and converts it into AI-understandable flow diagrams and object structures. Provides tools for code analysis, variable/function/component inspection, and project structure insights.
    9
    MIT

  • MCP Frontend Tools Server

    ashios15
    F
    license
    A
    quality
    D
    maintenance
    Provides AI assistants with frontend development tools including component scaffolding, bundle analysis, accessibility checks, and responsive design guidance. Enables automated generation of React components with tests and stories, bundle optimization recommendations, and WCAG compliance fixes.
    6
    -

Appeared in Searches

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