Which integrations are available for this server?

Provides read-only access to MySQL databases, enabling listing databases and tables, describing table schemas, executing SELECT, SHOW, DESCRIBE, EXPLAIN, and EXPLAIN ANALYZE queries, and retrieving foreign key relationships between tables.

How do I use @cano721/mysql-mcp-server?

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

@cano721/mysql-mcp-server

by cano721

Overview Schema Related Servers Score Discussions

JavaScript

Remote

npm version

MySQL 데이터베이스 접근 MCP 서버 (@cano721/mysql-mcp-server)

이 MCP 서버는 MySQL 데이터베이스에 읽기 전용 접근을 제공합니다. 다음과 같은 기능을 제공합니다:

사용 가능한 데이터베이스 목록 조회
데이터베이스의 테이블 목록 조회
테이블 스키마 설명
읽기 전용 SQL 쿼리 실행

📋 목차

Related MCP server: MySQL MCP Server

보안 기능

읽기 전용 접근: SELECT, SHOW, DESCRIBE 문 항상 허용
분석 도구: EXPLAIN, EXPLAIN ANALYZE 기본 허용 (읽기 전용 분석)
쿼리 검증: SQL 인젝션 방지 및 데이터 수정 시도 차단
쿼리 타임아웃: 장시간 실행되는 쿼리로부터 리소스 보호
행 제한: 과도한 데이터 반환 방지 (최대 1000행)
세밀한 권한 제어: 각 분석 도구별 개별 활성화/비활성화

지원되는 SQL 명령어:

SELECT - 데이터 조회 및 분석 (항상 허용)
SHOW - 데이터베이스/테이블/인덱스 정보 조회 (항상 허용)
DESCRIBE / DESC - 테이블 구조 및 컬럼 정보 (항상 허용)
EXPLAIN - 쿼리 실행 계획 분석 (기본 허용, 읽기 전용)
EXPLAIN ANALYZE - 쿼리 실제 실행 및 성능 분석 (기본 허용, 읽기 전용)

요구사항

Node.js: 18.0.0 이상 → Node.js 업데이트 방법
npm: 8.0.0 이상 (Node.js와 함께 설치됨)

💡 Node.js 버전이 낮다면? 여기를 클릭해서 업데이트 방법을 확인하세요

설치

방법 1: npx 사용 (대부분의 MCP 클라이언트에서 권장)

npx를 사용하면 별도 설치 없이 바로 사용할 수 있습니다:

# 설치 없이 바로 사용 가능
npx @cano721/mysql-mcp-server

💡 항상 최신 버전 사용하기:

# @latest 태그를 붙이면 캐시를 무시하고 항상 최신 버전을 가져옵니다
npx @cano721/mysql-mcp-server@latest

MCP 설정에서도 @latest를 사용하면 항상 최신 버전을 사용할 수 있습니다:

{
  "args": ["@cano721/mysql-mcp-server@latest"]
}

주의: 일부 MCP 클라이언트에서 npx가 제대로 작동하지 않을 수 있습니다. 그런 경우 방법 2를 사용하세요.

방법 2: 전역 설치 (npx가 안 될 때 권장)

npx에 문제가 있거나 더 안정적인 연결을 원한다면:

# 전역 설치
npm install -g @cano721/mysql-mcp-server

# 설치 확인
mysql-mcp-server --version

방법 3: 소스에서 빌드

개발이나 커스터마이징이 필요한 경우:

# 저장소 복제
git clone https://github.com/cano721/mysql-mcp-server.git
cd mysql-mcp-server

# 의존성 설치 및 빌드
npm install
npm run build

방법 4: Smithery를 통한 설치

Claude AI용 MySQL 데이터베이스 접근 MCP 서버를 Smithery를 통해 자동으로 설치:

npx -y @smithery/cli install @cano721/mysql-mcp-server --client claude

2. 환경 변수 설정

서버는 다음 환경 변수가 필요합니다:

필수 환경 변수:

MYSQL_HOST: 데이터베이스 서버 호스트명
MYSQL_USER: 데이터베이스 사용자명

선택적 환경 변수:

MYSQL_PORT: 데이터베이스 서버 포트 (기본값: 3306)
MYSQL_PASSWORD: 데이터베이스 비밀번호 (보안 연결에 권장)
MYSQL_DATABASE: 기본 데이터베이스명
MYSQL_QUERY_TIMEOUT: 쿼리 타임아웃 (밀리초, 기본값: 60000 = 60초)

보안 설정:

MYSQL_ALLOW_EXPLAIN: EXPLAIN 쿼리 허용 여부 (기본값: true, 비활성화: false)
MYSQL_ALLOW_ANALYZE: ANALYZE 쿼리 허용 여부 (기본값: true, 비활성화: false)

3. MCP 설정에 추가

MCP 설정 파일에 다음 구성을 추가하세요:

npx 사용 시:

{
  "mcpServers": {
    "mysql": {
      "command": "npx",
      "args": ["@cano721/mysql-mcp-server@latest"],
      "env": {
        "MYSQL_HOST": "your-mysql-host",
        "MYSQL_PORT": "3306",
        "MYSQL_USER": "your-mysql-user",
        "MYSQL_PASSWORD": "your-mysql-password",
        "MYSQL_DATABASE": "your-default-database"
      },
      "disabled": false,
      "autoApprove": []
    }
  }
}

전역 설치 후 사용 시:

{
  "mcpServers": {
    "mysql": {
      "command": "mysql-mcp-server",
      "args": [],
      "env": {
        "MYSQL_HOST": "your-mysql-host",
        "MYSQL_PORT": "3306",
        "MYSQL_USER": "your-mysql-user",
        "MYSQL_PASSWORD": "your-mysql-password",
        "MYSQL_DATABASE": "your-default-database"
      },
      "disabled": false,
      "autoApprove": []
    }
  }
}

소스에서 빌드한 경우:

{
  "mcpServers": {
    "mysql": {
      "command": "node",
      "args": ["/path/to/mysql-mcp-server/build/index.js"],
      "env": {
        "MYSQL_HOST": "your-mysql-host",
        "MYSQL_PORT": "3306",
        "MYSQL_USER": "your-mysql-user",
        "MYSQL_PASSWORD": "your-mysql-password",
        "MYSQL_DATABASE": "your-default-database"
      },
      "disabled": false,
      "autoApprove": []
    }
  }
}

사용 가능한 도구

list_databases

MySQL 서버에서 접근 가능한 모든 데이터베이스를 나열합니다.

매개변수: 없음

예제:

{
  "server_name": "mysql",
  "tool_name": "list_databases",
  "arguments": {}
}

list_tables

지정된 데이터베이스의 모든 테이블을 나열합니다.

매개변수:

database (선택사항): 데이터베이스명 (지정하지 않으면 기본값 사용)

예제:

{
  "server_name": "mysql",
  "tool_name": "list_tables",
  "arguments": {
    "database": "my_database"
  }
}

describe_table

특정 테이블의 스키마를 보여줍니다.

매개변수:

database (선택사항): 데이터베이스명 (지정하지 않으면 기본값 사용)
table (필수): 테이블명

예제:

{
  "server_name": "mysql",
  "tool_name": "describe_table",
  "arguments": {
    "database": "my_database",
    "table": "my_table"
  }
}

execute_query

읽기 전용 SQL 쿼리를 실행합니다.

매개변수:

query (필수): SQL 쿼리 (SELECT, SHOW, DESCRIBE, EXPLAIN 문만 허용)
database (선택사항): 데이터베이스명 (지정하지 않으면 기본값 사용)

지원되는 쿼리 유형:

SELECT - 데이터 조회
SHOW - 데이터베이스/테이블 정보 표시
DESCRIBE / DESC - 테이블 구조 설명
EXPLAIN - 쿼리 실행 계획 분석

예제:

{
  "server_name": "mysql",
  "tool_name": "execute_query",
  "arguments": {
    "database": "my_database",
    "query": "SELECT * FROM my_table LIMIT 10"
  }
}

EXPLAIN 사용 예제:

{
  "server_name": "mysql",
  "tool_name": "execute_query",
  "arguments": {
    "database": "my_database",
    "query": "EXPLAIN SELECT * FROM my_table WHERE id = 1"
  }
}

explain_query

쿼리 실행 계획을 분석합니다 (MYSQL_ALLOW_EXPLAIN=true 필요).

매개변수:

query (필수): 분석할 SQL 쿼리
database (선택사항): 데이터베이스명
format (선택사항): 출력 형식 (TRADITIONAL, JSON, TREE)

예제:

{
  "server_name": "mysql",
  "tool_name": "explain_query",
  "arguments": {
    "database": "my_database",
    "query": "SELECT * FROM users WHERE id = 1",
    "format": "JSON"
  }
}

analyze_query

쿼리를 실제로 실행하면서 성능 통계를 분석합니다 (MYSQL_ALLOW_ANALYZE=true 필요).

EXPLAIN ANALYZE 구문을 사용하여 쿼리를 실제로 실행하고, 각 단계별 실행 시간과 행 수 등의 상세한 성능 정보를 제공합니다.

매개변수:

query (필수): 분석할 SQL 쿼리 (SELECT 문)
database (선택사항): 데이터베이스명

주의: 이 도구는 쿼리를 실제로 실행하므로, 대용량 데이터 조회 시 시간이 오래 걸릴 수 있습니다.

예제:

{
  "server_name": "mysql",
  "tool_name": "analyze_query",
  "arguments": {
    "database": "my_database",
    "query": "SELECT * FROM users WHERE id = 1"
  }
}

특정 테이블과 FK로 연결된 모든 연관 테이블을 depth별로 조회합니다.

매개변수:

table (필수): 연관 테이블을 찾을 기준 테이블명
database (선택사항): 데이터베이스명
depth (선택사항): 탐색할 최대 깊이 (기본값: 3, 10 초과 시 경고)

검색 방법:

FK 제약조건 기반: 실제 Foreign Key가 설정된 테이블만 조회

예제:

{
  "server_name": "mysql",
  "tool_name": "get_related_tables",
  "arguments": {
    "database": "my_database",
    "table": "user",
    "depth": 2
  }
}

응답 예시:

{
  "root_table": "user",
  "database": "my_database",
  "requested_depth": 2,
  "fk_relations_count": 55,
  "total_relations": 55,
  "circular_references_detected": false,
  "fk_relations": [
    {
      "depth": 1,
      "child_table": "user_matching_information",
      "fk_column": "user_sn",
      "parent_table": "user",
      "constraint_name": "FK_USER_MATCHING_INFORMATION_USER_SN"
    }
  ]
}

순환참조 감지 예시:

{
  "root_table": "user",
  "circular_references_detected": true,
  "circular_references": [
    {
      "path": ["user", "profile", "user"],
      "description": "user → profile → user"
    }
  ],
  "circular_reference_note": "⚠️ 순환참조가 감지되었습니다 (1개). 이미 방문한 테이블은 재탐색하지 않았습니다."
}

성능 최적화:

v0.9.4부터 전체 FK 관계를 한 번에 로드하여 메모리에서 BFS 수행
쿼리 횟수: O(n) → O(1) (n = 탐색할 테이블 수)
대규모 데이터베이스에서도 빠른 응답 보장

참고: 응답은 JSON 배열 형태로 제공됩니다. 테이블이나 CSV 형식이 필요한 경우 LLM에게 변환을 요청하세요.


**SHOW 명령어 예제**:
```json
{
  "server_name": "mysql",
  "tool_name": "execute_query",
  "arguments": {
    "database": "my_database",
    "query": "SHOW CREATE TABLE my_table"
  }
}

고급 연결 풀 설정

MySQL 연결 풀 동작을 더 세밀하게 제어하려면 추가 매개변수를 설정할 수 있습니다:

{
  "mcpServers": {
    "mysql": {
      "command": "npx",
      "args": ["@cano721/mysql-mcp-server@latest"],
      "env": {
        "MYSQL_HOST": "your-mysql-host",
        "MYSQL_PORT": "3306",
        "MYSQL_USER": "your-mysql-user",
        "MYSQL_PASSWORD": "your-mysql-password",
        "MYSQL_DATABASE": "your-default-database",
        
        "MYSQL_CONNECTION_LIMIT": "1",
        "MYSQL_QUERY_TIMEOUT": "60000",
        "MYSQL_QUEUE_LIMIT": "0",
        "MYSQL_CONNECT_TIMEOUT": "10000",
        "MYSQL_IDLE_TIMEOUT": "60000",
        "MYSQL_MAX_IDLE": "10",
        "MYSQL_ALLOW_EXPLAIN": "true",
        "MYSQL_ALLOW_ANALYZE": "true"
      },
      "disabled": false,
      "autoApprove": []
    }
  }
}

이러한 고급 옵션을 통해 다음을 제어할 수 있습니다:

MYSQL_CONNECTION_LIMIT: 풀의 최대 연결 수 제어 (기본값: 1)
MYSQL_QUEUE_LIMIT: 대기열에 넣을 최대 연결 요청 수 설정 (기본값: 0, 무제한)
MYSQL_CONNECT_TIMEOUT: 연결 타임아웃을 밀리초 단위로 조정 (기본값: 10000)
MYSQL_QUERY_TIMEOUT: 쿼리 타임아웃을 밀리초 단위로 조정 (기본값: 60000 = 60초)
MYSQL_IDLE_TIMEOUT: 연결이 해제되기 전까지 유휴 상태로 있을 수 있는 시간 (밀리초 단위)
MYSQL_MAX_IDLE: 풀에 유지할 최대 유휴 연결 수 설정
MYSQL_ALLOW_EXPLAIN: EXPLAIN 쿼리 허용 여부 (기본값: true)
MYSQL_ALLOW_ANALYZE: ANALYZE 쿼리 허용 여부 (기본값: true)

테스트

서버에는 MySQL 설정으로 기능을 확인하는 테스트 스크립트가 포함되어 있습니다:

1. 테스트 데이터베이스 설정

이 스크립트는 테스트 데이터베이스, 테이블 및 샘플 데이터를 생성합니다:

# MySQL 자격 증명을 환경 변수로 설정
export MYSQL_HOST=localhost
export MYSQL_PORT=3306
export MYSQL_USER=your_username
export MYSQL_PASSWORD=your_password

# 설정 스크립트 실행
npm run test:setup

2. MCP 도구 테스트

이 스크립트는 테스트 데이터베이스에 대해 각 MCP 도구를 테스트합니다:

# MySQL 자격 증명을 환경 변수로 설정
export MYSQL_HOST=localhost
export MYSQL_PORT=3306
export MYSQL_USER=your_username
export MYSQL_PASSWORD=your_password
export MYSQL_DATABASE=mcp_test_db

# 도구 테스트 스크립트 실행
npm run test:tools

3. 모든 테스트 실행

설정 및 도구 테스트를 모두 실행하려면:

# MySQL 자격 증명을 환경 변수로 설정
export MYSQL_HOST=localhost
export MYSQL_PORT=3306
export MYSQL_USER=your_username
export MYSQL_PASSWORD=your_password

# 모든 테스트 실행
npm test

실제 사용 예제

Kiro IDE에서 사용하기

Kiro IDE에서 이 MCP 서버를 사용하는 예제:

{
  "mcpServers": {
    "mysql": {
      "command": "npx",
      "args": ["@cano721/mysql-mcp-server@latest"],
      "env": {
        "MYSQL_HOST": "localhost",
        "MYSQL_PORT": "4307",
        "MYSQL_USER": "developer"
      },
      "disabled": false,
      "autoApprove": []
    }
  }
}

IntelliJ Copilot에서 사용하기

IntelliJ IDEA의 GitHub Copilot에서 MCP 서버를 사용하려면:

npx 사용 시:

{
  "servers": {
    "mysql": {
      "command": "npx",
      "args": ["@cano721/mysql-mcp-server@latest"],
      "env": {
        "MYSQL_HOST": "localhost",
        "MYSQL_PORT": "4307",
        "MYSQL_USER": "developer"
      },
      "disabled": false,
      "autoApprove": []
    }
  }
}

전역 설치 후 사용 시:

{
  "servers": {
    "mysql": {
      "command": "mysql-mcp-server",
      "args": [],
      "env": {
        "MYSQL_HOST": "localhost",
        "MYSQL_PORT": "4307",
        "MYSQL_USER": "developer"
      },
      "disabled": false,
      "autoApprove": []
    }
  }
}

Cursor IDE에서 사용하기

Cursor IDE에서 MCP 서버를 사용하려면 .cursor/mcp.json 파일을 생성하세요:

{
  "servers": [
    {
      "name": "mysql",
      "type": "command",
      "command": "npx",
      "arguments": ["@cano721/mysql-mcp-server@latest"],
      "environment": {
        "MYSQL_HOST": "localhost",
        "MYSQL_PORT": "4307",
        "MYSQL_USER": "developer"
      }
    }
  ]
}

테스트 결과

이 MCP 서버는 다음과 같은 실제 환경에서 테스트되었습니다:

✅ 데이터베이스 목록 조회: 38개의 데이터베이스 성공적으로 조회
✅ 테이블 목록 조회: MySQL 시스템 데이터베이스의 40개 테이블 조회
✅ 테이블 스키마 조회: user 테이블의 46개 컬럼 정보 조회
✅ SQL 쿼리 실행: 사용자 정보 조회 쿼리 성공적으로 실행
✅ EXPLAIN 쿼리: 쿼리 실행 계획 분석 지원
✅ SHOW 명령어: 데이터베이스 메타데이터 조회 지원

문제 해결

빠른 해결책:

문제가 발생하면:

서버 로그에서 오류 메시지 확인
MySQL 자격 증명 및 연결 세부 정보 확인
MySQL 사용자에게 적절한 권한이 있는지 확인
쿼리가 읽기 전용이고 올바르게 형식화되었는지 확인

일반적인 오류

연결 오류: MYSQL_HOST, MYSQL_PORT, MYSQL_USER 환경 변수 확인
권한 오류: MySQL 사용자에게 데이터베이스 접근 권한이 있는지 확인
쿼리 오류: SELECT, SHOW, DESCRIBE, EXPLAIN 문만 사용 가능

npx 관련 문제

0. Node.js 버전 확인 (가장 중요!)

# Node.js 버전 확인 (18.0.0 이상 필요)
node --version

# npm 버전 확인
npm --version

Node.js 18 미만이면 다음 오류가 발생할 수 있습니다:

ES modules 지원 문제
최신 JavaScript 기능 미지원
의존성 패키지 호환성 문제

Node.js 업데이트 방법:

방법 1: 공식 웹사이트에서 다운로드 (권장)

https://nodejs.org/ 방문
LTS 버전 (Long Term Support) 다운로드
설치 프로그램 실행
터미널 재시작 후 버전 확인: node --version

방법 2: nvm 사용 (개발자 권장)

# nvm 설치 (macOS/Linux)
curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.0/install.sh | bash

# 터미널 재시작 후
nvm install --lts        # 최신 LTS 버전 설치
nvm use --lts           # LTS 버전 사용
nvm alias default lts/* # 기본값으로 설정

방법 3: Homebrew 사용 (macOS)

# Homebrew로 Node.js 업데이트
brew install node

# 또는 기존 설치가 있다면
brew upgrade node

방법 4: 패키지 매니저 사용 (Linux)

# Ubuntu/Debian
curl -fsSL https://deb.nodesource.com/setup_lts.x | sudo -E bash -
sudo apt-get install -y nodejs

# CentOS/RHEL/Fedora
curl -fsSL https://rpm.nodesource.com/setup_lts.x | sudo bash -
sudo yum install -y nodejs

방법 5: Windows

https://nodejs.org/ 에서 Windows Installer 다운로드
또는 Chocolatey 사용: choco install nodejs
또는 Scoop 사용: scoop install nodejs

Node.js 업데이트 후 설정:

# 1. 터미널/명령 프롬프트 재시작 (중요!)

# 2. 버전 확인
node --version  # v18.0.0 이상인지 확인
npm --version   # 8.0.0 이상인지 확인

# 3. npm 캐시 클리어 (권장)
npm cache clean --force

# 4. MCP 서버 테스트
npx @cano721/mysql-mcp-server@latest

# 5. 환경 변수 설정 후 테스트
export MYSQL_HOST=localhost
export MYSQL_PORT=4307
export MYSQL_USER=developer
echo '{"jsonrpc":"2.0","id":1,"method":"tools/list"}' | npx @cano721/mysql-mcp-server

주의사항:

Node.js 업데이트 후 반드시 터미널을 재시작하세요
IDE(IntelliJ, VSCode 등)도 재시작해야 새 Node.js 버전을 인식합니다
기존에 전역 설치한 패키지들은 재설치가 필요할 수 있습니다

1. npx 캐시 문제

# 최신 버전 강제 사용
npx --yes @cano721/mysql-mcp-server@latest

# npm 캐시 클리어
npm cache clean --force

2. 환경 변수 전달 문제

MCP 설정에서 환경 변수가 제대로 설정되었는지 확인:

{
  "mcpServers": {
    "mysql": {
      "command": "npx",
      "args": ["@cano721/mysql-mcp-server@latest"],
      "env": {
        "MYSQL_HOST": "localhost",
        "MYSQL_PORT": "4307",
        "MYSQL_USER": "developer"
      }
    }
  }
}

3. Node.js PATH 문제

# Node.js 경로 확인
which node
which npx

# PATH에 Node.js 추가 (필요시)
export PATH="/path/to/node/bin:$PATH"

4. 대안: 전역 설치 사용

npx가 계속 문제가 되면 전역 설치 후 직접 실행:

npm install -g @cano721/mysql-mcp-server

그 후 MCP 설정에서:

{
  "mcpServers": {
    "mysql": {
      "command": "mysql-mcp-server",
      "args": [],
      "env": {
        "MYSQL_HOST": "localhost",
        "MYSQL_PORT": "4307",
        "MYSQL_USER": "developer"
      }
    }
  }
}

5. 연결 테스트

터미널에서 직접 테스트:

# 환경 변수 설정 후 테스트
export MYSQL_HOST=localhost
export MYSQL_PORT=4307
export MYSQL_USER=developer

# MCP 서버 테스트
echo '{"jsonrpc":"2.0","id":1,"method":"tools/list"}' | npx @cano721/mysql-mcp-server

변경 이력

전체 변경 이력은 CHANGELOG.md를 참조하세요.

최근 버전

버전	날짜	주요 변경 사항
0.10.0	2025-01-09	`get_related_tables` 패턴 매칭 제거, FK 제약조건만 사용
0.9.5	2025-01-09	쿼리 타임아웃 설정 가능 (`MYSQL_QUERY_TIMEOUT`, 기본값 60초)
0.9.4	2025-01-09	`get_related_tables` 성능 최적화 (O(n) → O(1) 쿼리, 타임아웃 해결)
0.9.3	2025-01-09	모든 도구 description에 한글 키워드 추가 (한글 질문 인식 개선)
0.9.2	2025-01-09	`get_related_tables` 응답에서 `constraint_name` 필드 제거
0.9.1	2025-01-09	`get_related_tables` 응답 크기 최적화 (포맷 변환은 LLM이 수행)
0.9.0	2025-01-09	`get_related_tables` 응답 구조 개선 및 최적화
0.8.0	2025-01-09	`get_related_tables`에 패턴 매칭 옵션 추가, depth 제한 제거
0.7.0	2025-01-09	`get_related_tables` 도구 추가 (FK 기반 연관 테이블 depth별 조회)
0.6.0	2025-01-09	`analyze_table` → `analyze_query`로 변경, `@latest` 태그 문서 추가
0.5.0	2025-01-09	`explain_query`, `analyze_table` 전용 도구 추가
0.4.0	2025-01-09	EXPLAIN/ANALYZE 지원, 연결 풀 기본값 1로 변경
0.3.0	2025-01-09	Node.js 18+ 요구사항, 문제 해결 가이드 추가
0.2.0	2025-01-09	IntelliJ, Cursor, Kiro IDE 설정 예제 추가
0.1.0	2025-01-09	초기 릴리스

라이선스

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

기여

기여를 환영합니다! 이슈를 제출하거나 풀 리퀘스트를 보내주세요.

지원

문제가 있거나 질문이 있으시면 GitHub Issues에서 이슈를 생성해주세요.

Available Tools

7 tools

analyze_queryB

Analyze query performance and statistics using ANALYZE. 한글: 쿼리 성능 분석, 쿼리 통계, ANALYZE

ParametersJSON Schema

Name	Required	Description	Default
`query`	Yes	SQL query to analyze (SELECT, UPDATE, DELETE, INSERT, REPLACE statements)
`database`	No	Database name (optional, uses default if not specified)

TDQS

B3.1/5.0

Behavior2/5

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

No annotations are provided, so the description carries full burden. It only states it uses ANALYZE but does not disclose whether the command modifies data, requires permissions, or is read-only. For a tool that updates table statistics, this omission is significant.

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

Conciseness4/5

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

The description is short and to the point, but includes redundant Korean text that does not add value for an English-speaking agent. Still, it is appropriately sized and front-loaded with the core purpose.

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

Completeness2/5

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

For a tool with no output schema and limited parameters, the description should explain what ANALYZE does, its side effects, and how it differs from explain_query. It only provides minimal context, leaving gaps in understanding.

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

Parameters3/5

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

Schema description coverage is 100%, so baseline is 3. The description adds no additional meaning beyond what the schema already provides for the two parameters.

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

Purpose5/5

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

The description clearly states the tool analyzes query performance and statistics using ANALYZE, with a specific verb ('Analyze') and resource ('query performance and statistics'). It distinguishes from siblings like execute_query and explain_query by mentioning ANALYZE explicitly.

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

Usage Guidelines2/5

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

No guidance on when to use this tool versus alternatives like explain_query. The description does not provide context about when ANALYZE is appropriate or when not to use it, leaving the agent without decision support.

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

describe_tableB

Show the schema for a specific table. 한글: 테이블 스키마, 테이블 구조, 컬럼 정보, 테이블 설명

ParametersJSON Schema

Name	Required	Description	Default
`database`	No	Database name (optional, uses default if not specified)
`table`	Yes	Table name

TDQS

B3.1/5.0

Behavior2/5

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

With no annotations, the description should disclose behavioral traits. It only says 'show the schema' without detailing what that includes (e.g., columns, types) or side effects. It does not state it is read-only.

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

Conciseness4/5

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

The description is concise with two sentences. The Korean text may be unnecessary for most agents but does not detract. The main action is front-loaded.

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

Completeness2/5

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

Given the absence of an output schema, the description should clarify what the schema output includes. It does not. With sibling tools that may also describe tables, this leads to ambiguity.

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

Parameters3/5

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

Schema description coverage is 100%, so baseline is 3. The description adds no extra meaning beyond the schema, but the schema already describes 'database' and 'table' adequately.

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

Purpose5/5

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

The description clearly states the tool shows the schema for a specific table. This distinguishes it from siblings like execute_query, list_tables, etc., which focus on different operations.

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

Usage Guidelines2/5

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

No guidance on when to use this tool versus alternatives like get_related_tables or list_tables. No mention of prerequisites or context.

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

execute_queryA

Execute a read-only SQL query. 한글: 쿼리 실행, SQL 실행, 조회 쿼리

ParametersJSON Schema

Name	Required	Description	Default
`query`	Yes	SQL query (only SELECT, SHOW, DESCRIBE, EXPLAIN, ANALYZE statements are allowed)
`database`	No	Database name (optional, uses default if not specified)

TDQS

A3.5/5.0

Behavior3/5

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

No annotations provided, so description bears full burden. It discloses read-only nature and allowed SQL statement types (SELECT, SHOW, etc.), but does not describe return format, error behavior, or any other side effects. Lacks details beyond the schema.

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

Conciseness3/5

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

The description is brief (one English sentence plus Korean translations). The Korean is extraneous for an English-context AI, making it slightly less concise. However, the core message is front-loaded and no unnecessary elaboration exists beyond the translation.

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

Completeness3/5

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

Given two parameters, no output schema, and sibling tools, the description is adequate but incomplete. It fails to explain the result format or behavior, leaving the agent to infer from the SQL nature. The schema covers statement restrictions, but overall completeness is average for a simple tool.

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

Parameters3/5

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

Schema coverage is 100% with both parameters well-described in the schema. The description adds minimal additional meaning beyond stating 'read-only' and providing Korean translations, which do not enhance semantic understanding for an English-speaking AI.

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

Purpose5/5

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

The description clearly states it executes a read-only SQL query, with specific verb 'Execute' and resource 'SQL query'. The read-only constraint and the list of allowed statements in the schema help distinguish it from siblings like analyze_query or explain_query.

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

Usage Guidelines3/5

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

No explicit guidance on when to use this tool vs. alternatives. The description does not mention when not to use it or suggest sibling tools. Usage is implied by the name and schema but not clearly articulated.

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

explain_queryB

Analyze query execution plan using EXPLAIN. 한글: 쿼리 실행 계획, 쿼리 분석, EXPLAIN

ParametersJSON Schema

Name	Required	Description
`query`	Yes	SQL query to analyze (SELECT, UPDATE, DELETE, INSERT, REPLACE statements)
`database`	No	Database name (optional, uses default if not specified)
`format`	No	Output format: TRADITIONAL, JSON, or TREE (optional, default: TRADITIONAL)

TDQS

B3.4/5.0

Behavior3/5

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

No annotations provided, so description carries full burden. It implies read-only behavior by mentioning EXPLAIN, but lacks details on side effects, prerequisites, or performance considerations.

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

Conciseness4/5

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

Extremely concise at two sentences, but the second sentence is a Korean translation, which adds minimal value for English agents. Still efficient.

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

Completeness3/5

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

No output schema, and description does not explain what the tool returns (e.g., execution plan format). Could be more complete given the lack of output schema.

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

Parameters3/5

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

Schema description coverage is 100%, so description adds no parameter meaning beyond what's in the schema. Baseline score of 3 applies.

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

Purpose5/5

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

The description clearly states the tool analyzes query execution plans using EXPLAIN, specifying both the verb and resource. It distinguishes from siblings like execute_query by mentioning EXPLAIN.

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

Usage Guidelines2/5

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

No guidance on when to use this tool versus alternatives like analyze_query or execute_query. The description lacks context for when to prefer this tool.

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

get_related_tablesA

Find all related/connected/associated tables linked to a specific table through foreign keys. Discovers table relationships and dependencies with depth traversal. Use this when asked to find related tables, connected tables, associated tables, or table relationships. 한글: 연관 테이블, 관련 테이블, 연결된 테이블, 테이블 관계, 참조 테이블, FK 관계

ParametersJSON Schema

Name	Required	Description
`table`	Yes	Table name to find related tables for
`database`	No	Database name (optional, uses default if not specified)
`depth`	No	Maximum depth to traverse relationships (default: 3, warning if > 10)

TDQS

A3.8/5.0

Behavior3/5

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

No annotations are provided, so the description must cover behavioral traits. It mentions depth traversal and warns about depth >10, but does not clarify if relationships are direct only or transitive, or any side effects. It is adequate but not comprehensive.

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

Conciseness4/5

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

The description is concise with two main sentences plus a keyword list. The Korean translation adds some length but is not strictly necessary. It could be slightly more streamlined, but overall efficient.

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

Completeness3/5

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

Given no output schema, the description should clarify the return format (e.g., list of table names). It does not describe what the tool returns. Parameters are well-documented, but output info is missing, making it incomplete for an agent.

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

Parameters3/5

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

Schema coverage is 100%, so baseline is 3. The description adds minor value by explaining optional database default and depth warning, but these are already in the schema. No additional meaning beyond schema.

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

Purpose5/5

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

The description uses a clear verb 'Find' and specifies the resource 'all related/connected/associated tables linked to a specific table through foreign keys.' It distinguishes from siblings like 'list_tables' by focusing on relationships and depth traversal.

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

Usage Guidelines4/5

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

The description explicitly states when to use the tool: 'Use this when asked to find related tables, connected tables, associated tables, or table relationships.' It also provides Korean keywords. It does not specify when not to use or alternatives, but the context is clear given sibling tools.

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

list_databasesB

List all accessible databases on the MySQL server. 한글: 데이터베이스 목록, DB 목록, 데이터베이스 조회

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

B3.2/5.0

Behavior2/5

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

No annotations are present, so the description must fully disclose behavior. It only states that it lists accessible databases but does not mention authentication requirements, performance implications, or result format. This is insufficient for a tool with no other behavioral indicators.

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

Conciseness4/5

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

The description is very concise, with one clear sentence and Korean translations that add no confusion. It is front-loaded with the main purpose, but the translations slightly reduce conciseness for English-only agents.

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

Completeness3/5

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

Given zero parameters and no output schema, the description covers the basic functionality. However, it does not explain what the output contains (e.g., database names only or additional details), leaving some ambiguity for the agent.

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

Parameters3/5

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

The input schema has no parameters (100% coverage), so the baseline is 3. The description adds minimal context ('MySQL server', 'accessible') but does not provide additional semantics beyond the schema.

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

Purpose5/5

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

The description clearly states the tool's function with a specific verb ('List') and resource ('all accessible databases on the MySQL server'). It is distinct from sibling tools like 'list_tables' which operate on tables.

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

Usage Guidelines2/5

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

No guidance is provided on when to use this tool versus alternatives (e.g., 'list_tables', 'describe_table'). The description lacks context about prerequisites or typical use cases.

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

list_tablesA

List all tables in a specified database. 한글: 테이블 목록, 테이블 조회, 테이블 리스트

ParametersJSON Schema

Name	Required	Description	Default
`database`	No	Database name (optional, uses default if not specified)

TDQS

A3.6/5.0

Behavior3/5

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

With no annotations, the description carries full burden but only states the basic function; it omits details like return format or side effects.

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

Conciseness5/5

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

The description is extremely concise with one English sentence, though the Korean text is redundant but does not detract.

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

Completeness4/5

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

Given the simple nature (one optional param, no complex output), the description is mostly adequate, though it could mention return structure for completeness.

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

Parameters3/5

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

The description adds no new meaning beyond the input schema, which already describes the optional 'database' parameter.

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

Purpose5/5

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

The description clearly states 'List all tables in a specified database' with a specific verb and resource, differentiating it from siblings like 'analyze_query' and 'execute_query'.

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

Usage Guidelines2/5

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

No guidance on when to use this tool versus alternatives, such as 'describe_table' or 'list_databases', is provided.

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

Install Server

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

TDQS

A3.8/5.0

Disambiguation5/5

Each tool has a distinct purpose: listing databases, listing tables, describing table schemas, executing read-only queries, analyzing performance, explaining execution plans, and discovering table relationships. No overlap between tools.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern in snake_case (e.g., list_databases, describe_table, execute_query), making it predictable and easy for an agent to infer functionality.

Tool Count5/5

With 7 tools, the server covers the essential operations for a MySQL read-only analysis server: exploration (databases, tables, schema), query execution, performance analysis (EXPLAIN, ANALYZE), and relationship discovery. The count is well-scoped.

Completeness5/5

The tool set provides full lifecycle coverage for read-only database analysis: listing, describing, querying, analyzing, and relating. There are no obvious gaps for the intended purpose.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

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

Related MCP Connectors

QueryBear
io.github.spencerpauly
Safe, read-only Postgres and MySQL access for AI agents. Audit log + column-level controls.
Databases RAG Systems
2
data
co.thinair
Read-only PostgreSQL, MySQL, SQL Server access via MCP — 24 dialect-aware hosted tools.
Databases Developer Tools
2
mcpmyadmin
ai.mcpmyadmin
Query 40 databases from Claude, ChatGPT, or Cursor — on any device. Read-only, encrypted, audited.
Databases Security
2
codemouse
io.github.squidcode
Read-only access to your CodeMouse accounts, repositories, and AI pull-request reviews.
Version Control Code Analysis AI & Machine Learning
2

Related MCP Servers

MariaDB MCP Server
Databases Developer Tools
bretoreta
A
license
B
quality
D
maintenance
Provides secure, read-only access to MariaDB/MySQL databases, allowing users to list databases, explore table schemas, and execute SQL queries with built-in security measures.
Updated a year ago (2025-07-24 09:30 UTC)
4
72
4
MIT
MySQL MCP Server
Databases Search
guido-marinho
A
license
Not graded
quality
D
maintenance
Enables read-only access to MySQL databases through natural language queries. Provides automatic table schema discovery and executes SELECT, SHOW, DESCRIBE, and EXPLAIN statements within secure read-only transactions.
Updated 10 months ago (2025-10-27 03:39 UTC)
MIT
MySQL MCP Server
Databases Developer Tools
jeweis
F
license
Not graded
quality
D
maintenance
Enables safe interaction with MySQL databases through SELECT queries, table structure inspection, and database schema exploration. Provides read-only access to query data and examine database metadata.
Updated a year ago (2025-07-05 08:44 UTC)
1
MCP MySQL Server
Databases Developer Tools
jianglisuda
A
license
A
quality
D
maintenance
Enables read-only MySQL database connectivity, allowing execution of SELECT queries, listing tables, and describing table structures via natural language.
Updated 3 months ago (2026-05-26 01:19 UTC)
3
23
MIT

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/cano721/mysql-mcp-server'

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