Skip to main content
Glama

explain

Explain code logic and principles to understand how programs work and identify implementation details.

Instructions

【代码解释器】详细解释代码逻辑和原理

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
codeNo需要解释的代码
contextNo上下文信息

Implementation Reference

  • The core handler function for the 'explain' tool. It takes code and context arguments, constructs an elaborate Chinese-language prompt with explanation guidelines and examples (including debounce hook, longest palindrome, singleton), and returns it as MCP-formatted text content for an LLM to generate the explanation.
    export async function explain(args: any) {
      try {
        const code = args?.code || "";
        const context = args?.context || "";
    
        const message = `请详细解释以下代码:
    
    📝 **代码内容**:
    ${code || "请提供需要解释的代码"}
    
    📋 **上下文**:
    ${context || "无"}
    
    ---
    
    ## 代码解释指南
    
    ### 第一步:整体概览
    
    **快速总结**:
    - 这段代码的主要功能是什么?
    - 解决了什么问题?
    - 在项目中的作用?
    
    ### 第二步:逐行解释
    
    **详细分析**:
    - 每一行代码做了什么
    - 为什么这样写
    - 有什么注意事项
    
    ### 第三步:深入理解
    
    **核心概念**:
    - 使用的设计模式
    - 关键技术原理
    - 性能考虑
    - 潜在问题
    
    ---
    
    ## 解释示例
    
    ### 示例 1:React Hooks
    
    \`\`\`typescript
    function useDebounce<T>(value: T, delay: number): T {
      const [debouncedValue, setDebouncedValue] = useState<T>(value);
    
      useEffect(() => {
        const handler = setTimeout(() => {
          setDebouncedValue(value);
        }, delay);
    
        return () => {
          clearTimeout(handler);
        };
      }, [value, delay]);
    
      return debouncedValue;
    }
    \`\`\`
    
    **🎯 整体功能**:
    这是一个防抖 Hook,用于延迟更新值。常用于搜索输入,避免频繁触发 API 请求。
    
    **📖 逐行解释**:
    
    1. **函数签名**
    \`\`\`typescript
    function useDebounce<T>(value: T, delay: number): T
    \`\`\`
    - 泛型 \`<T>\` 表示可以处理任意类型的值
    - 接收两个参数:\`value\`(要防抖的值)和 \`delay\`(延迟毫秒数)
    - 返回类型也是 \`T\`,确保类型一致
    
    2. **状态管理**
    \`\`\`typescript
    const [debouncedValue, setDebouncedValue] = useState<T>(value);
    \`\`\`
    - 使用 \`useState\` 创建一个内部状态
    - 初始值设为传入的 \`value\`
    - 这个状态会在延迟后更新
    
    3. **副作用处理**
    \`\`\`typescript
    useEffect(() => {
      const handler = setTimeout(() => {
        setDebouncedValue(value);
      }, delay);
    
      return () => {
        clearTimeout(handler);
      };
    }, [value, delay]);
    \`\`\`
    - 当 \`value\` 或 \`delay\` 改变时,触发 effect
    - 创建一个定时器,\`delay\` 毫秒后更新 \`debouncedValue\`
    - **清理函数**:组件卸载或依赖变化时,清除旧的定时器(关键!)
    - 这样可以避免内存泄漏和意外的状态更新
    
    4. **返回值**
    \`\`\`typescript
    return debouncedValue;
    \`\`\`
    - 返回延迟后的值
    
    **💡 工作原理**:
    
    \`\`\`
    用户输入 h  → 创建定时器(500ms 后更新)
    用户输入 he → 清除旧定时器,创建新定时器
    用户输入 hel → 清除旧定时器,创建新定时器
    用户停止输入 → 500ms 后,debouncedValue 更新为 hel
    \`\`\`
    
    **🎨 设计模式**:
    - **装饰器模式**:为普通值添加防抖功能
    - **闭包**:定时器 ID 保存在 effect 作用域中
    
    **⚠️ 注意事项**:
    1. 每次 \`value\` 改变都会重置定时器
    2. 组件卸载时会清理定时器,防止内存泄漏
    3. \`delay\` 变化也会触发重新计时
    
    **💻 使用场景**:
    \`\`\`typescript
    function SearchComponent() {
      const [searchTerm, setSearchTerm] = useState('');
      const debouncedSearchTerm = useDebounce(searchTerm, 500);
    
      useEffect(() => {
        if (debouncedSearchTerm) {
          // 只有在用户停止输入 500ms 后才发起请求
          fetchSearchResults(debouncedSearchTerm);
        }
      }, [debouncedSearchTerm]);
    
      return (
        <input
          value={searchTerm}
          onChange={(e) => setSearchTerm(e.target.value)}
          placeholder="搜索..."
        />
      );
    }
    \`\`\`
    
    ---
    
    ### 示例 2:复杂算法
    
    \`\`\`typescript
    function longestPalindrome(s: string): string {
      if (s.length < 2) return s;
      
      let start = 0;
      let maxLen = 1;
      
      function expandAroundCenter(left: number, right: number): void {
        while (left >= 0 && right < s.length && s[left] === s[right]) {
          const len = right - left + 1;
          if (len > maxLen) {
            start = left;
            maxLen = len;
          }
          left--;
          right++;
        }
      }
      
      for (let i = 0; i < s.length; i++) {
        expandAroundCenter(i, i);     // 奇数长度回文
        expandAroundCenter(i, i + 1); // 偶数长度回文
      }
      
      return s.substring(start, start + maxLen);
    }
    \`\`\`
    
    **🎯 整体功能**:
    找出字符串中最长的回文子串(如 "babad" → "bab" 或 "aba")。
    
    **📖 核心思想**:
    
    **中心扩展法**:
    1. 遍历每个字符作为潜在的回文中心
    2. 从中心向两边扩展,检查是否对称
    3. 记录最长的回文串
    
    **📊 时间复杂度**:O(n²)
    **📊 空间复杂度**:O(1)
    
    **🔍 详细分析**:
    
    1. **边界处理**
    \`\`\`typescript
    if (s.length < 2) return s;
    \`\`\`
    - 长度 0 或 1 的字符串本身就是回文
    
    2. **状态变量**
    \`\`\`typescript
    let start = 0;   // 最长回文的起始位置
    let maxLen = 1;  // 最长回文的长度
    \`\`\`
    
    3. **扩展函数**
    \`\`\`typescript
    function expandAroundCenter(left: number, right: number): void {
      while (left >= 0 && right < s.length && s[left] === s[right]) {
        // 条件:不越界 && 两边字符相同
        const len = right - left + 1;
        if (len > maxLen) {
          start = left;
          maxLen = len;
        }
        left--;
        right++;
      }
    }
    \`\`\`
    - 从中心向两边扩展
    - 遇到不匹配或越界时停止
    - 更新全局最长记录
    
    4. **遍历所有中心**
    \`\`\`typescript
    for (let i = 0; i < s.length; i++) {
      expandAroundCenter(i, i);     // 奇数:中心是一个字符
      expandAroundCenter(i, i + 1); // 偶数:中心是两个字符之间
    }
    \`\`\`
    
    **💡 为什么要检查两次?**
    
    \`\`\`
    奇数长度:aba   中心是 b     (i, i)
    偶数长度:abba  中心是 bb    (i, i+1)
    \`\`\`
    
    **🎨 其他解法对比**:
    
    | 方法 | 时间复杂度 | 空间复杂度 | 说明 |
    |------|------------|------------|------|
    | 暴力枚举 | O(n³) | O(1) | 太慢 |
    | 中心扩展 | O(n²) | O(1) | 本方法 |
    | 动态规划 | O(n²) | O(n²) | 需要额外空间 |
    | Manacher | O(n) | O(n) | 最优,但复杂 |
    
    ---
    
    ### 示例 3:设计模式
    
    \`\`\`typescript
    class Singleton {
      private static instance: Singleton;
      private constructor() {}
      
      public static getInstance(): Singleton {
        if (!Singleton.instance) {
          Singleton.instance = new Singleton();
        }
        return Singleton.instance;
      }
    }
    \`\`\`
    
    **🎯 设计模式**:单例模式(Singleton)
    
    **📖 核心思想**:
    确保一个类只有一个实例,并提供全局访问点。
    
    **🔍 实现细节**:
    
    1. **私有构造函数**
    \`\`\`typescript
    private constructor() {}
    \`\`\`
    - 阻止外部直接 \`new Singleton()\`
    
    2. **静态实例变量**
    \`\`\`typescript
    private static instance: Singleton;
    \`\`\`
    - 保存唯一实例
    
    3. **懒加载**
    \`\`\`typescript
    public static getInstance(): Singleton {
      if (!Singleton.instance) {
        Singleton.instance = new Singleton();
      }
      return Singleton.instance;
    }
    \`\`\`
    - 第一次调用时才创建实例
    - 后续调用返回同一个实例
    
    **💻 使用场景**:
    - 数据库连接池
    - 配置管理器
    - 日志记录器
    
    **⚠️ TypeScript 现代替代**:
    \`\`\`typescript
    // 使用模块单例(更简单)
    export const config = {
      apiUrl: 'https://api.example.com',
      timeout: 5000,
    };
    \`\`\`
    
    ---
    
    ## 解释框架
    
    对于任何代码,按以下结构解释:
    
    ### 1. 概述(30 秒理解)
    - 一句话总结功能
    - 主要用途
    
    ### 2. 工作原理(5 分钟理解)
    - 核心逻辑
    - 数据流向
    - 关键步骤
    
    ### 3. 技术细节(深入理解)
    - 设计模式
    - 算法原理
    - 性能分析
    - 边界情况
    
    ### 4. 实际应用
    - 使用示例
    - 最佳实践
    - 常见陷阱
    
    ---
    
    现在请为提供的代码生成详细解释,包括:
    1. 整体功能概述
    2. 逐行代码说明
    3. 核心原理分析
    4. 设计模式识别
    5. 使用场景和注意事项`;
    
        return {
          content: [
            {
              type: "text",
              text: message,
            },
          ],
        };
      } catch (error) {
        const errorMessage =
          error instanceof Error ? error.message : String(error);
        return {
          content: [
            {
              type: "text",
              text: `❌ 代码解释失败: ${errorMessage}`,
            },
          ],
          isError: true,
        };
      }
    }
  • The input schema definition for the 'explain' tool, specifying parameters 'code' (string) and 'context' (string), both optional.
    {
      name: "explain",
      description: "【代码解释器】详细解释代码逻辑和原理",
      inputSchema: {
        type: "object",
        properties: {
          code: {
            type: "string",
            description: "需要解释的代码",
          },
          context: {
            type: "string",
            description: "上下文信息",
          },
        },
        required: [],
      },
    },
  • src/index.ts:513-515 (registration)
    The registration/dispatch handler in the main switch statement that calls the explain function when the tool 'explain' is invoked.
    case "explain":
      return await explain(args);
  • Re-export of the explain handler from its implementation file for use in the main index.
    export { explain } from "./explain.js";
  • src/index.ts:13-15 (registration)
    Import of the explain function from tools/index.js into the main server file.
      codeReview, gentest, genpr, checkDeps, gendoc, genchangelog, refactor, perf,
      fix, gensql, resolveConflict, genui, explain, convert, genreadme, split, analyzeProject
    } from "./tools/index.js";
Behavior2/5

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

With no annotations provided, the description carries full burden for behavioral disclosure. While it states the tool provides detailed explanations of code logic and principles, it doesn't disclose important behavioral traits: whether this is a read-only operation, what format the explanation returns (text, structured analysis, examples), whether it handles specific programming languages, or if there are limitations on code length/complexity. For a tool with zero annotation coverage, this represents significant gaps in behavioral transparency.

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

Conciseness5/5

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

The description is extremely concise with just one Chinese sentence containing 9 characters. It's front-loaded with the core purpose and wastes no words. Every character earns its place by conveying the essential function without unnecessary elaboration.

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 tool's complexity (explaining code logic and principles), lack of annotations, and absence of an output schema, the description is insufficiently complete. It doesn't explain what the tool returns, how comprehensive the explanations are, whether it includes examples, or what limitations exist. For a tool that presumably generates explanatory content, the description should provide more context about the output format and scope.

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 ('code' and 'context') having clear descriptions in the schema. The tool description adds no additional parameter semantics beyond what's already documented in the schema. According to scoring rules, when schema_description_coverage is high (>80%), the baseline is 3 even with no parameter information in the description, which applies here.

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 with a specific verb ('详细解释' - detailed explanation) and resource ('代码逻辑和原理' - code logic and principles). It distinguishes itself from siblings like 'debug', 'refactor', or 'code_review' by focusing on explanation rather than fixing, restructuring, or reviewing. However, it doesn't explicitly differentiate from tools like 'analyze_project' or 'gendoc' which might also involve explanation aspects.

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. With 21 sibling tools including 'debug', 'refactor', 'code_review', 'analyze_project', and 'gendoc', there's significant potential for overlap, but the description offers no explicit when/when-not instructions or alternative recommendations. The agent must infer usage context from the tool name and description alone.

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

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/mybolide/mcp-probe-kit'

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