How do I use mcp-server-grf?

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., "@mcp-server-grf add the lodash repository to my project references" 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.

mcp-server-grf

by haiyewei

Overview Schema Source Related Servers Discussions Admin

TypeScript

Local

mcp-server-grf

中文文档

npm version License: MIT Node.js Version

MCP server for managing Git reference repositories - add, load, and sync reference code from any Git repository.

Overview

mcp-server-grf (Git Reference) is a Model Context Protocol (MCP) server that enables AI assistants to manage Git reference repositories. It allows you to:

Add any Git repository as a reference code source
Load reference code into your current project
Sync loaded reference code to the latest version
Manage globally cached repositories

Primary Use Case

When an AI assistant needs to reference code implementations from open-source projects, this tool enables quick loading of reference code into the current working directory for the AI to read and learn from.

Related MCP server: MCP Git Enhanced

Features

Smart URL Parsing - Supports both HTTPS and SSH Git URL formats
Flexible Repository Matching - Match by full name, owner/repo, or just repo name
Shallow Clone Optimization - Uses shallow clones by default to save disk space and download time
Automatic .gitignore Management - Automatically adds loaded reference code to .gitignore
Subdirectory Loading - Load only specific subdirectories from a repository
Multi-Workspace Support - Independently manage loading state across different projects
Sync Status Tracking - Track commit ID changes and support incremental sync

Installation

Using npx (Recommended)

No installation required - run directly with npx:

npx mcp-server-grf

Global Installation

npm install -g mcp-server-grf

Then run:

mcp-server-grf

Configuration

Claude Desktop

Add the following to your Claude Desktop configuration file:

macOS: ~/Library/Application Support/Claude/claude_desktop_config.json Windows: %APPDATA%\Claude\claude_desktop_config.json

{
  "mcpServers": {
    "grf": {
      "command": "npx",
      "args": ["-y", "mcp-server-grf"]
    }
  }
}

Other MCP Clients

For other MCP-compatible clients, configure the server command as:

npx -y mcp-server-grf

Tools Reference

Repository Management

`grf_add`

Add a reference repository to the global cache.

Parameter	Type	Required	Default	Description
`url`	string	Yes	-	Git repository URL (HTTPS or SSH format)
`name`	string	No	-	Custom repository name
`branch`	string	No	-	Specify branch
`shallow`	boolean	No	`true`	Use shallow clone
`depth`	number	No	`1`	Shallow clone depth

`grf_list`

List all cached repositories.

No parameters required.

`grf_get`

Get detailed information about a repository.

Parameter	Type	Required	Description
`name`	string	Yes	Repository name (supports full name or short name)

`grf_update`

Update cached repositories.

Parameter	Type	Required	Default	Description
`name`	string	No	-	Repository name (updates all if not specified)
`checkOnly`	boolean	No	`false`	Only check for updates, don't pull

`grf_clean`

Clean cached repositories.

Parameter	Type	Required	Default	Description
`name`	string	No	-	Repository name to delete
`all`	boolean	No	`false`	Delete all cached repositories

`grf_switch_branch`

Switch repository branch.

Parameter	Type	Required	Description
`name`	string	Yes	Repository name
`branch`	string	Yes	Target branch

Loading/Unloading

`grf_load`

Copy reference repository to the current directory.

Parameter	Type	Required	Default	Description
`name`	string	Yes	-	Repository name, short name, or Git URL
`targetPath`	string	No	`.gitreference/<repo-path>`	Target path
`subdir`	string	No	-	Only copy specified subdirectory
`updateGitignore`	boolean	No	`true`	Update .gitignore
`branch`	string	No	-	Specify branch (only for Git URL)
`workingDirectory`	string	No	Current directory	Working directory

`grf_unload`

Remove reference code from the project.

Parameter	Type	Required	Default	Description
`name`	string	No	-	Repository name
`all`	boolean	No	`false`	Remove all reference code
`workingDirectory`	string	No	Current directory	Working directory

`grf_loaded`

List loaded reference code.

Parameter	Type	Required	Default	Description
`workingDirectory`	string	No	Current directory	Working directory (returns all if not specified)
`all`	boolean	No	`false`	Return loading entries for all working directories

Synchronization

`grf_sync`

Sync loaded reference code to the latest version.

Parameter	Type	Required	Default	Description
`entryId`	string	No	-	Entry ID (specify entry to sync)
`all`	boolean	No	`false`	Sync all entries
`force`	boolean	No	`false`	Force sync (ignore version check)
`workingDirectory`	string	No	Current directory	Working directory

`grf_sync_status`

Get sync status of loaded reference code.

Parameter	Type	Required	Default	Description
`workingDirectory`	string	No	Current directory	Working directory

Configuration

`grf_config`

Manage global configuration.

Parameter	Type	Required	Description
`action`	string	Yes	Operation type: `get`, `set`, or `list`
`key`	string	No	Configuration key (required for get/set)
`value`	string/number/boolean	No	Configuration value (required for set)

Usage Examples

Basic Workflow

Add a reference repository:

grf_add url="https://github.com/expressjs/express"

Load reference code into your project:
```
grf_load name="express"
```
Check loaded references:
```
grf_loaded
```
Sync to latest version:
```
grf_sync all=true
```
Remove reference code when done:
```
grf_unload name="express"
```

Load Specific Subdirectory

Load only the lib directory from a repository:

grf_load name="express" subdir="lib"

Quick Load from URL

Load directly from a Git URL without pre-adding:

grf_load name="https://github.com/lodash/lodash" subdir="src"

Check for Updates

Check if updates are available without pulling:

grf_update checkOnly=true

Configuration Options

Key	Type	Default	Description
`defaultBranch`	string	`"main"`	Default branch name
`shallowClone`	boolean	`true`	Use shallow clone
`shallowDepth`	number	`1`	Shallow clone depth

View/Modify Configuration

# List all configuration
grf_config action="list"

# Get specific configuration
grf_config action="get" key="shallowClone"

# Set configuration
grf_config action="set" key="shallowDepth" value=5

Data Storage

Global Storage

~/.gitreference/
├── config.json           # Global configuration
├── repos-index.json      # Repository index
├── loading-state.json    # Loading state records
└── repos/                # Cached repositories

Project Local Storage

<project>/
├── .gitreference/        # Default loading directory
└── .gitignore            # Automatically adds .gitreference/ entry

Requirements

Node.js >= 18.0.0
Git installed and available in PATH

License

MIT

Available Tools

12 tools

grf_addD

ParametersJSON Schema

Name	Required	Description
`url`	Yes	Git 仓库 URL（支持 HTTPS 和 SSH 格式）
`name`	No	自定义仓库名称
`depth`	No	浅克隆深度（默认: 1）
`branch`	No	指定分支
`shallow`	No	是否浅克隆（默认: true）

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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

Parameters1/5

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

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

grf_cleanD

ParametersJSON Schema

Name	Required	Description	Default
`all`	No	删除所有缓存的仓库
`name`	No	要删除的仓库名称

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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

Parameters1/5

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

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

grf_configD

ParametersJSON Schema

Name	Required	Description
`key`	No	配置键名（get/set 时需要）
`value`	No	配置值（set 时需要）
`action`	Yes	操作类型: get/set/list

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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

Parameters1/5

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

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

grf_getD

ParametersJSON Schema

Name	Required	Description	Default
`name`	Yes	仓库名称（支持完整名称或简短名称）

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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

Parameters1/5

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

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

grf_listD

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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

Parameters1/5

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

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

grf_loadD

ParametersJSON Schema

Name	Required	Description
`name`	Yes	仓库名称、简短名称或 Git URL
`branch`	No	指定分支（仅对 Git URL 有效）
`subdir`	No	只复制指定子目录
`targetPath`	No	目标路径（默认: .gitreference/<repo-path>）
`updateGitignore`	No	是否更新 .gitignore（默认: true）
`workingDirectory`	No	工作目录（默认: 当前目录）

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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

Parameters1/5

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

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

grf_loadedD

ParametersJSON Schema

Name	Required	Description	Default
`all`	No	返回所有工作目录的加载条目
`workingDirectory`	No	工作目录（默认: 当前目录，不指定则返回所有）

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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

Parameters1/5

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

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

grf_switch_branchD

ParametersJSON Schema

Name	Required	Description	Default
`name`	Yes	仓库名称
`branch`	Yes	目标分支

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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

Parameters1/5

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

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

grf_syncD

ParametersJSON Schema

Name	Required	Description
`all`	No	同步所有条目
`force`	No	强制同步（忽略版本检查）
`entryId`	No	条目 ID（可选，指定要同步的条目）
`workingDirectory`	No	工作目录（默认: 当前目录）

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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

Parameters1/5

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

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

grf_sync_statusD

ParametersJSON Schema

Name	Required	Description	Default
`workingDirectory`	No	工作目录（默认: 当前目录）

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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

Parameters1/5

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

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

grf_unloadD

ParametersJSON Schema

Name	Required	Description
`all`	No	移除所有参考代码
`name`	No	仓库名称
`workingDirectory`	No	工作目录（默认: 当前目录）

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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

Parameters1/5

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

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

grf_updateD

ParametersJSON Schema

Name	Required	Description	Default
`name`	No	仓库名称（不指定则更新所有）
`checkOnly`	No	仅检查更新，不拉取

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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

Parameters1/5

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

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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.

12 tool updatesv1.0.0Sep 13, 2026
- First observedgrf_add
- First observedgrf_clean
- First observedgrf_config
- First observedgrf_get
- First observedgrf_list
- First observedgrf_load
- First observedgrf_loaded
- First observedgrf_switch_branch
- First observedgrf_sync
- First observedgrf_sync_status
- First observedgrf_unload
- First observedgrf_update

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

D1.8/5.0

Scored 2026-09-13 06:10 across 12 tools

Disambiguation2/5

With no descriptions at all, multiple tools have unclear boundaries: grf_get vs grf_loaded, grf_load vs grf_loaded, and grf_sync vs grf_sync_status are hard to distinguish without context. An agent would likely misselect among these retrieval/state/action tools.

Naming Consistency4/5

All tools use a consistent snake_case convention with the grf_ prefix. However, the pattern is not strictly verb_noun (e.g., grf_loaded, grf_sync_status are noun/adjective forms), so minor deviations exist.

Tool Count4/5

12 tools fall within a reasonable range for a server managing a resource with CRUD, lifecycle, sync, config, and branch operations. The count is not excessive, though without descriptions we cannot confirm every tool is non-redundant.

Completeness4/5

The tool names suggest coverage of CRUD (list, add, get, update, clean), lifecycle (load, unload, loaded), sync (sync, sync_status), config, and branch switching. Minor gaps like explicit delete or search may exist, but the surface appears largely complete for an inferred resource management domain.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

Need Help?

Related Servers

Related MCP Connectors

Gluecron B
com.gluecron
AI-native git hosting — repos, PRs, issues, CI gates, and AI code review over MCP (60 tools).
Version Control CI/CD & DevOps Code Analysis
622
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
Artificial Wit AIOAuth
com.artificialwit
MCP server unifying ERPs, CRMs, APIs and knowledge base for Claude, ChatGPT and Gemini.
ERP Systems CRM Knowledge & Memory
2
neverinfamous-memory-journal-mcp
ai.smithery
A MCP server built for developers enabling Git based project management with project and personal…
Version Control Developer Tools Project Management
320

Related MCP Servers

Git MCP Server
Version Control Developer Tools Code Execution
Sheshiyer
F
license
B
quality
D
maintenance
The Git MCP Server allows AI assistants to perform enhanced Git operations via the Model Context Protocol, supporting core Git functions, branch and tag management, GitHub integration, and more.
Updated 2 years ago (2025-02-12 14:21 UTC)
21
91 npm
6
-
MCP Git Enhanced
Version Control Developer Tools
davidweb3-ctrl
A
license
B
quality
C
maintenance
An enhanced Git MCP server that provides AI assistants with powerful code review, commit analysis, and branch management capabilities for Git repositories.
Updated 4 months ago (2026-06-02 05:17 UTC)
5
34 npm
1
MIT
Git MCP Server
wty0512
A
license
Not graded
quality
D
maintenance
An MCP server that provides tools for interacting with Git repositories, enabling AI assistants to manage repositories, branches, commits, and files through a standardized interface.
Updated a year ago (2025-04-01 04:53 UTC)
3,381 npm
1
Apache 2.0
ctxpeek
Documentation Access Developer Tools
ruwadgroup
A
license
Not graded
quality
C
maintenance
MCP server that fetches documentation from public git repositories at specific versions, enabling AI coding assistants to access up-to-date, ref-pinned docs from source repos.
Updated 22 days ago (2026-08-31 06:13 UTC)
5 npm
2
Apache 2.0