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 服务器

DeepSource npm 版本 npm 下载

与 DeepSource 集成的模型上下文协议 (MCP) 服务器为 AI 助手提供对代码质量指标、问题和分析结果的访问权限。

概述

DeepSource MCP 服务器使 AI 助手能够通过模型上下文协议 (MCP) 与 DeepSource 的代码质量分析功能进行交互。这种集成使 AI 助手能够：

检索代码指标和分析结果
访问和过滤问题
检查质量状态
分析项目质量随时间的变化

Related MCP server: CodeAlive MCP

特征

DeepSource API 集成：通过 GraphQL API 连接到 DeepSource
MCP 协议支持：实现 AI 助手集成的模型上下文协议
质量指标和阈值：使用阈值检索和管理代码质量指标
安全合规性报告：访问 OWASP Top 10、SANS Top 25 和 MISRA-C 合规性报告
依赖项漏洞：访问有关依赖项的安全漏洞信息
TypeScript/Node.js ：使用 TypeScript 构建，以实现类型安全和现代 JavaScript 功能
跨平台：适用于 Linux、macOS 和 Windows
强大的错误处理：针对网络、身份验证和解析问题的全面错误处理

与 Claude Desktop 一起使用

编辑claude_desktop_config.json ：
- 打开 Claude 桌面
- 前往Settings -> Developer -> Edit Config
- 将以下配置之一添加到mcpServers部分
重新启动 Claude Desktop 以应用更改

示例查询

连接后，您的 AI 助手可以使用 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 （必需）：用于身份验证的 DeepSource API 密钥
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"
      }
    }
  }
}

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

可用工具

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 存储库 ID
  - metricShortcode （必需）- 要更新的指标的短代码
  - metricKey （必需）- 指标的语言或上下文键
  - thresholdValue （可选） - 新的阈值，或为 null 以删除阈值
- 示例：设置 80% 线路覆盖率阈值：metricShortcode="LCV", metricKey="AGGREGATE", thresholdValue=80
update_metric_setting ：更新质量指标的设置
- 参数：
  - projectKey （必需）- DeepSource 项目的唯一标识符
  - repositoryId （必需）- GraphQL 存储库 ID
  - 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

配置 Claude 桌面

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

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 服务器

概述

特征

与 Claude Desktop 一起使用

示例查询

环境变量

Docker

NPX

可用工具

发展

先决条件

脚本

故障排除

启用调试日志记录

常见问题

执照

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