Skip to main content
Glama

初始化规范检查配置

gitea_compliance_init

Initialize a Gitea compliance configuration file with default rules to enforce repository standards and policies.

Instructions

Initialize compliance configuration file (.gitea/compliance.yaml) with default rules.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
forceNoForce overwrite existing configuration (default: false)
config_pathNoCustom path for config file

Implementation Reference

  • The core handler function `initConfig` that creates the .gitea/compliance.yaml file with default compliance rules for branches, commits, and PRs. Handles force overwrite and directory creation.
    export async function initConfig(params: InitConfigParams): Promise<{ success: boolean; path: string; message: string }> {
      const configPath = params.config_path || path.join(process.cwd(), '.gitea', 'compliance.yaml');
      const configDir = path.dirname(configPath);
    
      // 检查文件是否存在
      if (fs.existsSync(configPath) && !params.force) {
        return {
          success: false,
          path: configPath,
          message: `配置文件已存在: ${configPath},使用 --force 覆盖`,
        };
      }
    
      // 创建目录
      if (!fs.existsSync(configDir)) {
        fs.mkdirSync(configDir, { recursive: true });
      }
    
      // 生成配置内容
      const configContent = `# Gitea 规范检查配置
    # 用于检查分支、提交、PR 是否符合项目规范
    
    # 分支命名规范
    branch:
      patterns:
        - "^feat/issue-\\\\d+-.*$"     # 功能分支: feat/issue-123-add-feature
        - "^fix/issue-\\\\d+-.*$"      # 修复分支: fix/issue-456-fix-bug
        - "^docs/.*$"                  # 文档分支: docs/update-readme
        - "^refactor/.*$"              # 重构分支: refactor/improve-performance
        - "^test/.*$"                  # 测试分支: test/add-unit-tests
        - "^chore/.*$"                 # 杂务分支: chore/update-deps
        - "^main$"                     # 主分支
        - "^dev$"                      # 开发分支
        - "^release/.*$"               # 发布分支: release/v1.0.0
    
    # 提交信息规范 (Conventional Commits)
    commit:
      types:
        - feat      # 新功能
        - fix       # 修复
        - docs      # 文档
        - refactor  # 重构
        - test      # 测试
        - chore     # 杂务
        - style     # 格式
        - perf      # 性能
        - ci        # CI/CD
        - build     # 构建
        - revert    # 回滚
      scope_required: false           # 是否要求 scope
      max_subject_length: 72          # 主题行最大长度
    
    # PR 格式规范
    pr:
      required_sections:
        - Summary                     # 摘要
        - Test Plan                   # 测试计划
      require_issue_link: true        # 是否要求关联 Issue
    `;
    
      fs.writeFileSync(configPath, configContent, 'utf-8');
    
      return {
        success: true,
        path: configPath,
        message: `配置文件已创建: ${configPath}`,
      };
    }
  • Registers the 'gitea_compliance_init' tool with MCP server, including title, description, input schema, and a thin wrapper handler that calls the core initConfig function.
    mcpServer.registerTool(
      'gitea_compliance_init',
      {
        title: '初始化规范检查配置',
        description: 'Initialize compliance configuration file (.gitea/compliance.yaml) with default rules.',
        inputSchema: z.object({
          force: z.boolean().optional().describe('Force overwrite existing configuration (default: false)'),
          config_path: z.string().optional().describe('Custom path for config file'),
        }),
      },
      async (args) => {
        try {
          const result = await ComplianceTools.initConfig(args as any);
          return { content: [{ type: 'text' as const, text: JSON.stringify(result, null, 2) }] };
        } catch (error: unknown) {
          const errorMessage = error instanceof Error ? error.message : String(error);
          return { content: [{ type: 'text' as const, text: `Error: ${errorMessage}` }], isError: true };
        }
      }
    );
  • TypeScript interface defining the input parameters for the initConfig function, matching the Zod schema in registration.
    export interface InitConfigParams {
      force?: boolean;
      config_path?: string;
    }
    
    /**
     * 初始化规范配置文件
     */
    export async function initConfig(params: InitConfigParams): Promise<{ success: boolean; path: string; message: string }> {
      const configPath = params.config_path || path.join(process.cwd(), '.gitea', 'compliance.yaml');
      const configDir = path.dirname(configPath);
    
      // 检查文件是否存在
      if (fs.existsSync(configPath) && !params.force) {
        return {
          success: false,
          path: configPath,
          message: `配置文件已存在: ${configPath},使用 --force 覆盖`,
        };
      }
    
      // 创建目录
      if (!fs.existsSync(configDir)) {
        fs.mkdirSync(configDir, { recursive: true });
      }
    
      // 生成配置内容
      const configContent = `# Gitea 规范检查配置
    # 用于检查分支、提交、PR 是否符合项目规范
    
    # 分支命名规范
    branch:
      patterns:
        - "^feat/issue-\\\\d+-.*$"     # 功能分支: feat/issue-123-add-feature
        - "^fix/issue-\\\\d+-.*$"      # 修复分支: fix/issue-456-fix-bug
        - "^docs/.*$"                  # 文档分支: docs/update-readme
        - "^refactor/.*$"              # 重构分支: refactor/improve-performance
        - "^test/.*$"                  # 测试分支: test/add-unit-tests
        - "^chore/.*$"                 # 杂务分支: chore/update-deps
        - "^main$"                     # 主分支
        - "^dev$"                      # 开发分支
        - "^release/.*$"               # 发布分支: release/v1.0.0
    
    # 提交信息规范 (Conventional Commits)
    commit:
      types:
        - feat      # 新功能
        - fix       # 修复
        - docs      # 文档
        - refactor  # 重构
        - test      # 测试
        - chore     # 杂务
        - style     # 格式
        - perf      # 性能
        - ci        # CI/CD
        - build     # 构建
        - revert    # 回滚
      scope_required: false           # 是否要求 scope
      max_subject_length: 72          # 主题行最大长度
    
    # PR 格式规范
    pr:
      required_sections:
        - Summary                     # 摘要
        - Test Plan                   # 测试计划
      require_issue_link: true        # 是否要求关联 Issue
    `;
    
      fs.writeFileSync(configPath, configContent, 'utf-8');
    
      return {
        success: true,
        path: configPath,
        message: `配置文件已创建: ${configPath}`,
      };
    }
  • Default compliance configuration used by initConfig to populate the YAML file with branch patterns, commit types, and PR requirements.
    const DEFAULT_CONFIG: ComplianceConfig = {
      branch: {
        patterns: [
          '^feat/issue-\\d+-.*$',
          '^fix/issue-\\d+-.*$',
          '^docs/.*$',
          '^refactor/.*$',
          '^test/.*$',
          '^chore/.*$',
          '^main$',
          '^dev$',
          '^release/.*$',
        ],
      },
      commit: {
        types: ['feat', 'fix', 'docs', 'refactor', 'test', 'chore', 'style', 'perf', 'ci', 'build', 'revert'],
        scope_required: false,
        max_subject_length: 72,
      },
      pr: {
        required_sections: ['Summary', 'Test Plan'],
        require_issue_link: true,
      },
    };
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 mentions the tool creates/initializes a configuration file with default rules, which implies a write operation. However, it doesn't disclose important behavioral aspects: whether this requires specific permissions, what happens if the file already exists (beyond the 'force' parameter), whether changes are reversible, or what the typical output/confirmation looks like. For a file creation tool with zero annotation coverage, 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.

Conciseness5/5

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

The description is a single, efficient sentence that states the tool's purpose clearly. It's appropriately sized for a simple initialization tool and wastes no words. Every element (action, resource, file path, outcome) earns its place without redundancy.

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?

For a tool that creates/initializes configuration files with no annotations and no output schema, the description is insufficient. It doesn't explain what 'default rules' entail, what format the configuration file uses, whether initialization can be partial or incremental, or what verification occurs. Given the complexity of compliance configuration and the lack of structured metadata, more context would be helpful for the agent to use this tool effectively.

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 fully documents both parameters ('force' and 'config_path'). The description doesn't add any parameter-specific information beyond what's in the schema. It mentions 'default rules' which relates to the tool's purpose but not to parameter semantics. The baseline score of 3 is appropriate when the schema does all the parameter documentation work.

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 ('Initialize'), the resource ('compliance configuration file'), and the outcome ('with default rules'). It specifies the exact file path (.gitea/compliance.yaml) which adds specificity. However, it doesn't explicitly differentiate from sibling tools like 'gitea_workflow_init' or 'gitea_init', which could create ambiguity about when to use this specific compliance initialization tool versus other initialization 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., whether a repository must exist), when this initialization should occur in a workflow, or how it relates to sibling tools like 'gitea_compliance_check_*' tools. The agent must infer usage context entirely 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/SupenBysz/gitea-mcp-tool'

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