de en es ja ko ru zh

DeepSource MCP Server

Name: DeepSource MCP Server
Author: sapientpants

by sapientpants

Overview Schema Source Related Servers Discussions Admin

TypeScript

Remote

DeepSource MCP-Server

DeepSource npm-Version npm-Downloads Lizenz

Ein Model Context Protocol (MCP)-Server, der in DeepSource integriert ist, um KI-Assistenten Zugriff auf Codequalitätsmetriken, Probleme und Analyseergebnisse zu bieten.

Überblick

Der DeepSource MCP Server ermöglicht KI-Assistenten die Interaktion mit den Codequalitätsanalysefunktionen von DeepSource über das Model Context Protocol. Diese Integration ermöglicht KI-Assistenten:

Abrufen von Codemetriken und Analyseergebnissen
Zugriffs- und Filterprobleme
Qualitätsstatus prüfen
Analysieren Sie die Projektqualität im Zeitverlauf

Related MCP server: CodeAlive MCP

Merkmale

DeepSource-API-Integration : Verbindung mit DeepSource über die GraphQL-API
MCP-Protokollunterstützung : Implementiert das Model Context Protocol für die Integration von KI-Assistenten
Qualitätsmetriken und Schwellenwerte : Abrufen und Verwalten von Codequalitätsmetriken mit Schwellenwerten
Sicherheits-Compliance-Berichte : Zugriff auf OWASP Top 10, SANS Top 25 und MISRA-C Compliance-Berichte
Abhängigkeitsschwachstellen : Zugriff auf Informationen zu Sicherheitsschwachstellen in Abhängigkeiten
TypeScript/Node.js : Erstellt mit TypeScript für Typsicherheit und moderne JavaScript-Funktionen
Plattformübergreifend : Funktioniert unter Linux, macOS und Windows
Robuste Fehlerbehandlung : Umfassende Fehlerbehandlung für Netzwerk-, Authentifizierungs- und Analyseprobleme

Verwendung mit Claude Desktop

Bearbeiten Sie claude_desktop_config.json :
- Öffnen Sie Claude Desktop
- Gehen Sie zu Settings -> Developer -> Edit Config
- Fügen Sie eine der folgenden Konfigurationen zum Abschnitt mcpServers hinzu
Starten Sie Claude Desktop neu, um die Änderungen zu übernehmen

Beispielabfragen

Sobald die Verbindung hergestellt ist, kann Ihr KI-Assistent DeepSource-Daten mit Abfragen wie den folgenden verwenden:

What issues are in the JavaScript files of my project?

Dies würde das Tool project_issues mit Filtern verwenden:

{
  "projectKey": "your-project-key",
  "path": "src/",
  "analyzerIn": ["javascript"],
  "first": 10
}

So filtern Sie Analyseläufe:

Show me the most recent Python analysis runs

Dies würde das Tool project_runs mit Filtern verwenden:

{
  "projectKey": "your-project-key",
  "analyzerIn": ["python"],
  "first": 5
}

Für Codequalitätsmetriken:

What's my code coverage percentage? Is it meeting our thresholds?

Dazu würde das Tool quality_metrics verwendet:

{
  "projectKey": "your-project-key",
  "shortcodeIn": ["LCV", "BCV", "CCV"]
}

Für Sicherheitskonformitätsberichte:

Are we compliant with OWASP Top 10 security standards?

Dazu würde das Tool compliance_report verwendet:

{
  "projectKey": "your-project-key",
  "reportType": "OWASP_TOP_10"
}

So legen Sie Schwellenwerte fest:

Update our line coverage threshold to 80%

Dies würde das Tool update_metric_threshold verwenden:

{
  "projectKey": "your-project-key",
  "repositoryId": "repo-id",
  "metricShortcode": "LCV",
  "metricKey": "AGGREGATE",
  "thresholdValue": 80
}

Umgebungsvariablen

Der Server unterstützt die folgenden Umgebungsvariablen:

DEEPSOURCE_API_KEY (erforderlich): Ihr DeepSource-API-Schlüssel zur Authentifizierung
LOG_FILE (optional): Pfad zu einer Datei, in die Protokolle geschrieben werden sollen. Wenn nicht angegeben, werden keine Protokolle geschrieben.
LOG_LEVEL (optional): Minimale Protokollebene zum Schreiben (DEBUG, INFO, WARN, ERROR). Standardmäßig DEBUG

Beispielkonfiguration mit Protokollierung:

{
  "mcpServers": {
    "deepsource": {
      "command": "npx",
      "args": [
        "-y",
        "deepsource-mcp-server@1.1.0"
      ],
      "env": {
        "DEEPSOURCE_API_KEY": "your-deepsource-api-key",
        "LOG_FILE": "/tmp/deepsource-mcp.log",
        "LOG_LEVEL": "DEBUG"
      }
    }
  }
}

Docker

{
  "mcpServers": {
    "deepsource": {
      "command": "docker",
      "args": [
        "run",
        "-i",
        "--rm",
        "-e",
        "DEEPSOURCE_API_KEY",
        "-e",
        "LOG_FILE=/tmp/deepsource-mcp.log",
        "-v",
        "/tmp:/tmp",
        "sapientpants/deepsource-mcp-server"
      ],
      "env": {
        "DEEPSOURCE_API_KEY": "your-deepsource-api-key",
        "LOG_FILE": "/tmp/deepsource-mcp.log"
      }
    }
  }
}

NPX

{
  "mcpServers": {
    "deepsource": {
      "command": "npx",
      "args": [
        "-y",
        "deepsource-mcp-server@1.1.0"
      ],
      "env": {
        "DEEPSOURCE_API_KEY": "your-deepsource-api-key"
      }
    }
  }
}

Verfügbare Tools

Der DeepSource MCP-Server bietet die folgenden Tools:

projects : Listet alle verfügbaren DeepSource-Projekte auf
- Parameter:
  - Keine erforderlichen Parameter
project_issues : Holen Sie sich Probleme aus einem DeepSource-Projekt mit Filterung
- Parameter:
  - projectKey (erforderlich) – Die eindeutige Kennung für das DeepSource-Projekt
  - Paginierungsparameter:
    - offset (optional) – Anzahl der Elemente, die bei der Paginierung übersprungen werden sollen
    - first (optional) – Anzahl der zurückzugebenden Elemente (Standardwert: 10)
    - after (optional) - Cursor für die Vorwärtspaginierung
    - before (optional) - Cursor für die Rückwärtspaginierung
    - last (optional) – Anzahl der Elemente, die vor dem Cursor „vor“ zurückgegeben werden sollen (Standard: 10)
  - Filterparameter:
    - path (optional) – Filtern Sie Probleme nach einem bestimmten Dateipfad
    - analyzerIn (optional) – Filtern Sie Probleme nach bestimmten Analysatoren (z. B. ["python", "javascript"])
    - tags (optional) – Probleme nach Tags filtern
project_runs : Listenanalyseläufe für ein DeepSource-Projekt mit Filterung
- Parameter:
  - projectKey (erforderlich) – Die eindeutige Kennung für das DeepSource-Projekt
  - Paginierungsparameter:
    - offset (optional) – Anzahl der Elemente, die bei der Paginierung übersprungen werden sollen
    - first (optional) – Anzahl der zurückzugebenden Elemente (Standardwert: 10)
    - after (optional) - Cursor für die Vorwärtspaginierung
    - before (optional) - Cursor für die Rückwärtspaginierung
    - last (optional) – Anzahl der Elemente, die vor dem Cursor „vor“ zurückgegeben werden sollen (Standard: 10)
  - Filterparameter:
    - analyzerIn (optional) – Filter, der von bestimmten Analysatoren ausgeführt wird (z. B. ["python", "javascript"])
run : Rufen Sie eine bestimmte Analyse ab, die über ihre runUid oder commitOid ausgeführt wird.
- Parameter:
  - runIdentifier (erforderlich) – Die runUid (UUID) oder commitOid (Commit-Hash) zur Identifizierung des Laufs
recent_run_issues : Ruft Probleme aus der letzten Analyse ab, die auf einem bestimmten Zweig mit Paginierungsunterstützung ausgeführt wurde.
- Parameter:
  - projectKey (erforderlich) – Die eindeutige Kennung für das DeepSource-Projekt
  - branchName (erforderlich) – Der Name des Zweigs, aus dem der letzte Lauf abgerufen werden soll
  - Paginierungsparameter:
    - first (optional) – Anzahl der zurückzugebenden Probleme (Standardwert: 10)
    - after (optional) - Cursor für die Vorwärtspaginierung
    - last (optional) – Anzahl der Probleme, die vor einem Cursor zurückgegeben werden sollen (Standard: 10)
    - before (optional) - Cursor für die Rückwärtspaginierung
- Widerrufsfolgen:
  - Informationen zum letzten Lauf auf der Filiale
  - Aktuelle Probleme im Projekt (Hinweis: Probleme treten auf Repository-Ebene auf, nicht laufspezifisch)
  - Paginierungsinformationen einschließlich Cursor und Seitenstatus
  - Metadaten zum Lauf und zum Zweig
dependency_vulnerabilities : Abhängigkeitsschwachstellen aus einem DeepSource-Projekt abrufen
- Parameter:
  - projectKey (erforderlich) – Die eindeutige Kennung für das DeepSource-Projekt
  - Paginierungsparameter:
    - offset (optional) – Anzahl der Elemente, die bei der Paginierung übersprungen werden sollen
    - first (optional) – Anzahl der zurückzugebenden Elemente (Standardwert: 10)
    - after (optional) - Cursor für die Vorwärtspaginierung
    - before (optional) - Cursor für die Rückwärtspaginierung
    - last (optional) – Anzahl der Elemente, die vor dem Cursor „vor“ zurückgegeben werden sollen (Standard: 10)
quality_metrics : Holen Sie Qualitätsmetriken aus einem DeepSource-Projekt mit Filterung
- Parameter:
  - projectKey (erforderlich) – Die eindeutige Kennung für das DeepSource-Projekt
  - shortcodeIn (optional) – Filtern Sie Metriken nach bestimmten Shortcodes (z. B. ["LCV", "BCV"])
- Gibt Kennzahlen zurück wie:
  - Linienabdeckung (LCV)
  - Filialabdeckung (BCV)
  - Dokumentationsumfang (DCV)
  - Prozentsatz doppelter Codes (DDP)
  - Jede Metrik umfasst aktuelle Werte, Schwellenwerte und den Pass/Fail-Status
update_metric_threshold : Aktualisieren Sie den Schwellenwert für eine bestimmte Qualitätsmetrik
- Parameter:
  - projectKey (erforderlich) – Die eindeutige Kennung für das DeepSource-Projekt
  - repositoryId (erforderlich) – Die GraphQL-Repository-ID
  - metricShortcode (erforderlich) – Der Shortcode der zu aktualisierenden Metrik
  - metricKey (erforderlich) – Der Sprach- oder Kontextschlüssel für die Metrik
  - thresholdValue (optional) - Der neue Schwellenwert oder null, um den Schwellenwert zu entfernen
- Beispiel: Festlegen eines Schwellenwerts für die Zeilenabdeckung von 80 %: metricShortcode="LCV", metricKey="AGGREGATE", thresholdValue=80
update_metric_setting : Aktualisieren Sie die Einstellungen für eine Qualitätsmetrik
- Parameter:
  - projectKey (erforderlich) – Die eindeutige Kennung für das DeepSource-Projekt
  - repositoryId (erforderlich) – Die GraphQL-Repository-ID
  - metricShortcode (erforderlich) – Der Shortcode der zu aktualisierenden Metrik
  - isReported (erforderlich) – Ob die Metrik gemeldet werden soll
  - isThresholdEnforced (erforderlich) – Ob der Schwellenwert erzwungen werden soll (kann bei Prüfungen fehlschlagen)
compliance_report : Erhalten Sie Sicherheits-Compliance-Berichte von einem DeepSource-Projekt

Parameter:
- projectKey (erforderlich) – Die eindeutige Kennung für das DeepSource-Projekt
- reportType (erforderlich) – Der Typ des abzurufenden Compliance-Berichts ( OWASP Top 10 , SANS Top 25 oder MISRA-C )
Gibt umfassende Daten zur Sicherheitskonformität zurück, darunter:
- Statistiken zu Sicherheitsproblemen nach Kategorie und Schweregrad
- Konformitätsstatus (bestanden/nicht bestanden)
- Trenddaten, die Veränderungen im Zeitverlauf zeigen
- Analyse und Empfehlungen zur Verbesserung der Sicherheitslage

Entwicklung

Klonen Sie das Repository:

git clone https://github.com/sapientpants/deepsource-mcp-server.git
cd deepsource-mcp-server

Installieren Sie Abhängigkeiten:

pnpm install

Erstellen Sie das Projekt:

pnpm run build

Claude Desktop konfigurieren

{
  "mcpServers": {
    "deepsource": {
      "command": "node",
      "args": [
        "/path/to/deepsource-mcp-server/dist/index.js"
      ],
      "env": {
        "DEEPSOURCE_API_KEY": "your-deepsource-api-key"
      }
    }
  }
}

Voraussetzungen

Node.js 20 oder höher
pnpm 10.7.0 oder höher
Docker (für Container-Builds)

Skripte

pnpm run build – Erstellen Sie den TypeScript-Code
pnpm run start - Starten Sie den Server
pnpm run dev - Starten Sie den Server im Entwicklungsmodus
pnpm run test – Tests ausführen
pnpm run lint – ESLint ausführen
pnpm run format - Code mit Prettier formatieren

Fehlerbehebung

Debug-Protokollierung aktivieren

Wenn Probleme auftreten, aktivieren Sie die Debug-Protokollierung, um ausführliche Informationen anzuzeigen:

Setzen Sie die Umgebungsvariable LOG_FILE auf einen Dateipfad, in den Protokolle geschrieben werden sollen
Setzen Sie LOG_LEVEL auf DEBUG (das ist die Standardeinstellung)
Überprüfen Sie die Protokolldatei auf detaillierte Fehlerinformationen

Beispielkonfiguration:

{
  "mcpServers": {
    "deepsource": {
      "command": "npx",
      "args": ["-y", "deepsource-mcp-server@1.1.0"],
      "env": {
        "DEEPSOURCE_API_KEY": "your-api-key",
        "LOG_FILE": "/tmp/deepsource-mcp.log",
        "LOG_LEVEL": "DEBUG"
      }
    }
  }
}

Überprüfen Sie dann die Protokolldatei:

tail -f /tmp/deepsource-mcp.log

Häufige Probleme

Authentifizierungsfehler : Stellen Sie sicher, dass Ihr DEEPSOURCE_API_KEY korrekt ist und über die erforderlichen Berechtigungen verfügt
Es werden keine Protokolle angezeigt : Überprüfen Sie, ob der LOG_FILE Pfad beschreibbar ist und das übergeordnete Verzeichnis vorhanden ist
Tool-Fehler : Überprüfen Sie die Protokolldatei auf detaillierte Fehlermeldungen und Stapelverfolgungen

Lizenz

MIT

Available Tools

10 tools

compliance_reportA

Get security compliance reports from a DeepSource project

ParametersJSON Schema

Name	Required	Description	Default
`projectKey`	Yes	DeepSource project key to identify the project
`reportType`	Yes	Type of compliance report to fetch

Output Schema

ParametersJSON Schema

Name	Required	Description
`key`	Yes
`title`	Yes
`currentValue`	Yes
`status`	Yes
`securityIssueStats`	Yes
`trends`	No
`analysis`	Yes
`recommendations`	Yes

TDQS

A3.5/5.0

Behavior2/5

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

No annotations are provided, so the description carries the full burden. It only says 'Get', implying a read operation, but does not disclose any side effects, permissions, rate limits, or output behavior beyond the schema.

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

Conciseness5/5

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

The description is a single sentence with no unnecessary words. It is front-loaded with the verb and resource, making it easy to parse.

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 presence of an output schema and 100% parameter coverage, the description is minimally adequate. However, it lacks behavioral transparency and usage context, which are not compensated by other fields.

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

Parameters3/5

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

Schema coverage is 100% – both 'projectKey' and 'reportType' are described in the input schema. The description adds no additional semantic information, so baseline 3 is appropriate.

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

Purpose5/5

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

The description clearly states the verb 'Get' and the resource 'security compliance reports from a DeepSource project'. It distinguishes this tool from siblings like 'dependency_vulnerabilities' and 'project_issues', which focus on different data.

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?

No explicit guidance on when to use this tool versus alternatives. The description implies it's for compliance reports but does not specify when not to use it or mention other tools for similar purposes.

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

dependency_vulnerabilitiesB

Get dependency vulnerabilities from a DeepSource project

ParametersJSON Schema

Name	Required	Description
`projectKey`	Yes	DeepSource project key to fetch vulnerabilities for
`first`	No	Number of items to retrieve (forward pagination)
`after`	No	Cursor to start retrieving items after (forward pagination)
`last`	No	Number of items to retrieve (backward pagination)
`before`	No	Cursor to start retrieving items before (backward pagination)
`page_size`	No	Number of items per page (alias for first, for convenience)
`max_pages`	No	Maximum number of pages to fetch (enables automatic multi-page fetching)

Output Schema

ParametersJSON Schema

Name	Required	Description
`vulnerabilities`	Yes
`pageInfo`	Yes
`totalCount`	Yes

TDQS

B3.1/5.0

Behavior2/5

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

With no annotations, the description must disclose behavioral traits. It only states a read operation but omits details like pagination behavior, potential errors, or authentication needs, despite the schema hinting at pagination.

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 concise sentence with no wasted words. However, it is very brief and could be restructured to include more context efficiently.

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 complexity (7 parameters, output schema, no annotations), the description is too minimal. It fails to explain the tool's purpose in a broader workflow or set expectations about pagination and project key usage.

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

Parameters3/5

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

Schema coverage is 100%, so the baseline is 3. The description adds no extra meaning beyond what the schema already provides for each parameter.

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

Purpose5/5

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

The description clearly states the action ('Get'), the resource ('dependency vulnerabilities'), and the scope ('from a DeepSource project'). This distinctly differentiates it from sibling tools like compliance_report or project_issues.

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. The description lacks any context about prerequisites, exclusions, or comparative scenarios.

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

project_issuesB

Get issues from a DeepSource project with filtering capabilities

ParametersJSON Schema

Name	Required	Description
`projectKey`	Yes	DeepSource project key to fetch issues for
`path`	No	Filter issues by file path
`analyzerIn`	No	Filter issues by analyzer shortcodes
`tags`	No	Filter issues by tags
`first`	No	Number of items to retrieve (forward pagination)
`after`	No	Cursor to start retrieving items after (forward pagination)
`last`	No	Number of items to retrieve (backward pagination)
`before`	No	Cursor to start retrieving items before (backward pagination)
`page_size`	No	Number of items per page (alias for first, for convenience)
`max_pages`	No	Maximum number of pages to fetch (enables automatic multi-page fetching)

Output Schema

ParametersJSON Schema

Name	Required	Description
`issues`	Yes
`pageInfo`	Yes
`pagination`	No	User-friendly pagination metadata
`totalCount`	Yes

TDQS

B3/5.0

Behavior2/5

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

No annotations provided; description does not disclose pagination behavior, rate limits, or what the response contains. Without annotations, the description fails to inform about key behavioral traits.

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

Conciseness3/5

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

Single sentence, front-loaded, but too brief; could be expanded to include key details without becoming verbose.

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

Completeness2/5

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

With 10 parameters including pagination, the description is insufficient; doesn't explain pagination cursor usage or filtering capabilities beyond the 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?

Input schema has 100% description coverage, so baseline is 3. Description adds no extra meaning beyond what the schema already provides.

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

Purpose5/5

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

Description clearly states verb 'Get' and resource 'issues from a DeepSource project', distinguishing it from sibling tools like compliance_report and dependency_vulnerabilities.

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 on when to use this tool vs. alternatives, such as other issue-related tools (e.g., recent_run_issues). Lacks explicit context for usage.

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

projectsA

List all available DeepSource projects. Returns a list of project objects with "key" and "name" properties.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`projects`	Yes

TDQS

A4.1/5.0

Behavior4/5

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

With no annotations, the description bears full responsibility. It transparently describes a read-only listing operation with no side effects. While simple, it fully discloses the behavior without omission.

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, well-structured sentence that front-loads the action ('List all available DeepSource projects') and follows with concise details. No extraneous words.

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

Completeness5/5

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

Given zero parameters, an output schema, and a straightforward task (listing projects), the description is complete. It covers the purpose and return format, and no additional context is needed.

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?

Since the input schema has no parameters (100% coverage), the description adds value by specifying the return structure (key and name properties). This exceeds the baseline of 4 for zero-parameter tools.

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 it lists all available DeepSource projects and specifies the return properties (key and name). This distinguishes it from sibling tools like compliance_report which focus on specific aspects.

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

Usage Guidelines2/5

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

No guidance is provided on when to use this tool versus alternatives such as compliance_report or project_issues. The description simply states the functionality without context for selection.

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

quality_metricsB

Get quality metrics from a DeepSource project with optional filtering

ParametersJSON Schema

Name	Required	Description	Default
`projectKey`	Yes	DeepSource project key to fetch quality metrics for
`shortcodeIn`	No	Optional filter for specific metric shortcodes

Output Schema

ParametersJSON Schema

Name	Required	Description
`metrics`	Yes

TDQS

B3.1/5.0

Behavior2/5

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

No annotations exist, so the description carries the full burden. It only indicates a read operation ('Get') but does not disclose side effects, authentication requirements, rate limits, or any behavioral traits beyond that.

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

Conciseness5/5

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

The description is a single, front-loaded sentence of 11 words. It is highly concise with no superfluous information, earning a top score.

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

Completeness3/5

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

The tool is simple with 2 parameters and an output schema, so the description partially covers what is needed. However, it lacks context on prerequisites, how quality metrics relate to other sibling tools, or any performance implications. With output schema present, return values are covered, but overall completeness is average.

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 covers 100% of parameters with descriptions, so the description adds minimal value ('optional filtering' is already implied by shortcodeIn). Baseline 3 is appropriate since the schema already explains the parameters 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 'Get', the resource 'quality metrics', and the source 'DeepSource project'. It also mentions optional filtering, which adds clarity. However, it does not elaborate on what 'quality metrics' entail (e.g., code quality metrics), missing an opportunity to differentiate from siblings like dependency_vulnerabilities or project_issues.

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 its siblings. The description mentions optional filtering but does not explain when filtering is appropriate or when alternative tools (e.g., for issues or vulnerabilities) should be used instead.

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

recent_run_issuesB

Get issues from the most recent analysis run on a specific branch

ParametersJSON Schema

Name	Required	Description
`projectKey`	Yes	DeepSource project key to fetch issues for
`branchName`	Yes	Branch name to fetch the most recent run from
`first`	No	Number of items to retrieve (forward pagination)
`after`	No	Cursor to start retrieving items after (forward pagination)
`last`	No	Number of items to retrieve (backward pagination)
`before`	No	Cursor to start retrieving items before (backward pagination)
`page_size`	No	Number of items per page (alias for first, for convenience)
`max_pages`	No	Maximum number of pages to fetch (enables automatic multi-page fetching)

Output Schema

ParametersJSON Schema

Name	Required	Description
`run`	Yes
`issues`	Yes
`pageInfo`	Yes
`totalCount`	Yes

TDQS

B3.3/5.0

Behavior2/5

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

No annotations are provided, so the description must disclose behavioral traits. However, it only states a read-like operation without mentioning it is read-only, does not discuss authentication, rate limits, or pagination behavior. The description adds minimal value beyond the tool name.

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

Conciseness5/5

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

The description is a single sentence of 9 words, extremely concise and front-loaded. Every word is necessary, and there is no redundant information.

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 complexity of 8 parameters including pagination, and the presence of an output schema, the description is minimal. It does not explain that only the latest run is considered, nor does it describe the order or filtering. Adequate for basic understanding but incomplete for nuanced usage.

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 input schema already explains all parameters. The description does not add new meaning to any parameter beyond what the schema provides. Baseline score is 3 as description provides no additional semantic value.

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 it retrieves issues from the most recent analysis run on a specific branch. The verb 'Get' and resource 'issues' are specific, and the scope 'most recent analysis run on a specific branch' distinguishes it from siblings like 'project_issues' which likely list all issues.

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 such as 'project_issues' or 'runs'. It does not mention when not to use it or provide context about prerequisites or limitations.

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

runB

Get a specific analysis run by its runUid or commitOid

ParametersJSON Schema

Name	Required	Description
`projectKey`	Yes	DeepSource project key to identify the project
`runIdentifier`	Yes	The run identifier (runUid or commitOid)
`isCommitOid`	No	Flag to indicate whether the runIdentifier is a commitOid (default: false)

Output Schema

ParametersJSON Schema

Name	Required	Description
`run`	Yes
`analysis`	Yes

TDQS

B3.4/5.0

Behavior3/5

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

The description indicates a read-only operation ('Get'), which is consistent with the expected behavior. With no annotations provided, the description adequately conveys that it is a retrieval tool, but it does not disclose error handling or behavior when the run is not found.

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

Conciseness5/5

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

The description is a single concise sentence that conveys the essential purpose. No unnecessary words, making it easy for the agent to parse quickly.

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?

With an output schema present, the description does not need to explain return values. The description is sufficient for a simple getter tool, though it could be improved by mentioning that it returns a single run object. Overall, it is reasonably complete for the tool's complexity.

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

Parameters3/5

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

Schema coverage is 100%, so the schema already documents the parameters. The description adds minimal value by restating that runIdentifier can be runUid or commitOid, but this is already encoded in the schema and the isCommitOid parameter. No additional semantic detail beyond the schema.

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 retrieves a specific analysis run using either runUid or commitOid. The verb 'Get' and the resource 'analysis run' are explicit. However, it does not explicitly differentiate from the sibling tool 'runs', which likely lists all runs, so clarity is good but not perfect.

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 on when to use this tool versus alternatives like 'runs' or other tools. There is no mention of prerequisites or context, leaving the agent to infer usage from the description alone.

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

runsA

List analysis runs for a DeepSource project with filtering

ParametersJSON Schema

Name	Required	Description
`projectKey`	Yes	DeepSource project key to fetch runs for
`analyzerIn`	No	Filter runs by analyzer shortcodes
`first`	No	Number of items to retrieve (forward pagination)
`after`	No	Cursor to start retrieving items after (forward pagination)
`last`	No	Number of items to retrieve (backward pagination)
`before`	No	Cursor to start retrieving items before (backward pagination)
`page_size`	No	Number of items per page (alias for first, for convenience)
`max_pages`	No	Maximum number of pages to fetch (enables automatic multi-page fetching)

Output Schema

ParametersJSON Schema

Name	Required	Description
`runs`	Yes
`pageInfo`	Yes
`totalCount`	Yes

TDQS

A3.7/5.0

Behavior2/5

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

No annotations are provided, so the description carries full burden for behavioral disclosure. It does not mention pagination behavior, rate limits, or what happens on invalid projects. The schema includes cursor parameters (first, after, last, before, page_size, max_pages), but the description omits any behavioral context like automatic pagination or cursor-based pagination.

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?

A single, clear sentence with no fluff. Every word is necessary and earns its place.

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 8 parameters and no annotations, the description is minimal but combined with the schema is adequate. However, it lacks context on pagination behavior and does not differentiate from sibling tool 'run'. Output schema exists to describe return values.

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

Parameters3/5

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

Schema coverage is 100% with all parameters described. The description adds only 'with filtering', which is vague and does not provide additional meaning beyond the schema. Baseline score of 3 is appropriate as 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?

Description clearly states the tool lists analysis runs for a DeepSource project with filtering. It uses a specific verb (list) and resource (analysis runs), and distinguishes from sibling tools like 'run' (likely single run retrieval) and 'project_issues'.

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?

Description implies usage for listing filtered runs, but does not explicitly state when not to use or mention alternatives. Context is clear, but no exclusions or comparisons to siblings are provided.

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

update_metric_settingC

Update the settings for a quality metric

ParametersJSON Schema

Name	Required	Description
`projectKey`	Yes	DeepSource project key to identify the project
`repositoryId`	Yes	Repository GraphQL ID
`metricShortcode`	Yes	Code for the metric to update
`isReported`	Yes	Whether the metric should be reported
`isThresholdEnforced`	Yes	Whether the threshold should be enforced

Output Schema

ParametersJSON Schema

Name	Required	Description
`ok`	Yes
`projectKey`	Yes
`metricShortcode`	Yes
`settings`	Yes
`message`	Yes
`next_steps`	Yes

TDQS

C2.9/5.0

Behavior2/5

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

With no annotations, the description carries full burden for behavioral disclosure. It only says 'Update', implying mutation, but fails to state side effects, authorization requirements, or error conditions (e.g., what happens if the metric doesn't exist). This is insufficient for an agent to safely invoke the tool.

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

Conciseness5/5

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

The description is a single, concise sentence with no unnecessary words. It is front-loaded with the key verb and resource, making it efficient for scanning.

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?

Despite the existence of an output schema, the description is too minimal. It does not explain the broader context of updating metric settings, such as the effect on reporting or enforcement, or how it relates to other metric tools. The five required parameters are left unexplained beyond the schema, which is insufficient for a complete understanding.

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

Parameters3/5

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

Schema coverage is 100%, so baseline is 3. The description adds no additional meaning beyond the schema; it merely restates the generic 'settings' without explaining how the boolean parameters affect the metric. The agent must rely entirely on the parameter descriptions in the schema.

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 action ('Update') and the resource ('settings for a quality metric'), which is sufficient to understand the basic purpose. However, it does not distinguish from the sibling tool 'update_metric_threshold', which might update a specific threshold value, so specificity is slightly lacking.

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 'update_metric_threshold'. The description does not mention context, prerequisites, or scenarios where this tool is appropriate, leaving the agent to infer usage from the schema alone.

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

update_metric_thresholdC

Update the threshold for a specific quality metric

ParametersJSON Schema

Name	Required	Description
`projectKey`	Yes	DeepSource project key to identify the project
`repositoryId`	Yes	Repository GraphQL ID
`metricShortcode`	Yes	Code for the metric to update
`metricKey`	Yes	Context key for the metric
`thresholdValue`	No	New threshold value, or null to remove

Output Schema

ParametersJSON Schema

Name	Required	Description
`ok`	Yes
`projectKey`	Yes
`metricShortcode`	Yes
`metricKey`	Yes
`thresholdValue`	No
`message`	Yes
`next_steps`	Yes

TDQS

C2.9/5.0

Behavior2/5

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

With no annotations available, the description carries the full burden of disclosing behavioral traits. It only states 'update' which implies mutation but does not mention authorization needs, idempotency, side effects on other metrics, or whether setting threshold to null removes it. The description adds minimal value beyond the tool name.

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

Conciseness5/5

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

The description is a single concise sentence with only 8 words, containing no fluff or repetition. It efficiently communicates the core purpose.

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 complexity of the tool (5 parameters, 4 required, mutation with no annotations) and the presence of an output schema, the description is too brief. It lacks details on the effect of null thresholdValue, the meaning of metricShortcode values, and the expected outcome. The existing output schema partially mitigates the need for return value explanation, but the description should provide more operational context.

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

Parameters3/5

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

The input schema already provides full descriptions for all 5 parameters (100% coverage). The description does not add any additional meaning or context beyond what is in the schema, so baseline score of 3 is appropriate.

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?

Description clearly states the action (update) and the object (threshold for a specific quality metric). It is specific enough to distinguish from sibling tools like update_metric_setting or quality_metrics, though it does not explicitly call out the distinction.

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, nor are there any prerequisites or when-not-to-use conditions stated. The description simply states what it does without contextual usage advice.

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

Deploy Server

Shareable, User-Owned Context BackendPeople, applications, and agents read, write, and coordinate together in one context lake. Reach it over MCP, a CLI, a Python SDK, or REST.fulcradynamics.comAd

TDQS

B3.4/5.0

Scored 2026-05-03 12:55 across 10 tools

Disambiguation4/5

Most tools have clearly distinct purposes (projects vs runs vs issues vs metrics vs security). However, project_issues and recent_run_issues both deal with issues and could cause initial confusion, though descriptions clarify the difference.

Naming Consistency4/5

Tool names follow a predictable pattern: query tools are named after the resource (noun or noun phrase, e.g., projects, runs, quality_metrics) and mutation tools use verb_resource (e.g., update_metric_setting). This is consistent and readable.

Tool Count5/5

10 tools is well-scoped for a code analysis server, covering core areas (projects, runs, issues, metrics, compliance, dependencies) without being overwhelming or too sparse.

Completeness3/5

The tool set covers most essential operations (list, get, update for key resources) but lacks branch listing (needed for recent_run_issues) and triggering analysis runs, which are notable gaps for a comprehensive interface.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

Need Help?

Reddit Discussion

Related Servers

Related MCP Connectors

hithereiamaliff-mcp-nextcloudOAuth
ai.smithery
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
Cloud Storage File Systems Workplace & Productivity
238
mcp COAuth
com.wix
A Model Context Protocol server for Wix AI tools
Developer Tools Content Management Systems App Automation
215
Cortex BOAuth
io.cortex.mcp
The Cortex MCP server provides read-only access to real-time engineering context from the Cortex developer portal, allowing AI coding assistants to answer natural language questions about your organization's catalog (microservices, libraries, domains, teams, infrastructure), scorecards (engineering standards and best practices), initiatives (goals and deadlines), and Engineering Intelligence metrics. It includes tools for querying documentation, tracking personal entities, and accessing AI-assisted insights across the entire Cortex ecosystem.
Developer Tools Monitoring Observability
1162
Sentry AOAuth
dev.sentry.mcp
Enable secure connectivity between Sentry issues and debugging data, and LLM clients, using a Model Context Protocol (MCP) server.
Monitoring Developer Tools Observability
3

Related MCP Servers

CodeAnalysis MCP Server
Code Analysis Developer Tools Documentation Access
0xjcf
F
license
D
quality
D
maintenance
A comprehensive Model Context Protocol server for advanced code analysis that provides tools for syntax analysis, dependency visualization, and AI-assisted development workflow support.
Updated 9 months ago (2026-01-20 23:07 UTC)
28
7
-
CodeAlive MCPofficial
Code Analysis RAG Systems Developer Tools
CodeAlive-AI
A
license
Not graded
quality
A
maintenance
A Model Context Protocol server that enhances AI agents by providing deep semantic understanding of codebases, enabling more intelligent interactions through advanced code search and contextual awareness.
Updated 22 days ago (2026-09-24 19:03 UTC)
91
MIT
MCP DeepWiki Server
LoganZechella
-
license
B
quality
Not graded
maintenance
A Model Context Protocol server that enables AI assistants to fetch and understand GitHub repository documentation on-demand from DeepWiki during conversations.
Updated a year ago (2025-07-19 19:17 UTC)
3
-
Codebase MCP Server
Code Analysis Developer Tools
cmaujean
A
license
Not graded
quality
D
maintenance
A Model Context Protocol server that analyzes application codebases with real-time file watching, providing AI assistants like Claude with deep insights into project structure, code patterns, and architecture.
Updated a year ago (2025-08-12 00:32 UTC)
MIT

DeepSource MCP-Server

Überblick

Merkmale

Verwendung mit Claude Desktop

Beispielabfragen

Umgebungsvariablen

Docker

NPX

Verfügbare Tools

Entwicklung

Voraussetzungen

Skripte

Fehlerbehebung

Debug-Protokollierung aktivieren

Häufige Probleme

Lizenz

Available Tools

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

CodeAlive MCPofficial

Appeared in Searches