Skip to main content
Glama

create_github_issues

Automate GitHub issue creation from analysis results. Specify repository owner, name, and optional issue numbers. Requires GitHub token.

Instructions

Create GitHub issues from analysis results. Requires GitHub token.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
issueNumbersNoIssue numbers to create (optional, creates all issues if not specified)
ownerYesGitHub repository owner
repoYesGitHub repository name

Implementation Reference

  • Core handler function that parses issues from LAST_RESPONSE_OPENAI.json, filters by numbers if specified, and creates GitHub issues using Octokit.
    export async function handleGitHubIssues(options: GitHubIssuesOptions): Promise<string> {
      try {
        if (!options.githubToken) {
          throw new GitHubError(
            'GitHub token is required. Please add your GitHub token to the MCP server configuration.'
          );
        }
    
        const octokit = new Octokit({
          auth: options.githubToken,
        });
    
        // Парсим файл с результатами анализа
        const allIssues = await parseResponseFile(
          path.join(process.cwd(), 'LAST_RESPONSE_OPENAI.json')
        );
        if (allIssues.length === 0) {
          return 'No issues found in the conversation file';
        }
    
        // Фильтруем issues по номерам, если они указаны
        const issuesToCreate = options.issueNumbers
          ? allIssues.filter(issue => options.issueNumbers?.includes(issue.number))
          : allIssues;
    
        if (issuesToCreate.length === 0) {
          return 'No matching issues found with the specified numbers';
        }
    
        // Создаем issues
        const results = await Promise.all(
          issuesToCreate.map(async issue => {
            try {
              await octokit.issues.create({
                owner: options.owner,
                repo: options.repo,
                title: `[#${issue.number}] ${issue.title}`,
                body: issue.body,
                labels: issue.labels,
              });
              return `Created issue #${issue.number}: ${issue.title}`;
            } catch (error) {
              return `Failed to create issue #${issue.number}: ${
                error instanceof Error ? error.message : String(error)
              }`;
            }
          })
        );
    
        return results.join('\n');
      } catch (error) {
        if (error instanceof GitHubError) {
          throw error;
        }
        throw new GitHubError(`Failed to create GitHub issues: ${(error as Error).message}`);
      }
    }
  • Input schema defining parameters for the tool: owner, repo, and optional issueNumbers.
    export const githubIssuesSchema = {
      type: 'object',
      properties: {
        owner: {
          type: 'string',
          description: 'GitHub repository owner',
        },
        repo: {
          type: 'string',
          description: 'GitHub repository name',
        },
        issueNumbers: {
          type: 'array',
          items: {
            type: 'number',
          },
          description: 'Issue numbers to create (optional, creates all issues if not specified)',
        },
      },
      required: ['owner', 'repo'],
      additionalProperties: false,
    } as const;
  • Tool object definition with name 'create_github_issues', description, schema reference, and wrapper handler that checks token and delegates to core handler.
    export const githubIssuesTool: Tool = {
      name: 'create_github_issues',
      description: 'Create GitHub issues from analysis results. Requires GitHub token.',
      inputSchema: githubIssuesSchema,
      handler: async (args: Record<string, unknown>) => {
        try {
          const githubToken = process.env.GITHUB_PERSONAL_ACCESS_TOKEN;
          if (!githubToken) {
            return {
              content: [
                {
                  type: 'text',
                  text: 'GitHub token is required. Please add GITHUB_PERSONAL_ACCESS_TOKEN to your MCP server configuration.',
                },
              ],
              isError: true,
            };
          }
    
          const options = {
            githubToken,
            owner: String(args.owner),
            repo: String(args.repo),
            issueNumbers: args.issueNumbers as number[] | undefined,
          };
    
          const result = await handleGitHubIssues(options);
          return {
            content: [
              {
                type: 'text',
                text: result,
              },
            ],
          };
        } catch (error) {
          return {
            content: [
              {
                type: 'text',
                text: `Error creating GitHub issues: ${error instanceof Error ? error.message : String(error)}`,
              },
            ],
            isError: true,
          };
        }
      },
    };
  • Main tools array registration including the githubIssuesTool.
    export const tools = [
      codeCollectorTool,
      installBaseServersTool,
      codeAnalyzerTool,
      githubIssuesTool,
    ];
  • Helper function to parse and extract issues from the LAST_RESPONSE_OPENAI.json file.
    async function parseResponseFile(filePath: string): Promise<ParsedIssue[]> {
      try {
        const content = await safeReadFile(filePath);
        const data = JSON.parse(content);
        return data.issues;
      } catch (error) {
        if (error instanceof GitHubError) {
          throw error;
        }
        throw new GitHubError(`Failed to parse conversation file: ${(error as Error).message}`);
      }
    }
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 mentions the requirement for a GitHub token, which adds some context about authentication needs. However, it fails to describe key behavioral traits such as whether this is a write operation (implied by 'create' but not explicit), potential side effects, error handling, rate limits, or what the output looks like. For a mutation tool with zero annotation coverage, this is a significant gap.

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 concise with two short sentences that are front-loaded with the main purpose. There's no unnecessary verbosity, and each sentence serves a purpose: the first states the action, and the second adds a critical requirement. However, it could be slightly more structured by explicitly separating purpose from prerequisites.

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 tool's complexity as a write operation with no annotations and no output schema, the description is incomplete. It lacks details on behavioral aspects like mutation effects, error cases, and output format. While it mentions a token requirement, it doesn't cover other contextual needs such as permissions or integration with sibling tools, leaving gaps for the agent to infer.

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%, meaning the input schema already documents all parameters thoroughly. The description adds no additional meaning about parameters beyond what's in the schema, such as clarifying the relationship between 'issueNumbers' and 'analysis results' or providing examples. With high schema coverage, the baseline score of 3 is appropriate as the description doesn't compensate but also doesn't detract.

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 ('create GitHub issues') and the source ('from analysis results'), providing a specific verb+resource combination. However, it doesn't differentiate from sibling tools like 'analyze_code' or 'collect_code' which might also relate to code analysis workflows, leaving room for ambiguity about when to use this versus other tools in the server.

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 mentions 'Requires GitHub token' which is a prerequisite but not a usage guideline. It provides no guidance on when to use this tool versus alternatives like 'analyze_code' or 'collect_code', nor does it specify scenarios where this tool is appropriate or inappropriate. Without such context, the agent lacks direction on tool selection.

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

Related 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/aindreyway/mcp-neurolora'

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