GitInsight-MCP

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.0.0
Disambiguation4/5
Most tools have distinct purposes, but there is some overlap between get_repository_stats and get_contribution_activity, as both provide aggregated metrics that could be confused for general analytics. The recruiter-focused tools (generate_portfolio_summary and get_skills_matrix) are clearly differentiated from data-fetching tools, but the boundary between statistical and activity analysis tools is slightly blurred.
Naming Consistency5/5
All tool names follow a consistent verb_noun pattern (e.g., generate_portfolio_summary, get_contribution_activity, list_repositories), using snake_case throughout. The naming is predictable and readable, with no deviations in style or convention across the set.
Tool Count5/5
With 8 tools, the count is well-scoped for a GitHub analytics server, covering key areas like repository listing, details, stats, activity, skills analysis, and project search. Each tool serves a specific function without redundancy, making the set manageable and purposeful.
Completeness4/5
The toolset provides comprehensive coverage for GitHub portfolio and analytics, including data retrieval (repositories, commits, details), statistical analysis, skills assessment, and project filtering. A minor gap is the lack of tools for modifying or interacting with GitHub (e.g., creating issues or pull requests), but this aligns with the server's focus on insight rather than action.
Average 3.7/5 across 8 of 8 tools scored. Lowest: 3.1/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

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. While it mentions what metrics are returned, it doesn't describe important behavioral aspects such as data sources (e.g., GitHub API), time ranges covered, authentication requirements, rate limits, or error handling. The description adds some context about the analysis but leaves significant gaps for a tool with no annotation coverage.
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 appropriately sized with two sentences: the first states the purpose and lists metrics, and the second provides usage context. It's front-loaded with key information and avoids unnecessary repetition. However, the second sentence could be more specific to enhance clarity without adding bulk.
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 the tool's complexity (analyzing contribution activity with multiple metrics), lack of annotations, and no output schema, the description is incomplete. It doesn't specify data sources, time frames, or what the returned metrics look like (e.g., formats, units). For a tool with no structured output and behavioral gaps, more detail is needed to be fully helpful.
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 has 1 parameter with 100% description coverage, providing clear documentation for 'use_cache.' The description doesn't add any parameter-specific information beyond what's in the schema. According to the rules, with high schema coverage (>80%), the baseline is 3 even with no param info in the description, which applies here.
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 states the tool's purpose with a specific verb ('analyzes') and resource ('contribution activity'), and lists concrete metrics returned (total commits, repositories contributed to, most active day, contribution streak). However, it doesn't explicitly differentiate from sibling tools like 'get_recent_commits' or 'get_repository_stats', which might also provide overlapping activity metrics.
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 provides implied usage context by stating it's 'useful for understanding development patterns and activity trends,' which suggests when this tool might be appropriate. However, it lacks explicit guidance on when to use this tool versus alternatives like 'get_recent_commits' or 'generate_portfolio_summary,' and doesn't mention any prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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. It mentions the tool 'creates' a summary, implying a write/generation operation, but doesn't disclose behavioral traits such as data sources (e.g., GitHub, user input), processing time, error handling, or output format. The description adds minimal context beyond the basic action, leaving significant gaps in understanding how the tool behaves.
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 appropriately sized and front-loaded with the core purpose. It uses an emoji and formatting for emphasis, which is slightly decorative but not wasteful. Each sentence adds value: the first defines the tool, the second lists components, and the third specifies optimization. However, it could be more streamlined by integrating the optimization note into the first sentence.
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?
Given no annotations, no output schema, and a simple input schema, the description provides basic purpose and context but lacks completeness. It doesn't explain what the output looks like (e.g., format, structure), data sources, or limitations. For a tool that generates a complex summary, more details on behavior and results would be helpful to compensate for the missing structured data.
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 input schema has 1 parameter with 100% description coverage, so the baseline is 3. The description doesn't mention parameters directly, but it implies the tool generates a comprehensive summary without needing user-provided data, which adds semantic context about the tool's operation beyond the schema's technical details for 'use_cache'.
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 states the tool's purpose: 'Creates a recruiter-friendly portfolio summary' with specific components listed (candidate profile, professional summary, etc.). It distinguishes itself from sibling tools by focusing on summary generation rather than data retrieval or analysis. However, it doesn't explicitly contrast with specific siblings like 'get_skills_matrix' which might overlap in technical assessment.
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 context ('Optimized for HR review and candidate evaluation') but doesn't provide explicit guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, when not to use it, or direct comparisons with sibling tools like 'get_skills_matrix' for technical proficiency or 'list_repositories' for project details.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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. It discloses return metadata and sorting/limiting behavior, but lacks critical details such as pagination, rate limits, authentication needs, error handling, or whether the operation is read-only (implied but not stated). For a tool with no annotations, this leaves significant behavioral 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 front-loaded with the core purpose, followed by return details and optional features. Every sentence adds value without redundancy, making it efficient and well-structured.
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?
Given no annotations and no output schema, the description provides basic purpose and return metadata but lacks completeness for a tool with 3 parameters and behavioral complexity. It should cover more about usage context, error cases, or output format to be fully adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents parameters. The description adds minimal value by mentioning sorting options and limiting results, which are already covered in the schema. Baseline 3 is appropriate 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 specific action ('Lists all public repositories'), identifies the resource ('for GitHub user: octocat'), and distinguishes from siblings by focusing on listing repositories rather than details, stats, or other repository-related operations. It explicitly mentions the scope ('public repositories') and target user.
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 like 'get_repository_details' or 'search_projects_by_tech'. The description mentions sorting and limiting options but does not explain use cases or prerequisites for selecting this tool over siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/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 mentions 'advanced filtering and sorting' but doesn't disclose critical traits like whether this is a read-only operation, potential rate limits, authentication requirements, or what the output format looks like. For a search tool with zero annotation coverage, this leaves significant gaps in understanding its 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 efficiently structured in two sentences: the first states the core functionality, and the second provides usage guidance with examples. Every sentence earns its place with no wasted words, and it's appropriately front-loaded with the main purpose.
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?
Given the tool's complexity (6 parameters, no output schema, no annotations), the description is adequate but incomplete. It covers the purpose and basic usage well, but lacks behavioral transparency and output information. For a search tool with multiple parameters and no structured output documentation, it should provide more context about results format and limitations.
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 schema description coverage is 100%, so the schema already documents all 6 parameters thoroughly. The description adds minimal value beyond the schema by mentioning 'technology stack' and 'programming language' (covered by 'language' parameter) and 'topics' (covered by 'topic' parameter), but doesn't provide additional semantic context. This meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific verb ('Searches and filters') and resource ('repositories') with precise criteria ('by technology stack, programming language, topics, or minimum stars'), and distinguishes itself from siblings like 'list_repositories' by emphasizing advanced filtering capabilities. The example categories further clarify its specialized purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool ('to find projects by category') with specific examples, but it doesn't explicitly state when not to use it or name alternatives among sibling tools. It implies usage for filtered searches versus basic listing, but lacks explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 of behavioral disclosure. It describes the return data (SHA, message, author, date, URL) and implies a read-only operation, but lacks details on permissions, rate limits, or error handling, leaving gaps for a tool with no annotation coverage.
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 efficiently structured in two sentences: the first states the purpose and scope, and the second adds utility context. Every sentence earns its place with no wasted words, making it front-loaded and appropriately sized.
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?
Given the tool's moderate complexity (3 parameters, no annotations, no output schema), the description is adequate but incomplete. It covers the purpose and output format, but lacks details on behavioral traits like error conditions or performance, which are needed for full contextual understanding without annotations or output schema.
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 schema description coverage is 100%, so the schema already documents all parameters thoroughly. The description adds no additional parameter semantics beyond what the schema provides, such as explaining interactions between parameters or edge cases, meeting the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('fetches recent commits') and resource ('for a specific repository or across all repositories'), distinguishing it from siblings like 'get_contribution_activity' or 'list_repositories' by focusing on commit-level data rather than broader metrics or repository lists.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for usage ('useful for tracking recent development activity'), but does not explicitly state when not to use it or name specific alternatives among the sibling tools, such as 'get_contribution_activity' for broader activity metrics.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 of behavioral disclosure. It describes what the tool returns (categorized skills, proficiency levels, domain expertise, project counts), which is helpful, but does not cover aspects like performance characteristics, error handling, or data freshness implications of the 'use_cache' parameter. It adds value but lacks comprehensive behavioral details.
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 appropriately sized and front-loaded, starting with the main purpose and key outputs. It uses an emoji and formatting ('🎯 RECRUITER TOOL:') for emphasis, but the sentence structure is slightly verbose with multiple listed details; every sentence earns its place by clarifying scope and use case.
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?
Given the tool's complexity (analyzing all repositories for skills) and lack of annotations and output schema, the description does a good job of explaining what it returns and its purpose. However, it could be more complete by detailing output format or limitations, such as how proficiency levels are calculated or if there are any constraints on repository analysis.
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 has 100% description coverage, with the 'use_cache' parameter well-documented in the schema. The description does not add any parameter-specific information beyond what the schema provides, so it meets the baseline of 3 for high schema coverage without compensating with extra insights.
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 purpose with specific verbs ('Generates a comprehensive skills matrix analyzing all repositories') and resources ('all repositories'). It distinguishes from siblings by focusing on skills analysis rather than summaries, activity, commits, details, stats, listings, or project 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 provides clear context for when to use this tool ('Perfect for HR screening and technical assessment'), which implies usage in recruitment scenarios. However, it does not explicitly state when not to use it or name alternatives among the sibling tools, such as when simpler repository stats might suffice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/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 mentions what information is returned (metadata, topics, README, etc.), which adds context beyond the input schema. However, it doesn't disclose behavioral traits like rate limits, authentication needs, error handling, or whether it's a read-only operation (though 'Gets' implies safe read).
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 purpose and specific details, followed by a usage hint. Every sentence adds value without redundancy, making it efficient and easy to parse.
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?
Given no annotations and no output schema, the description does a good job explaining what the tool returns and its purpose. It covers the tool's scope well, but could improve by adding more behavioral context (e.g., read-only nature, potential errors) to compensate for the lack of structured data.
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?
Schema description coverage is 100%, so the schema fully documents all parameters. The description adds value by implying the scope of information retrieved (e.g., 'including full metadata, topics, README content'), which helps contextualize the parameters' effects, but doesn't provide additional syntax or format details beyond the 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 clearly states the verb 'Gets' and resource 'detailed information about a specific repository', with specific examples of what's included (metadata, topics, README, etc.). It distinguishes from siblings like 'list_repositories' (which lists multiple) and 'get_repository_stats' (which might focus on statistics rather than comprehensive details).
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 for 'deep-diving into a particular project', suggesting it's for detailed analysis rather than overviews. However, it doesn't explicitly state when to use this vs. alternatives like 'get_repository_stats' or 'list_repositories', nor does it mention prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/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 describes what the tool calculates (e.g., statistics like total stars, language breakdown) but lacks details on performance aspects (e.g., computation time, data freshness), error handling, or output format. The mention of 'use_cache' in the schema hints at caching behavior, but the description does not elaborate on this or other operational traits.
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 appropriately sized and front-loaded, starting with the core function and listing key statistics in a clear, bullet-like format. Every sentence adds value by specifying the tool's output and use case without redundancy or unnecessary details, making it efficient and easy to understand.
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?
Given the tool's complexity (aggregating statistics across all repositories) and the absence of both annotations and an output schema, the description is somewhat incomplete. It outlines what statistics are calculated but does not specify the return structure, data granularity, or potential limitations (e.g., handling of large datasets). This leaves gaps for an AI agent to understand the full behavioral 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?
The input schema has 1 parameter with 100% description coverage, so the schema already documents it well. The description does not add any parameter-specific information beyond what the schema provides, but since there is only one parameter and schema coverage is high, the baseline is strong. No additional semantic context is needed, but the description could have explained the impact of caching on the statistics.
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 purpose with a specific verb ('calculates') and resource ('aggregate statistics across all repositories'), and it distinguishes itself from siblings by focusing on comprehensive analytics rather than listing, searching, or detailing individual repositories. It explicitly lists the types of statistics included, such as total count, stars, forks, language breakdown, and recent updates.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool ('Perfect for portfolio summaries and analytics'), which helps differentiate it from siblings like list_repositories or get_repository_details. However, it does not explicitly state when not to use it or name specific alternatives for overlapping functions, such as generate_portfolio_summary, which might serve a similar purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![GitInsight-MCP MCP server](https://glama.ai/mcp/servers/marwaniiwael18/GitInsight-MCP/badges/card.svg)](https://glama.ai/mcp/servers/marwaniiwael18/GitInsight-MCP)

Score Badge

Copy to your README.md:

[![GitInsight-MCP MCP server](https://glama.ai/mcp/servers/marwaniiwael18/GitInsight-MCP/badges/score.svg)](https://glama.ai/mcp/servers/marwaniiwael18/GitInsight-MCP)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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/marwaniiwael18/GitInsight-MCP'

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