참고 : 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"

선적 서류 비치

특허

MIT

CodeAnalysis MCP 서버

확장 가능한 아키텍처를 통해 도구와 통찰력을 제공하는 고급 코드 분석을 위한 포괄적인 MCP(Model Context Protocol) 서버입니다.

🚀 특징

기본 코드 분석 : 구문 및 구조 분석
코드 메트릭 : 복잡성, 줄 수 및 코드 품질 메트릭
종속성 분석 : 패키지 및 가져오기 관계 시각화
지식 그래프 : 코드 관계 시각화 및 쿼리
메모리 시스템 : 코드베이스에 대한 통찰력을 저장하고 검색합니다.
시각화 : 다양한 형식(Mermaid, DOT, ASCII)으로 다이어그램 생성
사회기술 분석 : 팀과 코드 관계 이해
다중 저장소 분석 : 교차 저장소 관계 분석
진화 계획 : 코드 개선 권장 사항
실시간 감시 : 실시간으로 코드 변경 사항을 모니터링합니다.
IDE 통합 : 편집기 통합 도구
개발자 도구 : 향상된 AI 지원 개발 워크플로 지원

📋 필수 조건

노드.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

이렇게 하면 Claude Desktop, Cursor 또는 기타 MCP 클라이언트가 연결할 수 있는 MCP 서버가 시작됩니다.

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 지원 개발을 위한 개발자 도구 사용

이 프로젝트에는 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

🤝 기여하기

기여를 환영합니다! 풀 리퀘스트를 제출해 주세요.

📄 라이센스

이 프로젝트는 MIT 라이선스에 따라 라이선스가 부여되었습니다. 자세한 내용은 라이선스 파일을 참조하세요.

MCP SDK 상태 관리 아키텍처

이 프로젝트는 MCP(Model Context Protocol) 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 사용)

AI 개발 도구

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"
```
Raw Client ( tools/mcp-raw-client.js ): 서버 정보만 캡처하는 더 간단한 클라이언트입니다.
```
node tools/mcp-raw-client.js --task "Your task description"
```

Simple Client ( tools/simple-client.js ): stdio를 통해 서버와 통신합니다.

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

모든 클라이언트 스크립트는 프로젝트 루트에 ai-context.json 파일을 생성합니다. 이 파일에는 코드베이스에 대한 귀중한 컨텍스트가 포함되어 있으며, 이를 AI 어시스턴트와 공유하여 더욱 정확한 응답을 제공할 수 있습니다.

프롬프트 템플릿

AI 어시스턴트용 프롬프트 템플릿은 templates/ai-prompt-template.md 에서 제공됩니다. 이 템플릿은 MCP 도구의 적절한 맥락을 활용하여 AI 어시스턴트에 대한 요청을 구성하는 데 도움이 됩니다.

서버 전송 모드

MCP 서버는 두 가지 전송 모드를 지원합니다.

HTTP 전송 (기본값): 기본적으로 3000번 포트에서 실행됩니다. 클라이언트-서버 아키텍처에 가장 적합합니다.
Stdio Transport : 프로세스 직접 통신을 위한 기능입니다. STDIO_TRANSPORT=true 환경 변수를 활성화하세요.

세션 스토리지 아키텍처

MCP 코드 분석은 이제 자동 백엔드 감지 기능을 갖춘 모듈식 세션 저장소 아키텍처를 제공합니다.

유연한 스토리지 : Redis와 인메모리 스토리지 간 자동 전환
개발 친화적 : 개발 중 Redis 없이 실행
프로덕션 준비 완료 : 프로덕션 환경에서 지속성을 위해 Redis를 사용하세요
자동 폴백 : Redis를 사용할 수 없을 때 메모리 저장소로 우아하게 폴백합니다.

자세한 내용은 세션 저장소 아키텍처 문서를 참조하세요.

요구 사항

노드.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와의 통합

사용 예

분산 상태 관리

테스트

AI 개발 도구

클라이언트 스크립트

프롬프트 템플릿

서버 전송 모드

세션 스토리지 아키텍처

요구 사항

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` )