Which integrations are available for this server?

Connects with Node.js applications in the Trae IDE environment to retrieve diagnostic information and code quality issues. Integrates with TypeScript diagnostics, allowing AI agents to access TypeScript type errors and warnings in real-time from the Trae IDE environment.

How do I use MCP Diagnostics?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@MCP Diagnostics check src/index.ts for any issues" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

MCP Diagnostics

by lin037

Overview Schema Related Servers Score Discussions

JavaScript

Local

MCP Diagnostics - Trae IDE 诊断信息读取工具

npm version License: MIT Node.js TypeScript MCP

一个专门为 Trae IDE 开发的 MCP (Model Context Protocol) 服务器，让 Trae 的 AI Agent 能够实时获取项目中的错误、警告和提示信息，从而提供更智能的代码分析和建议。

English Documentation: README_EN.md

🌟 功能特性

🔍 实时诊断: 读取 Trae IDE 当前工作区的所有诊断信息（错误/警告/提示）
📁 文件级诊断: 获取指定文件的诊断信息，支持多种路径格式
📊 统计摘要: 快速查看诊断统计（文件数、错误数、警告数）
🤖 AI 增强: 让 Trae 的 AI Agent 能够理解代码问题，提供更精准的修复建议
🔌 扩展协同: 通过配套的 VS Code 扩展，稳定、高效地获取诊断信息。
🎯 智能匹配: 支持相对路径、文件名、绝对URI等多种文件路径格式

Related MCP server: devpulse-mcp

🎯 项目目标

本项目专门为 Trae IDE 设计，目的是让 Trae 的 AI Agent 能够：

实时了解代码中的错误和警告
提供基于实际问题的修复建议
智能分析项目代码质量
协助开发者快速定位和解决问题

🚀 快速开始

步骤 1: 安装 VS Code 扩展

为了让此工具能够访问 VS Code 的诊断信息，您需要先安装配套的 VS Code 扩展。

打开 VS Code。
打开命令面板 (Ctrl+Shift+P 或 Cmd+Shift+P)。
选择 “扩展: 从 VSIX 安装...”。
找到本项目 diagnostics-extension 目录下的 trae-diagnostics-server-0.0.1.vsix 文件并安装。
安装后，重新加载 VS Code 窗口。

安装成功后，扩展会自动在后台运行一个本地服务器，用于提供诊断数据。

步骤 2: 克隆并构建项目

# 克隆项目
git clone https://github.com/lin037/mcp-diagnostics-trae.git
cd mcp-diagnostics

# 安装依赖
npm install

# 构建项目
npm run build

步骤 2: 在 Trae 中配置

打开 Trae 的MCP设置
添加选择手动添加
粘贴以下配置：

{
  "mcpServers": {
    "diagnostics": {
      "command": "npx",
      "args": ["-y", "/path/to/mcp-diagnostics"],
      "description": "Trae IDE 诊断信息读取工具"
    }
  }
}

注意：要将args中的/path/to/mcp-diagnostics替换为你clone下来项目的实际路径。

例如：git clone 后，项目在E:/MCPWork/trae-diagnostics/mcp目录下：

{
  "mcpServers": {
    "diagnostics": {
      "command": "npx",
      "args": [
        "-y",
        "E:/MCPWork/trae-diagnostics/mcp"
      ]
    }
  }
}

🛠️ MCP 工具清单

1. `getDiagnostics()`

获取当前工作区所有文件的诊断信息。

输入: 无参数

{}

输出: 诊断信息数组

[
  {
    "uri": "file:///workspace/src/index.ts",
    "diagnostics": [
      {
        "range": {
          "start": { "line": 12, "character": 5 },
          "end": { "line": 12, "character": 10 }
        },
        "severity": 1,
        "source": "typescript",
        "message": "类型 'string' 不能赋值给类型 'number'。"
      }
    ]
  }
]

2. `getDiagnosticsForPath(filePath)` ⭐ 推荐使用

根据文件路径获取诊断信息，支持灵活的路径匹配。

输入:

{
  "filePath": "src/index.ts"
}

支持的路径格式:

相对路径：src/index.ts
文件名：index.ts
带目录的文件名：test/TestJava.java

输出: 匹配文件的诊断信息数组

使用示例:

查看 TypeScript 文件："filePath": "src/index.ts"
查看 Java 文件："filePath": "TestJava.java"
查看测试文件："filePath": "test/test-errors.ts"

3. `getDiagnosticsForFile(fileUri)`

获取指定文件的诊断信息（需要完整URI）。

输入:

{
  "fileUri": "file:///workspace/src/index.ts"
}

注意: 必须使用 file:///workspace/ 开头的完整URI格式。

4. `getDiagnosticsSummary()`

获取诊断统计信息。

输入: 无参数

{}

输出: 统计摘要

{
  "totalFiles": 4,
  "errors": 4,
  "warnings": 4
}

💬 使用示例

获取项目诊断摘要

用户: "请帮我查看当前项目的诊断摘要"

AI 会自动调用 getDiagnosticsSummary 工具。

获取所有诊断详情

用户: "请列出当前项目的所有错误和警告"

AI 会调用 getDiagnostics 工具。

获取特定文件的诊断

用户: "请检查 src/index.ts 文件的问题"

AI 会调用 getDiagnosticsForPath 工具，参数为 {"filePath": "src/index.ts"}。

支持的对话示例

"当前项目有多少个错误？"
"帮我找出所有 TypeScript 类型错误"
"列出所有警告信息"
"检查 TestJava.java 文件有什么问题"
"项目代码质量如何？"
"有哪些文件需要修复？"

📊 诊断严重级别

1 - 错误 (Error) ❌
2 - 警告 (Warning) ⚠️
3 - 信息 (Info) ℹ️
4 - 提示 (Hint) 💡

🔧 技术架构

Trae IDE (MCP客户端) ←→ MCP服务器 ←→ Trae IDE (DAP接口)

MCP 层: 使用 @modelcontextprotocol/sdk 实现标准 MCP 协议
通信层: 通过 stdin/stdout 与 Trae 通信
诊断层: 通过 Debug Adapter Protocol 连接 Trae IDE
数据层: 解析和格式化诊断信息

🛠️ 开发

开发模式运行

npm run dev

构建

npm run build

测试连接

# 启动服务器
npm start

# 在另一个终端测试
node test-file-diagnostics.js

❓ 故障排除

无法连接到 Trae IDE

解决方案:

确保 Trae IDE 正在运行
检查项目已在 Trae 中打开
等待语言服务器完成初始化

返回空诊断

可能原因:

项目没有错误或警告
语言服务器还在分析中
文件类型不支持诊断

解决方案:

等待几秒钟后重试
确保文件已保存
检查 Trae 是否显示诊断信息

getDiagnosticsForFile 返回空数组

解决方案:

使用 getDiagnosticsForPath 工具（推荐）
确保使用正确的 URI 格式：file:///workspace/文件路径
先调用 getDiagnostics 查看可用的文件URI

工具调用失败

检查项目:

MCP 服务器是否正常启动
网络连接是否正常
查看 Trae 的错误日志

🔮 未来展望

官方版本: 相信 Trae 官方未来可能会开发官方版本的 MCP 诊断工具
社区维护: 本项目完全由作者通过 AI 开发，技术有限，未来维护主要依靠社区 fork
当前状态: 目前版本功能完整，足够日常使用

🤝 贡献与维护

本项目由作者通过 AI 助手开发完成，由于作者技术有限且时间有限，未来的维护主要依靠社区：

Fork 欢迎: 欢迎其他开发者 fork 本项目进行改进
Issue 反馈: 可以提交 Issue，但响应可能不及时
Pull Request: 欢迎提交 PR，会尽量审核
社区驱动: 鼓励社区自发维护和改进

📄 许可证

本项目采用 MIT 许可证。

🎉 现在您可以让 Trae 的 AI Agent 实时了解项目中的代码问题了！

Available Tools

4 tools

getDiagnosticsB

获取当前工作区所有文件的诊断信息（错误/警告/提示）。返回完整的诊断列表，包含所有文件的详细错误信息。

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

B3/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 of behavioral disclosure. It states the tool returns '完整的诊断列表，包含所有文件的详细错误信息' (complete diagnostic list with detailed error information for all files), which describes the output scope but lacks critical behavioral details. It doesn't mention whether this is a read-only operation, potential performance impacts, rate limits, or authentication requirements. For a tool with zero annotation coverage, this is insufficient.

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 concise and well-structured in two sentences. The first sentence states the purpose, and the second clarifies the output scope. There's no wasted text, and it's front-loaded with the core functionality. It could be slightly more efficient by combining ideas, but it's already very tight.

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 (diagnostics across all files), lack of annotations, and no output schema, the description is incomplete. It mentions the output includes a 'complete diagnostic list' but doesn't specify the format, structure, or what 'detailed error information' entails. For a tool with no structured output documentation and behavioral gaps, more context is needed to be fully helpful.

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

Parameters4/5

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

The tool has 0 parameters, and schema description coverage is 100%. With no parameters to document, the description appropriately doesn't discuss any. It focuses on the tool's purpose and output, which is sufficient. A baseline of 4 is appropriate for zero-parameter tools when the description is otherwise adequate.

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

Purpose4/5

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

The description clearly states the tool's purpose: '获取当前工作区所有文件的诊断信息（错误/警告/提示）' (Get diagnostic information for all files in the current workspace). It specifies the resource (all files in workspace) and the type of information (diagnostics including errors/warnings/hints). However, it doesn't explicitly differentiate from its siblings (getDiagnosticsForFile, getDiagnosticsForPath, getDiagnosticsSummary), which would be needed for a score of 5.

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 its siblings. It mentions '所有文件' (all files), which implies a comprehensive scope, but doesn't explicitly contrast with the more targeted sibling tools (for specific files, paths, or summaries). No usage context, exclusions, or alternatives are provided.

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

getDiagnosticsForFileA

获取指定文件的诊断信息。⚠️ 注意：需要使用完整的workspace URI格式，如 "file:///workspace/src/index.ts"。如果不确定URI格式，建议使用 getDiagnosticsForPath 工具。

ParametersJSON Schema

Name	Required	Description	Default
`fileUri`	Yes	完整的文件URI，必须使用 file:///workspace/ 开头的格式。示例：file:///workspace/src/index.ts

TDQS

A3.9/5.0

Behavior3/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It adds useful context about the URI format requirement and the warning symbol (⚠️), which hints at potential issues. However, it doesn't describe what diagnostic information is returned, error conditions, or performance characteristics.

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

Conciseness5/5

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

The description is perfectly concise and well-structured: two sentences that efficiently convey the purpose, critical requirement, and alternative tool. Every sentence earns its place with no wasted words.

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

Completeness3/5

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

Given the tool's moderate complexity (single parameter but with specific format requirements), no annotations, and no output schema, the description is adequate but incomplete. It covers usage and parameter format well but lacks information about what diagnostic information is returned, which is important context for an agent.

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

Parameters3/5

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

Schema description coverage is 100%, so the schema already fully documents the fileUri parameter. The description reinforces the URI format requirement but doesn't add significant semantic meaning beyond what's in the schema. Baseline 3 is appropriate when schema does the heavy lifting.

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

Purpose4/5

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

The description clearly states the tool's purpose: '获取指定文件的诊断信息' (get diagnostic information for a specified file). It specifies the resource (file) and action (get diagnostics), but doesn't explicitly differentiate from sibling tools like getDiagnostics or getDiagnosticsForPath beyond mentioning the latter as an alternative for uncertain URI formats.

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

Usage Guidelines5/5

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

The description provides explicit guidance on when to use this tool vs. alternatives: it specifies that this tool requires a full workspace URI format and recommends using getDiagnosticsForPath if unsure about the URI format. This clearly defines usage context and exclusions.

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

getDiagnosticsForPathB

🌟 推荐工具：根据文件路径获取诊断信息，支持灵活的路径匹配。可以使用相对路径、文件名等多种格式，比 getDiagnosticsForFile 更易用。

ParametersJSON Schema

Name	Required	Description	Default
`filePath`	Yes	文件路径，支持多种格式： - 相对路径：src/index.ts - 文件名：index.ts - 带目录的文件名：test/TestJava.java 示例：要查看 index.ts 文件的问题，使用 "src/index.ts" 或 "index.ts"

TDQS

B3.4/5.0

Behavior3/5

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

No annotations are provided, so the description carries the full burden. It discloses that the tool supports flexible path matching (relative paths, filenames) and is easier to use than getDiagnosticsForFile, which adds some behavioral context. However, it doesn't cover other important aspects like what diagnostic information is returned, error handling, performance implications, or authentication needs. The description adds value but leaves significant gaps in behavioral disclosure.

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 concise with two sentences that efficiently convey key information: the tool's purpose and its flexibility compared to a sibling tool. It's front-loaded with the main function. However, the use of an emoji (🌟) and promotional language ('推荐工具' - recommended tool) adds minor fluff that doesn't earn its place in a tool definition.

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

Completeness3/5

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

Given the tool has 1 parameter with full schema coverage, no annotations, and no output schema, the description is moderately complete. It covers the purpose and some usage context but lacks details on what diagnostic information is returned (since no output schema exists), error cases, or deeper behavioral traits. For a tool that presumably returns diagnostic data, more context on the output would be helpful to compensate for the missing output 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?

The schema description coverage is 100%, with the parameter 'filePath' fully documented in the input schema (including examples and supported formats). The description adds minimal value beyond the schema by mentioning '支持灵活的路径匹配' (supports flexible path matching) and '可以使用相对路径、文件名等多种格式' (can use relative paths, filenames, and other formats), but this largely repeats what's in the schema. Baseline 3 is appropriate as the schema does the heavy lifting.

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

Purpose4/5

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

The description clearly states the tool's purpose: '根据文件路径获取诊断信息' (get diagnostic information based on file path). It specifies the resource (diagnostic information) and the mechanism (file path). However, it doesn't explicitly differentiate from sibling tools like getDiagnosticsForFile beyond saying it's '更易用' (easier to use), which is somewhat vague rather than specific functional differentiation.

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

Usage Guidelines3/5

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

The description provides some usage context by mentioning support for flexible path matching (relative paths, filenames) and comparing it to getDiagnosticsForFile as 'easier to use.' However, it doesn't explicitly state when to use this tool versus alternatives like getDiagnostics or getDiagnosticsSummary, nor does it provide clear exclusions or prerequisites. The guidance is implied rather than explicit.

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

getDiagnosticsSummaryB

获取诊断统计摘要，快速了解项目整体代码质量。返回文件总数、错误数量、警告数量的统计信息。

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

B3.4/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 discloses that the tool returns statistical information (file count, error count, warning count), which is useful behavioral context. However, it doesn't mention other traits like whether it's read-only, requires specific permissions, has rate limits, or how it handles large projects. For a tool with zero annotation coverage, this leaves significant gaps in behavioral understanding.

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 very concise and well-structured in a single sentence: it states the action, purpose, and return values clearly. There's no wasted text, and it's front-loaded with the key information. Every part of the sentence earns its place by contributing essential details.

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

Completeness3/5

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

Given the tool's complexity (simple, no parameters) and lack of annotations and output schema, the description is moderately complete. It explains the purpose and output content (file total, error count, warning count), which is adequate for a basic summary tool. However, it doesn't cover behavioral aspects like performance or limitations, and without an output schema, the return format remains unspecified. This makes it minimally viable but with gaps.

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

Parameters4/5

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

The tool has 0 parameters, and schema description coverage is 100% (since there are no parameters to describe). The description doesn't need to add parameter semantics, but it does clarify the scope ('项目整体代码质量' - overall project code quality) and output content. With no parameters, the baseline is 4, and the description adds value by explaining what the tool does without parameter-related confusion.

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

Purpose4/5

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

The description clearly states the tool's purpose: '获取诊断统计摘要，快速了解项目整体代码质量' (Get diagnostic statistics summary, quickly understand overall code quality of the project). It specifies the verb '获取' (get) and resource '诊断统计摘要' (diagnostic statistics summary), and mentions what information it returns. However, it doesn't explicitly differentiate from sibling tools like getDiagnostics, getDiagnosticsForFile, and getDiagnosticsForPath, which appear to provide more granular diagnostics.

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

Usage Guidelines3/5

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

The description implies usage by stating it provides a '快速了解项目整体代码质量' (quick understanding of overall project code quality), suggesting it's for high-level summaries rather than detailed analysis. However, it doesn't explicitly state when to use this tool versus the sibling tools (e.g., getDiagnosticsForFile for file-specific details) or provide any exclusions or alternatives. The guidance is implied but not detailed.

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

Install Server

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

TDQS

A3.5/5.0

Disambiguation3/5

The tools have overlapping purposes that could cause confusion. getDiagnosticsForFile and getDiagnosticsForPath both retrieve diagnostics for a single file, with the latter described as more flexible and recommended, creating ambiguity about when to use each. However, getDiagnostics and getDiagnosticsSummary serve clearly distinct purposes (all files vs. summary statistics), which helps mitigate some confusion.

Naming Consistency5/5

All tool names follow a consistent camelCase pattern with a clear verb_noun structure (getDiagnostics, getDiagnosticsForFile, getDiagnosticsForPath, getDiagnosticsSummary). The naming is predictable and readable throughout the set, with no deviations in style or convention.

Tool Count5/5

With 4 tools, the count is well-scoped for a diagnostics server. Each tool appears to serve a specific and necessary function (e.g., retrieving all diagnostics, per-file diagnostics, and summaries), making the set focused and manageable without being overly sparse or bloated.

Completeness4/5

The tool surface covers core diagnostics retrieval operations comprehensively, including all files, per-file, and summary views. A minor gap exists in the lack of tools for managing or clearing diagnostics (e.g., reset or update functions), but agents can likely work with the provided read-only operations for most use cases.

Maintenance

ActivityInactive

ResponsivenessSyncing

Resources

Need Help?

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

slima
io.github.slima-ai
MCP Server for Slima - AI Writing IDE for Novel Authors with AI Beta Reader.
Developer Tools
21
mcp-server
com.niftypm
Nifty's MCP server — exposes tasks, projects, messages, and files as tools for AI agents.
Project Management Communication File Systems
2
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-aichat
io.github.AceDataCloud
MCP server for AI dialogue using various LLM models via AceDataCloud
AI & Machine Learning
2

Related MCP Servers

vscode-mcp-server
Developer Tools Code Execution Command Line
juehang
A
license
A
quality
D
maintenance
MCP server to expose VS Code editing features to an LLM for AI coding
Updated 8 months ago (2026-01-07 15:40 UTC)
9
98
391
MIT
devpulse-mcp
Developer Tools Monitoring Observability
tao-izm
A
license
A
quality
D
maintenance
Zero-config MCP server that gives AI coding assistants a real-time diagnostic snapshot of your local dev environment. Detects framework, running services, recent errors, git state, and provides a health diagnosis in one call.
Updated 4 months ago (2026-05-07 03:05 UTC)
3
40
1
MIT
Diagnostics MCP Server
Developer Tools Code Analysis
Maaz0313-png
A
license
Not graded
quality
B
maintenance
An HTTP MCP server providing AI agents with real-time access to all VS Code diagnostics (TypeScript, ESLint, Prettier, etc.) via 5 powerful tools including workspace health scoring.
Updated a year ago (2025-10-03 07:06 UTC)
1
MIT
mcdev-mcp
Games & Gamification Code Analysis Autonomous Agents
use-ai-for-mc
A
license
A
quality
A
maintenance
An MCP server that empowers AI coding agents to work effectively with Minecraft mod development, providing static analysis of decompiled source code and runtime interaction with a running Minecraft instance.
Updated 16 days ago (2026-08-18 10:26 UTC)
31
42
13
MIT

Appeared in Searches

Cómo ver errores y advertencias en Visual Studio Code

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/lin037/mcp-diagnostics-trae'

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

MCP Diagnostics - Trae IDE 诊断信息读取工具

🌟 功能特性

🎯 项目目标

🚀 快速开始

步骤 1: 安装 VS Code 扩展

步骤 2: 克隆并构建项目

步骤 2: 在 Trae 中配置

🛠️ MCP 工具清单

1. getDiagnostics()

2. getDiagnosticsForPath(filePath) ⭐ 推荐使用

3. getDiagnosticsForFile(fileUri)

4. getDiagnosticsSummary()

💬 使用示例

获取项目诊断摘要

获取所有诊断详情

获取特定文件的诊断

支持的对话示例

📊 诊断严重级别

🔧 技术架构

🛠️ 开发

开发模式运行

构建

测试连接

❓ 故障排除

无法连接到 Trae IDE

返回空诊断

getDiagnosticsForFile 返回空数组

工具调用失败

🔮 未来展望

🤝 贡献与维护

📄 许可证

Available Tools

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Appeared in Searches

Latest Blog Posts

MCP directory API

1. `getDiagnostics()`

2. `getDiagnosticsForPath(filePath)` ⭐ 推荐使用

3. `getDiagnosticsForFile(fileUri)`

4. `getDiagnosticsSummary()`