Skip to main content
Glama
jknithin36

github-insights-mcp

by jknithin36
OverviewSchemaRelated ServersScoreDiscussions
TypeScript

GitHub Insights MCP Server

A small server that lets an AI assistant look up and analyze GitHub repositories.

It's built with the Model Context Protocol (MCP). MCP is a standard way to give an AI access to outside tools and data. You build the server once, and any MCP-compatible app (like Claude Desktop or Cursor) can use it.

What it can do

Look up a repo — get a repository's stars, forks, language, description, and open issues.

Search repos — search GitHub by keyword and get back the top results.

Read a README — pull any repository's README so the AI can read it.

Analyze a repo — a ready-made prompt that tells the AI to gather the repo's stats and README and give a clear verdict on whether the project is healthy and worth using.

Related MCP server: GitHub MCP Server

Built with

  • TypeScript

  • The MCP TypeScript SDK

  • Zod (for checking inputs)

  • The GitHub API (for live data)

  • Node.js

How to run it

You'll need Node.js 18 or newer.

git clone https://github.com/YOUR_USERNAME/github-insights-mcp.git
cd git-mcp
npm install
npm run build

Try it out

The MCP Inspector is a simple tool for testing the server in your browser:

npm run inspect

Open the link it prints, click Connect, and try:

  • Tools — look up facebook / react

  • Resources — read repo://facebook/react/readme

  • Prompts — run analyze_repo and see the instruction it creates

Use it with Claude Desktop

Add this to your Claude Desktop config file:

{
  "mcpServers": {
    "github-insights": {
      "command": "node",
      "args": ["/full/path/to/github-insights-mcp/dist/index.js"]
    }
  }
}

Restart Claude Desktop and the tools will be ready to use.

What I learned

Building this taught me how MCP actually works:

  • How the client and server talk to each other, and why keeping them separate is useful

  • The three things an MCP server can offer — tools (actions), resources (data to read), and prompts (ready-made instructions)

  • How to connect real API calls, handle errors, and check inputs

  • How one prompt can tie the tools and resources together into a single task

  • END

Available Tools

2 tools
get_repo_infoGet Repository InfoA

Get key stats about a public GitHub repository: stars, forks, primary language, description, and open issue count. Use when the user asks about a specific repo's popularity or details.

ParametersJSON Schema
NameRequiredDescriptionDefault
repoYesThe Repository Name, eg: React
ownerYesThe Repository Owner, eg : Facebok

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. It discloses that the tool works on public repositories and lists the returned data points, which is useful. However, it does not discuss rate limits, authentication requirements, or any error behavior, leaving some transparency gaps.

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 exactly two sentences and every word contributes: the first sentence defines the tool's output, and the second defines its usage context. No unnecessary elaboration or repetition of schema details.

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 simple two-parameter tool with no output schema, the description lists the exact fields returned (stars, forks, language, etc.), which compensates for lacking an output schema. It also gives usage context. Minor gaps include no mention of error handling or rate limits, but the tool's simplicity makes this largely sufficient.

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 provides descriptions for both parameters ('owner' and 'repo') with examples, achieving 100% coverage. The description adds no additional parameter-level semantics beyond what's in the schema, 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 tool's function: 'Get key stats about a public GitHub repository' and enumerates the specific stats returned. The use-case sentence 'when the user asks about a specific repo' distinguishes this from the sibling 'search_repos' tool, which is for searching repositories.

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 an explicit when-to-use statement: 'Use when the user asks about a specific repo's popularity or details.' However, it does not address when not to use it or explicitly name the alternative sibling 'search_repos', so it lacks a full exclusion/alternative comparison.

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

search_reposSearch RepositoriesA

Search public GitHub repositories by keyword. Returns the top matches by stars. Use when the user wants to discover repos on a topic rather than look up a specific one.

ParametersJSON Schema
NameRequiredDescriptionDefault
queryYesSearch keywords, e.g. 'react state management'

TDQS

A4.4/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 full burden. It discloses that results are limited to public repos and returns top matches by stars, which is useful behavioral context. However, it doesn't mention result count, pagination, or output format.

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?

Two concise sentences front-load the purpose and then provide usage guidance. No redundant information or wasted words.

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 simple tool with one parameter and no output schema, the description gives enough information to select and invoke it. It covers purpose, usage alternative, and a key behavioral trait, but lacks details like how many results are returned.

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%, and the 'query' parameter is already described with an example. The description's 'by keyword' aligns with the schema but doesn't add extra semantic meaning beyond what's in the structured data.

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?

States 'Search public GitHub repositories by keyword' – a clear verb, resource, and scope. Distinguishes from sibling get_repo_info by focusing on discovery rather than lookup.

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

Usage Guidelines5/5

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

Explicitly says 'Use when the user wants to discover repos on a topic rather than look up a specific one,' which directly contrasts with the sibling tool and gives clear usage context.

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

Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.1/5.0
Disambiguation5/5

The two tools have clearly distinct purposes: one retrieves stats for a known repository, the other discovers repositories by keyword. There is no overlap in functionality or ambiguity about which to use.

Naming Consistency5/5

Both tool names follow a consistent verb_noun pattern: get_repo_info and search_repos. The verbs 'get' and 'search' clearly reflect the action, and the nouns match the resource type.

Tool Count3/5

With only two tools, the server feels thin for a topic like GitHub insights. However, the tools cover the two most common entry points (lookup and discovery), so it is borderline but not unreasonably sparse.

Completeness3/5

The server covers basic repository stats and search but lacks additional insight-oriented capabilities such as comparing repos, fetching contributor activity, or listing recent releases. These are notable gaps but not fatal for simple use cases.

Maintenance

ActivitySlowing
ResponsivenessSyncing

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

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/jknithin36/git-mcp'

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