Skip to main content
Glama
deenesjakoruzh
sosacrazy126

greptile-mcp

by sosacrazy126
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

Greptile MCP-Server [ABGESCHLOSSEN]

Spickzettel für Quick Run-Befehle

✅ PROJEKTSTATUS: ALLE AUFGABEN ABGESCHLOSSEN (11.11.)

Eine Zusammenfassung der abgeschlossenen Arbeiten finden Sie in PROJECT_COMPLETION.md und Gebrauchsanweisungen in USER_GUIDE.md .

Umfeld

Einrichten und Installieren

Befehl ausführen

Lokal (Python)

python -m venv .venv && source .venv/bin/activate && pip install -e .

python -m src.main

Docker

docker build -t greptile-mcp .

docker run --rm --env-file .env -p 8050:8050 greptile-mcp

Schmiedekunst

npm install -g smithery

smithery deploy (siehe smithery.yaml)

Füllen Sie .env mit .env.example aus und legen Sie vor dem Ausführen Ihren GREPTILE_API_KEY und GITHUB_TOKEN fest.

Vollständige Informationen zu den Voraussetzungen, zur erweiterten Agentennutzung, zur Integration und zur Fehlerbehebung: Die vollständige Dokumentation finden Sie in docs/README.md und Agentendetails in AGENT_USAGE.md .

Eine MCP-Serverimplementierung (Model Context Protocol), die in die Greptile-API integriert ist, um KI-Agenten Codesuch- und Abfragefunktionen bereitzustellen.

Schmiedeabzeichen

Merkmale

Der Server bietet vier wichtige Greptile-Tools, die es KI-Agenten ermöglichen, mit Codebasen zu interagieren:

  1. index_repository : Indizieren Sie ein Repository für die Codesuche und -abfrage.

    • Verarbeiten Sie ein Repository, um es durchsuchbar zu machen

    • Aktualisieren Sie vorhandene Indizes, wenn sich die Repositorys ändern

    • Konfigurieren der Benachrichtigungseinstellungen

  2. query_repository : Abfrage von Repositories, um Antworten mit Codereferenzen zu erhalten.

    • Stellen Sie Fragen zur Codebasis in natürlicher Sprache

    • Erhalten Sie detaillierte Antworten, die auf bestimmte Codepositionen verweisen

    • Unterstützung für den Gesprächsverlauf mit Sitzungs-IDs

  3. search_repository : Durchsucht Repositories nach relevanten Dateien, ohne eine vollständige Antwort zu generieren.

    • Suchen Sie nach Dateien, die sich auf bestimmte Konzepte oder Funktionen beziehen

    • Erhalten Sie kontextbezogene Übereinstimmungen nach Relevanz sortiert

    • Schneller als vollständige Abfragen, wenn nur Dateispeicherorte benötigt werden

  4. get_repository_info : Informationen zu einem indizierten Repository abrufen.

    • Überprüfen Sie den Indexierungsstatus und -fortschritt

    • Überprüfen, welche Repositories für Abfragen verfügbar sind

    • Metadaten zu indizierten Repositories abrufen

Related MCP server: mcp-meilisearch

Smithery-Bereitstellung

Der Greptile MCP-Server unterstützt die Bereitstellung über Smithery. Eine Konfigurationsdatei smithery.yaml ist im Projektstamm enthalten.

Schmiedekonfiguration

Die Smithery-Konfiguration ist in smithery.yaml definiert und unterstützt die folgenden Optionen:

build:
  dockerfile: Dockerfile

startCommand:
  type: stdio
  configSchema:
    type: object
    required:
      - greptileApiKey
      - githubToken
    properties:
      greptileApiKey:
        type: string
        description: "API key for accessing the Greptile API"
      githubToken:
        type: string
        description: "GitHub Personal Access Token for repository access"
      baseUrl:
        type: string
        description: "Base URL for Greptile API"
        default: "https://api.greptile.com/v2"
      host:
        type: string
        description: "Host to bind to when using SSE transport"
        default: "0.0.0.0"
      port:
        type: string
        description: "Port to listen on when using SSE transport"
        default: "8050"

Verwendung mit Schmiedearbeiten

So stellen Sie die Bereitstellung mit Smithery bereit:

  1. Installieren Sie Smithery: npm install -g smithery

  2. Stellen Sie den Server bereit: smithery deploy

  3. Konfigurieren Sie Ihren Smithery-Client mit den erforderlichen API-Schlüsseln

Zusätzliche Dokumentation

Ausführliche Anweisungen zur Verwendung von KI-Agenten finden Sie im Agent Usage Guide .

Voraussetzungen

  • Python 3.12+

  • Greptile API-Schlüssel (von https://app.greptile.com/settings/api )

  • GitHub oder GitLab Personal Access Token (PAT) mit repo Berechtigungen (oder gleichwertigen Leseberechtigungen) für die Repositories, die Sie indizieren möchten

  • Docker (für die Bereitstellung empfohlen)

Erforderliche Python-Pakete

  • fastmcp - MCP-Serverimplementierung

  • httpx – Asynchroner HTTP-Client

  • python-dotenv - Verwaltung von Umgebungsvariablen

  • uvicorn – ASGI-Server für SSE-Transport

Installation

Verwenden von pip (für Entwicklung oder lokale Tests)

  1. Klonen Sie dieses Repository:

    git clone https://github.com/sosacrazy126/greptile-mcp.git
cd greptile-mcp

  2. Erstellen Sie eine virtuelle Umgebung (empfohlen):

    python -m venv .venv
source .venv/bin/activate  # On Windows use `.venv\Scripts\activate`

  3. Installieren Sie Abhängigkeiten:

    pip install -e .

  4. Erstellen Sie eine .env Datei basierend auf .env.example :

    cp .env.example .env

  5. Konfigurieren Sie Ihre Umgebungsvariablen in der .env Datei:

    GREPTILE_API_KEY=your_api_key_here
GITHUB_TOKEN=your_github_token_here

Verwenden von Docker (für die Bereitstellung empfohlen)

  1. Klonen Sie das Repository:

    git clone https://github.com/sosacrazy126/greptile-mcp.git
cd greptile-mcp

  2. Erstellen Sie eine .env Datei basierend auf .env.example und konfigurieren Sie Ihre Umgebungsvariablen.

  3. Erstellen Sie das Docker-Image:

    docker build -t greptile-mcp .

Ausführen des Servers

Verwenden von pip

SSE-Transport (Standard)

Stellen Sie sicher, dass in Ihrer .env Datei TRANSPORT=sse und PORT=8050 (oder Ihr gewählter Port) festgelegt sind.

python -m src.main

Der Server lauscht auf http://<HOST>:<PORT>/sse .

Stdio Transport

Setzen Sie TRANSPORT=stdio in Ihrer .env Datei. Mit stdio startet der MCP-Client normalerweise den MCP-Serverprozess.

# Usually invoked by an MCP client, not directly
TRANSPORT=stdio python -m src.main

Verwenden von Docker

SSE-Transport (Standard)

# Mounts the .env file for configuration and maps the port
docker run --rm --env-file .env -p 8050:8050 greptile-mcp

Der Server lauscht auf http://localhost:8050/sse (oder der Host-IP, wenn es sich nicht um localhost handelt).

Stdio Transport

Konfigurieren Sie Ihren MCP-Client so, dass der Docker-Container mit TRANSPORT=stdio ausgeführt wird.

# Example of running with stdio transport
docker run --rm -i --env-file .env -e TRANSPORT=stdio greptile-mcp

Integration mit MCP-Clients

SSE-Konfigurationsbeispiel

Fügen Sie dies zur Konfiguration Ihres MCP-Clients hinzu (z. B. mcp_config.json ):

{
  "mcpServers": {
    "greptile": {
      "transport": "sse",
      "url": "http://localhost:8050/sse"
    }
  }
}

Python mit Stdio-Konfigurationsbeispiel

Stellen Sie sicher, dass TRANSPORT=stdio in der Umgebung festgelegt ist, in der der Befehl ausgeführt wird:

{
  "mcpServers": {
    "greptile": {
      "transport": "stdio",
      "command": "/path/to/your/greptile-mcp/.venv/bin/python",
      "args": ["-m", "src.main"],
      "env": {
        "TRANSPORT": "stdio",
        "GREPTILE_API_KEY": "YOUR-GREPTILE-API-KEY",
        "GITHUB_TOKEN": "YOUR-GITHUB-TOKEN",
        "GREPTILE_BASE_URL": "https://api.greptile.com/v2"
      }
    }
  }
}

Docker mit Stdio-Konfigurationsbeispiel

{
  "mcpServers": {
    "greptile": {
      "transport": "stdio",
      "command": "docker",
      "args": [
        "run", "--rm", "-i",
        "-e", "TRANSPORT=stdio",
        "-e", "GREPTILE_API_KEY",
        "-e", "GITHUB_TOKEN",
        "-e", "GREPTILE_BASE_URL",
        "greptile-mcp"
      ],
      "env": {
        "GREPTILE_API_KEY": "YOUR-GREPTILE-API-KEY",
        "GITHUB_TOKEN": "YOUR-GITHUB-TOKEN",
        "GREPTILE_BASE_URL": "https://api.greptile.com/v2"
      }
    }
  }
}

Detaillierte Gebrauchsanleitung

Workflow für die Codebasisanalyse

  1. Index-Repositorys, die Sie mit index_repository analysieren möchten

  2. Überprüfen Sie den Indexierungsstatus mit get_repository_info , um sicherzustellen, dass die Verarbeitung abgeschlossen ist

  3. Abfragen der Repositories in natürlicher Sprache mit query_repository

  4. Suchen Sie mithilfe von search_repositorynach bestimmten Dateien, die sich auf Funktionen oder Konzepte beziehen

Sitzungsverwaltung für Konversationskontext

Bei der Interaktion mit dem Greptile MCP-Server über einen beliebigen Client (einschließlich Smithery) ist eine ordnungsgemäße Sitzungsverwaltung für die Aufrechterhaltung des Konversationskontexts von entscheidender Bedeutung:

  1. Generieren Sie zu Beginn einer Konversation eine eindeutige Sitzungs-ID

  2. Verwenden Sie dieselbe Sitzungs-ID für alle zugehörigen Folgeanfragen erneut.

  3. Erstellen Sie eine neue Sitzungs-ID, wenn Sie eine neue Konversation starten

Beispiel für die Sitzungs-ID-Verwaltung:

# Generate a unique session ID
import uuid
session_id = str(uuid.uuid4())

# Initial query
initial_response = query_repository(
    query="How is authentication implemented?",
    repositories=[{"remote": "github", "repository": "owner/repo", "branch": "main"}],
    session_id=session_id  # Include the session ID
)

# Follow-up query using the SAME session ID
followup_response = query_repository(
    query="Can you provide more details about the JWT verification?",
    repositories=[{"remote": "github", "repository": "owner/repo", "branch": "main"}],
    session_id=session_id  # Reuse the same session ID
)

Wichtig für die Smithery-Integration : Agenten, die sich über Smithery verbinden, müssen ihre eigenen Sitzungs-IDs generieren und verwalten. Der Greptile MCP-Server generiert keine Sitzungs-IDs automatisch. Die Sitzungs-ID sollte Teil des Konversationsstatus des Agenten sein.

Bewährte Methoden

  • Indizierungsleistung : Kleinere Repositories indizieren schneller. Bei großen Monorepositorys empfiehlt sich die Indizierung bestimmter Branches oder Tags.

  • Abfrageoptimierung : Seien Sie in Ihren Abfragen spezifisch. Fügen Sie relevante Fachbegriffe ein, um bessere Ergebnisse zu erzielen.

  • Repository-Auswahl : Wenn Sie mehrere Repositories abfragen, listen Sie sie in der Reihenfolge ihrer Relevanz auf, um die besten Ergebnisse zu erzielen.

  • Sitzungsverwaltung : Verwenden Sie Sitzungs-IDs für Folgefragen, um den Kontext über Abfragen hinweg beizubehalten.

API-Referenz

1. Index-Repository

Indiziert ein Repository, um es bei zukünftigen Abfragen durchsuchbar zu machen.

Parameter:

  • remote (Zeichenfolge): Der Repository-Host, entweder „github“ oder „gitlab“

  • repository (Zeichenfolge): Das Repository im Besitzer-/Repo-Format (z. B. „greptileai/greptile“)

  • branch (Zeichenfolge): Der zu indizierende Zweig (z. B. „main“)

  • reload (boolesch, optional): Ob die erneute Verarbeitung eines zuvor indizierten Repositorys erzwungen werden soll

  • notify (Boolesch, optional): Ob eine E-Mail-Benachrichtigung gesendet werden soll, wenn die Indizierung abgeschlossen ist

Beispiel:

// Tool Call: index_repository
{
  "remote": "github",
  "repository": "greptileai/greptile",
  "branch": "main",
  "reload": false,
  "notify": false
}

Antwort:

{
  "message": "Indexing Job Submitted for: greptileai/greptile",
  "statusEndpoint": "https://api.greptile.com/v2/repositories/github:main:greptileai%2Fgreptile"
}

2. Abfrage-Repository

Fragt Repositories in natürlicher Sprache ab, um Antworten mit Codereferenzen zu erhalten.

Parameter:

  • query (Zeichenfolge): Die Abfrage in natürlicher Sprache zur Codebasis

  • repositories (Array): Liste der abzufragenden Repositories, jeweils im Format:

    {
  "remote": "github",
  "repository": "owner/repo",
  "branch": "main"
}

  • session_id (Zeichenfolge, optional): Sitzungs-ID zum Fortsetzen einer Konversation

  • stream (Boolesch, optional): Ob die Antwort gestreamt werden soll

  • genius (Boolesch, optional): Ob erweiterte Abfragefunktionen verwendet werden sollen

Beispiel:

// Tool Call: query_repository
{
  "query": "How is authentication handled in this codebase?",
  "repositories": [
    {
      "remote": "github",
      "repository": "greptileai/greptile",
      "branch": "main"
    }
  ],
  "session_id": null,
  "stream": false,
  "genius": true
}

Antwort:

{
  "message": "Authentication in this codebase is handled using JWT tokens...",
  "sources": [
    {
      "repository": "greptileai/greptile",
      "remote": "github",
      "branch": "main",
      "filepath": "/src/auth/jwt.js",
      "linestart": 14,
      "lineend": 35,
      "summary": "JWT token validation middleware"
    }
  ]
}

3. Repository durchsuchen

Durchsucht Repositories nach relevanten Dateien, ohne eine vollständige Antwort zu generieren.

Parameter:

  • query (Zeichenfolge): Die Suchanfrage zur Codebasis

  • repositories (Array): Liste der zu durchsuchenden Repositories

  • session_id (Zeichenfolge, optional): Sitzungs-ID zum Fortsetzen einer Konversation

  • genius (Boolesch, optional): Ob erweiterte Suchfunktionen verwendet werden sollen

Beispiel:

// Tool Call: search_repository
{
  "query": "Find files related to authentication middleware",
  "repositories": [
    {
      "remote": "github",
      "repository": "greptileai/greptile", 
      "branch": "main"
    }
  ],
  "session_id": null,
  "genius": true
}

Antwort:

{
  "sources": [
    {
      "repository": "greptileai/greptile",
      "remote": "github",
      "branch": "main",
      "filepath": "/src/auth/middleware.js",
      "linestart": 1,
      "lineend": 45,
      "summary": "Authentication middleware implementation"
    },
    {
      "repository": "greptileai/greptile",
      "remote": "github",
      "branch": "main",
      "filepath": "/src/auth/jwt.js",
      "linestart": 1,
      "lineend": 78,
      "summary": "JWT token handling functions"
    }
  ]
}

4. Repository-Informationen abrufen

Ruft Informationen zu einem bestimmten Repository ab, das indiziert wurde.

Parameter:

  • remote (Zeichenfolge): Der Repository-Host, entweder „github“ oder „gitlab“

  • repository (Zeichenfolge): Das Repository im Owner/Repo-Format

  • branch (Zeichenfolge): Der Zweig, der indiziert wurde

Beispiel:

// Tool Call: get_repository_info
{
  "remote": "github",
  "repository": "greptileai/greptile",
  "branch": "main"
}

Antwort:

{
  "repository": "greptileai/greptile",
  "remote": "github",
  "branch": "main",
  "private": false,
  "status": "COMPLETED",
  "filesProcessed": 234,
  "numFiles": 234,
  "sha": "a1b2c3d4e5f6..."
}

Integrationsbeispiele

1. Integration mit Claude.ai über die Anthropic API

from anthropic import Anthropic
import json
import requests

# Set up Anthropic client
anthropic = Anthropic(api_key="your_anthropic_key")

# Function to call Greptile MCP
def query_code(question, repositories):
    response = requests.post(
        "http://localhost:8050/tools/greptile/query_repository",
        json={
            "query": question,
            "repositories": repositories,
            "genius": True
        }
    )
    return json.loads(response.text)

# Ask Claude with enhanced code context
def ask_claude_with_code_context(question, repositories):
    # Get code context from Greptile
    code_context = query_code(question, repositories)
    
    # Format the context for Claude
    formatted_context = f"Code Analysis Result:\n{code_context['message']}\n\nRelevant Files:\n"
    for source in code_context.get('sources', []):
        formatted_context += f"- {source['filepath']} (lines {source['linestart']}-{source['lineend']})\n"
    
    # Send to Claude with context
    message = anthropic.messages.create(
        model="claude-3-opus-20240229",
        max_tokens=1000,
        messages=[
            {"role": "user", "content": f"Based on this code context:\n\n{formatted_context}\n\nQuestion: {question}"}
        ]
    )
    
    return message.content

# Example usage
answer = ask_claude_with_code_context(
    "How does the authentication system work?",
    [{"remote": "github", "repository": "greptileai/greptile", "branch": "main"}]
)
print(answer)

2. Integration mit einem LLM-basierten Chatbot

from fastapi import FastAPI, Request
from fastapi.responses import JSONResponse
import httpx
import json

app = FastAPI()

# Greptile MCP endpoint
GREPTILE_MCP_URL = "http://localhost:8050/tools/greptile"

@app.post("/chat")
async def chat_endpoint(request: Request):
    data = await request.json()
    user_message = data.get("message", "")
    
    # Check if this is a code-related question
    if "code" in user_message or "repository" in user_message or "function" in user_message:
        # Query the repository through Greptile MCP
        async with httpx.AsyncClient() as client:
            response = await client.post(
                f"{GREPTILE_MCP_URL}/query_repository",
                json={
                    "query": user_message,
                    "repositories": [
                        {"remote": "github", "repository": "your-org/your-repo", "branch": "main"}
                    ],
                    "genius": True
                }
            )
            
            greptile_result = response.json()
            
            # Process the result and return to the user
            answer = greptile_result.get("message", "")
            sources = greptile_result.get("sources", [])
            
            return JSONResponse({
                "message": answer,
                "code_references": sources
            })
    
    # For non-code questions, use your regular LLM
    return JSONResponse({
        "message": "This appears to be a general question. I'll handle it normally."
    })

# Run with: uvicorn app:app --reload

3. Tool zur Abfrage von Befehlszeilencode

#!/usr/bin/env python3
import argparse
import json
import requests
import sys

def main():
    parser = argparse.ArgumentParser(description="Query code repositories using natural language")
    parser.add_argument("query", help="The natural language query about the code")
    parser.add_argument("--repo", "-r", required=True, help="Repository in format github:owner/repo:branch")
    parser.add_argument("--genius", "-g", action="store_true", help="Use enhanced query capabilities")
    args = parser.parse_args()
    
    # Parse the repository string
    try:
        remote, repo_path = args.repo.split(":", 1)
        if ":" in repo_path:
            repo, branch = repo_path.split(":", 1)
        else:
            repo = repo_path
            branch = "main"
    except ValueError:
        print("Error: Repository must be in format 'github:owner/repo:branch' or 'github:owner/repo'")
        sys.exit(1)
        
    # Prepare the request
    payload = {
        "query": args.query,
        "repositories": [
            {
                "remote": remote,
                "repository": repo,
                "branch": branch
            }
        ],
        "genius": args.genius
    }
    
    # Make the request
    try:
        response = requests.post(
            "http://localhost:8050/tools/greptile/query_repository",
            json=payload
        )
        response.raise_for_status()
    except requests.exceptions.RequestException as e:
        print(f"Error: {e}")
        sys.exit(1)
    
    # Process the response
    result = response.json()
    
    # Display the answer
    print("\n=== ANSWER ===\n")
    print(result.get("message", "No answer found"))
    
    # Display the sources
    sources = result.get("sources", [])
    if sources:
        print("\n=== CODE REFERENCES ===\n")
        for i, source in enumerate(sources, 1):
            print(f"{i}. {source['filepath']} (lines {source.get('linestart', '?')}-{source.get('lineend', '?')})")
            print(f"   Repository: {source['repository']} ({source['branch']})")
            if 'summary' in source:
                print(f"   Summary: {source['summary']}")
            print()

if __name__ == "__main__":
    main()

Fehlerbehebung

Häufige Probleme

1. Authentifizierungsfehler

Symptom : Sie erhalten die Fehlermeldung 401 Unauthorized oder Repository not found with configured credentials .

Lösungen :

  • Überprüfen Sie, ob Ihr Greptile-API-Schlüssel gültig und in der .env Datei korrekt festgelegt ist.

  • Überprüfen Sie, ob Ihr GitHub/GitLab-Token abgelaufen ist (normalerweise verfallen sie nach einer festgelegten Zeit).

  • Stellen Sie sicher, dass Ihr GitHub/GitLab-Token den repo Bereich für den Zugriff auf Repositories hat

  • Testen Sie Ihr GitHub-Token direkt mit der GitHub-API, um sicherzustellen, dass es funktioniert

Testen des GitHub-Tokens :

curl -H "Authorization: token YOUR_GITHUB_TOKEN" https://api.github.com/user

2. Repository nicht gefunden

Symptom : Die API gibt einen 404-Fehler oder die Meldung „Repository nicht gefunden“ zurück.

Lösungen :

  • Überprüfen Sie, ob das Repository vorhanden ist und mit Ihrem GitHub/GitLab-Token darauf zugegriffen werden kann.

  • Überprüfen Sie das Repository-Format (es sollte owner/repo lauten).

  • Stellen Sie bei privaten Repositories sicher, dass Ihr Token über die entsprechenden Zugriffsberechtigungen verfügt

  • Überprüfen Sie, ob der Zweigstellenname korrekt ist

3. Verbindungsprobleme

Symptom : Es kann keine Verbindung zum MCP-Server hergestellt werden.

Lösungen :

  • Überprüfen Sie, ob der Server läuft ( ps aux | grep src.main )

  • Stellen Sie sicher, dass der Port nicht von einer anderen Anwendung verwendet wird

  • Überprüfen Sie die Netzwerkeinstellungen und Firewall-Konfigurationen

  • Versuchen Sie einen anderen Port, indem Sie den PORT Wert in Ihrer .env Datei ändern

4. Docker-Probleme

Symptom : Der Docker-Container kann nicht gestartet werden oder funktioniert nicht richtig.

Lösungen :

  • Überprüfen Sie die Docker-Protokolle: docker logs <container_id>

  • Überprüfen Sie, ob die .env Datei korrekt gemountet ist.

  • Stellen Sie sicher, dass die Portzuordnung in Ihrem docker run -Befehl korrekt ist.

  • Überprüfen Sie, ob die Docker-Netzwerkkonfiguration die erforderlichen Verbindungen zulässt

Protokolle und Debugging

Um eine ausführlichere Protokollierung zu aktivieren, legen Sie die folgenden Umgebungsvariablen fest:

# Add to your .env file
DEBUG=true
LOG_LEVEL=debug

Um Probleme mit bestimmten MCP-Interaktionen zu beheben, untersuchen Sie die MCP-Serverprotokolle:

# Run with enhanced logging
LOG_LEVEL=debug python -m src.main

Erweiterte Konfiguration

Umgebungsvariablen

Variable

Beschreibung

Standard

TRANSPORT

Transportmethode ( sse oder stdio )

sse

HOST

Host, an den für den SSE-Transport gebunden werden soll

0.0.0.0

PORT

Hafen für SSE-Transport

8050

GREPTILE_API_KEY

Ihr Greptile-API-Schlüssel

(erforderlich)

GITHUB_TOKEN

Persönlicher GitHub/GitLab-Zugriffstoken

(erforderlich)

GREPTILE_BASE_URL

Basis-URL der Greptile-API

https://api.greptile.com/v2

DEBUG

Debug-Modus aktivieren

false

LOG_LEVEL

Protokollierungsebene

info

Benutzerdefinierte API-Endpunkte

Wenn Sie einen benutzerdefinierten Greptile-API-Endpunkt verwenden müssen (z. B. für Unternehmensinstallationen), ändern Sie die Umgebungsvariable GREPTILE_BASE_URL :

GREPTILE_BASE_URL=https://greptile.your-company.com/api/v2

Leistungsoptimierung

Berücksichtigen Sie bei Produktionsbereitstellungen die folgenden Leistungsoptimierungen:

  1. Worker-Konfiguration : Wenn Sie SSE-Transport mit Uvicorn verwenden, konfigurieren Sie die entsprechende Worker-Anzahl:

    # For CPU-bound applications: workers = 1-2 × CPU cores
uvicorn src.main:app --workers 4

  2. Timeout-Einstellungen : Passen Sie Timeouts für große Repositories an:

    # Add to .env
GREPTILE_TIMEOUT=120.0  # Default is 60.0 seconds

  3. Speicheroptimierung : Berücksichtigen Sie bei großen Bereitstellungen die Ressourcenbeschränkungen des Containers:

    docker run --rm --env-file .env -p 8050:8050 --memory="1g" --cpus="1.0" greptile-mcp

Beitragen

Beiträge sind willkommen! Senden Sie gerne einen Pull Request.

  1. Forken Sie das Repository

  2. Erstellen Sie Ihren Feature-Zweig ( git checkout -b feature/amazing-feature )

  3. Übernehmen Sie Ihre Änderungen ( git commit -m 'Add some amazing feature' )

  4. Pushen zum Zweig ( git push origin feature/amazing-feature )

  5. Öffnen einer Pull-Anfrage

Entwicklungs-Setup

Installieren Sie für die Entwicklung zusätzliche Abhängigkeiten:

pip install -e ".[dev]"

Führen Sie Tests durch:

pytest

Lizenz

Dieses Projekt ist unter der MIT-Lizenz lizenziert – Einzelheiten finden Sie in der Datei LICENSE.

Erstellt von ( https://github.com/sosacrazy126 )

Available Tools

5 tools
get_repository_infoC

Get information about an indexed repository including status and metadata

ParametersJSON Schema
NameRequiredDescriptionDefault
remoteYesRepository host
repositoryYesRepository in owner/repo format
branchYesBranch that was indexed

TDQS

C2.9/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. It states the tool retrieves information, implying it's read-only, but doesn't disclose behavioral traits like authentication requirements, rate limits, error conditions, or what 'indexed' means operationally. The description is minimal and lacks context about the tool's behavior beyond its basic function.

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, efficient sentence that front-loads the core purpose. Every word earns its place, with no redundant or vague language. It's appropriately sized for a simple retrieval tool.

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 no annotations and no output schema, the description is incomplete for a tool with 3 required parameters. It doesn't explain what 'indexed' entails, what 'status and metadata' includes, or the response format. For a retrieval tool with structured inputs, more context is needed to guide effective use.

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%, with clear descriptions for all parameters (e.g., 'Repository host', 'Repository in owner/repo format', 'Branch that was indexed'). The description adds no additional semantic meaning beyond the schema, such as explaining format constraints or relationships between parameters. 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.

Purpose4/5

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

The description clearly states the verb 'Get' and the resource 'information about an indexed repository', specifying it includes 'status and metadata'. This distinguishes it from sibling tools like 'index_repository' (which creates) and 'query_repository' (which searches content), but doesn't explicitly differentiate from 'greptile_env_check' or 'greptile_help' in terms of scope.

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 doesn't mention prerequisites (e.g., that the repository must already be indexed), exclusions, or compare to siblings like 'query_repository' for different types of information needs. Usage is implied but not explicitly stated.

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

greptile_env_checkB

Check environment variable configuration and setup status

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

B3.2/5.0
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 states what the tool does but doesn't describe how it behaves—for example, whether it's a read-only check, what output format to expect, if it has side effects, or any error conditions. This leaves significant gaps in understanding the tool's operational characteristics.

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, efficient sentence that directly states the tool's function without any wasted words. It's appropriately sized for a simple tool and front-loaded with the core purpose, making it easy for an agent to parse quickly.

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 simplicity (0 parameters, no output schema, no annotations), the description is adequate but has clear gaps. It explains what the tool does but lacks details on behavioral traits, usage context, or output expectations, which are important even for simple tools to ensure correct invocation.

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 0 parameters, and the input schema has 100% description coverage (though empty). The description doesn't need to add parameter information, so it appropriately focuses on the tool's purpose. A baseline score of 4 is applied since no parameters exist, and the description doesn't attempt to explain nonexistent parameters.

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 as checking environment variable configuration and setup status, which is a specific verb+resource combination. However, it doesn't differentiate itself from sibling tools like 'get_repository_info' or 'greptile_help', which might also provide status information, so it doesn't reach the highest score.

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 doesn't mention any prerequisites, exclusions, or specific contexts for usage, leaving the agent to infer when this check is appropriate compared to other tools on the server.

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

greptile_helpA

Get comprehensive help and usage examples for all Greptile MCP tools

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

A3.6/5.0
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 states the tool provides 'comprehensive help and usage examples,' which suggests it's a read-only, informational resource without side effects. However, it lacks details on behavioral traits like response format, potential rate limits, or error handling, which would be useful given the absence of annotations.

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

Conciseness5/5

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

The description is a single, efficient sentence that clearly conveys the tool's function without any wasted words. It's front-loaded with the core purpose ('Get comprehensive help and usage examples') and specifies the scope ('for all Greptile MCP tools'), making it easy to understand at a glance.

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 simplicity (0 parameters, no output schema, no annotations), the description is adequate but could be more complete. It covers the basic purpose but doesn't address potential context like what 'comprehensive help' includes, whether it's interactive, or how it integrates with sibling tools. For a help tool in this environment, more detail on output or usage scenarios would enhance completeness.

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 0 parameters, and schema description coverage is 100%, so there's no need for parameter details in the description. The baseline for 0 parameters is 4, as the description appropriately focuses on the tool's purpose without unnecessary parameter explanations.

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: 'Get comprehensive help and usage examples for all Greptile MCP tools.' It specifies the verb ('Get') and resource ('help and usage examples'), and the scope ('for all Greptile MCP tools') is well-defined. However, it doesn't explicitly differentiate from sibling tools like 'greptile_env_check' which might also provide system information.

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—when users need help or examples for Greptile tools—but doesn't provide explicit guidance on when to use this tool versus alternatives. There's no mention of prerequisites, timing, or comparisons to sibling tools like 'get_repository_info' or 'query_repository', leaving usage somewhat open to interpretation.

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

index_repositoryC

Index a repository to make it searchable for future queries

ParametersJSON Schema
NameRequiredDescriptionDefault
remoteYesRepository host (github or gitlab)
repositoryYesRepository in owner/repo format
branchYesBranch to index
reloadNoForce reprocessing of previously indexed repository
notifyNoSend email notification when indexing completes

TDQS

C2.9/5.0
Behavior2/5

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

With no annotations provided, the description carries full burden but offers limited behavioral insight. It mentions the outcome ('make it searchable') but omits critical details: whether indexing is idempotent, time-consuming, or requires specific permissions; what 'searchable' entails (e.g., content types indexed); or side effects like notifications. The 'reload' and 'notify' parameters hint at reprocessing and notifications, but the description doesn't explain these behaviors.

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, efficient sentence that front-loads the core action ('index a repository') and purpose ('make it searchable'). It avoids redundancy and waste, though it could be slightly more informative without losing conciseness. Structure is clear but minimal.

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 no annotations, no output schema, and a mutation tool (indexing implies write operation), the description is incomplete. It lacks details on behavioral traits (e.g., idempotency, performance), output format, error handling, or dependencies. For a 5-parameter tool that modifies state, more context is needed to guide safe and effective use.

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 all 5 parameters (remote, repository, branch, reload, notify). The description adds no parameter-specific information beyond implying indexing scope, but doesn't detail how parameters interact (e.g., 'reload' vs. initial indexing). Baseline is 3 since the schema handles parameter documentation adequately.

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 verb ('index') and resource ('repository') with a specific purpose ('to make it searchable for future queries'). It distinguishes from siblings like 'get_repository_info' (read-only info) and 'query_repository' (search after indexing), though it doesn't explicitly name alternatives. The purpose is specific but could be more precise about what 'indexing' entails.

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 minimal guidance, stating the tool makes repositories searchable for future queries, which implies it should be used before querying. However, it lacks explicit when-to-use rules (e.g., prerequisites, timing), when-not-to-use scenarios (e.g., if already indexed), or named alternatives like 'reload' parameter for reprocessing. No sibling tools are referenced for comparison.

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

query_repositoryC

Query repositories using natural language to get detailed answers with code references

ParametersJSON Schema
NameRequiredDescriptionDefault
queryYesNatural language query about the codebase
repositoriesNoList of repositories to query
session_idNoSession ID for conversation continuity (auto-generated if not provided)
streamNoEnable streaming response
geniusNoUse enhanced query capabilities
timeoutNoRequest timeout in milliseconds
previous_messagesNoPrevious conversation messages for context

TDQS

C2.9/5.0
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 'natural language querying' and 'detailed answers with code references,' but fails to describe critical behaviors such as authentication requirements, rate limits, error handling, or what constitutes a 'detailed answer.' For a complex tool with 7 parameters, this is a significant gap in transparency.

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, efficient sentence that clearly states the tool's core functionality without unnecessary details. It's front-loaded with the main purpose and avoids redundancy, making it easy for an agent to parse quickly. Every word earns its place.

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 (7 parameters, no annotations, no output schema), the description is insufficient. It lacks information on behavioral traits, output format, error conditions, and how it differs from siblings. For a query tool that likely returns structured data, the absence of output details and usage context makes it incomplete for effective agent operation.

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, so each parameter is documented in the schema itself. The description adds no additional semantic context beyond implying natural language input for the 'query' parameter. This meets the baseline of 3, as the schema handles the heavy lifting, but the description doesn't enhance understanding of parameter usage or interactions.

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: 'Query repositories using natural language to get detailed answers with code references.' It specifies the action (query), resource (repositories), and outcome (detailed answers with code references). However, it doesn't explicitly differentiate from sibling tools like 'get_repository_info' or 'index_repository', which prevents a perfect score.

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 doesn't mention sibling tools like 'get_repository_info' for metadata or 'index_repository' for preparation, nor does it specify scenarios where this tool is preferred. This lack of comparative context leaves the agent without clear usage direction.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 5 tool updates
    • First observedget_repository_info
    • First observedgreptile_env_check
    • First observedgreptile_help
    • First observedindex_repository
    • First observedquery_repository
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 across 5 tools

Disambiguation5/5

Each tool has a clearly distinct purpose with no overlap. get_repository_info retrieves metadata, greptile_env_check verifies setup, greptile_help provides documentation, index_repository prepares data, and query_repository performs searches. An agent can easily differentiate them.

Naming Consistency3/5

The naming is mixed: three tools use a verb_noun pattern (get_repository_info, index_repository, query_repository), while two use a noun_verb pattern (greptile_env_check, greptile_help). This inconsistency is noticeable but still readable, as all names are descriptive and in snake_case.

Tool Count5/5

With 5 tools, this server is well-scoped for its purpose of repository indexing and querying. Each tool earns its place by covering essential functions like setup, indexing, querying, and help, without being overly sparse or bloated.

Completeness4/5

The tool set covers the core workflow for a repository search service: environment setup, indexing, querying, and metadata retrieval, with a help tool for guidance. A minor gap is the lack of tools for managing indexed repositories (e.g., delete or update), but agents can work around this.

Maintenance

ActivityInactive
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers