de en es ja ko ru

github-assistant-mcp

Name: github-assistant-mcp
Author: imshashwatsingh

by imshashwatsingh

Overview Schema Source Related Servers Discussions Admin

TypeScript

Local

GitHub Assistant MCP

Model Context Protocol(MCP) 프로토콜을 사용하는 작고 독립적인 서버로, AI 코딩 어시스턴트(예: OpenCode)에 5개의 읽기 전용 도구를 노출합니다. 이 서버는 어시스턴트가 로컬 워크스페이스를 검사하고 클린하고 샌드박스 처리된 stdio 전송을 통해 공개 GitHub 프로필을 가져올 수 있게 해줍니다.

"OpenCode용 간단한 GitHub MCP 서버."

개요

이 서버는 OpenCode가 자식 프로세스로 시작하는 로컬 MCP 서버입니다. 이 서버는 stdio(stdin/stdout)를 통해 MCP 프로토콜을 사용하며 5개의 도구를 등록합니다. 어시스턴트가 해당 도구를 호출하면 서버가 작업(파일시스템 읽기, git diff, 또는 GitHub API 호출)을 수행하고 구조화된 텍스트 결과를 반환합니다.

파일시스템에 접근하는 모든 작업은 단일 WORKSPACE_ROOT 디렉터리로 제한되므로, 어시스턴트는 프로젝트 폴더 밖을 읽거나 벗어날 수 없습니다.

작동 방식 (아키텍처)

┌─────────────────────────┐         stdio (MCP/JSON-RPC)        ┌──────────────────────────────┐
│                         │  ───────────────────────────────▶  │   github-assistant  (this)   │
│     OpenCode / AI       │  tool call: get_github_profile     │                              │
│     Assistant           │                                    │  ┌────────────────────────┐  │
│                         │  ◀───────────────────────────────  │  │      McpServer          │  │
│  - sees 5 tools         │     result (JSON text)             │  │  (server.ts)            │  │
│  - calls them           │                                    │  └───────────┬────────────┘  │
│  - sandbox enforced     │                                    │              │ registerTools  │
└─────────────────────────┘                                    └──────────────┼──────────────┘
                                                                          ▼
                                                         ┌────────────────────────────────┐
                                                         │  tools.ts  (5 tool handlers)   │
                                                         └───┬──────┬──────┬──────┬─────┬──┘
                                          ┌───────────────┘      │      │      │     │
                                          ▼                      ▼      ▼      ▼     ▼
                                   ┌────────────┐        ┌────────────┐ ┌─────────┐ ┌────────────┐
                                   │ github.ts  │        │ workspace.ts│ │ git.ts │ │ paths.ts   │
                                   │ GitHub API │        │ list/read/  │ │ git diff│ │ resolve    │
                                   │ (fetch)   │        │ search      │ │         │ │ sandbox    │
                                   └─────┬──────┘        └─────┬──────┘ └────┬────┘ └─────┬──────┘
                                         │                    │            │           │
                                         ▼                    ▼            ▼           ▼
                                 api.github.com       WORKSPACE_ROOT/*   git CLI    config.ts
                                                        (files only)   (cwd=root)  WORKSPACE_ROOT

단일 도구 호출의 데이터 흐름:

Assistant ──JSON-RPC request──▶ McpServer
                                     │
                                     ▼
                               tool handler (tools.ts)
                                     │  validates args with zod
                                     ▼
                          business logic (github / workspace / git / paths)
                                     │  resolveWorkspacePath() enforces sandbox
                                     ▼
                          result helper (result.ts) → { content: [{ type:"text", text }] }
                                     │
                                     ▼
Assistant ◀──JSON-RPC response── McpServer

전송 및 수명 주기

유형: local — OpenCode가 서버를 자식 프로세스로 실행합니다.
전송: @modelcontextprotocol/server/stdio의 serveStdio()를 통한 stdio.
시작 순서:
1. node dist/server.js가 실행됩니다(opencode.json에 선언, cwd = ".").
2. createServer()가 github-assistant(v1.0.0)라는 이름의 McpServer를 만듭니다.
3. registerTools(server)가 5개의 도구를 등록합니다.
4. serveStdio(createServer)가 stdin에서 JSON-RPC 메시지를 읽고 stdout으로 결과를 쓰기 시작합니다.
종료: 세션이 끝나면 OpenCode가 프로세스를 종료합니다.

프로세스가 OpenCode의 작업 디렉터리를 상속하므로 WORKSPACE_ROOT는 프로젝트 디렉터리(path.resolve(process.cwd()))로 결정됩니다.

도구 참조

모든 도구는 src/tools.ts에 등록되며 MCP 텍스트 결과(JSON 또는 일반 텍스트)를 반환합니다.

1. `get_github_profile`

공개 GitHub 프로필(imshashwatsingh)을 가져옵니다.

입력: 없음
백엔드: Accept: application/vnd.github+json 및 User-Agent 헤더를 사용하여 https://api.github.com/users/imshashwatsingh에 fetch() 호출.
반환값: 사용자 이름, 이름, 회사, 위치, 팔로워, 팔로잉, 공개 저장소/게시글 수, 생성/업데이트 타임스탬프.
파일: src/github.ts

2. `list_files`

워크스페이스 디렉터리의 파일을 깊이 제한과 함께 나열합니다.

입력: path (기본값 "."), maxDepth (0–10, 기본값 3)
백엔드: src/workspace.ts의 재귀 collectFiles() — 심볼릭 링크를 건너뛰고(순환 방지) 구성된 디렉터리를 무시하며(node_modules, .git, dist, .next, coverage, .cache), MAX_RESULTS(500)로 제한합니다.
반환: 작업공간 루트, 파일 수, 상대 파일 경로.
파일: src/workspace.ts

3. `read_file`

선택적 줄 범위로 UTF-8 텍스트 파일을 읽습니다.

입력: path(필수), startLine(선택), endLine(선택)
백엔드: readWorkspaceFile() — 샌드박스를 적용하고 파일이 아닌 것을 거부하며 MAX_FILE_SIZE(1 MB)보다 큰 파일을 거부하고 바이너리 확장자를 거부합니다. 줄 번호가 매겨진 내용을 반환합니다.
반환: line: text 접두사가 있는 파일 내용.
파일: src/workspace.ts

4. `search_context`

작업 공간 전체에서 컨텍스트와 함께 키워드 검색.

입력: query (필수), path (기본값 "."), maxResults (1–10), contextLines (0–10, 기본 2)
백엔드: searchContext()가 텍스트 파일과 크기 제한이 있는 파일만 필터링한 후 각 줄을 스캔하고(대소문자 구분 없음) contextLines 주변 컨텍스트를 캡처합니다.
반환: 쿼리, 검색 경로, 파일/줄/컨텍스트가 포함된 일치 항목.
파일: src/workspace.ts

5. `summarize_diff`

현재 Git diff를 검사하고 구조화된 결과를 반환합니다.

입력: staged(기본값 false), path(선택 사항), maxDiffChars(1000–50000)
백엔드: git diff --no-ext-diff --unified=3 명령을 실행합니다(--cached/base ref 포함). 통계는 diff 텍스트에서 직접 파싱됩니다. diff는 maxDiffChars로 잘립니다.
반환: 변경된 파일 수, 파일별 통계, 원시 diff — 변경 사항이 없으면 빈 결과.
파일: src/git.ts

보안 모델

서버는 읽기 전용 및 샌드박스입니다:

우려 사항	보호 장치
경로 이탈(`../../etc/passwd`)	`resolveWorkspacePath()`가 경로를 확인하고 `WORKSPACE_ROOT`를 벗어나면 예외를 발생시킵니다.
바이너리 파일 읽기	`isProbablyTextFile()`이 비텍스트 확장자(`png`, `exe`, `pdf` 등)를 차단합니다.
대용량 파일	`read_file`/`search_context`가 `MAX_FILE_SIZE`(1MB)를 초과하는 파일을 거부합니다.
심볼릭 링크	`collectFiles()`가 심볼릭 링크를 완전히 건너뜁니다.
디렉터리 폭주	목록/검색이 `MAX_RESULTS`(500) 및 `maxDepth`(기본 3)로 제한됩니다.
쓰기/삭제/실행	쓰기, 삭제 또는 임의 셸 실행 API가 없습니다. `git`만 자식 프로세스로 허용됩니다.

프로젝트 둘러보기

src/server.ts — createServer()가 McpServer를 구성하고 도구를 등록합니다. serve()는 @modelcontextprotocol/sdk의 표준 stdio 서버 전송을 사용합니다.
src/tools.ts — 5개의 도구 정의는 스키마와 핸들러를 매핑합니다. 모든 도구는 MCP 결과를 반환하기 전에 textResult() 또는 errorResult()를 호출합니다.
src/workspace.ts — 파일 시스템 도구(list_files, read_file, search_context)를 구현합니다. 모든 파일 접근은 resolveWorkspacePath()를 통과합니다.
src/git.ts — git_diff 도구를 구현합니다. git diff --no-ext-diff --unified=3을 실행하고 출력에서 통계를 파싱합니다.
src/github.ts — GitHub API 호출을 캡슐화합니다. fetchGitHubProfile(백엔드), getGitHubProfile(도구 래퍼).
src/paths.ts — 경로 안전 계층: resolveWorkspacePath()(샌드박스 게이트)와 isProbablyTextFile().
src/config.ts — WORKSPACE_ROOT, MAX_RESULTS, MAX_FILE_SIZE, GITHUB_USERNAME, IGNORED_DIRECTORIES, BINARY_EXTENSIONS와 같은 모든 상수.
src/result.ts — 도구가 반환하는 결과를 만들기 위한 작은 헬퍼.

구성

opencode.json(프로젝트 루트)이 서버를 선언합니다:

{
  "$schema": "https://opencode.ai/config.json",
  "mcp": {
    "github-assistant": {
      "type": "local",
      "command": ["node", "dist/server.js"],
      "cwd": ".",
      "enabled": true
    }
  }
}

서버 내부 동작은 src/config.ts의 상수로 조정됩니다:

상수	기본값	의미
`WORKSPACE_ROOT`	`path.resolve(process.cwd())`	샌드박스 루트(프로젝트 디렉터리)
`MAX_FILE_SIZE`	`1 MB`	읽을 수 있는 최대 파일 크기
`MAX_RESULTS`	`500`	목록/검색의 최대 파일 수
`GITHUB_USERNAME`	`imshashwatsingh`	프로필 대상
`IGNORED_DIRECTORIES`	`node_modules`, `.git`, `dist` 등	순회 시 건너뜀
`BINARY_EXTENSIONS`	`png`, `exe`, `pdf` 등	비텍스트로 처리

빌드 및 실행

# install dependencies
npm install

# compile TypeScript -> dist/
npm run build

# start the server (used by opencode.json)
npm start

# run directly from source (no build step)
npm run dev

# the workspace must be a git repo for summarize_diff to work
git init

OpenCode는 빌드된 dist/server.js를 opencode.json에서 자동으로 감지합니다.

파일 구조

github_assistant_mcp/
├── opencode.json          # MCP server declaration for OpenCode
├── package.json           # scripts + dependencies
├── tsconfig.json          # TypeScript config
├── src/
│   ├── server.ts          # Entry point: create + serve McpServer
│   ├── tools.ts           # Registers the 5 tools + handlers
│   ├── config.ts          # Constants, limits, GitHub target
│   ├── paths.ts           # Sandbox path resolution + helpers
│   ├── workspace.ts       # list / read / search filesystem
│   ├── github.ts          # GitHub profile fetch
│   ├── git.ts             # git diff summary + stat parsing
│   └── result.ts          # MCP result/error helpers
└── dist/                  # Compiled output (npm run build)

제한 사항

get_github_profile은 단일 하드코딩된 사용자만 대상으로 하며 매개변수화되지 않습니다.
summarize_diff는 작업 트리 변경 사항만 보고합니다 — 추적되지 않은 파일은 제외됩니다.
파일 시스템 도구는 워크스페이스로 제한되며 교차 프로젝트 접근이 없습니다.
모든 도구는 읽기 전용이며 쓰기/삭제 작업이 없습니다.

Available Tools

5 tools

get_github_profileA

Get the public GitHub profile of imshashwatsingh.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4/5.0

Behavior2/5

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

No annotations are provided, so the description must disclose behavior. It only states 'Get the public GitHub profile' without mentioning authentication requirements, rate limits, return format, or side effects. The description is minimally transparent beyond the core action.

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, front-loaded sentence with no fluff. It states the action and target clearly, earning full marks for conciseness.

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 the tool's simplicity (no parameters, no output schema), the description adequately conveys what it does. It could mention the return format, but the core purpose is clear and complete for the given context.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

There are zero parameters, and schema coverage is effectively 100% (vacuously). The description doesn't need to explain parameters, and the baseline for 0-parameter tools is 4. It does not add any misleading parameter info.

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 uses a specific verb ('Get') and clearly identifies the resource ('public GitHub profile of imshashwatsingh'). This distinguishes it from sibling tools (file operations), making the purpose unambiguous.

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 context is clear: use when you need the public GitHub profile for the specified user. No explicit exclusions or alternatives are mentioned, but the sibling tools are unrelated, so confusion is unlikely. It lacks explicit 'when not to use' guidance, hence not a 5.

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

list_filesA

List files in the workspace so the assistant can inspect the project before reading or summarizing it.

ParametersJSON Schema

Name	Required	Description	Default
`path`	No	Directory relative to the workspace root.	.
`maxDepth`	No	Maximum directory depth to traverse.

TDQS

A3.8/5.0

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. However, it only restates the basic function without exposing any behavioral traits: it doesn't mention that it traverses directories, that output includes files and directories (or just files), whether it returns a tree or flat list, or any caveats like permission requirements. This is a significant gap for a tool with no annotations.

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, focused sentence with no filler. It immediately states the action and purpose, making it highly scannable and efficient.

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?

The tool is simple with only two parameters, both fully described in the schema, and no output schema. The description states the core purpose and intended usage context, which is sufficient for an agent to know when to invoke it. It doesn't detail return format, but for a listing tool that's often implicit. Overall, it's adequately complete for the tool's simplicity.

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% (both parameters are fully described in the schema), so the baseline is 3. The description adds no parameter-specific details, but the schema already provides defaults and explanation, so the description does not need to compensate. No extra semantic value is added.

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 action ('List files') and the resource ('in the workspace'), with a specific purpose ('so the assistant can inspect the project before reading or summarizing it'). This distinguishes it from sibling tools like read_file (which reads content) and search_context (which searches).

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 explicitly indicates when to use it: 'before reading or summarizing it' – providing a clear usage context. It doesn't explicitly state exclusions or alternatives, but the context is sufficient for an agent to infer it should be used first in a project inspection workflow.

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

read_fileA

Read a text file from the workspace. Use list_files first to discover available files.

ParametersJSON Schema

Name	Required	Description
`path`	Yes	File path relative to the workspace root.
`endLine`	No	Optional 1-based ending line.
`startLine`	No	Optional 1-based starting line.

TDQS

A4/5.0

Behavior3/5

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

With no annotations provided, the description carries the full burden. 'Read' clearly implies a non-destructive, read-only operation, but the description does not disclose any additional behavioral traits such as error behavior, encoding, or line range semantics (though line range is covered by the schema). It is adequate but minimal, not misleading.

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, front-loaded with the core action and followed by a useful usage hint. There is zero filler, and every word earns its place.

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?

The tool is simple, with a well-documented schema. The description provides sufficient context for a basic read operation, including the prerequisite step of listing files. While there is no output schema, the return value (file content) is obvious. Missing details like error handling are minor and expected for such a straightforward tool.

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% for all three parameters (path, startLine, endLine), with clear descriptions. The tool description adds no additional meaning beyond the schema, so the baseline of 3 applies as the schema does the heavy lifting.

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 verb and resource: 'Read a text file from the workspace.' This is a specific, unambiguous action that distinguishes it from sibling tools like list_files (listing) and search_context (searching). The inclusion of 'text file' also scopes the tool's domain.

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 explicitly instructs to 'Use list_files first to discover available files,' providing clear contextual guidance on when to use this tool relative to the siblings. It implies that read_file is for after discovery, though it does not explicitly state exclusions or alternative scenarios.

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

search_contextA

Search the workspace for a keyword or phrase. Returns matching files and surrounding lines so the assistant can understand relevant context.

ParametersJSON Schema

Name	Required	Description	Default
`path`	No	Optional directory relative to the workspace root.	.
`query`	Yes	Keyword or phrase to search for.
`maxResults`	No	Maximum number of matching lines.
`contextLines`	No	Number of surrounding lines to return.

TDQS

A4/5.0

Behavior3/5

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

With no annotations, the description carries the full burden for behavioral disclosure. It states the core behavior (returns matching files and surrounding lines) but does not mention edge behaviors such as case sensitivity, binary file handling, or ordering of results. It adds value beyond the schema but lacks deeper behavioral context.

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, both information-dense with no filler. It immediately states the action, then the result and purpose, making it easy to scan and understand the tool's role.

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?

Despite lacking an output schema and annotations, the description provides a sufficient high-level understanding of the return value. Combined with a fully documented schema, it is complete enough for a straightforward search tool. It could elaborate on return format, but the essentials are present.

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 is 3. The description echoes the 'query' and 'contextLines' concepts ('keyword or phrase', 'surrounding lines') but does not add substantive meaning beyond what the schema parameters already document. It does not clarify path defaults or maxResults behavior beyond schema.

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 uses a specific verb ('Search') with a clear resource ('the workspace') and explicitly states the output ('matching files and surrounding lines'). This clearly distinguishes it from sibling tools like list_files and read_file, which serve different purposes.

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 implies when to use it through the clause 'so the assistant can understand relevant context,' indicating it is for gaining situational understanding via keyword search. It does not explicitly mention alternatives or exclusion cases, but for a simple search tool this is adequate context.

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

summarize_diffA

Inspect the current Git diff and return a compact structured summary of changed files, additions, deletions, and the actual diff for the assistant to summarize.

ParametersJSON Schema

Name	Required	Description
`base`	No	Optional Git ref such as main, HEAD~1, or origin/main.
`path`	No	Optional file or directory relative to the workspace.
`staged`	No	When true, inspect staged changes instead of working-tree changes.
`maxDiffChars`	No	Maximum number of diff characters returned.

TDQS

A4/5.0

Behavior4/5

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

No annotations are provided, so the description carries the transparency burden. It clearly signals a read-only operation via 'Inspect' and describes the output shape (summary plus actual diff). It does not detail edge cases such as empty diffs or repository errors, but the core behavioral contract is well communicated.

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, well-structured sentence that front-loads the key action and outcome. Every clause adds value, and there is no fluff or redundant repetition of the tool name.

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?

With no output schema, the description correctly explains what the tool returns: changed files, additions, deletions, and the actual diff. The parameters are fully documented in the schema, so the description combined with the schema gives sufficient context for correct selection and invocation.

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 already has 100% description coverage for all four parameters, so the baseline is 3. The description adds context about the overall output but does not enrich understanding of individual parameters beyond what the schema already provides.

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 uses a specific verb ('Inspect') and resource ('current Git diff'), and clearly states it returns a structured summary with changed files, additions, deletions, and the actual diff. This distinguishes it from sibling tools like list_files and read_file, which do not operate on Git diffs.

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

Usage Guidelines3/5

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

The phrase 'for the assistant to summarize' implies the intended use case: obtaining diff data to produce a summary. However, there is no explicit guidance about when to choose this over alternatives or when not to use it, so it relies on implication rather than clear direction.

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.

5 tool updatesv1.0.0Aug 21, 2026
- First observedget_github_profile
- First observedlist_files
- First observedread_file
- First observedsearch_context
- First observedsummarize_diff

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A3.9/5.0

Scored 2026-08-21 02:06 across 5 tools

Disambiguation5/5

The tools are clearly distinct: one fetches GitHub profile data, while the others handle local workspace file operations (listing, reading, searching, diffing). No functional overlap exists between them.

Naming Consistency5/5

All tool names follow a consistent 'verb_noun' pattern (e.g., list_files, read_file, summarize_diff). The single compound name 'get_github_profile' still adheres to the same structure, maintaining a uniform convention.

Tool Count4/5

Five tools is a reasonable number for a focused assistant, neither too sparse nor overwhelming. However, the mix leans heavily toward workspace operations rather than GitHub-specific actions, which slightly reduces appropriateness for the server's stated purpose.

Completeness2/5

The tool surface is severely incomplete for a GitHub assistant: it only covers profile retrieval and local file operations. Core GitHub workflows like issues, pull requests, repository management, and code search are entirely absent, making the toolset insufficient for its intended domain.

Maintenance

ActivitySlowing

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Related MCP Connectors

gread A
io.github.NitroRCr
An MCP server that gives your AI access to the source code and docs of all public github repos
Version Control Code Analysis Documentation Access
5365
saagarpatel.dev Portfolio A
io.github.saagpatel
Agent-native MCP server over the public saagarpatel.dev corpus. Read-only, stateless.
Search Documentation Access
82
hithereiamaliff-mcp-nextcloudOAuth
ai.smithery
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
Cloud Storage File Systems Workplace & Productivity
238
ORANO MCP Server
io.github.infotik
Read-only MCP server exposing a user ORANO library to their own AI agent.
Note Taking Knowledge & Memory Search
1

Related MCP Servers

CodeAudit MCP
Code Analysis Testing & QA Tools Developer Tools
priyanshuchawda
A
license
Not graded
quality
C
maintenance
A read-only MCP server for AI coding agents to inspect repositories, audit code quality, route engineering skills, and plan safe issue/PR workflows.
Updated 5 months ago (2026-05-04 04:27 UTC)
1
MIT
agenticscope
Developer Tools Project Management Knowledge & Memory
jessn-dev
A
license
Not graded
quality
C
maintenance
A read-only MCP server that provides AI agents with live, structured workspace awareness, including project listing, git status, and budgeted context packing, minimizing token usage.
Updated 4 months ago (2026-06-26 06:17 UTC)
22 npm
2
MIT
mcp-readonly-code-server
John0615
F
license
B
quality
D
maintenance
A read-only MCP server that exposes a local code workspace to AI clients via stdio, providing file browsing and text search capabilities with path safety rules.
Updated 3 months ago (2026-07-18 08:30 UTC)
1
-
dev-mcp
CodeIbrah
A
license
Not graded
quality
B
maintenance
A local MCP server that gives AI agents access to developer tooling — GitHub (read-only), documentation search, and web research — via stdio transport.
Updated 2 months ago (2026-07-27 12:11 UTC)
MIT

GitHub Assistant MCP

목차

개요

작동 방식 (아키텍처)

전송 및 수명 주기

도구 참조

1. get_github_profile

2. list_files

3. read_file

4. search_context

5. summarize_diff

보안 모델

프로젝트 둘러보기

구성

빌드 및 실행

파일 구조

제한 사항

Available Tools

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

1. `get_github_profile`

2. `list_files`

3. `read_file`

4. `search_context`

5. `summarize_diff`