Skip to main content
Glama

code_review

Analyze code for quality, security, performance, and best practices to identify issues and improve development standards.

Instructions

【代码审查】全面审查代码质量、安全性、性能和最佳实践

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
codeNo需要审查的代码
focusNo审查重点:quality, security, performance, all(默认 all)

Implementation Reference

  • The core handler function for the 'code_review' tool. It constructs a comprehensive prompt template for code review covering quality, security, performance, and best practices, based on the provided code and focus area, and returns it as MCP content.
    export async function codeReview(args: any) {
      try {
        const code = args?.code || "";
        const focus = args?.focus || "all"; // quality, security, performance, all
    
        const message = `请对以下代码进行全面审查:
    
    📝 **代码内容**:
    ${code || "请提供需要审查的代码"}
    
    🎯 **审查重点**:${focus}
    
    ---
    
    ## 代码审查清单
    
    ### 1️⃣ 代码质量检查
    
    **代码坏味道(Code Smells)**:
    - [ ] 重复代码(Duplicated Code)
    - [ ] 过长函数(Long Function)> 30 行
    - [ ] 过长参数列表(Long Parameter List)> 3 个
    - [ ] 复杂条件判断(Complex Conditional)> 3 层嵌套
    - [ ] 魔法数字(Magic Numbers)
    - [ ] 命名不清晰(Poor Naming)
    
    **设计原则**:
    - [ ] 单一职责原则(SRP)
    - [ ] 开闭原则(OCP)
    - [ ] 接口隔离原则(ISP)
    - [ ] 依赖倒置原则(DIP)
    
    ### 2️⃣ 安全漏洞检查
    
    **常见漏洞**:
    - [ ] SQL 注入风险
    - [ ] XSS(跨站脚本)风险
    - [ ] CSRF(跨站请求伪造)
    - [ ] 硬编码密钥/密码
    - [ ] 不安全的随机数生成
    - [ ] 路径遍历漏洞
    - [ ] 未验证的输入
    - [ ] 敏感信息泄露
    
    **安全最佳实践**:
    - [ ] 输入验证和过滤
    - [ ] 输出编码
    - [ ] 使用参数化查询
    - [ ] 密码/密钥使用环境变量
    - [ ] HTTPS 通信
    
    ### 3️⃣ 性能问题检查
    
    **性能风险**:
    - [ ] 循环内创建对象
    - [ ] 嵌套循环(O(n²) 或更差)
    - [ ] 不必要的重复计算
    - [ ] 内存泄漏风险
    - [ ] 阻塞主线程
    - [ ] 大数据量未分页
    - [ ] 同步 I/O 操作
    
    **React/Vue 性能**:
    - [ ] 未使用 useMemo/useCallback
    - [ ] 组件不必要的重渲染
    - [ ] 大列表未虚拟化
    - [ ] 状态管理不当
    
    ### 4️⃣ 最佳实践检查
    
    **TypeScript/JavaScript**:
    - [ ] 类型定义完整(避免 any)
    - [ ] 错误处理完善(try-catch)
    - [ ] 异步操作正确处理
    - [ ] 使用 const/let 替代 var
    - [ ] 箭头函数合理使用
    
    **命名规范**:
    - [ ] 变量:驼峰命名(camelCase)
    - [ ] 常量:大写下划线(UPPER_CASE)
    - [ ] 类/接口:帕斯卡命名(PascalCase)
    - [ ] 文件:短横线命名(kebab-case)
    - [ ] 布尔值:is/has/should 前缀
    
    **注释和文档**:
    - [ ] 复杂逻辑有注释说明
    - [ ] 公共 API 有文档
    - [ ] TODO/FIXME 标记清晰
    
    ---
    
    ## 审查报告格式
    
    **严重问题(🔴 Critical)**:
    1. [位置] 问题描述
       - 风险:...
       - 建议:...
       - 修复示例:\`\`\`typescript ... \`\`\`
    
    **警告(🟡 Warning)**:
    1. [位置] 问题描述
       - 影响:...
       - 建议:...
    
    **建议(🟢 Suggestion)**:
    1. [位置] 改进建议
       - 当前:...
       - 建议:...
       - 收益:...
    
    **优点(✅ Good)**:
    - 做得好的地方
    
    ---
    
    现在请开始代码审查,生成详细的审查报告。`;
    
        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,
        };
      }
    }
  • Input schema definition for the code_review tool, specifying 'code' as required string and optional 'focus' string parameter.
    inputSchema: {
      type: "object",
      properties: {
        code: {
          type: "string",
          description: "需要审查的代码",
        },
        focus: {
          type: "string",
          description: "审查重点:quality, security, performance, all(默认 all)",
        },
      },
      required: [],
    },
  • src/index.ts:140-157 (registration)
    Tool registration in the MCP server's ListTools handler, including name, description, and schema.
    {
      name: "code_review",
      description: "【代码审查】全面审查代码质量、安全性、性能和最佳实践",
      inputSchema: {
        type: "object",
        properties: {
          code: {
            type: "string",
            description: "需要审查的代码",
          },
          focus: {
            type: "string",
            description: "审查重点:quality, security, performance, all(默认 all)",
          },
        },
        required: [],
      },
    },
  • src/index.ts:477-478 (registration)
    Registration in the CallToolRequestHandler switch statement that routes tool calls to the codeReview function.
    case "code_review":
      return await codeReview(args);
  • Re-export of the codeReview handler from the individual tool file for centralized import.
    export { codeReview } from "./code_review.js";
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 states the tool performs a comprehensive review but doesn't describe what the review entails (e.g., static analysis, linting, output format), whether it modifies the code, or any limitations (e.g., language support, timeouts). For a tool with zero annotation coverage, this leaves significant gaps in understanding its behavior.

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 in Chinese that front-loads the core purpose. It's appropriately sized for a tool with two parameters and no annotations, though it could be slightly more structured (e.g., separating key aspects with commas). Every word contributes to the purpose statement.

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 of a code review tool (which could involve analysis, reporting, or recommendations), the description is incomplete. No annotations exist to clarify behavior, and there's no output schema to explain return values. The description only states what the tool does at a high level, lacking details on how it works, what it returns, or any constraints, making it inadequate for informed use.

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 ('code' and 'focus') with descriptions. The description adds no additional meaning beyond what the schema provides (e.g., it doesn't explain what 'quality' or 'security' entail in the review context). Baseline 3 is appropriate 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: '全面审查代码质量、安全性、性能和最佳实践' (comprehensively reviews code quality, security, performance, and best practices). It specifies the verb '审查' (review) and the resource '代码' (code), distinguishing it from siblings like 'analyze_project' or 'debug'. However, it doesn't explicitly differentiate from all siblings (e.g., 'perf' might overlap with performance 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. It doesn't mention prerequisites, when not to use it, or compare it to siblings like 'analyze_project' (which might analyze broader project aspects) or 'perf' (which might focus solely on performance). The agent must infer usage 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