git-issuer-mcp
Create GitHub issues on allow-listed repositories using GitHub App authentication.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@git-issuer-mcpCreate an issue in my-org/my-repo titled 'Add login page' with description 'Need login functionality.'"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
git-issuer-mcp
An MCP (Model Context Protocol) server that enables AI agents to create GitHub issues on explicitly allow-listed repositories. It uses GitHub App authentication so the agent never touches tokens directly, and enforces input validation, rate limiting, and repository-level access control.
How It Works
AI Agent → MCP Server (stdio) → GitHub App Auth → GitHub REST API → RepositoryThe server exposes a single create_issue tool over MCP's stdio transport. When an agent calls it, the request flows through:
Input validation — Zod-based schema checks, HTML/script sanitization, base64 payload rejection
Rate limiting — Sliding-window limiter (default 10 requests/minute)
Repository allowlist — Only repos listed in
ALLOWED_REPOSare acceptedGitHub App authentication — JWT generated from private key, exchanged for a short-lived installation token (cached for 55 minutes)
Issue creation — Octokit REST client creates the issue and returns the number and URL
All errors are returned as structured JSON with a code and message. Tokens and private keys are never logged or exposed.
Related MCP server: GitHub Integration Hub
Prerequisites
1. Node.js
Node.js 18+ is required (ES2022 target).
node --version # v18.x or higher2. GitHub App
You need a GitHub App installed on your target organization or account. The app grants the server permission to create issues without sharing personal access tokens with the agent.
Create the app:
Go to GitHub Settings > Developer settings > GitHub Apps > New GitHub App
Set the following permissions:
Repository permissions > Issues: Read & Write
Under "Where can this GitHub App be installed?", choose Only on this account (recommended for internal use)
Create the app and note the App ID from the app settings page
Generate a private key (.pem file) — download and store it securely
Install the app on the repositories you want the agent to access
After installation, note the Installation ID (visible in the URL:
https://github.com/settings/installations/<INSTALLATION_ID>)
3. Environment Variables
Variable | Required | Description |
| Yes | App ID from your GitHub App settings page |
| Yes | Installation ID from the app installation URL |
| Yes | Path to the |
| Yes | Comma-separated list of |
| No | Max issue creations per minute (default: |
See .env.example for a documented template.
Installation
git clone <repo-url> git-issuer-mcp
cd git-issuer-mcp
npm install
npm run buildThe compiled output lands in dist/.
Running Tests
Tests use Jest with ts-jest and do not require GitHub credentials — all external calls are mocked.
npm testThis runs the full suite covering:
validation.test.ts— Repo format, title/body limits, label constraints, HTML sanitization, base64 detectionauth.test.ts— Env validation, .pem file loading, base64 key loading, token caching and refreshissues.test.ts— Allowlist enforcement, successful creation, GitHub API error handlingrateLimiter.test.ts— Default/custom limits, per-agent tracking, sliding-window expirytools.test.ts— End-to-end tool handler flow, error code formatting
To type-check without running tests:
npm run typecheckSetting Up in Claude Code
Add the server to your Claude Code MCP configuration at ~/.claude.json:
{
"mcpServers": {
"git-issuer": {
"command": "node",
"args": ["/absolute/path/to/git-issuer-mcp/dist/server.js"],
"env": {
"GITHUB_APP_ID": "123456",
"GITHUB_INSTALLATION_ID": "78901234",
"GITHUB_PRIVATE_KEY": "/absolute/path/to/private-key.pem",
"ALLOWED_REPOS": "your-org/repo-a,your-org/repo-b",
"RATE_LIMIT_PER_MINUTE": "10"
}
}
}
}Claude Code injects the environment variables into the server process at launch. The agent never sees or controls these values.
After saving the config, restart Claude Code. The create_issue tool will appear in the agent's available tools.
Setting Up in Cursor
Add the server to your Cursor MCP configuration. Open Settings > MCP (or edit .cursor/mcp.json in your project root) and add:
{
"mcpServers": {
"git-issuer": {
"command": "node",
"args": ["/absolute/path/to/git-issuer-mcp/dist/server.js"],
"env": {
"GITHUB_APP_ID": "123456",
"GITHUB_INSTALLATION_ID": "78901234",
"GITHUB_PRIVATE_KEY": "/absolute/path/to/private-key.pem",
"ALLOWED_REPOS": "your-org/repo-a,your-org/repo-b",
"RATE_LIMIT_PER_MINUTE": "10"
}
}
}
}Restart Cursor after saving. The server will start automatically when the agent invokes the create_issue tool.
MCP Tool Reference
create_issue
Create a GitHub issue on an allowed repository.
Input:
Field | Type | Required | Constraints |
|
| Yes |
|
|
| Yes | 1–200 characters |
|
| Yes | Max 10,000 characters |
|
| No | Max 10 labels, each 1–50 characters |
Success response:
{
"success": true,
"issue_number": 42,
"issue_url": "https://github.com/your-org/repo/issues/42"
}Error response:
{
"success": false,
"error": {
"code": "REPO_NOT_ALLOWED",
"message": "Repository your-org/other-repo is not on the allowlist"
}
}Error codes:
Code | Meaning |
| Input failed schema validation or sanitization |
| Repository is not in |
| Too many requests within the rate-limit window |
| GitHub API returned an error |
| GitHub App authentication failed |
Security Model
Repository allowlist — The agent can only target repos explicitly listed in
ALLOWED_REPOS. Everything else is rejected.No token exposure — Tokens are generated server-side, cached in memory, and never logged or returned to the agent.
Input sanitization —
<script>blocks, HTML event attributes, and base64 payloads are stripped or rejected before reaching GitHub.Rate limiting — A configurable sliding-window limiter prevents runaway issue creation.
Environment-only config — All secrets are injected via environment variables by the MCP host. The agent cannot modify them at runtime.
Project Structure
src/
├── server.ts # Entry point — registers tools, starts stdio transport
├── mcp/
│ └── tools.ts # Tool schema and handler (validation → rate limit → create)
├── github/
│ ├── auth.ts # GitHub App JWT + installation token with caching
│ └── issues.ts # Issue creation, allowlist enforcement, structured logging
├── security/
│ ├── validation.ts # Zod schema, HTML sanitization, base64 detection
│ └── rateLimiter.ts # Sliding-window per-agent rate limiter
└── __tests__/
├── auth.test.ts
├── issues.test.ts
├── rateLimiter.test.ts
├── tools.test.ts
└── validation.test.tsDevelopment
npm install # Install dependencies
npm run build # Compile TypeScript to dist/
npm run typecheck # Type-check without emitting
npm test # Run test suite
npm start # Start the server (requires env vars)License
Internal use only.
Available Tools
1 toolcreate_issueA
Create a GitHub issue on an allowed repository
| Name | Required | Description | Default |
|---|---|---|---|
| body | Yes | Issue body, max 10,000 characters | |
| repo | Yes | "owner/repo" format | |
| title | Yes | Issue title, 1-200 characters | |
| labels | No | Optional labels, max 10 |
TDQS
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 only states the action 'Create a GitHub issue' and does not mention authentication requirements, effects on the repository, response behavior, or any other side effects. This is a significant gap for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that directly states the tool's purpose with no filler or redundant information. It is front-loaded and appropriately sized for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The combination of schema and description covers the inputs and basic action, but the description does not disclose what the response looks like, any permission prerequisites beyond 'allowed repository', or error behavior. Since there is no output schema and no annotations, the description alone is only minimally complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with each parameter clearly described (repo, title, body, labels). The description adds no extra parameter-level context beyond what the schema already provides, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Create' with a specific resource 'GitHub issue' and adds context 'on an allowed repository', making the tool's purpose immediately clear. It is distinguishable from any potential sibling tools, though none are present, and the action is specific enough.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context about what the tool does and the constraint 'allowed repository' implies a restriction. However, it does not explicitly mention when to use it versus alternatives or when not to use it, but given no siblings, the context is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
1 tool update
v1.0.0- First observed
create_issue
TDQS
Scored across 1 tool
Only one tool exists, so there is no possibility of overlap or confusion. The tool's purpose is clearly stated.
The single tool name 'create_issue' follows a clear verb_noun convention, so there is no inconsistency.
With only one tool, the server is severely under-scoped for a GitHub issue workflow. A typical issue lifecycle requires at least create, read, and update operations.
The tool only supports issue creation and offers no way to list, read, update, or delete issues. This leaves agents unable to track or manage issues after creation, creating a dead end.
Maintenance
Related MCP Connectors
Connect AI assistants to GitHub - manage repos, issues, PRs, and workflows through natural language.
Task management for people and AI agents, with scoped OAuth access to issues, projects, and docs.
Security gateway for AI agents: policy, approval, and audited execution, no secrets shared.
AgentGuard — 20-tool AI safety MCP: policy preflight, risk scoring, audit logging, rate limits.
Related MCP Servers
- AlicenseBqualityFmaintenanceEnables LLMs to interact with GitHub issues by providing details as tasks, allowing for seamless integration and task management through GitHub's platform.12014MIT
- FlicenseNot gradedqualityDmaintenanceEnables AI agents to interact with GitHub through OAuth-authenticated operations including starting authorization flows, listing repositories, and creating issues using stored access tokens.1-
- AlicenseBqualityCmaintenanceIntegrates with GitHub REST API to allow LLM agents to list and create repository issues.2222ISC
- AlicenseNot gradedqualityCmaintenanceEnables AI agents to securely perform privileged actions like creating GitHub issues by minting short-lived, single-purpose tokens on demand, with policy enforcement and audit logging.MIT