de en es ja ko ru zh

GoSQLX

Name: GoSQLX
Author: ajitpratap0

by ajitpratap0

Overview Schema Related Servers Score Discussions

Remote

GoSQLX

Go의 속도로 SQL을 파싱하세요

Glama MCP Server

Tests Go Report GoDoc Stars OpenSSF Scorecard

🌐 플레이그라운드 체험하기 · 📖 문서 읽기 · 🚀 시작하기 · 📊 벤치마크

초당 138만 건 이상의 작업

<1μs 지연 시간

85% SQL-99

8개 방언 지원

0 레이스 컨디션

GoSQLX란 무엇인가요?

GoSQLX는 Go를 위한 프로덕션급 SQL 파싱 SDK입니다. 제로 카피 최적화와 지능형 객체 풀링을 통해 SQL을 토큰화, 파싱하고 AST를 생성하며, 마이크로초 미만의 지연 시간으로 초당 138만 건 이상의 작업을 처리합니다.

ast, _ := gosqlx.Parse("SELECT u.name, COUNT(*) FROM users u JOIN orders o ON u.id = o.user_id GROUP BY u.name")
// → Full AST with statements, columns, joins, grouping - ready for analysis, transformation, or formatting

왜 GoSQLX인가요?

ORM이 아닙니다 - 파서입니다. AST를 얻고, 그것으로 무엇을 할지 결정할 수 있습니다.
느리지 않습니다 - 제로 카피 토큰화, sync.Pool 재사용, 핫 패스(hot path)에서의 할당 없음.
제한이 없습니다 - PostgreSQL, MySQL, MariaDB, SQL Server, Oracle, SQLite, Snowflake, ClickHouse를 지원합니다. CTE, 윈도우 함수, MERGE, 집합 연산 등을 지원합니다.
단순한 라이브러리가 아닙니다 - CLI, VS Code 확장 프로그램, GitHub Action, MCP 서버, WASM 플레이그라운드, Python 바인딩을 제공합니다.

Related MCP server: mcp-server-duckdb

60초 만에 시작하기

go get github.com/ajitpratap0/GoSQLX

package main

import (
    "fmt"
    "github.com/ajitpratap0/GoSQLX/pkg/gosqlx"
)

func main() {
    // Parse any SQL dialect
    ast, _ := gosqlx.Parse("SELECT * FROM users WHERE active = true")
    fmt.Printf("%d statement(s)\n", len(ast.Statements))

    // Format messy SQL
    clean, _ := gosqlx.Format("select id,name from users where id=1", gosqlx.DefaultFormatOptions())
    fmt.Println(clean)
    // SELECT
    //   id,
    //   name
    // FROM users
    // WHERE id = 1

    // Catch errors before production
    if err := gosqlx.Validate("SELECT * FROM"); err != nil {
        fmt.Println(err) // → expected table name
    }
}

어디서나 설치 가능

📦 Go 라이브러리

go get github.com/ajitpratap0/GoSQLX

🖥️ CLI 도구

go install github.com/ajitpratap0/GoSQLX/cmd/gosqlx@latest
gosqlx validate "SELECT * FROM users"
gosqlx format query.sql
gosqlx lint query.sql

💻 VS Code 확장 프로그램

code --install-extension ajitpratap0.gosqlx

바이너리가 포함되어 있어 별도의 설정이 필요 없습니다. 더 알아보기 →

🤖 MCP 서버 (AI 통합)

claude mcp add --transport http gosqlx \
  https://mcp.gosqlx.dev/mcp

Claude, Cursor 또는 모든 MCP 클라이언트에서 7개의 SQL 도구를 사용할 수 있습니다. 가이드 →

주요 기능 요약

문서

	리소스	설명
🌐	gosqlx.dev	대화형 플레이그라운드가 있는 웹사이트
🚀	시작하기	5분 만에 첫 SQL 파싱하기
📖	사용 가이드	포괄적인 패턴 및 예제
📄	API 참조	전체 API 문서
🖥️	CLI 가이드	명령줄 도구 참조
🌍	SQL 호환성	방언 지원 매트릭스
🤖	MCP 가이드	AI 어시스턴트 통합
🏗️	아키텍처	시스템 설계 심층 분석
📊	벤치마크	성능 데이터 및 방법론
📝	릴리스 노트	버전별 변경 사항

기여하기

GoSQLX는 여러분과 같은 기여자들에 의해 만들어집니다. 버그 수정, 새로운 기능, 문서 개선, 오타 수정 등 모든 기여가 소중합니다.

git clone https://github.com/ajitpratap0/GoSQLX.git && cd GoSQLX
task check    # fmt → vet → lint → test (with race detection)

main 브랜치에서 포크 및 브랜치 생성
테스트 작성 - TDD를 사용하며 레이스 프리 코드를 요구합니다
task check 실행 - PR 전에 통과해야 합니다
PR 열기 - 24시간 이내에 검토합니다

📋 기여 가이드 · 📜 행동 강령 · 🏛️ 거버넌스

누가 GoSQLX를 사용하나요?

GoSQLX는 전 세계 개발자들에 의해 다운로드 및 클론되고 있습니다. 단 14일 만에 595명의 고유 사용자가 클론했습니다. 귀하의 프로젝트나 조직에서 GoSQLX를 사용 중이라면, 알려주세요!

프로젝트 / 회사	사용 사례
귀하의 프로젝트	PR을 통해 추가하거나 토론에서 알려주세요

업무에서 GoSQLX를 사용하시나요? 멋진 것을 만들고 계신가요? GitHub 토론에서 이야기를 공유해 주세요. 커뮤니티 성장에 도움이 되며 지속적인 개발의 동기가 됩니다.

커뮤니티

질문이 있으신가요? 아이디어가 있으신가요? 버그를 발견하셨나요?

라이선스

Apache License 2.0 - 자세한 내용은 LICENSE를 참조하세요.

GoSQLX 커뮤니티가 ❤️를 담아 제작함

gosqlx.dev · 플레이그라운드 · 문서 · MCP 서버 · VS Code

GoSQLX가 프로젝트에 도움이 되었다면 ⭐를 눌러주세요

Available Tools

7 tools

analyze_sqlA

Read-onlyIdempotent

Run all 6 analysis tools concurrently and return a composite report (validate, parse, metadata, security, lint, format).

ParametersJSON Schema

Name	Required	Description	Default
`sql`	Yes	The SQL string to analyze

TDQS

A4.2/5.0

Behavior4/5

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

Beyond annotations (readOnly, idempotent), the description adds that it runs six tools concurrently and returns a composite report, though it doesn't detail error handling or report structure.

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

Conciseness5/5

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

A single, well-structured sentence that conveys the essential purpose and behavior without redundancy.

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?

The description adequately covers the tool's purpose and behavior given the simple parameter set and safety annotations, but lacks details about the composite report format.

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% and the description adds no additional meaning to the 'sql' parameter beyond the schema's description.

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

Purpose5/5

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

The description clearly states the verb 'run' and the resource 'all 6 analysis tools concurrently', distinguishing itself from sibling tools that perform individual analyses.

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?

Describes when to use (concurrent analysis), but does not explicitly state when not to use or name alternatives; however, sibling tool list provides implicit guidance.

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

extract_metadataA

Read-onlyIdempotent

Extract tables, columns, and functions referenced in SQL.

ParametersJSON Schema

Name	Required	Description	Default
`sql`	Yes	The SQL string to analyze

TDQS

A3.6/5.0

Behavior3/5

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

Annotations already declare the tool as read-only and idempotent. The description adds that it extracts specific SQL elements but does not detail error handling or output behavior, adding modest value beyond annotations.

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

Conciseness5/5

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

The description is a single, front-loaded sentence with no superfluous words, effectively conveying the core functionality.

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 lack of an output schema, the description hints at what is returned (tables, columns, functions), which is sufficient for a focused extraction tool, though more detail on output structure would improve 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?

With 100% schema coverage, the description adds some meaning by listing extracted items but no additional detail on parameter formatting or constraints 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 that the tool extracts tables, columns, and functions from SQL, which is specific and distinct from sibling tools like format_sql or security_scan.

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

Usage Guidelines2/5

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

No guidance is provided on when to use this tool versus alternatives such as parse_sql or analyze_sql, leaving the agent to infer context.

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

format_sqlA

Read-onlyIdempotent

Format SQL with configurable indentation and keyword casing.

ParametersJSON Schema

Name	Required	Description
`add_semicolon`	No	Append a trailing semicolon (default: false)
`indent_size`	No	Spaces per indent level (default: 2)
`sql`	Yes	The SQL string to format
`uppercase_keywords`	No	Uppercase SQL keywords (default: false)

TDQS

A3.8/5.0

Behavior3/5

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

Annotations already declare the tool as read-only (readOnlyHint=true), non-destructive, and idempotent. The description adds no further behavioral details beyond what parameters suggest. No contradiction, but also no extra context.

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

Conciseness5/5

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

A single, front-loaded sentence that efficiently conveys the tool's purpose. No extraneous words.

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?

The description, together with the schema and annotations, covers most aspects. However, since there is no output schema, it would be helpful to mention that the tool returns the formatted SQL string. Minor gap.

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

Parameters3/5

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

Input schema has 100% description coverage for all 4 parameters. The description merely summarizes the parameters without adding new meaning beyond what the schema already provides.

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

Purpose5/5

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

The description clearly states 'Format SQL with configurable indentation and keyword casing,' using a specific verb and resource. This distinguishes it from sibling tools like analyze_sql, lint_sql, and parse_sql.

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

Usage Guidelines3/5

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

The description implies usage for formatting SQL but does not explicitly state when to use this tool versus alternatives, nor does it mention any when-not-to-use scenarios. Usage is clear from context but lacks explicit guidance.

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

lint_sqlA

Read-onlyIdempotent

Lint SQL against all 10 GoSQLX style rules (L001–L010).

ParametersJSON Schema

Name	Required	Description	Default
`sql`	Yes	The SQL string to lint

TDQS

A3.7/5.0

Behavior3/5

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

Annotations (readOnlyHint, destructiveHint, idempotentHint) already declare safe, read-only, idempotent behavior. The description adds the specific rule coverage but no additional behavioral traits like output format or side effects, providing limited extra transparency.

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

Conciseness5/5

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

A single, front-loaded sentence that efficiently conveys the tool's purpose without any redundant information. Every word earns its place.

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

Completeness3/5

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

With no output schema, the description lacks details about the return format (e.g., list of issues, pass/fail). Given the tool's simplicity, this is a notable gap, but annotations partially compensate.

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 a clear description for the single 'sql' parameter. The description does not add further meaning beyond what the schema already provides, so a baseline of 3 is appropriate.

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

Purpose5/5

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

The description clearly states 'Lint SQL against all 10 GoSQLX style rules (L001–L010).' It specifies the exact verb (lint), resource (SQL), and rule set, distinguishing it from siblings like format_sql or security_scan.

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?

Usage is implied through the rule set (GoSQLX), but no explicit when-to-use, when-not-to-use, or alternative tools are mentioned. The description lacks guidance on choosing this over siblings like analyze_sql or validate_sql.

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

parse_sqlA

Read-onlyIdempotent

Parse SQL and return an AST summary: statement count and types.

ParametersJSON Schema

Name	Required	Description	Default
`sql`	Yes	The SQL string to parse

TDQS

A4.1/5.0

Behavior4/5

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

Annotations already confirm read-only, non-destructive, idempotent. Description adds that output is an AST summary with count and types, which goes beyond annotations.

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?

Single sentence, no redundancy, all information is useful.

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

Completeness5/5

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

Given simple tool and good annotations, description provides all needed context: input (SQL string) and output (AST summary). No output schema needed as description covers return value.

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?

Single parameter 'sql' has description in schema. Description does not add additional meaning beyond the schema's description.

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?

Clearly states verb 'Parse' and resource 'SQL', specifying output as 'AST summary: statement count and types'. Distinguishes from siblings like analyze_sql which likely does deeper analysis.

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 when-to-use or when-not-to-use guidance. Implies use for quick overview, but doesn't mention alternatives like analyze_sql for detailed analysis.

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

security_scanA

Read-onlyIdempotent

Scan SQL for injection patterns: tautologies, UNION attacks, stacked queries, comment bypasses, and more.

ParametersJSON Schema

Name	Required	Description	Default
`sql`	Yes	The SQL string to scan

TDQS

A3.6/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=true and idempotentHint=true, so the description adds only that it detects injection patterns. No additional behavioral details (e.g., output format, blocking behavior) are provided, but annotations carry the safety burden.

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?

Single sentence with no wasted words. Essential information is front-loaded and clear.

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 interface (1 required param, no output schema) and annotations covering safety, the description adequately explains the tool's purpose. However, it could mention the return format or highlight that it is a security-focused analysis.

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 100% coverage (the `sql` parameter has a description), so the description adds no extra meaning beyond listing patterns the scan looks for. Baseline 3 is appropriate.

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

Purpose5/5

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

The description clearly specifies the action (scan) and resource (SQL) and lists specific injection patterns (tautologies, UNION attacks, etc.), making it distinct from sibling tools like analyze_sql or lint_sql.

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 validate_sql or parse_sql. The description implies use for security scanning but does not state exclusions or prerequisites.

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

validate_sqlA

Read-onlyIdempotent

Validate SQL syntax. Returns {valid: bool, error?: string, dialect?: string}.

ParametersJSON Schema

Name	Required	Description	Default
`dialect`	No	SQL dialect: generic, mysql, postgresql, sqlite, sqlserver, oracle, snowflake
`sql`	Yes	The SQL string to validate

TDQS

A3.6/5.0

Behavior3/5

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

Annotations already indicate this is a safe, idempotent read operation (readOnlyHint=true, destructiveHint=false, idempotentHint=true). The description adds the return value shape ({valid, error, dialect}) but does not disclose edge-case behaviors (e.g., handling of invalid dialect). This is adequate but not exceptional.

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

Conciseness5/5

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

The description is a single sentence with the return type, perfectly concise and front-loaded. No unnecessary words.

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 tool's simplicity, two well-documented parameters, and no output schema, the description is largely complete. It reveals the return shape, which compensates for the missing output schema. However, it omits any mention of error handling or usage context (e.g., 'use for quick syntax checks before execution').

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%: both 'sql' and 'dialect' have descriptions and the latter has an enum. The description does not add any additional semantic meaning beyond what the schema provides, so baseline 3 is appropriate.

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

Purpose5/5

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

The description concisely states 'Validate SQL syntax', which clearly identifies the verb and resource. It distinguishes this tool from siblings like lint_sql (style checking) and parse_sql (parsing into AST).

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 explicit guidance is given on when to use this tool versus alternatives (e.g., analyze_sql for deeper analysis, format_sql for formatting). The description only states what it does, not when it is appropriate.

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.

7 tool updatesv1.12.1Mar 17, 2026
- First observedanalyze_sql
- First observedextract_metadata
- First observedformat_sql
- First observedlint_sql
- First observedparse_sql
- First observedsecurity_scan
- First observedvalidate_sql

Install Server

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

TDQS

A4.1/5.0

Disambiguation5/5

Each tool targets a distinct SQL analysis function: syntax validation, AST parsing, metadata extraction, security scanning, linting, formatting, and a composite report. No overlaps exist.

Naming Consistency5/5

All tools follow a clear verb_noun pattern (e.g., validate_sql, format_sql). The one exception (extract_metadata) still uses a verb and clearly refers to SQL metadata, maintaining consistency.

Tool Count5/5

7 tools is well-scoped for SQL analysis, covering the core tasks without being too many or too few. Each tool has a clear purpose.

Completeness5/5

The tool set covers the full lifecycle of SQL analysis: validation, parsing, metadata extraction, security, linting, and formatting. The aggregate tool enhances usability. No obvious gaps for the intended domain.

Maintenance

ActivitySlowing

ResponsivenessWithin a week

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

sixta-connect AOAuth
ai.sixta
DBRE-grade SQL analysis inside any MCP client. No connection. No install. Paste a query.
Databases Code Analysis
2
dataOAuth
co.thinair
Read-only PostgreSQL, MySQL, SQL Server access via MCP — 24 dialect-aware hosted tools.
Databases Developer Tools
2
Frogeye Security Scanner A
io.github.frogeye-ai
Zero-config MCP security scanner for AI-generated apps. 25K+ vulnerability patterns.
Security Penetration Testing
2
Veto — SQL Safety & Cost Oracle A
com.vetosql
Deterministic safety, correctness & cost gate that vets Postgres SQL before your AI agent runs it.
Databases Security Autonomous Agents
32

Related MCP Servers

MySQL MCP Server
Databases Developer Tools
designcomputer
A
license
A
quality
A
maintenance
Allows AI assistants to list tables, read data, and execute SQL queries through a controlled interface, making database exploration and analysis safer and more structured.
Updated a month ago (2026-08-02 13:36 UTC)
3
1,374
MIT
mcp-server-duckdb
Databases Developer Tools
ktanaka101
A
license
Not graded
quality
D
maintenance
A Model Context Protocol (MCP) server implementation for DuckDB, providing database interaction capabilities through MCP tools. It would be interesting to have LLM analyze it. DuckDB is suitable for local analysis.
Updated a year ago (2025-05-05 11:02 UTC)
178
MIT
mcp-clickhouseofficial
Databases Developer Tools
ClickHouse
A
license
A
quality
A
maintenance
ClickHouse database integration with schema inspection and query capabilities
Updated 2 days ago (2026-09-04 18:45 UTC)
3
866
Apache 2.0
mysql_mcp_server
Databases Developer Tools
wenb1n-dev
A
license
B
quality
F
maintenance
Added support for STDIO mode and SSE mode Added support for multiple SQL execution, separated by ";" Added ability to query database table names and fields based on table comments Added SQL Execution Plan Analysis Added Chinese field to pinyin conversion
Updated a year ago (2025-08-28 13:50 UTC)
5
248
MIT

Appeared in Searches

A search for a string containing SQL injection and XSS payload characters

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/ajitpratap0/GoSQLX'

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

GoSQLX

Go의 속도로 SQL을 파싱하세요

GoSQLX란 무엇인가요?

왜 GoSQLX인가요?

60초 만에 시작하기

어디서나 설치 가능

📦 Go 라이브러리

🖥️ CLI 도구

💻 VS Code 확장 프로그램

🤖 MCP 서버 (AI 통합)

주요 기능 요약

문서

기여하기

누가 GoSQLX를 사용하나요?

커뮤니티

라이선스

Available Tools

Tool Schema Changelog

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

mcp-clickhouseofficial

Appeared in Searches

Latest Blog Posts

MCP directory API