Skip to main content
Glama
AimanFadillah

mcp-database

by AimanFadillah
OverviewSchemaRelated ServersScoreDiscussions
TypeScript
Remote

mcp-database

MCP server read-only untuk MySQL / MariaDB. Memungkinkan Claude melakukan pengecekan data lewat query SQL — tanpa bisa mengubah/menghapus data.

Tools yang disediakan

Tool

Fungsi

list_tables

Menampilkan daftar semua tabel di database

describe_table

Menampilkan struktur kolom sebuah tabel

run_query

Menjalankan SELECT/SHOW/DESCRIBE/EXPLAIN/WITH (read-only)

Pengaman (read-only)

  • Hanya statement baca yang diterima. INSERT/UPDATE/DELETE/DROP/ALTER/CREATE/... ditolak otomatis.

  • Multi-statement (dipisah ;) ditolak.

  • Komentar SQL (-- , #, /* */) dibersihkan sebelum divalidasi.

  • LIMIT otomatis ditambahkan (default 1000 baris) bila query tidak punya.

  • Query punya timeout (default 15 detik).

Sangat disarankan: tetap pakai user MySQL yang hanya punya hak SELECT, sebagai lapisan keamanan kedua di sisi database.

CREATE USER 'readonly_user'@'%' IDENTIFIED BY 'password_kuat';
GRANT SELECT ON nama_database.* TO 'readonly_user'@'%';
FLUSH PRIVILEGES;

Setup

npm install
cp .env.example .env   # lalu isi kredensial database
npm run build

Isi .env:

DB_HOST=localhost
DB_PORT=3306
DB_USER=readonly_user
DB_PASSWORD=...
DB_NAME=nama_database
MAX_ROWS=1000
QUERY_TIMEOUT_MS=15000

Menghubungkan ke Claude Desktop

Edit file konfigurasi:

  • Windows: %APPDATA%\Claude\claude_desktop_config.json

  • macOS: ~/Library/Application Support/Claude/claude_desktop_config.json

Kredensial cukup ditaruh di file .env (server otomatis memuatnya dari folder proyek). Config-nya jadi sederhana:

{
  "mcpServers": {
    "database": {
      "command": "node",
      "args": ["c:\\project\\mcp-database\\dist\\index.js"]
    }
  }
}

⚠️ JANGAN menambahkan blok env dengan nilai placeholder (localhost, nama_database, dst). Nilai di blok env akan menimpa .env Anda dan menyebabkan koneksi gagal (ECONNREFUSED). Isi .env saja.

Restart total Claude Desktop (Quit dari tray, lalu buka lagi) setiap kali mengubah config atau melakukan rebuild — bukan sekadar tutup window.

Menghubungkan ke Claude Code (CLI)

claude mcp add database -- node c:\project\mcp-database\dist\index.js

(pastikan .env sudah terisi, atau tambahkan --env DB_HOST=... dst.)

Contoh penggunaan di Claude

"Cek ada berapa pengguna yang statusnya aktif di tabel pengguna"

Claude akan memanggil list_tables → describe_table → run_query dengan SELECT COUNT(*) FROM pengguna WHERE status = 'aktif'.

Pengembangan

npm run dev   # tsc --watch

Available Tools

3 tools
describe_tableA

Tampilkan struktur (kolom, tipe data, nullable, key) dari sebuah tabel. Gunakan untuk memahami skema sebelum menulis SELECT.

ParametersJSON Schema
NameRequiredDescriptionDefault
tableYesNama tabel yang ingin dilihat strukturnya.

TDQS

A4.3/5.0
Behavior3/5

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

With no annotations, the description discloses it returns structural metadata and implies a read operation. However, does not mention error handling, auth needs, or edge cases (e.g., nonexistent table).

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?

Two efficient sentences. First defines purpose, second adds usage guidance. No filler.

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?

For a simple tool with one parameter and no output schema, the description fully covers purpose, output content, and usage context. Complete as is.

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

Parameters4/5

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

Schema covers the single parameter with a clear description. The tool description adds value by specifying what output fields are returned (columns, types, nullable, keys), exceeding schema info.

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 table structure (columns, data types, nullable, keys) and gives explicit usage context ('before writing SELECT'). Differentiates from siblings as a schema inspection tool.

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?

Explicitly says to use before writing SELECT, implying when to use. Lacks explicit when-to-avoid or alternate tool mentions, but context from sibling names (list_tables, run_query) helps.

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

list_tablesA

Tampilkan daftar semua tabel di database. Gunakan ini lebih dulu untuk tahu tabel apa saja yang tersedia sebelum membuat query.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

A4.2/5.0
Behavior3/5

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

No annotations provided, but the description correctly identifies it as a read-only listing operation. Does not disclose additional behavior like performance or sorting, but acceptable for a simple tool.

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?

Two sentences, front-loaded with purpose, no unnecessary words. Efficient and to the point.

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 zero parameters and no output schema, the description adequately explains functionality and usage context. Could mention return format but not essential.

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

Parameters4/5

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

No parameters exist, baseline of 4 applies. Description adds no parameter details because none are needed.

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 'tampilkan' (show) and resource 'semua tabel di database' (all tables in database), and differentiates from siblings by recommending it as the first step before querying.

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?

Explicitly says 'Gunakan ini lebih dulu' (use this first) and 'sebelum membuat query' (before making a query), providing clear usage context and implying when to use it versus siblings.

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

run_queryA

Jalankan query SQL read-only (SELECT/SHOW/DESCRIBE/EXPLAIN/WITH) untuk pengecekan data. Perintah tulis (INSERT/UPDATE/DELETE/DROP/dll) akan ditolak. Hasil dibatasi maksimal 1000 baris.

ParametersJSON Schema
NameRequiredDescriptionDefault
sqlYesQuery SQL read-only. Contoh: SELECT id, nama FROM pengguna WHERE status = 'aktif'

TDQS

A4.2/5.0
Behavior4/5

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

With no annotations, description carries full burden. It discloses two key behaviors: read-only enforcement and 1000-row limit. Does not mention timeouts or error handling, but coverage is adequate for a simple query tool.

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?

Two sentences, front-loaded with purpose, followed by constraints. No unnecessary words; every sentence adds value.

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?

Covers purpose, allowed commands, constraints (read-only, row limit). Lacks explicit mention of alternatives among siblings, but is otherwise complete for a simple tool without 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 coverage is 100% and already includes example and read-only note. Description adds row limit and write rejection but these are tool-level, not parameter-specific. 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?

Description clearly states it runs read-only SQL queries for data checking, listing specific commands (SELECT/SHOW/DESCRIBE/EXPLAIN/WITH). It distinguishes from sibling tools by being a general query tool versus specific table description/listing.

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?

Provides guidance on when to use (read-only data checking) and what commands are rejected (writes). Implicitly covers use cases but does not explicitly compare to sibling tools like describe_table or list_tables.

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.

  1. 3 tool updatesv1.0.0
    • First observeddescribe_table
    • First observedlist_tables
    • First observedrun_query
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.3/5.0
Disambiguation5/5

Each tool has a clear, distinct purpose: listing tables, describing table schema, and running custom queries. There is no overlap or ambiguity.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern in snake_case (list_tables, describe_table, run_query), making them predictable.

Tool Count4/5

Three tools is minimal but appropriate for a read-only database server, covering the essential operations. Slightly more could be added, but not necessary.

Completeness4/5

The set covers the core read-only operations: enumeration, schema inspection, and arbitrary queries. Minor gaps like listing views or indexes exist, but the surface is sufficient for most exploration tasks.

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

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

Related MCP Connectors

Latest Blog Posts

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/AimanFadillah/mcp-database'

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