Skip to content

Fix GitHub MCP server label handling for create_issue #715

Closed
@sirkitree

Description

@sirkitree

Issue Description

The GitHub MCP server's create_issue function encounters an error when provided with labels that are objects with name/description properties instead of simple strings. This causes the following error when creating issues with labels:

MCP error -32603: Invalid arguments: labels.0.description: Expected string, received null

Problem Analysis

The issue occurs because:

  1. The GitHub API can accept labels in two formats:

    • Simple string arrays: ["bug", "enhancement"]
    • Objects with name and description: [{"name": "bug", "description": "A bug"}]
  2. The current implementation in schemas.ts only accepts string arrays:

    labels: z.array(z.string()).optional()
  3. When clients (like Cursor) send labels as objects with name/description properties, the validation fails.

Proposed Changes

I've implemented the following changes to fix this issue:

  1. Updated the schema in src/github/schemas.ts to accept either format:

    labels: z.array(
      z.union([
        z.string(),
        z.object({
          name: z.string(),
          description: z.string().optional()
        })
      ])
    ).optional().describe("Array of label names or label objects")
  2. Modified the createIssue function in src/github/index.ts to process the labels before sending them to the GitHub API:

    // Process labels to ensure they're in the right format for GitHub API
    let processedOptions = { ...options };
    
    if (processedOptions.labels && Array.isArray(processedOptions.labels)) {
      processedOptions = {
        ...processedOptions,
        labels: processedOptions.labels.map(label => 
          typeof label === 'string' ? label : label.name
        ) as string[]
      };
    }

Testing

The fix has been tested and confirmed to work with:

  1. Labels as simple string arrays
  2. Multiple labels
  3. Single labels

This change makes the GitHub MCP server more robust when handling different label formats while maintaining backward compatibility with existing code.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions