en es ja ko zh

CodeAnalysis MCP Server

Name: CodeAnalysis MCP Server
Author: 0xjcf

by 0xjcf

Overview Schema Related Servers Score Discussions

Python

Hybrid

MCP代码分析

强大的代码库分析工具包，利用模型上下文协议 (MCP) 进行 AI 辅助代码理解和转换。

特征

代码分析：使用抽象语法树解析和分析代码库
上下文生成：为人工智能模型创建丰富的上下文信息
工具集成：基于 MCP SDK 构建，实现无缝 AI 工具集成
可扩展架构：基于插件的自定义分析器系统

Related MCP server: Moatless MCP Server

要求

Node.js 18+
NPM 9+
Redis（可选，仅生产环境需要）

安装

# Clone the repository
git clone https://github.com/yourusername/mcp-codeanalysis.git
cd mcp-codeanalysis

# Install dependencies
npm install

# Build the project
npm run build

Redis 配置（可选）

Redis 用于生产环境中的会话存储。在开发和测试环境中，如果 Redis 不可用，系统将自动回退到内存会话存储。

注意：Redis 连接存在一个已知问题，即使 Redis 正在运行，操作也可能会失败。有关详情，请参阅plan.md中的“技术债务”部分。目前，您可以使用./use-memory-session.sh脚本运行带有内存会话存储的服务器。有关更多信息，请参阅Redis 故障排除指南。

安装 Redis：

# Ubuntu/Debian
sudo apt-get install redis-server

# macOS
brew install redis

# Windows (using WSL is recommended)
# For native Windows, download from https://redis.io/download

默认情况下，应用程序会尝试通过redis://localhost:6379连接到 Redis。您可以使用环境变量配置 Redis 连接：

# Set custom Redis URL
export REDIS_URL=redis://custom-host:6379

# Force memory session store even if Redis is available
export FORCE_MEMORY_SESSION=true

发展

# Run in development mode
npm run dev

# Run tests
npm test

# Run linting
npm run lint

用法

# Start the MCP server
npm start

# Run CLI tool
node ./tools/mcp-stdio-client.js --task "Analyze dependencies" --files "src/*.ts"

文档

执照

麻省理工学院

CodeAnalysis MCP 服务器

用于高级代码分析的综合模型上下文协议 (MCP) 服务器，通过可扩展的架构提供工具和见解。

🚀 功能

基本代码分析：语法和结构分析
代码指标：复杂度、行数和代码质量指标
依赖关系分析：包和导入关系可视化
知识图谱：代码关系可视化和查询
记忆系统：存储和检索有关代码库的见解
可视化：生成多种格式的图表（Mermaid、DOT、ASCII）
社会技术分析：了解团队和代码关系
多存储库分析：跨存储库关系分析
演进规划：代码改进建议
实时监控：实时监控代码变化
IDE 集成：编辑器集成工具
开发者工具：增强的AI辅助开发工作流程支持

📋 先决条件

Node.js 18+
npm 或 yarn
Redis（开发可选，生产推荐）

🛠️ 安装

# Clone the repository
git clone https://github.com/your-username/codeanalysis-mcp.git
cd codeanalysis-mcp

# Install dependencies
pnpm install

# Build the project
pnpm build

🖥️ 使用方法

CodeAnalysis MCP 服务器可以通过两种方式使用：

1. 作为 MCP 服务器

# Start the MCP server
pnpm start

这将启动 MCP 服务器，任何 MCP 客户端（如 Claude Desktop、Cursor 或其他客户端）都可以连接到该服务器。

2. 使用 CLI

该项目包括一个用于直接交互的综合 CLI：

# Get help
pnpm run cli --help

# Analyze a repository or directory
pnpm run cli analyze repo ./src

# Check code quality
pnpm run cli quality analyze ./src

3. 使用开发者工具进行AI辅助开发

该项目包括旨在增强人工智能辅助开发的特殊工具：

# Generate code context for AI assistants
node tools/ai-dev-helper.js --task="Implement new feature" --search="related functionality"

# Run example client
node examples/dev-tools-client.js

有关详细信息，请参阅开发人员工具指南。

📊 示例命令

基本分析

# Analyze a local directory
pnpm run cli analyze repo ./src

# Analyze a specific file
pnpm run cli analyze file ./src/server.ts

代码指标

# Get code metrics with function details
pnpm run cli metrics analyze ./src --functions

# Save metrics to a file
pnpm run cli metrics analyze ./src -o metrics-report.json

依赖关系分析

# Analyze dependencies in Mermaid format
pnpm run cli dependencies analyze ./src -f mermaid -o deps.mmd

# Visualize dependencies
pnpm run cli visualize dependencies -p ./src --format mermaid

代码质量

# Run quality analysis
pnpm run cli quality analyze ./src

# Generate HTML report
pnpm run cli quality analyze ./src --html -o quality-report.html

知识图谱

# Build knowledge graph
pnpm run cli knowledge build ./src

# Query the knowledge graph
pnpm run cli knowledge query ./src "type:function AND complexity>5"

# Export as diagram
pnpm run cli knowledge export ./src -f mermaid

洞察力与记忆

# Store an insight
pnpm run cli insights store -r ./src -t code-pattern -c "Refactoring opportunity"

# Retrieve insights
pnpm run cli insights retrieve -r ./src

开发人员工具

# Prepare context for AI interactions
node tools/ai-dev-helper.js --task="Fix authentication bug" --files="src/auth/*.ts" --search="login"

# Use with AI prompts
# Copy content from the generated ai-context.json file into your AI assistant prompt
# or use the template in templates/ai-prompt-template.md

🏗️ 建筑

该项目遵循 MCP 架构，包含以下组件：

MCP 服务器：使用 MCP 协议的核心服务器实现
分析特点：模块化代码分析功能
CLI ：用于直接交互的命令行界面
传输层：通信机制（默认为stdio）

🔌 与 MCP 客户端集成

该服务器与任何符合 MCP 的客户端兼容，包括：

克劳德桌面应用程序
光标编辑器
继续
其他 MCP 兼容工具

📝 路径规范

命令接受各种格式的路径：

本地目录： ./src或/absolute/path/to/dir
本地文件： ./src/file.ts或/path/to/file.ts
存储库 URL： https://github.com/username/repo

🤝 贡献

欢迎贡献代码！欢迎提交 Pull 请求。

📄 许可证

该项目根据 MIT 许可证获得许可 - 有关详细信息，请参阅 LICENSE 文件。

MCP SDK 状态管理架构

该项目为模型上下文协议 (MCP) SDK 实现了有状态工具，为构建在调用之间维护上下文的工具提供了框架。

架构概述

状态管理架构分为几个模块化组件：

src/state/
├── helpers/
│   └── statefulTool.ts       # Main entry point for stateful tool creation
├── machines/
│   └── toolMachine.ts        # XState machine for tool execution flow
├── services/
│   ├── toolService.ts        # Core execution service for tools
│   ├── redisToolExecutionService.ts  # Distributed execution service
│   ├── redisSessionStore.ts  # Redis-based session persistence
│   └── types.ts              # Shared type definitions

核心组件

状态工具助手（ `statefulTool.ts` ）

与 MCP SDK 的中央集成点，提供：

带有会话管理的工具注册
符合 MCP 标准的响应格式
内存会话管理
用于会话访问和操作的辅助函数

// Creating a stateful tool with state persistence
createStatefulTool(server, "my-tool", schema, handler);

// With description
createStatefulTool(server, "my-tool", "My stateful tool", schema, handler);

工具机（ `toolMachine.ts` ）

基于 XState 的状态机，定义工具的执行流程：

状态转换（空闲、工具选择、参数设置、执行等）
参数、结果和历史记录的上下文管理
错误处理和恢复路径

该组件将会话管理委托给 statefulTool 实现。

工具服务（ `toolService.ts` ）

协调工具状态转换的核心执行服务：

管理工具选择、参数验证和执行
跟踪执行历史
处理执行结果和错误

类型（ `types.ts` ）

共享类型定义可确保整个状态管理系统的一致性：

SessionData：用于存储工具状态的结构
SessionStore：会话存储实现的接口
ExecutionResult：工具的标准响应格式

与 MCP SDK 集成

该架构通过以下方式与 MCP SDK 集成：

使用状态管理扩展工具注册模式
保持与 MCP 响应格式的兼容性
为状态操作提供会话和上下文跟踪

使用示例

import { createServer } from "@modelcontextprotocol/sdk";
import { createStatefulTool } from "./state/helpers/statefulTool";
import { z } from "zod";

const server = createServer();

// Register a stateful tool
createStatefulTool(
  server,
  "counter",
  "A tool that maintains a count between invocations",
  {
    action: z.enum(["increment", "decrement", "reset"]),
  },
  async (params) => {
    // Get session ID from params (or a new one will be created)
    const sessionId = params.sessionId;

    // Process the action
    let count = 0;

    // Tool logic with state manipulation...

    return { count };
  }
);

server.listen(3000);

分布式状态管理

对于分布式环境，基于 Redis 的实现提供：

服务器重启后会话仍然保持
用于并发访问的分布式锁定
基于TTL的会话清理
网络/连接问题的错误处理

测试

这些组件包括全面的测试套件，用于验证：

工具状态转换
会话管理
错误处理和恢复
响应格式
分布式操作（使用Redis）

人工智能开发工具

CodeAnalysis MCP 服务器提供用于 AI 辅助开发的专用工具。这些工具有助于收集代码上下文，并将其提供给 AI 系统，从而提供更有效的辅助。

客户端脚本

该存储库在tools/目录中包含几个客户端脚本：

HTTP 客户端（ tools/http-client.js ）：通过 HTTP 传输连接到 MCP 服务器（默认）。

node tools/http-client.js --task "Your task description" --files "src/features/*.ts" --search "session"

原始客户端（ tools/mcp-raw-client.js ）：一个更简单的客户端，仅捕获服务器信息。
```
node tools/mcp-raw-client.js --task "Your task description"
```

简单客户端（ tools/simple-client.js ）：通过 stdio 与服务器通信。

node tools/simple-client.js --task "Your task description" --files "src/features/*.ts"

所有客户端脚本都会在项目根目录中生成一个ai-context.json文件。该文件包含有关您的代码库的宝贵上下文信息，可以与 AI 助手共享，以提供更明智的响应。

提示模板

templates/ai-prompt-template.md提供了 AI 助手的提示模板。此模板可帮助您根据 MCP 工具中的适当上下文，构建对 AI 助手的请求。

服务器传输模式

MCP 服务器支持两种传输模式：

HTTP 传输（默认）：默认在 3000 端口运行。最适合客户端-服务器架构。
Stdio Transport ：用于直接进程通信。设置STDIO_TRANSPORT=true环境变量即可启用。

会话存储架构

MCP 代码分析现在具有模块化会话存储架构，具有自动后端检测功能：

灵活存储：自动在 Redis 和内存存储之间切换
开发友好：开发过程中无需 Redis 即可运行
生产就绪：在生产环境中使用 Redis 进行持久化
自动回退：当 Redis 不可用时，优雅地回退到内存存储

有关更多详细信息，请参阅会话存储架构文档。

要求

Node.js 18+
npm 或 yarn
Redis（开发可选，生产推荐）

Available Tools

28 tools

analyze-cursorD

ParametersJSON Schema

Name	Required	Description
`filePath`	Yes	Path to the file
`fileContent`	Yes	Content of the file
`line`	Yes	Cursor line position (1-based)
`column`	Yes	Cursor column position (1-based)
`context`	Yes	Context around cursor

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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

Parameters1/5

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

Tool has no description.

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

Purpose1/5

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

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

analyze-dependenciesD

ParametersJSON Schema

Name	Required	Description
`repositoryUrl`	No	URL of the repository to analyze (e.g., 'https://github.com/username/repo')
`fileContent`	No	Source code content to analyze directly instead of from a repository
`language`	No	Programming language of the code (e.g., 'javascript', 'python', 'typescript', 'rust')

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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

Parameters1/5

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

Tool has no description.

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

Purpose1/5

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

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

analyze-filesD

ParametersJSON Schema

Name	Required	Description	Default
`files`	Yes	Files to analyze

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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

Parameters1/5

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

Tool has no description.

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

Purpose1/5

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

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

analyze-metricsD

ParametersJSON Schema

Name	Required	Description
`repositoryPath`	Yes	Path to the repository to analyze
`includeFiles`	No	Include file-level metrics in the output
`includeFunctions`	No	Include function-level metrics in the output

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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

Parameters1/5

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

Tool has no description.

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

Purpose1/5

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

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

analyze-qualityD

ParametersJSON Schema

Name	Required	Description
`repositoryPath`	Yes	Path to the repository to analyze
`includePaths`	No	Patterns of files to include
`excludePaths`	No	Patterns of files to exclude
`maxIssues`	No	Maximum number of issues to report
`minSeverity`	No	Minimum severity level to report

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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

Parameters1/5

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

Tool has no description.

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

Purpose1/5

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

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

analyze-repositoryD

ParametersJSON Schema

Name	Required	Description
`repositoryUrl`	Yes	URL of the repository to analyze (e.g., 'https://github.com/username/repo')
`depth`	No	Analysis depth - higher values analyze more deeply but take longer (1-5)
`includeDependencies`	No	Include dependency analysis in the results
`includeComplexity`	No	Include complexity metrics in the results
`specificFiles`	No	Specific files to analyze, can include glob patterns (e.g., ['src/*.ts', 'lib/utils.js'])

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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

Parameters1/5

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

Tool has no description.

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

Purpose1/5

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

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

build-knowledge-graphD

ParametersJSON Schema

Name	Required	Description	Default
`repositoryUrl`	Yes
`depth`	No
`includeExternalDependencies`	No

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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

Parameters1/5

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

Tool has no description.

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

Purpose1/5

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

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

calculate-metricsD

ParametersJSON Schema

Name	Required	Description
`repositoryUrl`	No	URL of the repository to analyze (e.g., 'https://github.com/username/repo')
`filePath`	No	Path to the file within the repository (e.g., 'src/main.ts')
`fileContent`	No	Source code content to analyze directly instead of from a repository
`language`	No	Programming language of the code (e.g., 'javascript', 'python', 'typescript', 'rust')
`metrics`	No	Specific metrics to calculate, such as 'complexity', 'linesOfCode', 'maintainability', 'functions', 'classes'

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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

Parameters1/5

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

Tool has no description.

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

Purpose1/5

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

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

clear-sessionD

ParametersJSON Schema

Name	Required	Description	Default
`sessionId`	Yes	ID of the session to clear

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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

Parameters1/5

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

Tool has no description.

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

Purpose1/5

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

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

create-sessionD

ParametersJSON Schema

Name	Required	Description	Default
`description`	No	Optional description for this session

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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

Parameters1/5

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

Tool has no description.

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

Purpose1/5

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

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

cross-repo-analysisD

ParametersJSON Schema

Name	Required	Default
`primaryRepoUrl`	Yes
`relatedRepoUrls`	Yes
`analysisType`	No	dependencies
`contextDepth`	No

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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

Parameters1/5

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

Tool has no description.

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

Purpose1/5

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

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

evolution-pathwayD

ParametersJSON Schema

Name	Required	Description	Default
`repositoryUrl`	Yes
`targetGoal`	Yes
`timeframe`	Yes
`includeImplementationDetails`	No

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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

Parameters1/5

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

Tool has no description.

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

Purpose1/5

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

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

export-knowledge-graphD

ParametersJSON Schema

Name	Required	Description	Default
`repositoryUrl`	Yes
`format`	No		json

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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

Parameters1/5

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

Tool has no description.

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

Purpose1/5

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

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

folder-structureD

ParametersJSON Schema

Name	Required	Description	Default
`path`	No	Relative path to the directory	.
`depth`	No	Depth of folders to show

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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

Parameters1/5

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

Tool has no description.

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

Purpose1/5

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

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

get-fileD

ParametersJSON Schema

Name	Required	Description
`path`	Yes	Relative path to the file
`startLine`	No	Starting line number (1-based)
`endLine`	No	Ending line number (1-based)

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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

Parameters1/5

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

Tool has no description.

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

Purpose1/5

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

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

get-session-historyD

ParametersJSON Schema

Name	Required	Description	Default
`sessionId`	Yes	ID of the session to retrieve history for
`limit`	No	Maximum number of history entries to return

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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

Parameters1/5

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

Tool has no description.

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

Purpose1/5

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

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

get-session-infoD

ParametersJSON Schema

Name	Required	Description	Default
`sessionId`	Yes	ID of the session to retrieve information for

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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

Parameters1/5

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

Tool has no description.

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

Purpose1/5

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

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

list-quality-rulesD

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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

Parameters1/5

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

Tool has no description.

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

Purpose1/5

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

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

list-sessionsD

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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

Parameters1/5

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

Tool has no description.

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

Purpose1/5

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

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

project-infoD

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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

Parameters1/5

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

Tool has no description.

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

Purpose1/5

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

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

query-knowledge-graphD

ParametersJSON Schema

Name	Required	Default
`query`	Yes
`repositoryUrl`	No
`contextDepth`	No
`includeExternalKnowledge`	No
`outputFormat`	No	json

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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

Parameters1/5

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

Tool has no description.

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

Purpose1/5

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

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

retrieve-codebase-insightsD

ParametersJSON Schema

Name	Required	Description	Default
`repositoryUrl`	Yes
`insightTypes`	No
`tags`	No
`relatedFile`	No
`limit`	No

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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

Parameters1/5

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

Tool has no description.

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

Purpose1/5

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

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

search-codeD

ParametersJSON Schema

Name	Required	Description
`query`	Yes	Search query to find code in the repository
`filePattern`	No	Optional file pattern to limit search (e.g., '*.ts')
`maxResults`	No	Maximum number of results to return

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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

Parameters1/5

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

Tool has no description.

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

Purpose1/5

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

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

socio-technical-analysisD

ParametersJSON Schema

Name	Required	Default
`repositoryUrl`	Yes
`includeContributorPatterns`	No
`includeTeamDynamics`	No
`timeRange`	No
`visualizationFormat`	No	json

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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

Parameters1/5

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

Tool has no description.

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

Purpose1/5

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

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

store-codebase-insightD

ParametersJSON Schema

Name	Required	Description	Default
`repositoryUrl`	Yes
`insightType`	Yes
`insightContent`	Yes
`relatedFiles`	No
`tags`	No

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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

Parameters1/5

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

Tool has no description.

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

Purpose1/5

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

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

update-codebase-insightD

ParametersJSON Schema

Name	Required	Description	Default
`insightId`	Yes
`insightContent`	No
`insightType`	No
`relatedFiles`	No
`tags`	No

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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

Parameters1/5

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

Tool has no description.

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

Purpose1/5

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

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

visualize-code-structureD

ParametersJSON Schema

Name	Required	Default
`repositoryUrl`	No
`filePath`	No
`fileContent`	No
`showMethods`	No
`showAttributes`	No
`format`	No	mermaid

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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

Parameters1/5

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

Tool has no description.

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

Purpose1/5

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

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

visualize-dependenciesD

ParametersJSON Schema

Name	Required	Default
`repositoryUrl`	No
`filePath`	No
`path`	No
`fileContent`	No
`format`	No	mermaid

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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

Parameters1/5

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

Tool has no description.

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

Purpose1/5

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

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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.

28 tool updatesJun 13, 2025
- First observedanalyze-cursor
- First observedanalyze-dependencies
- First observedanalyze-files
- First observedanalyze-metrics
- First observedanalyze-quality
- First observedanalyze-repository
- First observedbuild-knowledge-graph
- First observedcalculate-metrics
- First observedclear-session
- First observedcreate-session
- First observedcross-repo-analysis
- First observedevolution-pathway
- First observedexport-knowledge-graph
- First observedfolder-structure
- First observedget-file
- First observedget-session-history
- First observedget-session-info
- First observedlist-quality-rules
- First observedlist-sessions
- First observedproject-info
- First observedquery-knowledge-graph
- First observedretrieve-codebase-insights
- First observedsearch-code
- First observedsocio-technical-analysis
- First observedstore-codebase-insight
- First observedupdate-codebase-insight
- First observedvisualize-code-structure
- First observedvisualize-dependencies

Install Server

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

Multiple tools have unclear boundaries and overlapping purposes, such as analyze-files, analyze-repository, and project-info, which could all relate to codebase analysis, and analyze-metrics versus calculate-metrics, which seem redundant. The lack of descriptions exacerbates this ambiguity, making it difficult for an agent to distinguish between similar-sounding tools like visualize-code-structure and visualize-dependencies.

Naming Consistency3/5

The naming shows mixed conventions: most tools use kebab-case (e.g., analyze-cursor, build-knowledge-graph), but some deviate with underscores (e.g., cross-repo-analysis, socio-technical-analysis) or inconsistent verb styles (e.g., analyze-* versus get-* versus list-*). While readable, the patterns are not fully consistent, leading to a moderate score.

Tool Count2/5

With 28 tools, this server feels heavy and potentially over-scoped for code analysis, suggesting redundancy or fragmentation. A typical well-scoped server might have 3-15 tools; this count is borderline excessive, indicating a lack of focus that could overwhelm agents and reduce usability.

Completeness3/5

Inferring the domain as code analysis, the tool set covers aspects like analysis, metrics, knowledge graphs, and visualization, but there are notable gaps. For example, it lacks clear CRUD operations for core entities beyond insights (e.g., no update or delete for sessions), and the overlap in analysis tools suggests incomplete coverage rather than a streamlined workflow.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

GitHub Repository

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

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
saidsef-mcp-github-pr-issue-analyser
ai.smithery
A Model Context Protocol (MCP) application for automated GitHub PR analysis and issue management.…
Version Control Developer Tools Project Management
26

Related MCP Servers

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
Moatless MCP Server
Code Analysis Vector Databases Code Execution
TwT23333
F
license
A
quality
D
maintenance
A Model Context Protocol (MCP) server for advanced code analysis and editing with semantic search capabilities, enabling AI assistants to perform complex code operations through a standardized interface.
Updated a year ago (2025-08-08 13:07 UTC)
15
1
-
CodeCompass MCP
TheAlchemist6
A
license
A
quality
D
maintenance
An enterprise-grade Model Context Protocol server that provides comprehensive GitHub repository analysis and AI-powered development assistance through 11 streamlined tools.
Updated a year ago (2025-07-18 02:46 UTC)
11
2
MIT
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/0xjcf/MCP_CodeAnalysis'

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

MCP代码分析

特征

要求

安装

Redis 配置（可选）

发展

用法

文档

执照

CodeAnalysis MCP 服务器

🚀 功能

📋 先决条件

🛠️ 安装

🖥️ 使用方法

1. 作为 MCP 服务器

2. 使用 CLI

3. 使用开发者工具进行AI辅助开发

📊 示例命令

基本分析

代码指标

依赖关系分析

代码质量

知识图谱

洞察力与记忆

开发人员工具

🏗️ 建筑

🔌 与 MCP 客户端集成

📝 路径规范

🤝 贡献

📄 许可证

MCP SDK 状态管理架构

架构概述

核心组件

状态工具助手（ statefulTool.ts ）

工具机（ toolMachine.ts ）

工具服务（ toolService.ts ）

类型（ types.ts ）

与 MCP SDK 集成

使用示例

分布式状态管理

测试

人工智能开发工具

客户端脚本

提示模板

服务器传输模式

会话存储架构

要求

Available Tools

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

状态工具助手（ `statefulTool.ts` ）

工具机（ `toolMachine.ts` ）

工具服务（ `toolService.ts` ）

类型（ `types.ts` ）