What can you do with this server?

You can query GitHub repository analytics and insights from OSSInsight with the following tools: * ossinsight_repo: Fetch metadata (stars, forks, language, license, description) for a specific GitHub repository. * ossinsight_trending: Discover trending repositories by language and timeframe (past 24 hours, week, month, or 3 months). * ossinsight_collections: List all 102 curated collections. * ossinsight_search: Search repositories and collections by keyword with pagination and sorting. * ossinsight_compare: Compare two repositories side-by-side. * ossinsight_ranking: Rank repositories in a collection by stars, issues, or PRs over a chosen time range. No API key is required, and the API allows 600 requests per hour per IP.

Which integrations are available for this server?

Provides access to GitHub repository analytics including metadata, trending repositories, curated collections, search, comparison, and rankings.

How do I use OSSInsight MCP Server?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@OSSInsight MCP Server what are the trending Python repos this week?" 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.

OSSInsight MCP Server

by GeniusTechnoMystic

Overview Schema Source Related Servers Discussions Admin

Python

Remote

OSSInsight MCP Server

A Model Context Protocol (MCP) server for querying GitHub repository analytics from OSSInsight (by PingCAP). Provides repo metadata, trending repos, curated collections, search, compare, and collection rankings — no API key required.

Features

ossinsight_repo — GitHub repo metadata: stars, forks, language, license, description
ossinsight_trending — Trending repos by language and timeframe
ossinsight_collections — List all 102 curated collections
ossinsight_search — Search repos and collections by keyword
ossinsight_compare — Side-by-side comparison of two repos
ossinsight_ranking — Rank repos in a collection by stars, issues, or PRs

Related MCP server: CodeCompass MCP

Installation

uv (recommended)

uvx ossinsight-mcp

pip

pip install ossinsight-mcp
ossinsight-mcp

Configuration

Claude Desktop

{
  "mcpServers": {
    "ossinsight-mcp": {
      "command": "uvx",
      "args": ["ossinsight-mcp"]
    }
  }
}

Cursor / VS Code

{
  "mcpServers": {
    "ossinsight-mcp": {
      "command": "uvx",
      "args": ["ossinsight-mcp"]
    }
  }
}

Tools

Tool	Description	Key Params
`ossinsight_repo`	Repo metadata — stars, forks, language, license	`owner`, `repo` (required)
`ossinsight_trending`	Trending repos by language/timeframe	`language`, `period` (past_24h/past_week/past_month/past_3mo)
`ossinsight_collections`	List all curated collections	(none)
`ossinsight_search`	Search repos and collections	`q` (required), `page`, `page_size`, `sort`
`ossinsight_compare`	Compare two repos side-by-side	`repo1`, `repo2` (required)
`ossinsight_ranking`	Rank repos in a collection	`collection_id` (required), `metric`, `range`

Examples

# Get repo metadata
ossinsight_repo({"owner": "grafana", "repo": "grafana"})
# → stars: 76K, forks: 14K, language: TypeScript, license: AGPL-3.0

# What's trending in Rust this month
ossinsight_trending({"language": "rust", "period": "past_month"})

# List all collections
ossinsight_collections({})

# Compare two databases
ossinsight_compare({"repo1": "postgres/postgres", "repo2": "clickhouse/clickhouse"})

# Top repos in the AI/ML collection by stars this year
ossinsight_ranking({"collection_id": 12, "metric": "stars", "range": "year"})

Data Source

Uses the OSSInsight API (/api/mcp).

Auth: None required
Rate limit: 600 requests per hour per IP
Data: GH Archive (all public GitHub events since 2011)

Development

git clone https://github.com/GeniusTechnoMystic/ossinsight-mcp.git
cd ossinsight-mcp
uv sync
uv run ossinsight-mcp

Other OSSInsight MCP servers in the ecosystem:

Project	Language	Tools	Tests	Install	Differentiator
damonxue/mcp-ossinsight	Python	5	None	`npx` / Docker	Developer analysis, natural language query, web scraping fallback
gztchan/ossinsight-mcp	Python	4	None	git clone	Stargazer/issue/PR creator demographics, generic request tool
This one (ours)	Python	6	28 tests	`uvx` / `pip install`	Collections, search, compare, ranking, PyPI-published

Our differentiators

Broadest open-source tool set — 6 tools covering repo metadata, trending, collections, search, compare, and ranking. The only open-source server with dedicated tools for collections, search, and compare.
Test coverage — 28 tests with mocked HTTP (respx). No competitor has tests.
PyPI publication — install with uvx ossinsight-mcp or pip install ossinsight-mcp. No npm, no Docker, no build step.
Ranking flexibility — ossinsight_ranking supports stars, issues, or PRs across day/week/month/year ranges.

When to use the alternatives

damonxue/mcp-ossinsight — if you need developer contribution analysis, natural language queries, or web scraping for repos with <25 stars.
gztchan/ossinsight-mcp — if you need stargazer/issue/PR creator demographics (countries, history) or a generic forward-compatible request tool.

Scope note

None of the open-source OSSInsight MCP servers fully wrap the OSSInsight Public API v1beta. A hosted 18-tool OSSInsight MCP server exists on mcpbundles.com covering issue creator, PR creator, and stargazer demographics (countries, history, orgs) — but it's not open source.

License

MIT

Available Tools

6 tools

ossinsight_collectionsB

List all curated collections.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

B3.2/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 full burden for behavioral disclosure. It does not explicitly state that the operation is read-only, nor mention pagination, output format, or other behaviors. The verb 'list' implies a read operation, but this is not made explicit.

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, concise sentence that is entirely front-loaded and free of any wasted words. It earns its place by conveying the essential action and target.

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 simple no-parameter list tool, the description states the core function but omits any context about the return format or when to use it. There is no output schema to compensate, making it minimally viable but not complete.

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?

The tool has zero parameters, so schema coverage is trivially 100%. Per the baseline rule for 0-param tools, a score of 4 is appropriate; the description adds no parameter semantics, but none are needed.

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 uses a specific verb 'List' and clearly identifies the resource as 'curated collections'. It is distinct from the sibling tools (compare, ranking, repo, trending, search), though it does not explicitly differentiate itself from them.

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 on when to use this tool versus alternatives. The description simply states what it does without indicating context, exclusions, or alternatives, leaving the agent to infer usage.

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

ossinsight_compareB

Compare two GitHub repositories side-by-side.

ParametersJSON Schema

Name	Required	Description	Default
`repo1`	Yes	First repo as 'owner/name'
`repo2`	Yes	Second repo as 'owner/name'

TDQS

B3.4/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. It only states the action without revealing what metrics are compared, what output format to expect, or any limitations/side effects. This leaves the agent with insufficient information to predict the tool's behavior.

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, clear sentence with zero filler or repetition. Every word contributes to understanding the tool's purpose, making it highly concise and well-structured.

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

Completeness2/5

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

With no output schema and no annotations, the description must explain return values and behavioral context, but it does not. Critical gaps remain: no indication of what 'compare' returns, what criteria are used, or any usage context. The tool is simple but still under-specified for an agent to invoke confidently.

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% with both parameters described as 'owner/name' format. The description adds no new parameter semantics beyond restating 'two GitHub repositories', so a 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 uses a specific verb 'Compare' and clearly identifies the resource as 'two GitHub repositories', unambiguously distinguishing it from sibling tools like ossinsight_repo which would handle a single repository. It succinctly conveys the tool's core function.

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 description implies usage (when you need to compare two repos) but provides no explicit guidance on when to use this over alternatives. There is no mention of prerequisites, exclusions, or scenarios where another tool would be more appropriate.

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

ossinsight_rankingB

Rank repositories in a collection by stars/issues/PRs over a time range.

ParametersJSON Schema

Name	Required	Description	Default
`range`	No	day \| week \| month (default) \| year	month
`metric`	No	stars (default) \| issues \| prs	stars
`collection_id`	Yes	Collection ID (use ossinsight_collections)

TDQS

B3.3/5.0

Behavior2/5

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

With no annotations, the description carries the full burden. It doesn't disclose whether the operation is read-only, how results are ordered/limited, or the output format. The term 'Rank' implies a computation but leaves side effects and return structure unspecified.

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 zero filler. It conveys the core action, target, and criteria efficiently.

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?

The tool is simple (3 params, no nested objects), but the description omits return value details, ordering, and limits. Since no output schema exists, this is a notable gap, though the description gives a basic sense of the action.

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 echoes the schema's metric and range options but adds no new meaning or usage details beyond what the schema 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 'Rank' with a clear resource ('repositories in a collection') and scope ('by stars/issues/PRs over a time range'). This clearly distinguishes it from sibling tools like ossinsight_collections or ossinsight_trending.

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?

No guidance is provided about when to use this tool versus alternatives. The description doesn't mention prerequisites (e.g., obtaining a collection ID) or exclusions (e.g., use ossinsight_trending for global rankings).

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

ossinsight_repoA

Get GitHub repository metadata: stars, forks, language, license, description.

ParametersJSON Schema

Name	Required	Description	Default
`repo`	Yes	Repository name (e.g. 'nginx')
`owner`	Yes	GitHub owner (e.g. 'nginx')

TDQS

A3.5/5.0

Behavior3/5

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

No annotations are present, so the description must carry the behavioral burden. It does disclose the returned fields (stars, forks, etc.) and implies a read-only operation via 'Get', but it does not mention error handling, authorization, or whether the metadata is limited to public repositories.

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 clear front-loading ('Get GitHub repository metadata') and a concise list of outputs. Every word is informative, with no redundant or filler content.

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 simple two-parameter lookup, the description names the core purpose and output fields. However, without an output schema or annotations, it lacks behavioral details like error responses and usage context relative to sibling tools, leaving some gaps.

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% with clear descriptions and examples for both owner and repo. The description adds no additional parameter semantics beyond the schema, so the baseline score of 3 applies.

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 ('Get') and the resource ('GitHub repository metadata'), and enumerates the key fields returned (stars, forks, language, license, description). This distinguishes it from sibling tools like ossinsight_trending or ossinsight_compare, 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 Guidelines2/5

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

No guidance is provided on when to use this tool versus alternatives such as ossinsight_search or ossinsight_trending. There are no exclusions, prerequisites, or context signals; usage is only implied by the tool name and description.

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

ossinsight_searchC

Search GitHub repos and collections.

ParametersJSON Schema

Name	Required	Description	Default
`q`	Yes	Search keyword
`page`	No	Page (1-based)
`sort`	No	popular \| recent	popular
`page_size`	No	Results per page

TDQS

C2.7/5.0

Behavior1/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 behavioral disclosure. It only says 'search' and does not mention what is returned, pagination, sorting, or any side effects. This is a significant gap.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence with no filler, making it concise and front-loaded. However, it is so brief that it omits valuable context, which prevents a higher score.

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

Completeness2/5

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

Given there is no output schema and no annotations, the description should clarify what the tool returns or its limitations. It does neither, leaving the agent with insufficient information for a search tool with four parameters.

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 all parameters are documented in the input schema. The description adds no extra meaning beyond the basic search intent, so the baseline of 3 applies.

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 specifies the action (search) and the target resources (GitHub repos and collections), which distinguishes it from sibling tools like rankings or comparisons. However, it does not explicitly contrast itself with siblings, so it loses a point.

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?

The description provides no guidance on when to use this tool versus alternatives. It merely states the basic function without any context or exclusions.

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

ossinsight_trendingB

Get trending GitHub repos by language and timeframe.

ParametersJSON Schema

Name	Required	Description	Default
`period`	No	past_24_hours \| past_week (default) \| past_month \| past_3_months	past_week
`language`	No	Language filter (default: '' for all)

TDQS

B3.3/5.0

Behavior2/5

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

With no annotations, the description carries the full burden of behavioral disclosure. It merely says 'Get trending GitHub repos' without explaining how trendiness is determined, the response format, ordering, pagination, or any rate limits. This is a significant gap for a tool with no output schema.

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 concise sentence that front-loads the core purpose. Every word earns its place, with no redundancy or filler.

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?

The tool is simple with few parameters, but the minimal description lacks output details and usage context. Without an output schema or annotations, the agent is left uncertain about the response structure and how 'trending' is defined, leaving clear gaps.

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 descriptions cover both parameters completely (period with allowed values, language with default). The description's mention of 'language and timeframe' paraphrases the schema without adding new details, so the baseline of 3 applies.

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 ('Get') and the resource ('trending GitHub repos'), with explicit filters for language and timeframe. This distinguishes it from sibling tools like ossinsight_ranking by focusing on 'trending' status rather than general ranking.

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?

The description provides no guidance on when to use this tool versus its siblings (e.g., ossinsight_ranking, ossinsight_repo). There is no mention of alternatives, exclusions, or preferred use cases, leaving the agent to infer based on the name alone.

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.

6 tool updatesv0.1.0Aug 3, 2026
- First observedossinsight_collections
- First observedossinsight_compare
- First observedossinsight_ranking
- First observedossinsight_repo
- First observedossinsight_search
- First observedossinsight_trending

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

B3.4/5.0

Scored 2026-08-03 05:00 across 6 tools

Disambiguation5/5

Each tool targets a distinct aspect of GitHub insights: collections listing, repo comparison, ranking within collections, repo metadata, trending repos, and search. There is no significant overlap in their primary functions, making them easy to distinguish.

Naming Consistency3/5

All tools share the consistent 'ossinsight_' prefix, but the suffixes mix nouns (collections, ranking, repo, trending) with verbs (compare, search), creating an inconsistent pattern. A uniform verb_noun structure would improve predictability.

Tool Count5/5

With six tools, the server is well-scoped for its purpose of providing GitHub repository insights. Each tool fills a necessary role without unnecessary bloat, falling comfortably within the ideal range.

Completeness4/5

The tool set covers core workflows: discovery (search/trending), metadata retrieval (repo), comparison (compare), and curated collections (collections/ranking). Minor gaps exist, such as a dedicated tool to view collection details directly, but these are workable through existing tools.

Maintenance

ActivitySlowing

ResponsivenessNo issues

Resources

Need Help?

Related Servers

Related MCP Connectors

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
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
5364
Cortex C
io.cortex.mcp
The Cortex MCP server provides read-only access to real-time engineering context from the Cortex developer portal, allowing AI coding assistants to answer natural language questions about your organization's catalog (microservices, libraries, domains, teams, infrastructure), scorecards (engineering standards and best practices), initiatives (goals and deadlines), and Engineering Intelligence metrics. It includes tools for querying documentation, tracking personal entities, and accessing AI-assisted insights across the entire Cortex ecosystem.
Developer Tools Monitoring Observability
312
anotherai
dev.anotherai
MCP server for building and testing AI agents with multi-model experimentation and insights.
Agent Orchestration Autonomous Agents Testing & QA Tools
2

Related MCP Servers

MCP GitHub OAuth Analytics
Developer Tools Code Execution Autonomous Agents
bighadj22
F
license
Not graded
quality
D
maintenance
A Model Context Protocol server that enables AI models to access tools through GitHub authentication and provides comprehensive analytics tracking of tool usage, performance, and user behavior.
Updated a year ago (2025-06-30 10:04 UTC)
3
-
CodeCompass MCP
TheAlchemist6
A
license
A
quality
D
maintenance
An enterprise-grade Model Context Protocol server that provides comprehensive GitHub repository analysis and AI-powered development assistance through 11 streamlined tools.
Updated a year ago (2025-07-18 02:46 UTC)
11
2
MIT
ossinsight-mcp
Search Developer Tools Open Data
gztchan
A
license
B
quality
D
maintenance
An MCP server that provides access to the OSS Insight Public API for GitHub repository analytics. It enables querying trending repositories, contributor statistics, and collection rankings through various tools.
Updated 5 months ago (2026-04-16 10:03 UTC)
18
10 npm
3
MIT
MCP GitHub Reader
Version Control Code Analysis Developer Tools
skydeckai
A
license
D
quality
D
maintenance
A lightweight MCP server for bringing GitHub repositories into context for large language models, enabling repository analysis, file access, and search without local cloning.
Updated a year ago (2025-03-29 21:08 UTC)
4
6 npm
6
Apache 2.0

OSSInsight MCP Server

Features

Installation

uv (recommended)

pip

Configuration

Claude Desktop

Cursor / VS Code

Tools

Examples

Data Source

Development

Related Projects

Our differentiators

When to use the alternatives

Scope note

License

Available Tools

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers