Skip to main content
Glama
deenesjakoruzh
barissozudogru

release-intel

by barissozudogru
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

release-intel-mcp

GitHub 저장소 데이터에서 릴리스 인텔리전스를 생성하는 MCP 서버입니다. 두 git ref 사이의 커밋, 풀 리퀘스트, 이슈, 기여자를 연관시키고 AI가 릴리스 노트, 체인지로그, 릴리스 요약으로 합성할 수 있는 구조화된 컨텍스트를 반환합니다.

도구

get_changes_between_refs

두 git ref 사이의 모든 커밋을 관련 PR 메타데이터, 작성자 정보, 연결된 이슈와 함께 가져옵니다.

필드

유형

설명

owner

string

GitHub 저장소 소유자 또는 조직

repo

string

GitHub 저장소 이름

base

string

기준 ref (이전 태그, 브랜치 또는 SHA)

head

string

헤드 ref (최신 태그, 브랜치 또는 SHA)

get_pull_requests_in_range

두 ref 사이의 병합된 모든 PR을 가져와 레이블별로 자동 분류합니다: breaking, feature, fix, docs, chore, dependencies, other.

입력 필드는 get_changes_between_refs와 동일합니다.

get_release_summary

커밋 데이터, PR 메타데이터, 연결된 이슈, 기여자 목록, 집계 통계를 결합한 구조화된 릴리스 컨텍스트 객체를 생성합니다.

필드

유형

설명

owner

string

GitHub 저장소 소유자

repo

string

GitHub 저장소 이름

from_tag

string

이전 릴리스 태그 (기준)

to_tag

string

새 릴리스 태그 또는 HEAD

Related MCP server: MCP Releases Server

설정

모든 옵션에는 repo 읽기 권한이 있는 GitHub 개인 액세스 토큰이 필요합니다. https://github.com/settings/tokens에서 생성하세요.

옵션 A: stdio (로컬 프로세스)

표준 방식: MCP 클라이언트가 서버를 로컬 하위 프로세스로 실행합니다.

Claude Desktop

구성 파일: ~/Library/Application Support/Claude/claude_desktop_config.json

{
  "mcpServers": {
    "release-intel": {
      "command": "npx",
      "args": ["-y", "@barissozudogru/release-intel-mcp"],
      "env": {
        "GITHUB_TOKEN": "ghp_your_token"
      }
    }
  }
}

Claude Code

claude mcp add release-intel -e GITHUB_TOKEN=ghp_your_token -- npx -y @barissozudogru/release-intel-mcp

Cursor

구성 파일: ~/.cursor/mcp.json

{
  "mcpServers": {
    "release-intel": {
      "command": "npx",
      "args": ["-y", "@barissozudogru/release-intel-mcp"],
      "env": {
        "GITHUB_TOKEN": "ghp_your_token"
      }
    }
  }
}

Windsurf

구성 파일: ~/.codeium/windsurf/mcp_config.json

{
  "mcpServers": {
    "release-intel": {
      "command": "npx",
      "args": ["-y", "@barissozudogru/release-intel-mcp"],
      "env": {
        "GITHUB_TOKEN": "ghp_your_token"
      }
    }
  }
}

VS Code + Copilot

구성 파일: .vscode/mcp.json

{
  "servers": {
    "release-intel": {
      "type": "stdio",
      "command": "npx",
      "args": ["-y", "@barissozudogru/release-intel-mcp"],
      "env": {
        "GITHUB_TOKEN": "ghp_your_token"
      }
    }
  }
}

Cline

구성 파일: ~/.cline/mcp_settings.json (또는 Cline 확장 설정 UI를 통해)

{
  "mcpServers": {
    "release-intel": {
      "command": "npx",
      "args": ["-y", "@barissozudogru/release-intel-mcp"],
      "env": {
        "GITHUB_TOKEN": "ghp_your_token"
      }
    }
  }
}

Continue.dev

구성 파일: ~/.continue/config.yaml

mcpServers:
  - name: release-intel
    command: npx
    args:
      - -y
      - "@barissozudogru/release-intel-mcp"
    env:
      GITHUB_TOKEN: ghp_your_token

Zed

구성 파일: ~/.config/zed/settings.json

{
  "context_servers": {
    "release-intel": {
      "command": {
        "path": "npx",
        "args": ["-y", "@barissozudogru/release-intel-mcp"],
        "env": {
          "GITHUB_TOKEN": "ghp_your_token"
        }
      }
    }
  }
}

JetBrains (AI Assistant 플러그인)

{
  "mcpServers": {
    "release-intel": {
      "command": "npx",
      "args": ["-y", "@barissozudogru/release-intel-mcp"],
      "env": {
        "GITHUB_TOKEN": "ghp_your_token"
      }
    }
  }
}

옵션 B: HTTP (원격 / 무상태)

서버를 HTTP 엔드포인트로 실행합니다. 원격 클라이언트, 공유 팀 배포, 또는 URL 기반 연결을 선호하는 클라이언트에 유용합니다.

GITHUB_TOKEN=ghp_your_token npx @barissozudogru/release-intel-mcp --http

기본적으로 포트 3000에서 시작합니다. PORT를 설정하여 변경할 수 있습니다.

Cursor (HTTP)

{
  "mcpServers": {
    "release-intel": {
      "url": "http://localhost:3000/mcp"
    }
  }
}

VS Code + Copilot (HTTP)

{
  "servers": {
    "release-intel": {
      "type": "http",
      "url": "http://localhost:3000/mcp"
    }
  }
}

Windsurf (HTTP)

{
  "mcpServers": {
    "release-intel": {
      "serverUrl": "http://localhost:3000/mcp"
    }
  }
}

Continue.dev (HTTP)

mcpServers:
  - name: release-intel
    type: streamable-http
    url: http://localhost:3000/mcp

GET /health에서 상태 확인 엔드포인트를 사용할 수 있습니다.

옵션 C: Docker

docker build -t release-intel-mcp .
docker run -p 3000:3000 -e GITHUB_TOKEN=ghp_your_token release-intel-mcp

컨테이너는 기본적으로 HTTP 모드로 시작합니다. MCP 엔드포인트는 http://localhost:3000/mcp에 있습니다.

환경 변수

변수

필수

기본값

설명

GITHUB_TOKEN

예

-

GitHub 개인 액세스 토큰 (repo 범위)

TRANSPORT

아니요

stdio

HTTP 모드를 활성화하려면 http로 설정

PORT

아니요

3000

HTTP 포트 (HTTP 모드 전용)

로컬 개발

git clone https://github.com/barissozudogru/release-intel-mcp.git
cd release-intel-mcp
npm install
npm run build
GITHUB_TOKEN=ghp_... node dist/index.js

라이선스

MIT

Available Tools

3 tools
get_changes_between_refsGet Changes Between RefsB

Get all commits between two git refs enriched with associated PR metadata, author information, and linked issues. Uses the GitHub compare API.

ParametersJSON Schema
NameRequiredDescriptionDefault
baseYesBase ref (tag, branch, or commit SHA), the older point
headYesHead ref (tag, branch, or commit SHA), the newer point
repoYesGitHub repository name
ownerYesGitHub repository owner (user or organization)

TDQS

B3.1/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are present, so the description must carry the full burden of behavioral disclosure. It only says the tool 'gets' commits and uses the GitHub compare API; it does not mention pagination, rate limits, auth requirements, potential response size, or any other operational behavior beyond the implied read-only nature.

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 two concise sentences with the main operation front-loaded and no filler. The mention of the GitHub compare API is brief and serves as useful context without bloating the definition.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with four required and fully documented parameters, the description plus schema covers the core invocation. It also states what the response contains semantically. However, with no output schema and no annotations, it leaves response shape, pagination, and error/limit behavior unspecified, so it is not fully complete.

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 baseline applies. The schema already documents owner, repo, base, and head, including that base is the older point and head is the newer point. The description's phrase 'between two git refs' adds little semantic value beyond what the schema provides.

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 identifies the action: get all commits between two git refs, and specifies the enrichment (PR metadata, author information, linked issues). It does not explicitly contrast with sibling tools like get_pull_requests_in_range or get_release_summary, but the commit-focused wording makes the distinction mostly clear.

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?

There is no guidance about when to use this tool versus the sibling tools. It names the GitHub compare API but does not explain when an agent should prefer this over get_pull_requests_in_range or get_release_summary, nor does it state prerequisites or exclusions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_pull_requests_in_rangeGet Pull Requests in RangeA

Get all merged pull requests between two refs with full metadata including labels, linked issues, review counts, and files changed. PRs are categorized by label into: breaking, feature, fix, docs, chore, dependencies, other.

ParametersJSON Schema
NameRequiredDescriptionDefault
baseYesBase ref (tag, branch, or commit SHA), the older point
headYesHead ref (tag, branch, or commit SHA), the newer point
repoYesGitHub repository name
ownerYesGitHub repository owner (user or organization)

TDQS

A4.2/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden of disclosing behavior. It specifies that only merged PRs are returned, lists included metadata (labels, linked issues, review counts, files changed), and explains label categorization. It does not mention auth, pagination, or error behavior, but for a retrieval tool the core behavior is transparent.

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 two sentences with no filler. The key action and scope are front-loaded, and the category list adds useful detail without bloating the text.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a straightforward read/list tool with all parameters documented in the schema, the description adequately covers what the tool returns and how results are categorized. It does not describe return format or pagination, but it is sufficiently complete for an agent to call it correctly.

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 fully documents all four parameters. The description adds no parameter-specific details beyond what the schema provides, so the baseline score of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the specific verb 'Get' and the precise resource ('all merged pull requests between two refs'). It differentiates from the siblings by emphasizing PRs with labels, metadata, and categorization, which is distinct from get_changes_between_refs and get_release_summary.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear context for when to use the tool: when you need merged PRs between two refs, with the additional distinction that only merged PRs are included. However, it does not explicitly name alternatives or state when not to use this tool, so it stops short of a 5.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_release_summaryGet Release SummaryA

Generate a structured release context object ready for AI synthesis into release notes. Combines commit data, PR metadata, linked issues, contributor list, and aggregate statistics for the range between two tags.

ParametersJSON Schema
NameRequiredDescriptionDefault
repoYesGitHub repository name
ownerYesGitHub repository owner (user or organization)
to_tagYesThe new release tag or HEAD (head / newer ref)
from_tagYesThe previous release tag (base / older ref)

TDQS

A4.2/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden. It transparently describes behavior by listing what data the tool combines and clarifying that the output is a structured object intended for synthesis. It does not discuss side effects, rate limits, or edge cases, but 'Generate' and the aggregation wording sufficiently signal a read-only, non-destructive operation.

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 sentence with no wasted words. It front-loads the core purpose and then efficiently enumerates the combined data sources, giving the agent maximum signal per word.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

There is no output schema, but the description compensates by naming the output type and its major components. The four required parameters are fully covered by the schema. Some detail about output shape or edge cases is absent, but the description is complete enough for an agent to select and invoke the tool effectively.

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 coverage is 100%, so the baseline is 3. The description adds only the 'range between two tags' framing, which reinforces from_tag and to_tag semantics but does not meaningfully expand on what the schema already documents for owner, repo, from_tag, or to_tag.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a specific verb ('Generate'), a specific resource ('structured release context object'), and the scope ('range between two tags'). It also lists concrete contents (commit data, PR metadata, linked issues, contributors, aggregate statistics), which clearly distinguishes it from sibling tools focused on individual data types.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The phrase 'ready for AI synthesis into release notes' gives a clear context for when to use the tool. It does not explicitly name sibling alternatives or state when not to use them, but the 'Combines...' clause implies that this is the aggregate choice when multiple data sources are needed.

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. 3 tool updatesv0.6.1
    • First observedget_changes_between_refs
    • First observedget_pull_requests_in_range
    • First observedget_release_summary
Deploy Server
Shareable, User-Owned Context BackendPeople, applications, and agents read, write, and coordinate together in one context lake. Reach it over MCP, a CLI, a Python SDK, or REST.fulcradynamics.comAd

TDQS

A3.7/5.0

Scored across 3 tools

Disambiguation4/5

The three tools are largely distinct: one fetches commits, one fetches PRs, and one combines both into a summary. However, get_changes_between_refs and get_pull_requests_in_range both retrieve PR-related data, which could cause slight confusion for an agent deciding between them. The descriptions provide enough clarity to mitigate overlap.

Naming Consistency5/5

All tool names follow a consistent 'get_' verb prefix followed by descriptive noun phrases in snake_case (changes_between_refs, pull_requests_in_range, release_summary). This pattern is predictable and aligns with common conventions.

Tool Count4/5

With only 3 tools, the server is lean but each tool serves a clear purpose in the release-intel workflow: retrieving commits, retrieving PRs, and generating a summary. The count is minimal yet sufficient for the stated domain, though it sits at the low end of the ideal range.

Completeness3/5

The server covers the core operations for generating release context: commits, PRs, and a combined summary. However, there is no tool to list available tags/refs, which would be a natural precursor to using the other tools, and no way to directly fetch issues outside of PRs. These gaps could require agents to work around them.

Maintenance

ActivityActive
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers

  • MCP Releases Server

    hngkr
    F
    license
    Not graded
    quality
    D
    maintenance
    An MCP server that provides GitHub release information through the Model Context Protocol. It features a tool to retrieve the latest stable release version of any specified GitHub repository.
    -

  • devflow-mcp

    boranesn
    A
    license
    Not graded
    quality
    D
    maintenance
    A production-ready MCP server that provides AI assistants with comprehensive GitHub developer tooling including PR analysis, code review, changelog generation, dependency auditing, commit summarization, and refactoring suggestions.
    8 npm
    ISC