de en es ja ko ru zh

DeepSource MCP Server

Name: DeepSource MCP Server
Author: sapientpants

by sapientpants

Overview Schema Related Servers Score Discussions

TypeScript

Remote

Сервер DeepSource MCP

DeepSource npm-версия npm-загрузки Лицензия

Сервер Model Context Protocol (MCP), который интегрируется с DeepSource, чтобы предоставить помощникам на базе искусственного интеллекта доступ к показателям качества кода, проблемам и результатам анализа.

Обзор

DeepSource MCP Server позволяет помощникам ИИ взаимодействовать с возможностями анализа качества кода DeepSource через Model Context Protocol. Эта интеграция позволяет помощникам ИИ:

Извлечение метрик кода и результатов анализа
Проблемы с доступом и фильтрацией
Проверить статус качества
Анализ качества проекта с течением времени

Related MCP server: CodeAlive MCP

Функции

Интеграция с DeepSource API : подключение к DeepSource через GraphQL API
Поддержка протокола MCP : реализует протокол контекста модели для интеграции помощника на основе искусственного интеллекта.
Метрики и пороговые значения качества : получение и управление метриками качества кода с помощью пороговых значений.
Отчеты о соответствии требованиям безопасности : доступ к отчетам о соответствии OWASP Top 10, SANS Top 25 и MISRA-C
Уязвимости зависимостей : доступ к информации об уязвимостях безопасности зависимостей
TypeScript/Node.js : создан с использованием TypeScript для обеспечения безопасности типов и современных функций JavaScript.
Кроссплатформенность : работает на Linux, macOS и Windows
Надежная обработка ошибок : комплексная обработка ошибок, связанных с сетью, аутентификацией и анализом.

Использование с Claude Desktop

Редактировать claude_desktop_config.json :
- Открыть рабочий стол Клода
- Перейдите в Settings -> Developer -> Edit Config
- Добавьте одну из конфигураций ниже в раздел mcpServers
Перезапустите Claude Desktop, чтобы изменения вступили в силу.

Примеры запросов

После подключения ваш помощник на базе искусственного интеллекта сможет использовать данные DeepSource с такими запросами:

What issues are in the JavaScript files of my project?

Для этого будет использоваться инструмент project_issues с фильтрами:

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

Для фильтрации результатов анализа:

Show me the most recent Python analysis runs

Для этого будет использоваться инструмент project_runs с фильтрами:

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

Для показателей качества кода:

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

Для этого будет использоваться инструмент quality_metrics :

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

Для отчетов о соответствии требованиям безопасности:

Are we compliant with OWASP Top 10 security standards?

Для этого будет использоваться инструмент compliance_report :

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

Для установки пороговых значений:

Update our line coverage threshold to 80%

Для этого будет использоваться инструмент update_metric_threshold :

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

Переменные среды

Сервер поддерживает следующие переменные среды:

DEEPSOURCE_API_KEY (обязательно): Ваш ключ API DeepSource для аутентификации
LOG_FILE (необязательно): Путь к файлу, в который должны записываться логи. Если не задано, логи записываться не будут
LOG_LEVEL (необязательно): Минимальный уровень журнала для записи (DEBUG, INFO, WARN, ERROR). По умолчанию DEBUG

Пример конфигурации с ведением журнала:

{
  "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"
      }
    }
  }
}

Докер

{
  "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"
      }
    }
  }
}

НПХ

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

Доступные инструменты

Сервер DeepSource MCP предоставляет следующие инструменты:

projects : список всех доступных проектов DeepSource
- Параметры:
  - Нет обязательных параметров
project_issues : Получить проблемы из проекта DeepSource с фильтрацией
- Параметры:
  - projectKey (обязательно) — уникальный идентификатор проекта DeepSource.
  - Параметры пагинации:
    - offset (необязательно) — количество элементов, которые необходимо пропустить при разбивке на страницы.
    - first (необязательно) — количество возвращаемых элементов (по умолчанию 10)
    - after (необязательно) - Курсор для прямой пагинации
    - before (необязательно) - Курсор для обратной пагинации
    - last (необязательно) — количество возвращаемых элементов перед курсором «before» (по умолчанию: 10)
  - Параметры фильтрации:
    - path (необязательно) — фильтрация проблем по определенному пути к файлу
    - analyzerIn (необязательно) — фильтрация проблем по определенным анализаторам (например, ["python", "javascript"])
    - tags (необязательно) — фильтрация проблем по тегам
project_runs : список запусков анализа для проекта DeepSource с фильтрацией
- Параметры:
  - projectKey (обязательно) — уникальный идентификатор проекта DeepSource.
  - Параметры пагинации:
    - offset (необязательно) — количество элементов, которые необходимо пропустить при разбивке на страницы.
    - first (необязательно) — количество возвращаемых элементов (по умолчанию 10)
    - after (необязательно) - Курсор для прямой пагинации
    - before (необязательно) - Курсор для обратной пагинации
    - last (необязательно) — количество возвращаемых элементов перед курсором «before» (по умолчанию: 10)
  - Параметры фильтрации:
    - analyzerIn (необязательно) — фильтрация запусков определенных анализаторов (например, ["python", "javascript"])
run : Получить определенный анализ, запущенный по его runUid или commitOid
- Параметры:
  - runIdentifier (обязательно) — runUid (UUID) или commitOid (хэш коммита) для идентификации запуска
recent_run_issues : получение проблем из последнего анализа, выполненного в определенной ветке, с поддержкой постраничного просмотра
- Параметры:
  - projectKey (обязательно) — уникальный идентификатор проекта DeepSource.
  - branchName (обязательно) — имя ветки, из которой необходимо получить последний запуск.
  - Параметры пагинации:
    - first (необязательно) — количество возвращаемых вопросов (по умолчанию 10)
    - after (необязательно) - Курсор для прямой пагинации
    - last (необязательно) — количество возвращаемых проблем перед курсором (по умолчанию: 10)
    - before (необязательно) - Курсор для обратной пагинации
- Возврат:
  - Информация о последнем прогоне на ветке
  - Текущие проблемы в проекте (примечание: проблемы касаются уровня репозитория, а не конкретного запуска)
  - Информация о пагинации, включая курсоры и статус страницы
  - Метаданные о запуске и ветвлении
dependency_vulnerabilities : получение уязвимостей зависимостей из проекта DeepSource
- Параметры:
  - projectKey (обязательно) — уникальный идентификатор проекта DeepSource.
  - Параметры пагинации:
    - offset (необязательно) — количество элементов, которые необходимо пропустить при разбивке на страницы.
    - first (необязательно) — количество возвращаемых элементов (по умолчанию 10)
    - after (необязательно) - Курсор для прямой пагинации
    - before (необязательно) - Курсор для обратной пагинации
    - last (необязательно) — количество возвращаемых элементов перед курсором «before» (по умолчанию: 10)
quality_metrics : получение показателей качества из проекта DeepSource с помощью фильтрации
- Параметры:
  - projectKey (обязательно) — уникальный идентификатор проекта DeepSource.
  - shortcodeIn (необязательно) — фильтрация показателей по определенным коротким кодам (например, ["LCV", "BCV"])
- Возвращает такие показатели, как:
  - Линейное покрытие (LCV)
  - Покрытие филиалов (BCV)
  - Покрытие документации (DCV)
  - Процент дублирующегося кода (DDP)
  - Каждая метрика включает текущие значения, пороговые значения и статус «пройдено/не пройдено».
update_metric_threshold : обновить пороговое значение для определенной метрики качества
- Параметры:
  - projectKey (обязательно) — уникальный идентификатор проекта DeepSource.
  - repositoryId (обязательно) — идентификатор репозитория GraphQL
  - metricShortcode (обязательно) — короткий код метрики для обновления.
  - metricKey (обязательно) — ключ языка или контекста для метрики.
  - thresholdValue (необязательно) — новое пороговое значение или null для удаления порога.
- Пример: Установить порог покрытия линии 80%: metricShortcode="LCV", metricKey="AGGREGATE", thresholdValue=80
update_metric_setting : Обновить настройки для метрики качества
- Параметры:
  - projectKey (обязательно) — уникальный идентификатор проекта DeepSource.
  - repositoryId (обязательно) — идентификатор репозитория GraphQL
  - metricShortcode (обязательно) — короткий код метрики для обновления.
  - isReported (обязательно) — следует ли сообщать метрику
  - isThresholdEnforced (обязательно) — следует ли принудительно применять пороговое значение (может не пройти проверку)
compliance_report : получение отчетов о соответствии требованиям безопасности из проекта DeepSource

Параметры:
- projectKey (обязательно) — уникальный идентификатор проекта DeepSource.
- reportType (обязательно) — тип отчета о соответствии, который необходимо получить ( OWASP Top 10 , SANS Top 25 или MISRA-C )
Возвращает комплексные данные о соответствии требованиям безопасности, включая:
- Статистика проблем безопасности по категориям и серьезности
- Статус соответствия (пройдено/не пройдено)
- Данные о тенденциях, показывающие изменения с течением времени
- Анализ и рекомендации по улучшению состояния безопасности

Разработка

Клонируйте репозиторий:

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

Установить зависимости:

pnpm install

Создайте проект:

pnpm run build

Настроить рабочий стол Клода

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

Предпосылки

Node.js 20 или выше
pnpm 10.7.0 или выше
Docker (для сборки контейнеров)

Скрипты

pnpm run build — сборка кода TypeScript
pnpm run start - Запустить сервер
pnpm run dev - Запустить сервер в режиме разработки
pnpm run test - Запустить тесты
pnpm run lint - Запустить ESLint
pnpm run format - Форматирование кода с помощью Prettier

Поиск неисправностей

Включить отладочное ведение журнала

Если у вас возникли проблемы, включите ведение журнала отладки, чтобы увидеть подробную информацию:

Установите переменную среды LOG_FILE на путь к файлу, куда должны записываться журналы.
Установите LOG_LEVEL на DEBUG (это значение по умолчанию)
Проверьте файл журнала для получения подробной информации об ошибке.

Пример конфигурации:

{
  "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"
      }
    }
  }
}

Затем проверьте файл журнала:

tail -f /tmp/deepsource-mcp.log

Общие проблемы

Ошибка аутентификации : убедитесь, что ваш DEEPSOURCE_API_KEY правильный и имеет необходимые разрешения.
Журналы не отображаются : убедитесь, что путь LOG_FILE доступен для записи и родительский каталог существует.
Ошибки инструмента : проверьте файл журнала на наличие подробных сообщений об ошибках и трассировок стека.

Лицензия

Массачусетский технологический институт

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.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

No tool schema history has been recorded yet.

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

B3.4/5.0

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

ResponsivenessSyncing

Resources

Need Help?

Reddit Discussion

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

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
237
mcp COAuth
com.wix
A Model Context Protocol server for Wix AI tools
Developer Tools Content Management Systems App Automation
216
Cortex C
io.cortex.mcp
The Cortex MCP server provides read-only access to real-time engineering context from the Cortex developer portal, allowing AI coding assistants to answer natural language questions about your organization's catalog (microservices, libraries, domains, teams, infrastructure), scorecards (engineering standards and best practices), initiatives (goals and deadlines), and Engineering Intelligence metrics. It includes tools for querying documentation, tracking personal entities, and accessing AI-assisted insights across the entire Cortex ecosystem.
Developer Tools Monitoring Observability
312
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 8 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 21 days ago (2026-08-16 13:58 UTC)
89
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

Appeared in Searches

Latest Blog Posts

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

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/sapientpants/deepsource-mcp-server'

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

Сервер DeepSource MCP

Обзор

Функции

Использование с Claude Desktop

Примеры запросов

Переменные среды

Докер

НПХ

Доступные инструменты

Разработка

Предпосылки

Скрипты

Поиск неисправностей

Включить отладочное ведение журнала

Общие проблемы

Лицензия

Available Tools

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Tool Schema Changelog

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

CodeAlive MCPofficial

Appeared in Searches

Latest Blog Posts

MCP directory API