Skip to main content
Glama
code-alchemist01

Development Tools MCP Server

lint_code

Analyze code files with ESLint to identify syntax errors, enforce style guidelines, and improve code quality in development workflows.

Instructions

Lint code files using ESLint

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
filesYesFile paths to lint

Implementation Reference

  • Handler logic for the 'lint_code' tool. Extracts file paths from input, calls LintingUtils.lintFiles to perform ESLint linting, and formats results using Formatters.
    case 'lint_code': {
      const files = params.files as string[];
      const results = await lintingUtils.lintFiles(files);
      return Formatters.formatLintResults(results);
    }
  • Tool definition including name, description, and input schema for 'lint_code' tool, specifying array of file paths as required input.
    {
      name: 'lint_code',
      description: 'Lint code files using ESLint',
      inputSchema: {
        type: 'object',
        properties: {
          files: {
            type: 'array',
            items: { type: 'string' },
            description: 'File paths to lint',
          },
        },
        required: ['files'],
      },
    },
  • src/server.ts:18-25 (registration)
    Registration of lintingTools (containing lint_code) into the allTools array, which is returned in list tools response.
    const allTools = [
      ...codeAnalysisTools,
      ...codeQualityTools,
      ...dependencyAnalysisTools,
      ...lintingTools,
      ...webScrapingTools,
      ...apiDiscoveryTools,
    ];
  • Core helper function that initializes ESLint, lints the given files, maps results to structured LintResult format including messages, counts, and fixes, with fallback for no config.
    async lintFiles(filePaths: string[]): Promise<LintResult[]> {
      try {
        const eslint = await this.getESLint();
        const results = await eslint.lintFiles(filePaths);
    
        return results.map((result: any) => ({
          file: result.filePath,
          messages: result.messages.map((msg: any) => ({
            ruleId: msg.ruleId,
            severity: msg.severity as 0 | 1 | 2,
            message: msg.message,
            line: msg.line,
            column: msg.column,
            endLine: msg.endLine,
            endColumn: msg.endColumn,
            fix: msg.fix
              ? {
                  range: [msg.fix.range[0], msg.fix.range[1]],
                  text: msg.fix.text,
                }
              : undefined,
          })),
          errorCount: result.errorCount,
          warningCount: result.warningCount,
          fixableErrorCount: result.fixableErrorCount,
          fixableWarningCount: result.fixableWarningCount,
        }));
      } catch (error) {
        // If ESLint is not configured, return empty results
        if (error instanceof Error && error.message.includes('No ESLint configuration')) {
          return filePaths.map((file) => ({
            file,
            messages: [],
            errorCount: 0,
            warningCount: 0,
            fixableErrorCount: 0,
            fixableWarningCount: 0,
          }));
        }
        throw error;
      }
    }
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 action ('lint code files') but lacks details on what linting entails (e.g., checking for style, errors, best practices), potential side effects (e.g., no changes to files, only reporting), or operational constraints (e.g., performance impact, ESLint version requirements). This leaves significant gaps for an agent to understand the tool's behavior.

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 with zero waste: 'Lint code files using ESLint'. It's front-loaded with the core action and tool, making it easy to parse. Every word earns its place by specifying the verb, resource, and implementation method 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 complexity of a linting tool with no annotations and no output schema, the description is incomplete. It doesn't explain what the tool returns (e.g., linting results, error reports), how failures are handled, or dependencies like ESLint configuration. For a tool that performs code analysis, more context is needed to guide an agent effectively, especially with rich sibling tools available.

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 input schema has 100% description coverage, with the 'files' parameter documented as 'File paths to lint'. The description adds no additional parameter semantics beyond what the schema provides, such as file format expectations or path resolution rules. Since schema coverage is high, the baseline score of 3 is appropriate, as the description doesn't compensate but also doesn't need to given the schema's completeness.

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 ('lint') and resource ('code files'), and specifies the tool used ('using ESLint'). It distinguishes itself from siblings like 'validate_syntax' or 'fix_lint_issues' by focusing on linting specifically. However, it doesn't explicitly differentiate from all code analysis tools in the list, such as 'analyze_code_quality', which might overlap in purpose.

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 when to choose linting over other code analysis tools like 'validate_syntax' for syntax checking or 'fix_lint_issues' for automated fixes. There's no context about prerequisites, such as requiring ESLint configuration files, or exclusions for certain file types.

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/code-alchemist01/development-tools-mcp-Server'

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