Sqlanywhere Mcp

MCP (Model Context Protocol) server for SQL Anywhere 17. Lets an MCP client such as Claude Code or Claude Desktop query a SQL Anywhere database directly to explore the schema, stored procedures, triggers, and views. It runs on Windows, Linux, and macOS.

Disclaimer: sqlanywhere-mcp is an independent, community open-source project. It is not affiliated with, endorsed by, or sponsored by SAP SE. SAP and SQL Anywhere are trademarks or registered trademarks of SAP SE. sqlanywhere-mcp does not include or redistribute any SAP software.

Table of contents

• sqlanywhere-mcp
  • Table of contents
  • Prerequisites
    • ODBC driver setup
  • Installation
    • From NuGet
    • From a release
    • From source
  • Configuration
    • File location
    • Fields
    • Live reload
  • Database password
    • Suggested helper: keyturn
  • Claude Code integration
    • As a plugin
    • By hand
  • Claude Desktop integration
  • Multiple databases
  • Available tools
    • Databases
    • Query execution
    • Ownership
    • Schema introspection
    • Object lists
    • Source retrieval
    • Procedure calls
  • How it works
  • License

Prerequisites

• The SQL Anywhere 17 ODBC driver, installed on the machine that runs sqlanywhere-mcp. It comes with the SQL Anywhere 17 client or server install, for the platform you run on.
• On Linux and macOS, an ODBC driver manager: unixODBC (for example apt install unixodbc, dnf install unixODBC, brew install unixodbc). On Windows the driver manager is built in.
• The .NET 10 SDK, to build from source.
• An MCP client, such as Claude Code or Claude Desktop.

sqlanywhere-mcp itself is a .NET application with no platform-specific code. What differs per platform is how the driver is registered, which is covered in ODBC driver setup.

ODBC driver setup

sqlanywhere-mcp connects with the ODBC driver named SQL Anywhere 17, which is the name the Windows installer registers. Use the driver setting (see Fields) when your driver is registered under another name.

• Windows: nothing to do after installing SQL Anywhere 17.
• Linux and macOS: unixODBC needs to know the driver. Either register it in odbcinst.ini under the name SQL Anywhere 17, or set driver in config.json to the path of the driver library, for example /opt/sqlanywhere17/lib64/libdbodbc17.so (the path depends on where SQL Anywhere is installed). The driver also needs its own libraries to be loadable; SQL Anywhere provides an sa_config.sh script for that, which you can source before starting your MCP client. See SAP's documentation for the details of your platform.

When the connection fails, the tool error names the driver it used, so a wrong driver name or a missing driver is visible in the client.

Installation

There are three ways to get sqlanywhere-mcp. All of them give the same server, which needs the prerequisites above (the ODBC driver, plus unixODBC on Linux and macOS).

From NuGet

The SqlAnywhereMcp package is a .NET tool with a self-contained build for each platform (win-x64, linux-x64, linux-arm64, osx-x64, osx-arm64), so no .NET runtime is needed to run it. It needs the .NET 10 SDK to install, which provides dnx and dotnet tool.

Run it without installing, which is what MCP clients usually do:

dnx SqlAnywhereMcp --yes

Or install it as a global tool, which puts sqlanywhere-mcp on your PATH:

dotnet tool install --global SqlAnywhereMcp

To register it with Claude Code without installing anything first:

claude mcp add --transport stdio --scope user sqlanywhere -- dnx SqlAnywhereMcp --yes

From a release

Each GitHub release has an archive per platform with the self-contained executable, plus a SHA256SUMS file. Unpack the one for your platform somewhere on your PATH and verify it with sha256sum -c SHA256SUMS. The executables are not code-signed, so macOS Gatekeeper and Windows SmartScreen may warn on first run.

From source

Run the install script for your platform from a regular user account (no administrator rights needed). Each one publishes a self-contained executable, so the .NET runtime is not needed to run it.

Windows (PowerShell):

.\install.ps1

It publishes sqlanywhere-mcp.exe to %LOCALAPPDATA%\sqlanywhere-mcp\, adds that directory to the user PATH, and prints the command to register the server with Claude Code.

Linux and macOS (bash):

./install.sh

It detects the platform (linux-x64, linux-arm64, osx-x64, or osx-arm64), publishes sqlanywhere-mcp to ~/.local/bin/, and prints the command to register the server with Claude Code. -c Debug builds in Debug mode.

The driver must match the architecture of the executable. If your SQL Anywhere 17 driver is x64 only, use an x64 build (on Apple silicon, the x64 build runs under Rosetta).

Any platform, by hand:

dotnet publish src/SqlAnywhereMcp -c Release -r <rid> --self-contained -o <output-dir>

where <rid> is a .NET runtime identifier such as win-x64, linux-x64, or osx-x64.

Configuration

File location

If the file is missing on first launch, an example is created automatically. Edit it and restart sqlanywhere-mcp once; after that, changes are picked up without a restart (see Live reload).

Example configuration:

{  "defaults": {    "username": "dba",    "passwordCommand": "keyturn get dev-db --refresh"  },  "allowedProcedures": [],  "defaultDatabase": "demo",  "databases": {    "demo": { "host": "localhost", "database": "demodb" },    "staging": {      "host": "db.example.com",      "port": 2700,      "database": "stagingdb",      "passwordCommand": "keyturn get staging-db --refresh",      "allowedProcedures": ["dbo.sa_conn_info"]    }  }}

Unknown fields are rejected, so a misspelled field (for example allowedProcedure) is reported instead of being silently ignored.

Fields

Top level:

defaults:

Each database:

Live reload

sqlanywhere-mcp checks config.json before every tool call. When the file changed and is valid, the next call uses it: added databases become available, removed ones disappear, and open connections are closed so they reopen with the new settings. No restart of sqlanywhere-mcp or Claude Code is needed.

When the changed file is invalid (malformed JSON, an unknown field, a duplicate name, a bad procedure name, ...) or was deleted, sqlanywhere-mcp keeps using the last valid version. list_databases reports the error in reloadError, and the error is also written to sqlanywhere-mcp's standard error, which MCP clients show in their logs. Fixing the file clears it.

The first load at startup is still strict: sqlanywhere-mcp exits with an error when the file is invalid then.

Database password

sqlanywhere-mcp never stores the database password. It follows the credential-helper pattern: passwordCommand is a command that prints the password on its standard output, and sqlanywhere-mcp runs it each time it opens a connection, so a password that rotates is picked up on the next reconnect.

The contract for a helper:

• It prints only the password on stdout. A trailing newline is ignored.
• It exits 0 on success. Any other exit code fails the connection, and the tool returns an error naming the command and its exit code.
• Diagnostics go to stderr, which sqlanywhere-mcp passes through to its own, where MCP clients show it in their logs.
• It runs without a shell and without input (stdin is closed). Quote arguments that contain spaces.

Any helper that follows this works, for example pass show sqlanywhere/dev, secret-tool lookup service sqlanywhere, or a small script of your own.

Suggested helper: keyturn

keyturn keeps a rotating secret in the OS credential store (Windows Credential Manager, macOS Keychain, Linux Secret Service) and asks for the new value when it expires. It is built around this pattern: keyturn get NAME prints the secret, and --refresh opens a prompt when the secret is stale or missing, then continues with the new value. One-time setup:

keyturn add dev-db daily@06:00 "SQL Anywhere dev password"keyturn set dev-db

"passwordCommand": "keyturn get dev-db --refresh"

keyturn runs on Windows, Linux, and macOS. The command runs on the same operating system as sqlanywhere-mcp, so install keyturn there and make sure it is on that system's PATH. For example, when Claude Code runs inside WSL2 but launches the Windows sqlanywhere-mcp.exe, the helper is the Windows one and reads the Windows Credential Manager.

A database with other credentials can point at another secret with its own passwordCommand, overriding defaults.passwordCommand.

config.json never holds the password: a config with a password field is rejected with an error.

Claude Code integration

As a plugin

The repository is also a Claude Code plugin marketplace. The plugin registers the server for you, and runs it with dnx SqlAnywhereMcp --yes, so it needs the .NET 10 SDK and always uses the latest published package. It doesn't create your config.json: see Configuration.

The plugin starts the server on the machine Claude Code runs on. Inside WSL2 that means dnx runs in Linux, so WSL2 needs its own .NET 10 SDK and the Linux ODBC driver. To use the Windows install from WSL2, skip the plugin and register the server by hand, as described under Claude Code inside WSL2.

claude plugin marketplace add Dwarf1er/sqlanywhere-mcpclaude plugin install sqlanywhere@sqlanywhere-mcp

By hand

The install script prints the exact command at the end of its run. The --scope user flag registers the server globally across all projects.

Linux and macOS - run from any terminal:

claude mcp add --transport stdio --scope user sqlanywhere \  ~/.local/bin/sqlanywhere-mcp

Windows - run from any terminal:

claude mcp add --transport stdio --scope user sqlanywhere `  "C:\Users\<username>\AppData\Local\sqlanywhere-mcp\sqlanywhere-mcp.exe"

Claude Code inside WSL2 - pick the build by where your databases run:

• Databases on Windows (or reached through the Windows side): run the Windows build from WSL2 through interop. It uses the Windows driver, and stdio works transparently. There are two ways:
  • The Windows .NET tool (dotnet tool install --global SqlAnywhereMcp, run in Windows). It installs a sqlanywhere-mcp.cmd launcher in %USERPROFILE%\.dotnet\tools, and WSL2 can't run a .cmd file directly, so go through cmd.exe:
    bash

    claude mcp add --transport stdio --scope user sqlanywhere \  -- cmd.exe /d /c 'C:\Users\<username>\.dotnet\tools\sqlanywhere-mcp.cmd'

    Don't point at the executable under .dotnet\tools\.store\sqlanywheremcp\<version>\: its path contains the version, so it breaks on every dotnet tool update. The .cmd launcher keeps working.
  • The executable from the Windows install script, which WSL2 can run directly:
    bash

    claude mcp add --transport stdio --scope user sqlanywhere \  /mnt/c/Users/<username>/AppData/Local/sqlanywhere-mcp/sqlanywhere-mcp.exe

• Databases in WSL2's Linux: install and run it as a Linux program inside WSL2, exactly as on Linux above. That needs the Linux SQL Anywhere 17 driver and unixODBC inside WSL2.

The two builds don't share anything: the Windows build reads the Windows config and credential helper, and the Linux one reads the config in WSL2.

Restart Claude Code for the configuration to take effect. The MCP server starts automatically when Claude Code launches.

Claude Desktop integration

Claude Desktop reads its MCP server list from claude_desktop_config.json. Open it via Settings > Developer > Edit Config (this creates the file if it doesn't exist yet), and add an entry under mcpServers:

{  "mcpServers": {    "sqlanywhere": {      "command": "C:\\Users\\<username>\\AppData\\Local\\sqlanywhere-mcp\\sqlanywhere-mcp.exe"    }  }}

On macOS, use the path of the installed executable instead, for example /Users/<username>/.local/bin/sqlanywhere-mcp.

If the file already has other entries under mcpServers, just add sqlanywhere alongside them.

Save the file and fully restart Claude Desktop (quit it completely, not just close the window). To verify the connection, click the "+" button in the chat box and select "Connectors" - sqlanywhere should appear with its tools listed. If it fails to connect, check Settings > Developer for logs.

Multiple databases

List every database under databases in one config.json, keyed by name (see Configuration). Every tool takes an optional database argument with the name of the database to use; without it, the tool uses defaultDatabase, or the only database when there is just one. list_databases lists the names that exist.

Registering sqlanywhere-mcp several times, each with its own config file through the SQLANYWHERE_MCP_CONFIG environment variable, still works. It is only useful to keep databases fully apart, for example a separate server entry for production:

claude mcp add --transport stdio --scope user sqlanywhere-prod \  --env SQLANYWHERE_MCP_CONFIG=~/.config/sqlanywhere-mcp/prod.json \  -- ~/.local/bin/sqlanywhere-mcp

When SQLANYWHERE_MCP_CONFIG is not set, the server uses the default config path.

Available tools

Tool names are in snake_case, as clients see them (for example list_databases). Every tool except call_procedure is annotated as read-only, idempotent and closed-world (readOnlyHint, idempotentHint, openWorldHint), so MCP clients can approve them without prompting; call_procedure is annotated as non-read-only and destructive. Failures are returned as MCP tool errors (isError), with the reason as the message.

Every tool declares an outputSchema and returns its result as structuredContent (the same JSON is also in the text content for clients that ignore structured output). Most tools return { "rows": [...], "truncated": bool, "count": int }, where each row is an object keyed by column name. explain_query returns { "query", "plan", "estimatedRows", "estimatedTime" } and list_databases returns the databases and the config status.

Tool calls are cancellable: when the client cancels a request, sqlanywhere-mcp asks the database to stop the running statement and stops a password command that is still running.

Every tool below except list_databases also takes an optional database parameter: the name of the database to use, from list_databases. Without it, the tool uses the default database. The parameter is left out of the tables below.

Databases

list_databases

Lists the configured databases with their name, host, port, database name, username, and the procedures call_procedure may call on each, along with the default database, the config file path, and reloadError when the last change to config.json could not be loaded.

Query execution

execute_query

Executes a read-only SQL query and returns results as JSON. Only SELECT and WITH statements are accepted. Multi-statement queries (;) and SELECT ... INTO are rejected. A query that runs longer than 60 seconds is cancelled.

The response includes a truncated flag set to true when the result exceeds maxRows, and a count field with the number of rows returned.

explain_query

Returns the execution plan for a read-only SQL query (SELECT or WITH only).

describe_query

Describes the result set of a read-only query without running it (sa_describe_query): each column's name, data type, nullability, and the table column it comes from. The same read-only checks as execute_query apply.

Ownership

list_owners

Lists all distinct owners (users) that own at least one table or view in the database.

Schema introspection

list_tables

Lists all base tables and views with their type and owner.

describe_table

Returns the column definitions of a table: name, type, length, nullability, default value, primary key flag, and comment.

list_check_constraints

Lists all check constraints on a table with their name and definition.

list_indexes

Lists all indexes of a table: primary key, foreign key, secondary, and text indexes, with their uniqueness and the columns they cover in order (descending columns are marked desc).

list_foreign_keys

Lists all foreign keys in the database: role name, child table, parent table, and mapped columns.

get_table_definition

Returns the CREATE statements the database generates for a table (sa_get_table_definition): the table and its columns, keys, foreign keys, the sequences it uses, and granted privileges.

Triggers and comments are left out by default: a table with a few large triggers can produce more output than an MCP client accepts in one call, since each trigger appears twice (its definition and its preserved original source). get_trigger_source and get_table_comments return them separately.

get_table_comments

Returns the comment of a table and of each of its columns: one table row, then one row per column, each with the database's own comment (remarks, set with COMMENT ON).

list_dependent_views

Lists the views that depend on a table or view, directly or through other views (sa_dependent_views).

describe_procedure

Describes a stored procedure or function: its parameters (in, out, inout) with their types and defaults, the columns of the result set it returns, and a function's return value.

get_table_stats

Returns the exact row count for a table. Table and owner names must contain only letters, digits, and underscores.

Object lists

list_procedures

Lists all stored procedures and functions in the database, each tagged as procedure or function.

list_views

Lists all views in the database.

list_triggers

Lists all triggers in the database with their associated table.

get_database_info

Returns database-level properties: name, product version, character set, collation, and page size.

list_events

Lists all database events (scheduled jobs) with their name and enabled status.

list_sequences

Lists all sequences with their owner, start value, increment, bounds, and cycling.

list_user_types

Lists all user-defined data types (domains) with their owner, base type, nullability, default, and check condition.

list_web_services

Lists the web services defined in the database with their type (HTTP, SOAP, DISH, RAW, ...), whether they're enabled, whether they require authentication or HTTPS, and the user they run as.

Source retrieval

When the database's preserve_source_format option is On, SQL Anywhere keeps the original source of procedures, views, triggers, and events, with comments and formatting. The source tools return that original source, and fall back to the definition as reformatted by the server when there is none.

get_procedure_source

Returns the full source definition of a stored procedure or function.

get_view_source

Returns the full source definition of a view.

get_trigger_source

Returns the full source definition of a trigger.

get_event_source

Returns the full source definition of a database event.

get_web_service_source

Returns the definition of a web service: the SQL statement it runs, its URL handling, the DISH prefix for DISH services, and its remarks.

search_source

Searches the source of procedures and functions, views, triggers, events, and web service statements for a piece of text, case-insensitively, and lists the objects that contain it. The text is matched literally: % and _ aren't wildcards.

Procedure calls

call_procedure

Calls a stored procedure allowed for the database in config.json: the top-level allowedProcedures apply to every database, and a database's own allowedProcedures add to them. Every other procedure is rejected, and the error lists the allowed ones. With no allowed procedure, which is the default, every call is rejected.

"allowedProcedures": ["dbo.sa_db_info"],"databases": {  "demo": { "host": "localhost", "database": "demodb", "allowedProcedures": ["dbo.sa_conn_info"] }}

Here demo allows both procedures, and any other database only dbo.sa_db_info.

Only list procedures you are comfortable letting Claude run: they run with the connection's permissions, outside the read-only check of execute_query.

How it works

The server keeps one persistent ODBC connection per database, opened on the first tool call that uses it, pinging before each operation and reconnecting automatically if the connection is dropped. A change to config.json closes the connections, which reopen with the new settings on the next call.

execute_query enforces read-only access at the application level: it strips comments, rejects anything that is not a SELECT or WITH statement, and blocks multi-statement queries and SELECT ... INTO. This is a safeguard, not a security boundary: for real protection, connect with a database user that only has read permissions. All other tools use hardcoded parameterized queries against SQL Anywhere's system catalog.

They also call the sa_get_table_definition, sa_dependent_views, and sa_describe_query system procedures. None of these are deprecated compatibility views.

The MCP server runs in stdio mode and is managed automatically by Claude Code.

License

This software is licensed under the MIT license.

SAP and SQL Anywhere are trademarks or registered trademarks of SAP SE. This project is not affiliated with or endorsed by SAP SE.