Skip to main content
Glama
deenesjakoru
imshashwatsingh

github-assistant-mcp

by imshashwatsingh
OverviewSchemaRelated ServersScoreDiscussions
TypeScript
Local

GitHub Assistant MCP

A small, self-contained Model Context Protocol (MCP) server that exposes five read-focused tools to an AI coding assistant (e.g. OpenCode). It lets the assistant inspect a local workspace and pull a public GitHub profile over a clean, sandboxed stdio transport.

"A simple GitHub MCP server for OpenCode."

Table of Contents

Related MCP server: agenticscope

Overview

The server is a local MCP server started by OpenCode as a child process. It speaks the MCP protocol over stdio (stdin/stdout) and registers five tools. The assistant calls those tools; the server performs the work (filesystem reads, a git diff, or a GitHub API call) and returns structured text results.

Everything that touches the filesystem is confined to a single WORKSPACE_ROOT directory, so the assistant can never read or escape outside the project folder.

How It Works (Architecture)

┌─────────────────────────┐         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

Data flow for a single tool call:

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

Transport & Lifecycle

  • Type: local — OpenCode launches the server as a child process.

  • Transport: stdio via serveStdio() from @modelcontextprotocol/server/stdio.

  • Startup sequence:

    1. node dist/server.js is executed (declared in opencode.json) with cwd = ".".

    2. createServer() builds an McpServer named github-assistant (v1.0.0).

    3. registerTools(server) wires up the five tools.

    4. serveStdio(createServer) begins reading JSON-RPC messages from stdin and writing results to stdout.

  • Shutdown: OpenCode terminates the process when the session ends.

Because the process inherits OpenCode's working directory, WORKSPACE_ROOT resolves to the project directory (path.resolve(process.cwd())).

Tools Reference

All tools are registered in src/tools.ts and return MCP text results (JSON or plain text).

1. get_github_profile

Fetches the public GitHub profile of the hardcoded user (imshashwatsingh).

  • Inputs: none

  • Backend: fetch() to https://api.github.com/users/imshashwatsingh with Accept: application/vnd.github+json and a User-Agent header.

  • Returns: username, name, company, location, bio, public repos/gists, followers, following, profile URL, created/updated timestamps.

  • File: src/github.ts

2. list_files

Lists files under a workspace directory up to a depth.

  • Inputs: path (default "."), maxDepth (0–10, default 3)

  • Backend: recursive collectFiles() in src/workspace.ts — skips symlinks (no loops) and ignores configured directories (node_modules, .git, dist, .next, coverage, .cache). Capped at MAX_RESULTS (500).

  • Returns: workspace root, file count, and relative file paths.

  • File: src/workspace.ts

3. read_file

Reads a UTF-8 text file with optional line range.

  • Inputs: path (required), startLine (optional), endLine (optional)

  • Backend: readWorkspaceFile() — enforces sandbox, rejects non-files, refuses files larger than MAX_FILE_SIZE (1 MB), and refuses binary extensions. Returns numbered lines.

  • Returns: file content with line: text prefixes.

  • File: src/workspace.ts

4. search_context

Keyword search across the workspace with surrounding context.

  • Inputs: query (required), path (default "."), maxResults (1–100, default 50), contextLines (0–10, default 2)

  • Backend: searchContext() collects files, filters text-only and size-bounded files, then scans each line (case-insensitive) and captures contextLines above/below every match.

  • Returns: query, search path, match count, and matches with file/line/context.

  • File: src/workspace.ts

5. summarize_diff

Inspects the current Git diff and returns a structured summary.

  • Inputs: staged (default false), base (optional git ref), path (optional file/dir), maxDiffChars (1000–200000, default 50000)

  • Backend: summarizeDiff() runs git diff --no-ext-diff --unified=3 (with --cached / base ref / path filters) from WORKSPACE_ROOT. Stats are parsed from the unified diff itself (no second git call). Diff is truncated if it exceeds maxDiffChars.

  • Returns: files changed, insertions, deletions, per-file stats, and the raw diff — or { empty: true } when there are no changes.

  • File: src/git.ts

Security Model

The server is intentionally read-only and sandboxed:

Concern

Protection

Path traversal (../../etc/passwd)

resolveWorkspacePath() (src/paths.ts) resolves the path, computes its relation to WORKSPACE_ROOT, and throws if it escapes (.. prefix or absolute).

Binary file reads

isProbablyTextFile() blocks non-text extensions (png, exe, pdf, …).

Oversized files

read_file / search_context refuse files above MAX_FILE_SIZE (1 MB).

Symlink loops

collectFiles() skips symbolic links entirely.

Directory blow-up

Listing/searching capped at MAX_RESULTS (500) and maxDepth 10.

Write / delete / exec

None. The server has no write, delete, or arbitrary shell-exec tools. The only spawned process is git with a fixed argument shape.

Network

Only one outbound call: the read-only GitHub public API for a fixed user.

The sandbox boundary lives entirely in paths.ts. Any new tool that touches the filesystem must route paths through resolveWorkspacePath().

Project Walkthrough

  1. Entry point — src/server.ts createServer() instantiates McpServer and calls registerTools(). serveStdio() bridges it to stdin/stdout.

  2. Tool registration — src/tools.ts Five server.registerTool(...) calls. Each declares a description, a zod-validated inputSchema, and an async handler. Handlers delegate to the modules below and wrap output with result.ts helpers.

  3. Configuration — src/config.ts Central constants: WORKSPACE_ROOT (resolved from process.cwd()), size/result limits, the GitHub username/URL, and ignore/binary sets.

  4. Path safety — src/paths.ts resolveWorkspacePath() is the sandbox gate. toWorkspaceRelative() turns absolute paths back into workspace-relative strings for display. isProbablyTextFile() classifies files by extension.

  5. Workspace I/O — src/workspace.ts collectFiles() (recursive listing), readWorkspaceFile() (safe read), and searchContext() (keyword scan). All go through resolveWorkspacePath().

  6. GitHub — src/github.ts fetchGitHubProfile() calls the public API and maps the raw GitHubUser to the friendlier GitHubProfile shape.

  7. Git — src/git.ts summarizeDiff() builds and runs the git diff command; parseDiffStats() derives per-file insert/delete counts straight from the diff text.

  8. Results — src/result.ts Small helpers (textResult, errorResult, errorWithContext) standardize the MCP content envelope and error flagging.

Configuration

opencode.json (project root) declares the server:

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

Inside the server, behavior is tuned via constants in src/config.ts:

Constant

Default

Meaning

WORKSPACE_ROOT

path.resolve(process.cwd())

Sandbox root (project dir)

MAX_FILE_SIZE

1 MB

Max readable file size

MAX_RESULTS

500

Max files from list/search

GITHUB_USERNAME

imshashwatsingh

Profile target

IGNORED_DIRECTORIES

node_modules, .git, dist, …

Skipped while walking

BINARY_EXTENSIONS

png, exe, pdf, …

Treated as non-text

Building & Running

# 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 picks up the server automatically from opencode.json once built (dist/server.js).

File Structure

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)

Limitations

  • get_github_profile targets a single hardcoded user; it is not parameterized.

  • summarize_diff reports working-tree changes only — untracked files are not shown by git diff.

  • Filesystem tools are confined to WORKSPACE_ROOT; there is no cross-project access.

  • All tools are read-only by design — no edits, deletions, or shell execution.

  • No authentication: the GitHub call uses the unauthenticated public API (rate-limited to 60 req/hr per IP).

Available Tools

5 tools
get_github_profileA

Get the public GitHub profile of imshashwatsingh.

ParametersJSON Schema
NameRequiredDescriptionDefault

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
NameRequiredDescriptionDefault
pathNoDirectory relative to the workspace root..
maxDepthNoMaximum 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
NameRequiredDescriptionDefault
pathYesFile path relative to the workspace root.
endLineNoOptional 1-based ending line.
startLineNoOptional 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
NameRequiredDescriptionDefault
pathNoOptional directory relative to the workspace root..
queryYesKeyword or phrase to search for.
maxResultsNoMaximum number of matching lines.
contextLinesNoNumber 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
NameRequiredDescriptionDefault
baseNoOptional Git ref such as main, HEAD~1, or origin/main.
pathNoOptional file or directory relative to the workspace.
stagedNoWhen true, inspect staged changes instead of working-tree changes.
maxDiffCharsNoMaximum 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. Dates show when Glama detected each change.

  1. 5 tool updatesv1.0.0
    • First observedget_github_profile
    • First observedlist_files
    • First observedread_file
    • First observedsearch_context
    • First observedsummarize_diff
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.9/5.0
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

ActivityMaintained
ResponsivenessNo issues

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Related MCP Servers

  • mcp-readonly-code-server

    John0615
    F
    license
    B
    quality
    C
    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.
    1
    -

  • TimeVerse Code Reader

    elimyliu
    A
    license
    Not graded
    quality
    B
    maintenance
    A read-only MCP server for code reading with intelligent caching, line-range selection, and language detection, enabling AI assistants to efficiently and safely explore file systems.
    MIT

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/imshashwatsingh/github-assitant-mcp'

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