Skip to main content
Glama
deenesjakoruzh
OpenLinkSoftware

mcp-sqlalchemy

by OpenLinkSoftware
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

通过 SQLAlchemy 实现 MCP 服务器 ODBC

使用FastAPI 、 pyodbc和SQLAlchemy构建的轻量级 ODBC MCP (模型上下文协议) 服务器。此服务器与 Virtuoso DBMS 以及其他实现了 SQLAlchemy 提供程序的 DBMS 后端兼容。

mcp-客户端和服务器|648x499

特征

  • 获取模式：从连接的数据库中获取并列出所有模式名称。

  • 获取表：检索特定模式或所有模式的表信息。

  • Describe Table ：生成表结构的详细描述，包括：

    • 列名和数据类型

    • 可空属性

    • 主键和外键

  • 搜索表：根据名称子字符串过滤和检索表。

  • 执行存储过程：在 Virtuoso 的情况下，执行存储过程并检索结果。

  • 执行查询：

    • JSONL 结果格式：针对结构化响应进行了优化。

    • Markdown 表格格式：适合报告和可视化。

Related MCP server: MCP SQL Server

先决条件

  1. 安装 uv ：

    pip install uv

    或者使用 Homebrew：

    brew install uv

  2. unixODBC 运行时环境检查：

  3. 通过运行以下命令检查安装配置（即关键 INI 文件的位置）： odbcinst -j

  4. 通过运行以下命令列出可用的数据源名称： odbcinst -q -s

  5. ODBC DSN 设置：为目标数据库配置 ODBC 数据源名称 ( ~/.odbc.ini )。例如，以 Virtuoso DBMS 为例：

    [VOS]
Description = OpenLink Virtuoso
Driver = /path/to/virtodbcu_r.so
Database = Demo
Address = localhost:1111
WideAsUTF16 = Yes

  6. SQLAlchemy URL 绑定：使用格式：

    virtuoso+pyodbc://user:password@VOS

安装

克隆此存储库：

git clone https://github.com/OpenLinkSoftware/mcp-sqlalchemy-server.git
cd mcp-sqlalchemy-server

环境变量

通过覆盖默认值来更新您的.env以符合您的偏好

ODBC_DSN=VOS
ODBC_USER=dba
ODBC_PASSWORD=dba
API_KEY=xxx

配置

对于Claude Desktop用户：将以下内容添加到claude_desktop_config.json ：

{
  "mcpServers": {
    "my_database": {
      "command": "uv",
      "args": ["--directory", "/path/to/mcp-sqlalchemy-server", "run", "mcp-sqlalchemy-server"],
      "env": {
        "ODBC_DSN": "dsn_name",
        "ODBC_USER": "username",
        "ODBC_PASSWORD": "password",
        "API_KEY": "sk-xxx"
      }
    }
  }
}

用法

数据库管理系统 (DBMS) 连接 URL

以下是使用此 mcp-server 测试过的用于连接 DBMS 系统的 pyodbc URL 示例。

数据库

URL 格式

Virtuoso 数据库管理系统

virtuoso+pyodbc://user:password@ODBC_DSN

PostgreSQL

postgresql://user:password@localhost/dbname

MySQL

mysql+pymysql://user:password@localhost/dbname

SQLite

sqlite:///path/to/database.db

一旦连接，您就可以通过 Claude 与您的 WhatsApp 联系人互动，并在您的 WhatsApp 对话中利用 Claude 的 AI 功能。

提供的工具

概述

姓名

描述

podbc_get_schemas

列出连接的数据库管理系统 (DBMS) 可访问的数据库模式。

podbc_get_tables

列出与选定数据库模式关联的表。

podbc_describe_table

提供与指定数据库模式关联的表的描述。这包括有关列名、数据类型、空值处理、自动增量、主键和外键的信息。

podbc_filter_table_names

根据q输入字段中的子字符串模式列出与所选数据库模式关联的表。

podbc_query_database

执行 SQL 查询并以 JSONL 格式返回结果。

podbc_execute_query

执行 SQL 查询并以 JSONL 格式返回结果。

podbc_execute_query_md

执行 SQL 查询并以 Markdown 表格式返回结果。

podbc_spasql_query

执行SPASQL查询并返回结果。

podbc_sparql_query

执行 SPARQL 查询并返回结果。

podbc_virtuoso_support_ai

与 Virtuoso 支持助手/代理进行交互——Virtuoso 特有的与 LLM 交互的功能

详细描述

  • podbc_get_schemas

    • 从连接的数据库中检索并返回所有模式名称的列表。

    • 输入参数：

      • user （字符串，可选）：数据库用户名。默认为“demo”。

      • password （字符串，可选）：数据库密码。默认为“demo”。

      • dsn （字符串，可选）：ODBC 数据源名称。默认为“Local Virtuoso”。

    • 返回架构名称的 JSON 字符串数组。

  • podbc_get_tables

    • 检索并返回包含指定架构中表的信息的列表。如果未提供架构，则使用连接的默认架构。

    • 输入参数：

      • schema （字符串，可选）：用于过滤表的数据库模式。默认为连接默认值。

      • user （字符串，可选）：数据库用户名。默认为“demo”。

      • password （字符串，可选）：数据库密码。默认为“demo”。

      • dsn （字符串，可选）：ODBC 数据源名称。默认为“Local Virtuoso”。

    • 返回包含表信息（例如，TABLE_CAT、TABLE_SCHEM、TABLE_NAME、TABLE_TYPE）的 JSON 字符串。

  • podbc_filter_table_names

    • 过滤并返回有关名称包含特定子字符串的表的信息。

    • 输入参数：

      • q （字符串，必需）：在表名中搜索的子字符串。

      • schema （字符串，可选）：用于过滤表的数据库模式。默认为连接默认值。

      • user （字符串，可选）：数据库用户名。默认为“demo”。

      • password （字符串，可选）：数据库密码。默认为“demo”。

      • dsn （字符串，可选）：ODBC 数据源名称。默认为“Local Virtuoso”。

    • 返回包含匹配表的信息的 JSON 字符串。

  • podbc_describe_table

    • 检索并返回有关特定表的列的详细信息。

    • 输入参数：

      • schema （字符串，必需）：包含表的数据库模式名称。

      • table （字符串，必需）：要描述的表的名称。

      • user （字符串，可选）：数据库用户名。默认为“demo”。

      • password （字符串，可选）：数据库密码。默认为“demo”。

      • dsn （字符串，可选）：ODBC 数据源名称。默认为“Local Virtuoso”。

    • 返回描述表的列的 JSON 字符串（例如，COLUMN_NAME、TYPE_NAME、COLUMN_SIZE、IS_NULLABLE）。

  • podbc_query_database

    • 执行标准 SQL 查询并以 JSON 格式返回结果。

    • 输入参数：

      • query （字符串，必需）：要执行的 SQL 查询字符串。

      • user （字符串，可选）：数据库用户名。默认为“demo”。

      • password （字符串，可选）：数据库密码。默认为“demo”。

      • dsn （字符串，可选）：ODBC 数据源名称。默认为“Local Virtuoso”。

    • 以 JSON 字符串形式返回查询结果。

  • podbc_query_database_md

    • 执行标准 SQL 查询并返回格式化为 Markdown 表的结果。

    • 输入参数：

      • query （字符串，必需）：要执行的 SQL 查询字符串。

      • user （字符串，可选）：数据库用户名。默认为“demo”。

      • password （字符串，可选）：数据库密码。默认为“demo”。

      • dsn （字符串，可选）：ODBC 数据源名称。默认为“Local Virtuoso”。

    • 以 Markdown 表字符串形式返回查询结果。

  • podbc_query_database_jsonl

    • 执行标准 SQL 查询并以 JSON 行 (JSONL) 格式返回结果（每行一个 JSON 对象）。

    • 输入参数：

      • query （字符串，必需）：要执行的 SQL 查询字符串。

      • user （字符串，可选）：数据库用户名。默认为“demo”。

      • password （字符串，可选）：数据库密码。默认为“demo”。

      • dsn （字符串，可选）：ODBC 数据源名称。默认为“Local Virtuoso”。

    • 以 JSONL 字符串形式返回查询结果。

  • podbc_spasql_query

    • 执行 SPASQL（SQL/SPARQL 混合）查询并返回结果。这是 Virtuoso 独有的功能。

    • 输入参数：

      • query （字符串，必需）：SPASQL 查询字符串。

      • max_rows （number，可选）：返回的最大行数。默认为 20。

      • timeout （数字，可选）：查询超时时间（以毫秒为单位）。默认为 30000。

      • user （字符串，可选）：数据库用户名。默认为“demo”。

      • password （字符串，可选）：数据库密码。默认为“demo”。

      • dsn （字符串，可选）：ODBC 数据源名称。默认为“Local Virtuoso”。

    • 返回底层存储过程调用的结果（例如， Demo.demo.execute_spasql_query ）。

  • podbc_sparql_query

    • 执行 SPARQL 查询并返回结果。这是 Virtuoso 独有的功能。

    • 输入参数：

      • query （字符串，必需）：SPARQL 查询字符串。

      • format （字符串，可选）：所需的结果格式。默认为 'json'。

      • timeout （数字，可选）：查询超时时间（以毫秒为单位）。默认为 30000。

      • user （字符串，可选）：数据库用户名。默认为“demo”。

      • password （字符串，可选）：数据库密码。默认为“demo”。

      • dsn （字符串，可选）：ODBC 数据源名称。默认为“Local Virtuoso”。

    • 返回底层函数调用的结果（例如， "UB".dba."sparqlQuery" ）。

  • podbc_virtuoso_support_ai

    • 使用 Virtuoso 独有的 AI 助手功能，传递提示符和可选的 API 密钥。这是 Virtuoso 独有的功能。

    • 输入参数：

      • prompt （字符串，必需）：AI 功能的提示文本。

      • api_key （字符串，可选）：AI 服务的 API 密钥。默认为“无”。

      • user （字符串，可选）：数据库用户名。默认为“demo”。

      • password （字符串，可选）：数据库密码。默认为“demo”。

      • dsn （字符串，可选）：ODBC 数据源名称。默认为“Local Virtuoso”。

    • 返回 AI 支持助手函数调用的结果（例如， DEMO.DBA.OAI_VIRTUOSO_SUPPORT_AI ）。

故障排除

为了更容易地排除故障：

  1. 安装 MCP 检查器：

    npm install -g @modelcontextprotocol/inspector

  2. 启动检查器：

    npx @modelcontextprotocol/inspector uv --directory /path/to/mcp-sqlalchemy-server run mcp-sqlalchemy-server

访问提供的 URL 来排除服务器交互故障。

Available Tools

11 tools
podbc_describe_tableC

Retrieve and return a dictionary containing the definition of a table, including column names, data types, nullable, autoincrement, primary key, and foreign keys.

ParametersJSON Schema
NameRequiredDescriptionDefault
SchemaYes
tableYes
urlNo

TDQS

C2.7/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 the full burden. It describes the output format ('dictionary containing the definition') but lacks critical behavioral details: whether this is a read-only operation, potential performance impacts, error conditions, or authentication needs. For a database tool with zero annotation coverage, this is a significant gap.

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 a single, efficient sentence that front-loads the purpose. It avoids unnecessary words and directly states the action and output. However, it could be slightly more structured by separating usage context from output details.

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 3 parameters, 0% schema coverage, no annotations, and no output schema, the description is incomplete. It adequately explains the purpose but misses parameter explanations, behavioral transparency, and usage guidelines. Given the complexity and lack of structured data, it should provide more context to be fully helpful.

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%, so parameters are undocumented in the schema. The description mentions 'table' implicitly but doesn't explain any of the three parameters (Schema, table, url) or their semantics. It adds no value beyond what the parameter names suggest, failing to compensate for the coverage gap.

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

Purpose4/5

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

The description clearly states the verb ('retrieve and return') and resource ('definition of a table'), specifying what information is included (column names, data types, etc.). It distinguishes from siblings like podbc_get_tables (which likely lists tables) by focusing on table structure details. However, it doesn't explicitly name alternatives or contrast with all siblings.

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?

The description provides no guidance on when to use this tool versus alternatives like podbc_get_tables or podbc_filter_table_names. It doesn't mention prerequisites, context for use, or exclusions. Usage is implied by the purpose but not explicitly stated.

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

podbc_execute_queryC

Execute a SQL query and return results in JSONL format.

ParametersJSON Schema
NameRequiredDescriptionDefault
max_rowsNo
paramsNo
queryYes
urlNo

TDQS

C2.8/5.0
Behavior2/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions the output format (JSONL) but doesn't address critical aspects like whether this is a read-only or write operation, authentication requirements, rate limits, error handling, or what happens when max_rows is exceeded. For a SQL execution tool, this leaves significant gaps.

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 - a single sentence that efficiently communicates the core functionality. There's no wasted verbiage, and the information is front-loaded with the essential action and output format.

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 SQL execution tool with 4 parameters, 0% schema coverage, no annotations, and no output schema, the description is inadequate. It doesn't explain parameter usage, behavioral constraints, or what the tool returns beyond format. The agent would struggle to use this tool correctly without significant trial and error.

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?

With 0% schema description coverage and 4 parameters (query, max_rows, params, url), the description provides no information about any parameters. It doesn't explain what 'params' should contain, what 'url' refers to, or how 'max_rows' affects execution. The description fails to compensate for the complete lack of schema documentation.

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

Purpose4/5

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

The description clearly states the action ('Execute a SQL query') and outcome ('return results in JSONL format'), which is specific and unambiguous. However, it doesn't differentiate itself from sibling tools like 'podbc_query_database' or 'podbc_execute_query_md', which likely have overlapping functionality.

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?

The description provides no guidance on when to use this tool versus alternatives. With multiple sibling tools involving queries (podbc_query_database, podbc_execute_query_md, podbc_sparql_query, etc.), there's no indication of what makes this tool distinct or when it should be preferred over others.

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

podbc_execute_query_mdB

Execute a SQL query and return results in Markdown table format.

ParametersJSON Schema
NameRequiredDescriptionDefault
max_rowsNo
paramsNo
queryYes
urlNo

TDQS

B3/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 the full burden. It mentions execution and output format, but lacks critical behavioral details: it doesn't specify if this is read-only or mutating, potential risks (e.g., data modification), authentication needs, rate limits, or error handling. For a tool with 4 parameters and no annotation coverage, this is a significant gap in 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?

The description is a single, efficient sentence that front-loads the core functionality ('Execute a SQL query') and adds value with the output detail ('in Markdown table format'). There is no wasted wording, making it appropriately sized for its 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?

Given 4 parameters with 0% schema coverage, no annotations, no output schema, and sibling tools with similar names, the description is incomplete. It doesn't explain parameters, behavioral traits, or differentiate from alternatives, making it inadequate for a tool of this complexity. The output format is mentioned, but other critical context is missing.

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%, meaning none of the 4 parameters have descriptions in the schema. The tool description adds no information about parameters like 'query', 'max_rows', 'params', or 'url', failing to compensate for the coverage gap. This leaves parameters largely unexplained beyond their titles and types.

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

Purpose4/5

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

The description clearly states the action ('Execute a SQL query') and the output format ('return results in Markdown table format'), which distinguishes it from siblings like 'podbc_execute_query' that likely return different formats. However, it doesn't explicitly mention what resource it acts on (e.g., a database), making it slightly less specific than a perfect score.

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 queries needing Markdown output, but provides no explicit guidance on when to use this vs. alternatives like 'podbc_execute_query' or other query tools. There's no mention of prerequisites, limitations, or specific scenarios favoring this tool, leaving usage context inferred rather than stated.

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

podbc_filter_table_namesC

Retrieve and return a list containing information about tables whose names contain the substring 'q' in the format [{'schema': 'schema_name', 'table': 'table_name'}, {'schema': 'schema_name', 'table': 'table_name'}].

ParametersJSON Schema
NameRequiredDescriptionDefault
qYes
urlNo

TDQS

C2.9/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 the full burden of behavioral disclosure. It states the tool retrieves and returns a list, implying a read-only operation, but doesn't mention any behavioral traits like performance characteristics, error handling, authentication requirements, or rate limits. The description is minimal and doesn't provide context beyond the basic operation.

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 a single, well-structured sentence that efficiently conveys the core functionality and output format. It's front-loaded with the main purpose and includes specific details about the return format. There's no wasted verbiage, though it could be slightly more concise by omitting the explicit output example if not critical.

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 the tool's moderate complexity (2 parameters, no annotations, no output schema), the description is minimally adequate. It covers the purpose and output format but lacks details on parameters, behavioral context, and usage guidelines. The absence of an output schema means the description should ideally explain return values more thoroughly, though it does specify the 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?

The description mentions the 'q' parameter implicitly ('tables whose names contain the substring 'q''), adding semantic meaning that the schema lacks (0% coverage). However, it doesn't explain the 'url' parameter at all, leaving half of the parameters undocumented. The baseline is 3 because the description compensates partially but not fully for the low schema coverage.

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

Purpose4/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: 'Retrieve and return a list containing information about tables whose names contain the substring 'q''. It specifies the verb ('retrieve and return'), resource ('tables'), and filtering criteria ('names contain the substring'). However, it doesn't explicitly differentiate from sibling tools like podbc_get_tables or podbc_get_schemas, which likely have overlapping functionality.

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?

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like podbc_get_tables (which might list all tables without filtering) or podbc_get_schemas (which might list schemas). There's no context about prerequisites, constraints, or typical use cases for substring filtering versus other filtering methods.

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

podbc_get_schemasC

Retrieve and return a list of all schema names from the connected database.

ParametersJSON Schema
NameRequiredDescriptionDefault
urlNo

TDQS

C2.9/5.0
Behavior2/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It states the action but lacks details on permissions, rate limits, error handling, or what 'connected database' entails. This is a significant gap for a tool that interacts with a database, making it inadequate for safe and effective use.

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, efficient sentence that directly states the tool's purpose without any fluff. It's appropriately sized and front-loaded, making it easy to parse quickly.

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 database operations, no annotations, no output schema, and 0% schema description coverage, the description is incomplete. It fails to address critical aspects like return format, error cases, or connection requirements, which are essential for an AI agent to use this tool reliably.

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 information about the single parameter 'url', and schema description coverage is 0%, leaving the parameter undocumented. However, with only one parameter and a baseline of 3 for minimal coverage, the score reflects that the description doesn't compensate but doesn't worsen the gap significantly.

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

Purpose4/5

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

The description clearly states the verb ('Retrieve and return') and resource ('list of all schema names from the connected database'), making the purpose specific and understandable. It doesn't explicitly differentiate from sibling tools like 'podbc_get_tables' or 'podbc_filter_table_names', which might retrieve different database objects, so it misses the highest score.

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. It doesn't mention prerequisites like needing a database connection, nor does it compare to siblings such as 'podbc_get_tables' for table-level retrieval, leaving the agent without context for selection.

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

podbc_get_tablesC

Retrieve and return a list containing information about tables in specified schema, if empty uses connection default

ParametersJSON Schema
NameRequiredDescriptionDefault
SchemaNo
urlNo

TDQS

C2.8/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 the full burden. It mentions the action 'retrieve and return' but doesn't disclose behavioral traits such as read-only vs. destructive nature, authentication requirements, rate limits, error handling, or output format. For a tool with zero annotation coverage, this is a significant gap in 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?

The description is a single, efficient sentence with zero waste. It's front-loaded with the core purpose and includes essential conditional behavior. Every word earns its place, making it highly concise and well-structured.

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 tool's moderate complexity (2 parameters, database interaction), lack of annotations, and no output schema, the description is incomplete. It doesn't cover return values, error cases, or behavioral details needed for safe and effective use. The description should do more to compensate for missing structured data.

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%, so the description must compensate. It implies the 'Schema' parameter's purpose ('specified schema') and default behavior ('if empty uses connection default'), but doesn't explain the 'url' parameter at all. With 2 parameters and incomplete coverage, the description adds only marginal value beyond the bare schema.

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

Purpose4/5

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

The description clearly states the verb 'retrieve and return' and the resource 'list containing information about tables in specified schema'. It distinguishes the scope by mentioning 'if empty uses connection default', which helps differentiate it from siblings like podbc_filter_table_names or podbc_get_schemas. However, it doesn't explicitly contrast with all siblings, keeping it at 4 rather than 5.

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?

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention siblings like podbc_get_schemas for schema listing or podbc_filter_table_names for filtered table names, nor does it specify prerequisites or exclusions. This leaves the agent without context for tool selection.

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

podbc_query_databaseC

Execute a SQL query and return results in JSONL format.

ParametersJSON Schema
NameRequiredDescriptionDefault
queryYes
urlNo

TDQS

C2.8/5.0
Behavior2/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions the action ('Execute a SQL query') and output format ('JSONL format'), but fails to cover critical aspects like whether this is a read-only or write operation, potential side effects (e.g., data modification), error handling, or performance considerations (e.g., query timeouts). For a database query tool, this is a significant gap in 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?

The description is a single, efficient sentence that front-loads the core functionality ('Execute a SQL query') and specifies the output format. There is no wasted language, making it highly concise and well-structured for quick comprehension.

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 a database query tool with no annotations, 2 parameters (one undocumented), and no output schema, the description is incomplete. It omits essential details like the tool's scope (e.g., supported SQL dialects), return value structure beyond 'JSONL format', and error conditions. This leaves the agent with inadequate context for reliable use.

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?

The schema description coverage is 0%, meaning parameters 'query' and 'url' are undocumented in the schema. The description adds minimal value by implying 'query' is a SQL statement, but it doesn't explain the purpose of the 'url' parameter (e.g., database connection string) or provide any syntax examples. This insufficiently compensates for the lack of schema documentation.

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

Purpose4/5

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

The description clearly states the verb ('Execute') and resource ('SQL query') with the specific outcome ('return results in JSONL format'). It distinguishes itself from siblings like 'podbc_describe_table' or 'podbc_get_tables' by focusing on query execution rather than metadata retrieval, though it doesn't explicitly differentiate from 'podbc_execute_query' which has a similar name.

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?

The description provides no guidance on when to use this tool versus alternatives like 'podbc_execute_query' or 'podbc_execute_query_md'. It lacks context about prerequisites, such as whether a database connection is required or how the 'url' parameter relates to usage. This leaves the agent without clear direction for tool selection among siblings.

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

podbc_sparql_funcD

Call ???.

ParametersJSON Schema
NameRequiredDescriptionDefault
api_keyNo
promptYes
urlNo

TDQS

D1.1/5.0
Behavior1/5

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

With no annotations provided, the description carries full burden for behavioral disclosure but provides none. 'Call ???.' gives no indication of whether this is a read/write operation, what permissions might be required, what side effects exist, or how results are returned. This is completely inadequate for a tool with 3 parameters.

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

Conciseness2/5

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

While technically concise with just two words, this represents under-specification rather than effective brevity. The description is too minimal to be useful, and the placeholder '???' suggests it's incomplete rather than intentionally concise.

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

Completeness1/5

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

For a tool with 3 parameters, no annotations, no output schema, and 0% schema description coverage, the description is completely inadequate. It provides no information about purpose, behavior, parameters, or usage context, making it impossible for an agent to understand how to use this tool effectively.

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

Parameters1/5

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

Schema description coverage is 0%, meaning none of the 3 parameters (api_key, prompt, url) have descriptions in the schema. The tool description provides absolutely no information about parameter meanings, formats, or usage, failing completely to compensate for the schema's deficiencies.

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

Purpose1/5

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

The description 'Call ???.' is tautological (restates the name 'podbc_sparql_func' without adding meaningful content) and provides no information about what the tool actually does. It doesn't specify what resource or operation is involved, making it completely unhelpful for understanding the tool's purpose.

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

Usage Guidelines1/5

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

No guidance is provided about when to use this tool versus the 9 sibling tools on the server. The description offers no context about appropriate use cases, prerequisites, or alternatives, leaving the agent with no basis for selection among similar database/query tools.

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

podbc_sparql_queryC

Execute a SPARQL query and return results.

ParametersJSON Schema
NameRequiredDescriptionDefault
formatNojson
queryYes
timeoutNo
urlNo

TDQS

C2.4/5.0
Behavior1/5

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states the basic action and outcome, lacking critical details like error handling, rate limits, authentication needs, or what 'return results' entails (e.g., format, structure). This is inadequate for a tool with no annotation coverage.

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 a single sentence that front-loads the core purpose. There's no wasted text, making it efficient and easy to parse, though this brevity contributes to gaps in other dimensions.

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

Completeness1/5

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

Given the complexity (4 parameters, 0% schema coverage, no output schema, no annotations), the description is severely incomplete. It doesn't explain parameter semantics, behavioral traits, or output details, making it inadequate for effective tool use by an AI agent.

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

Parameters1/5

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

Schema description coverage is 0%, meaning parameters are undocumented in the schema. The description adds no information about parameters like 'query', 'format', 'timeout', or 'url', failing to compensate for the coverage gap. This leaves the agent guessing about parameter meanings and usage.

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

Purpose4/5

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

The description clearly states the action ('Execute a SPARQL query') and outcome ('return results'), which is specific and unambiguous. However, it doesn't differentiate from sibling tools like 'podbc_sparql_func' or 'podbc_spasql_query', which likely have similar purposes, so it misses full sibling distinction.

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?

The description provides no guidance on when to use this tool versus alternatives, such as sibling tools like 'podbc_execute_query' or 'podbc_sparql_func'. There's no mention of context, prerequisites, or exclusions, leaving the agent with minimal usage direction.

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

podbc_spasql_queryC

Execute a SPASQL query and return results.

ParametersJSON Schema
NameRequiredDescriptionDefault
max_rowsNo
queryYes
timeoutNo
urlNo

TDQS

C2.8/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 states the tool executes a query and returns results, but lacks critical behavioral details such as whether it's read-only or destructive, authentication requirements, rate limits, error handling, or what format results are returned in. This is inadequate for a tool with potential data access implications.

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, efficient sentence with no wasted words. It's appropriately sized for a basic tool description and front-loads the core functionality without unnecessary elaboration.

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 4 parameters with 0% schema coverage, no annotations, no output schema, and multiple sibling tools, the description is incomplete. It doesn't provide enough context about behavior, parameters, or usage differentiation to adequately guide an agent in selecting and invoking this tool correctly.

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%, so the description must compensate but adds no parameter information. It doesn't explain what 'query' should contain, what 'max_rows' limits, what 'timeout' controls, or what 'url' specifies. With 4 parameters (1 required) and no schema descriptions, this leaves significant gaps in understanding.

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

Purpose4/5

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

The description clearly states the verb 'Execute' and the resource 'SPASQL query', specifying the action and target. It distinguishes from siblings like 'podbc_sparql_query' by specifying SPASQL rather than SPARQL, but doesn't fully differentiate from other query execution tools like 'podbc_execute_query' or 'podbc_query_database' beyond the query language type.

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. With multiple sibling tools for querying and execution (e.g., podbc_execute_query, podbc_sparql_query, podbc_query_database), the description lacks context about specific use cases, prerequisites, or comparisons to help an agent choose appropriately.

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

podbc_virtuoso_support_aiD

Tool to use the Virtuoso AI support function

ParametersJSON Schema
NameRequiredDescriptionDefault
api_keyNo
promptYes
urlNo

TDQS

D1.3/5.0
Behavior1/5

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

With no annotations provided, the description carries full burden for behavioral disclosure but offers almost none. It doesn't indicate whether this is a read or write operation, what kind of AI support is provided, what the typical response format is, or any limitations. The description is too vague to help an agent understand what behavior to expect when invoking this tool.

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

Conciseness2/5

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

While technically concise (one sentence), this is under-specification rather than effective conciseness. The single sentence 'Tool to use the Virtuoso AI support function' doesn't provide enough information to be useful. Good conciseness balances brevity with completeness - this leans too far toward brevity at the expense of utility.

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

Completeness1/5

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

Given 3 parameters with 0% schema coverage, no annotations, no output schema, and a complex-sounding 'AI support function', the description is completely inadequate. It doesn't explain what the tool does, how to use it, what inputs it expects, or what outputs to anticipate. For a tool that appears to involve AI interaction with a database system, this level of documentation is insufficient.

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

Parameters1/5

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

With 0% schema description coverage and 3 parameters (api_key, prompt, url), the description provides no information about any parameters. It doesn't explain what the 'prompt' parameter should contain, what the 'api_key' is for, or what 'url' refers to. The description fails to compensate for the complete lack of parameter documentation in the schema.

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

Purpose2/5

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

The description 'Tool to use the Virtuoso AI support function' is tautological - it essentially restates the tool name 'podbc_virtuoso_support_ai' with minimal elaboration. While it mentions 'AI support function', it doesn't specify what this function actually does (e.g., answer questions, generate code, troubleshoot). It doesn't distinguish itself from sibling tools like podbc_execute_query or podbc_sparql_query.

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

Usage Guidelines1/5

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

The description provides no guidance on when to use this tool versus alternatives. Given the sibling tools include various database query and schema exploration tools, there's no indication whether this AI support function is for natural language queries, debugging assistance, or something else. No context about appropriate use cases or prerequisites is provided.

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.

  1. 11 tool updatesv1.0.0
    • First observedpodbc_describe_table
    • First observedpodbc_execute_query
    • First observedpodbc_execute_query_md
    • First observedpodbc_filter_table_names
    • First observedpodbc_get_schemas
    • First observedpodbc_get_tables
    • First observedpodbc_query_database
    • First observedpodbc_sparql_func
    • First observedpodbc_sparql_query
    • First observedpodbc_spasql_query
    • First observedpodbc_virtuoso_support_ai
Deploy Server
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

C2.3/5.0

Scored across 11 tools

Disambiguation2/5

Multiple tools have overlapping or unclear purposes, causing confusion. For example, podbc_execute_query and podbc_query_database both execute SQL queries and return results in JSONL format, making them nearly indistinguishable. Additionally, podbc_sparql_func and podbc_virtuoso_support_ai have vague descriptions that don't clearly differentiate their functions from other query tools.

Naming Consistency4/5

The naming follows a consistent prefix pattern (podbc_) and uses snake_case throughout, which is predictable. However, there are minor deviations like podbc_spasql_query (likely a typo for SPARQL) and inconsistent verb usage (e.g., get_schemas vs. filter_table_names), but overall the structure is readable and mostly uniform.

Tool Count4/5

With 11 tools, the count is reasonable for a database interaction server, covering schema exploration, table queries, and specialized functions. It's slightly on the higher side but still manageable, as each tool appears to serve a distinct technical purpose, though some redundancy exists.

Completeness3/5

The toolset covers core database operations like querying, schema retrieval, and table description, but there are notable gaps. For instance, there are no tools for data manipulation (e.g., insert, update, delete) or transaction management, which are essential for a complete SQLAlchemy-like interface. The inclusion of SPARQL and specialized functions adds niche coverage but doesn't fill these basic CRUD gaps.

Maintenance

ActivityInactive
ResponsivenessUnresponsive

Resources

Related MCP Connectors

Related MCP Servers

  • mcp-odbc

    OpenLinkSoftware
    A
    license
    Not graded
    quality
    F
    maintenance
    Provides generic Open Database Connectivity (ODBC) to any Database Management System (DBMS) that's accessible via an ODBC Connector (Driver).
    12
    MIT

  • MCP SQL Server

    steevenmentech
    A
    license
    Not graded
    quality
    D
    maintenance
    Enables interaction with Microsoft SQL Server databases using both SQL Server and Windows Authentication. It supports flexible connection configurations, including read-only modes and encrypted communication for secure data management.
    2,348 npm
    MIT

  • Data Agent Connector

    MagnusS0
    A
    license
    Not graded
    quality
    D
    maintenance
    Enables SQL agents to connect to any SQLAlchemy-supported database via MCP, providing read-only SQL querying, automatic table summarization, and column content search.
    4
    Apache 2.0

Appeared in Searches