Skip to main content
Glama

generate_commit_message

Generate Git commit messages from code diffs. Choose from conventional, simple, or detailed styles to match your project's needs.

Instructions

根据代码变更生成 Git commit message

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
diffYes代码变更内容(git diff 输出)
styleNo提交信息风格:conventional(约定式)、simple(简洁)、detailed(详细)

Implementation Reference

  • src/server.ts:325-343 (registration)
    Registers the 'generate_commit_message' tool with name, description, and input schema (diff string required, optional style enum with values conventional/simple/detailed).
    {
      name: 'generate_commit_message',
      description: '根据代码变更生成 Git commit message',
      inputSchema: {
        type: 'object',
        properties: {
          diff: {
            type: 'string',
            description: '代码变更内容(git diff 输出)',
          },
          style: {
            type: 'string',
            enum: ['conventional', 'simple', 'detailed'],
            description: '提交信息风格:conventional(约定式)、simple(简洁)、detailed(详细)',
          },
        },
        required: ['diff'],
      },
    },
  • Input schema for the tool: requires 'diff' (string) and optionally accepts 'style' (enum: conventional/simple/detailed).
    inputSchema: {
      type: 'object',
      properties: {
        diff: {
          type: 'string',
          description: '代码变更内容(git diff 输出)',
        },
        style: {
          type: 'string',
          enum: ['conventional', 'simple', 'detailed'],
          description: '提交信息风格:conventional(约定式)、simple(简洁)、detailed(详细)',
        },
      },
      required: ['diff'],
    },
  • Handler for generate_commit_message: extracts diff and optional style, builds a prompt with style-specific instructions, truncates diff to 8000 chars, calls orchestrator.askDynamicExpert with a 'fast' tier expert role 'Git commit规范专家', and returns formatted commit message.
            case 'generate_commit_message': {
              const { diff, style = 'conventional' } = args as { diff: string; style?: string };
              
              const stylePrompts: Record<string, string> = {
                conventional: '使用约定式提交格式:type(scope): description。type 可以是 feat/fix/docs/style/refactor/test/chore。',
                simple: '使用简洁风格:一行描述主要变更。',
                detailed: '使用详细风格:标题 + 空行 + 详细说明(列出所有变更点)。',
              };
              
              const prompt = `请根据以下代码变更生成 Git commit message。
    
    ${stylePrompts[style] || stylePrompts.conventional}
    
    代码变更:
    \`\`\`diff
    ${diff.slice(0, 8000)}
    \`\`\`
    
    请只输出 commit message,不要其他内容。`;
    
              const response = await orchestrator.askDynamicExpert('fast', '你是一位 Git 提交规范专家。', prompt);
              
              return {
                content: [{ type: 'text', text: `# 📝 推荐的 Commit Message\n\n\`\`\`\n${response}\n\`\`\`` }],
              };
            }
  • Helper method askDynamicExpert that creates a dynamic Expert instance with the given tier and role, sends the prompt (question), and returns the response. Used by the generate_commit_message handler to call an LLM with the commit message prompt.
    async askDynamicExpert(tier: ModelTier, role: string, question: string): Promise<string> {
      const expert = new Expert(
        {
          id: 'dynamic',
          name: '专家',
          role,
          capabilities: [],
        },
        this.getAdapterByTier(tier)
      );
    
      const response = await expert.respond(question);
      this.space.send('user', 'dynamic', question, 'question');
      this.space.send('dynamic', 'user', response, 'output');
    
      return response;
    }
Behavior2/5

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

With no annotations, the description bears full responsibility for behavioral disclosure. It only states the high-level action, with no mention of output format, error handling, side effects, or limitations.

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 concise sentence that front-loads the core purpose. While efficient, it lacks any structural elements like sections or lists that could improve readability.

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?

The tool has no output schema, so the description should define the output. It does not. It also omits prerequisites (e.g., valid git diff input) and any potential impacts, making it incomplete for a generative tool.

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. The description adds no extra meaning or context beyond what the schema provides, meeting the baseline but not enhancing it.

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 verb 'generate' and the resource 'commit message', making the tool's purpose unambiguous. However, it does not differentiate from siblings like code_review or fix_bug, which could cause confusion for an agent.

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 does not specify prerequisites, context, or exclusions, leaving the agent with no decision-making support.

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/7836246/claude-team-mcp'

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