Skip to main content
Glama
eukos

mcp-sequel

by eukos
OverviewSchemaRelated ServersScoreDiscussions
Python
Hybrid

mcp-sequel

MCP server for Claude that connects to MySQL, MariaDB, PostgreSQL, and SQLite databases. Query your databases using natural language. Supports multiple named connections, SSH tunnels, readonly mode, and per-connection row limits.

Install & Registration

Tip: ask Claude to read this README and set up the server for you.

Option 1: uvx (recommended) — no installation needed, always runs the latest version:

claude mcp add mcp-sequel uvx mcp-sequel

Option 2: from cloned repository:

git clone https://github.com/eukos/mcp-sequel
claude mcp add mcp-sequel uv run --directory /path/to/mcp-sequel mcp-sequel

Related MCP server: MariaDB MCP Server

Configuration

Tip: ask Claude to read this README and create a connection config for you.

One file per connection in ~/.config/mcp-sequel/. The filename (without .json) becomes the connection name.

~/.config/mcp-sequel/
├── production.json
├── staging.json
└── local.json

Each file is one connection. Examples:

MySQL / MariaDB

{
  "type": "mysql",
  "host": "db.example.com",
  "port": 3306,
  "user": "analyst",
  "password": "secret",
  "database": "myapp",
  "readonly": true,
  "row_limit": 1000,
  "description": "Production replica, analytics only"
}

Field

Required

Default

Description

type

yes

—

"mysql" or "mariadb"

host

yes

—

hostname or IP

user

yes

—

database user

password

yes

—

database password

port

no

3306

TCP port

database

no

—

default database; can be overridden per query

readonly

no

true

if true, only SELECT/SHOW/DESCRIBE/EXPLAIN are allowed

row_limit

no

1000

max rows returned; null for no limit

description

no

—

human-readable label shown in list_connections

ssh_tunnel

no

—

SSH tunnel config (see below); routes the connection through a bastion host

MySQL via SSH tunnel

Use ssh_tunnel when the database is only reachable through a bastion/jump host. host and port in the top-level config refer to the DB as seen from the SSH server (commonly localhost).

With a key file (most common):

{
  "type": "mysql",
  "host": "localhost",
  "port": 3306,
  "user": "reader",
  "password": "secret",
  "database": "myapp",
  "ssh_tunnel": {
    "host": "bastion.example.com",
    "user": "ubuntu",
    "key_file": "~/.ssh/id_rsa"
  }
}

With an SSH password:

{
  "type": "mysql",
  "host": "localhost",
  "port": 3306,
  "user": "reader",
  "password": "secret",
  "ssh_tunnel": {
    "host": "bastion.example.com",
    "user": "ubuntu",
    "password": "sshpass"
  }
}

Field

Required

Default

Description

host

yes

—

SSH server hostname or IP

user

yes

—

SSH username

key_file

no*

—

path to private key file (~ expanded)

password

no*

—

SSH password (if not using key file)

port

no

22

SSH server port

* at least one of key_file or password should be provided.

PostgreSQL

{
  "type": "postgresql",
  "host": "db.example.com",
  "port": 5432,
  "user": "analyst",
  "password": "secret",
  "database": "myapp",
  "readonly": true,
  "row_limit": 1000,
  "description": "Production PostgreSQL"
}

Field

Required

Default

Description

type

yes

—

"postgresql"

host

yes

—

hostname or IP

user

yes

—

database user

password

yes

—

database password

port

no

5432

TCP port

database

no*

—

database to connect to; can be passed per query instead

readonly

no

true

if true, connection is opened in read-only mode (DB-level enforcement)

row_limit

no

1000

max rows returned; null for no limit

description

no

—

human-readable label shown in list_connections

ssh_tunnel

no

—

SSH tunnel config (same format as MySQL)

* database must be provided either in the config or per query — PostgreSQL requires a database to connect.

SQLite

{
  "type": "sqlite",
  "path": "/data/analytics.db",
  "readonly": true,
  "row_limit": 1000,
  "description": "Local analytics database"
}

Field

Required

Default

Description

type

yes

—

"sqlite"

path

yes

—

absolute path to the .db file

readonly

no

true

if true, opens connection with ?mode=ro (OS-level enforcement)

row_limit

no

1000

max rows returned; null for no limit

description

no

—

human-readable label shown in list_connections

Set permissions to owner-only:

chmod 600 ~/.config/mcp-sequel/*.json

Usage

After registering, restart Claude to load the server. Then try:

  • "List available database connections"

  • "Show databases for staging"

  • "How many customers do we have on production?"

  • "Show me the schema of the orders table"

  • "Query local: SELECT * FROM users LIMIT 10"

  • "Query production: show me the top 10 users by order count"

License

MIT

Available Tools

3 tools
get_versionA

Return the installed mcp-sequel package version.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.1/5.0
Behavior3/5

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

The description discloses a read-only operation (return version) with no side effects, but no additional context beyond that. Since annotations are absent, the description carries the full burden but provides minimal behavioral detail.

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 tool's purpose efficiently with no unnecessary words.

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 the tool's simplicity (no parameters, no side effects, and existence of an output schema), the description is complete enough to understand what the tool does and what to expect.

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?

There are zero parameters, and the input schema has 100% coverage. The description adds no parameter information, but baseline for zero-param tools is 4, as no further semantics 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 'Return' and the resource 'installed mcp-sequel package version', making the tool's specific purpose unambiguous. It is distinct from sibling tools 'list_connections' and '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 versus alternatives. However, the purpose is simple and self-explanatory; it is primarily for checking the installed version, which is unlikely to conflict with siblings.

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

list_connectionsA

List all configured database connections.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4/5.0
Behavior3/5

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

Without annotations, the description carries the burden. It correctly implies a read-only operation but fails to disclose details like authentication needs, rate limits, or the meaning of 'configured'.

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 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?

Given zero parameters and an existing output schema, the description is mostly complete. However, it could clarify what 'configured' means or mention typical return fields.

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?

There are no parameters, so the baseline is 4. The description adds no parameter information, but none is 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 'List' and the resource 'configured database connections,' distinguishing it from siblings get_version and 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?

The description provides no explicit when-to-use or when-not-to-use guidance. It is adequate for a simple list operation but lacks context on alternatives or prerequisites.

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

queryB

Execute a SQL query on a database connection. Returns JSON with columns, rows, row_count, limit_applied.

ParametersJSON Schema
NameRequiredDescriptionDefault
connectionYes
sqlYes
databaseNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

B3.2/5.0
Behavior2/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 fails to disclose whether queries are read-only or can mutate data, potential side effects, or authorization requirements. Mentioning return structure helps but is insufficient.

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 covering purpose and output. It is front-loaded and efficient, though it could mention parameter details without adding significant length.

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 complexity of SQL execution, the lack of annotations, and the minimal parameter explanation, the description is insufficient for an agent to safely and correctly invoke the tool. Missing safety, parameter semantics, and usage context detail.

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

Parameters2/5

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

Schema description coverage is 0%, and the description does not explain the parameters (connection, sql, database) beyond the generic phrase 'on a database connection.' No details on format, defaults, or constraints are given, leaving the agent without necessary context.

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 purpose: 'Execute a SQL query on a database connection.' It also specifies the return format (JSON with columns, rows, row_count, limit_applied), distinguishing it from sibling tools like get_version and list_connections.

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 SQL execution but gives no explicit guidance on when to choose this tool over siblings or what contexts are appropriate. No exclusions or alternative recommendations are 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.7/5.0
Disambiguation5/5

Each tool has a clearly distinct purpose: version info, listing connections, and executing queries. No overlaps or ambiguity.

Naming Consistency4/5

Two tools follow verb_noun pattern (get_version, list_connections), but 'query' is a single verb without a noun, creating minor inconsistency. Overall still clear and predictable.

Tool Count4/5

Three tools is appropriate for a focused SQL query interface. It covers basic needs without being too many or too few, though slightly minimal.

Completeness3/5

Core query functionality is present, but missing schema introspection, connection management (create/delete), or result pagination control. Gaps may force agents to work around limitations.

Maintenance

ActivitySlowing
ResponsivenessSyncing

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

Related MCP Servers

  • MariaDB MCP Server

    abel9851
    A
    license
    Not graded
    quality
    D
    maintenance
    An MCP server implementation that enables Claude to execute read-only queries against MariaDB databases and explore database schemas through natural language.
    20
    MIT

  • Database Tools for Claude AI

    elber-code
    A
    license
    B
    quality
    D
    maintenance
    MCP server that allows Claude AI to interact directly with MySQL databases, enabling query execution and table information retrieval through natural language.
    1
    5
    4
    MIT

  • xamp

    yeyorg
    A
    license
    A
    quality
    B
    maintenance
    MCP server that gives Claude Code and OpenCode direct access to your XAMPP MariaDB/MySQL databases, enabling database listing, table inspection, and read/write query execution.
    5
    MIT

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/eukos/mcp-sequel'

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