Skip to main content
Glama

gendoc

Generate detailed JSDoc/TSDoc comments for code to improve documentation and maintainability. Supports multiple comment styles and languages.

Instructions

【生成注释】为代码生成详细的 JSDoc/TSDoc 注释

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
codeNo需要生成注释的代码
styleNo注释风格:jsdoc, tsdoc, javadoc(默认 jsdoc)
langNo语言:zh, en(默认 zh)

Implementation Reference

  • The core handler function for the 'gendoc' tool. It constructs a comprehensive prompt message including code, style, language preferences, detailed templates for JSDoc/TSDoc comments, guidelines, and quality standards, then returns it as MCP content for LLM processing.
    export async function gendoc(args: any) {
      try {
        const code = args?.code || "";
        const style = args?.style || "jsdoc"; // jsdoc, tsdoc, javadoc
        const lang = args?.lang || "zh"; // zh, en
    
        const message = `请为以下代码生成详细的注释文档:
    
    📝 **代码内容**:
    ${code || "请提供需要生成注释的代码"}
    
    📖 **注释风格**:${style}
    🌐 **语言**:${lang === "zh" ? "中文" : "English"}
    
    ---
    
    ## 注释生成指南
    
    ### JSDoc/TSDoc 格式
    
    **函数注释模板**:
    \`\`\`typescript
    /**
     * 函数简短描述(一句话)
     * 
     * 详细描述功能、用途、使用场景(可选,多行)
     * 
     * @param {类型} 参数名 - 参数描述
     * @param {类型} 参数名 - 参数描述
     * @returns {类型} 返回值描述
     * @throws {ErrorType} 抛出异常的情况
     * 
     * @example
     * // 使用示例
     * const result = functionName(arg1, arg2);
     * console.log(result); // 输出: ...
     * 
     * @see 相关函数或文档链接
     * @since 1.0.0
     * @deprecated 使用 newFunction 替代(如果已废弃)
     */
    function functionName(param1, param2) {
      // ...
    }
    \`\`\`
    
    **类注释模板**:
    \`\`\`typescript
    /**
     * 类简短描述
     * 
     * 详细描述类的职责、使用场景
     * 
     * @class
     * @example
     * const instance = new ClassName(param);
     * instance.method();
     */
    class ClassName {
      /**
       * 构造函数描述
       * @param {类型} param - 参数描述
       */
      constructor(param) {}
      
      /**
       * 方法描述
       * @returns {类型} 返回值描述
       */
      method() {}
    }
    \`\`\`
    
    **接口注释模板**:
    \`\`\`typescript
    /**
     * 接口描述
     * 
     * @interface
     */
    interface InterfaceName {
      /** 属性描述 */
      property: string;
      
      /**
       * 方法描述
       * @param {类型} param - 参数描述
       * @returns {类型} 返回值描述
       */
      method(param: string): void;
    }
    \`\`\`
    
    **类型注释模板**:
    \`\`\`typescript
    /**
     * 类型描述
     * 
     * @typedef {Object} TypeName
     * @property {string} prop1 - 属性 1 描述
     * @property {number} prop2 - 属性 2 描述
     */
    type TypeName = {
      prop1: string;
      prop2: number;
    };
    \`\`\`
    
    ---
    
    ## 注释内容要求
    
    ### 必须包含
    
    1. **功能描述**
       - 简短说明(一句话)
       - 详细说明(用途、场景、原理)
    
    2. **参数说明**
       - 参数类型
       - 参数含义
       - 是否可选
       - 默认值(如有)
       - 取值范围/约束(如有)
    
    3. **返回值**
       - 返回类型
       - 返回值含义
       - 可能的返回值
    
    4. **异常情况**
       - 可能抛出的异常
       - 抛出条件
    
    5. **使用示例**
       - 基本用法
       - 典型场景
       - 边界情况
    
    ### 可选包含
    
    1. **复杂度**:\`@complexity O(n)\`
    2. **版本信息**:\`@since 1.0.0\`
    3. **作者**:\`@author Kyle\`
    4. **废弃信息**:\`@deprecated\`
    5. **相关链接**:\`@see\`
    6. **待办事项**:\`@todo\`
    
    ---
    
    ## 注释质量标准
    
    **好的注释**:
    - ✅ 说明"为什么",而不只是"做什么"
    - ✅ 描述边界条件和特殊情况
    - ✅ 提供有意义的示例
    - ✅ 保持与代码同步
    - ✅ 使用清晰简洁的语言
    
    **避免的注释**:
    - ❌ 重复代码内容的注释
    - ❌ 过时的注释
    - ❌ 误导性的注释
    - ❌ 废话注释(如:\`// 定义变量 x\`)
    
    ---
    
    ## 特殊注释标记
    
    **标记类型**:
    \`\`\`typescript
    // TODO: 待实现的功能
    // FIXME: 需要修复的问题
    // HACK: 临时解决方案
    // NOTE: 重要说明
    // WARNING: 警告信息
    // OPTIMIZE: 可优化的地方
    \`\`\`
    
    ---
    
    现在请为代码生成${lang === "zh" ? "中文" : "英文"}的${style}风格注释文档,包括:
    1. 完整的函数/类/接口注释
    2. 复杂逻辑的行内注释
    3. 使用示例
    4. 特殊情况说明`;
    
        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 'gendoc' tool registered in the ListTools handler, specifying parameters: code (string), style (string, default jsdoc), lang (string, default zh).
    {
      name: "gendoc",
      description: "【生成注释】为代码生成详细的 JSDoc/TSDoc 注释",
      inputSchema: {
        type: "object",
        properties: {
          code: {
            type: "string",
            description: "需要生成注释的代码",
          },
          style: {
            type: "string",
            description: "注释风格:jsdoc, tsdoc, javadoc(默认 jsdoc)",
          },
          lang: {
            type: "string",
            description: "语言:zh, en(默认 zh)",
          },
        },
        required: [],
      },
    },
  • src/index.ts:489-490 (registration)
    Registration of the gendoc handler in the CallToolRequest switch statement, dispatching calls to the gendoc function.
    case "gendoc":
      return await gendoc(args);
  • Re-export of the gendoc function from its implementation module, allowing import in src/index.ts.
    export { gendoc } from "./gendoc.js";
  • src/index.ts:12-13 (registration)
    Import statement in src/index.ts that brings in the gendoc function from src/tools/index.js for use in the server handlers.
    detectShell, initSetting, initProject, gencommit, debug, genapi,
    codeReview, gentest, genpr, checkDeps, gendoc, genchangelog, refactor, perf,
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 what the tool does, it doesn't describe how it works - whether it analyzes code structure, uses AI models, has rate limits, requires specific code formats, or what happens with invalid input. For a code processing tool with zero annotation coverage, this leaves significant behavioral questions unanswered.

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 a single, efficient sentence in Chinese that communicates the core functionality without any wasted words. It's appropriately sized for a straightforward tool and front-loads the essential information about generating code annotations.

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 tool's moderate complexity (code processing with 3 parameters) and 100% schema coverage but no annotations or output schema, the description is minimally adequate. It states the core purpose clearly but lacks behavioral context, usage guidance, and output information that would make it more complete for 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?

Schema description coverage is 100%, so the schema already documents all three parameters thoroughly. The description doesn't add any parameter information beyond what's in the schema - it doesn't explain when to use different styles, what languages are supported beyond the two listed, or provide examples of code input format. 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.

Purpose5/5

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

The description clearly states the specific action ('生成注释' - generate annotations) and target resource ('为代码' - for code) with precise output format ('详细的 JSDoc/TSDoc 注释' - detailed JSDoc/TSDoc annotations). It distinguishes from siblings like 'explain' (which explains code) or 'genapi' (which generates API documentation) by focusing specifically on annotation generation.

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 like 'explain' (which explains code functionality) or 'genapi' (which generates API documentation). It doesn't mention prerequisites, typical use cases, or limitations that would help an agent choose between similar documentation-related tools.

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