Skip to main content
Glama
deenesjakoruzh
spences10

mcp-turso-cloud

by spences10
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

mcp-turso-云

模型上下文协议 (MCP) 服务器，为 LLM 提供与 Turso 数据库的集成。该服务器实现了两级身份验证系统，可同时处理组织级和数据库级操作，从而可以轻松地直接从 LLM 管理和查询 Turso 数据库。

特征

🏢 组织级运营

  • 列出数据库：查看 Turso 组织中的所有数据库

  • 创建数据库：使用可自定义的选项创建新的数据库

  • 删除数据库：从您的组织中删除数据库

  • 生成数据库令牌：为特定数据库创建身份验证令牌

💾 数据库级操作

  • 列出表：查看特定数据库中的所有表

  • 执行只读查询：运行 SELECT 和 PRAGMA 查询（只读操作）

  • 执行查询：运行可能具有破坏性的 SQL 查询（INSERT、UPDATE、DELETE 等）

  • 描述表：获取数据库表的架构信息

  • 向量搜索：使用 SQLite 向量扩展执行向量相似性搜索

Related MCP server: Supabase MCP Server

⚠️ 重要：查询执行安全性 ⚠️

该服务器实现了只读和破坏性数据库操作之间的以安全性为中心的分离：

  • 使用execute_read_only_query进行SELECT和PRAGMA查询（安全的只读操作）

  • 使用execute_query进行INSERT、UPDATE、DELETE、CREATE、DROP和其他修改数据的操作

这种分离允许不同的权限级别和批准要求：

  • 在许多情况下，只读操作可以自动批准

  • 破坏性操作可能需要明确的安全批准

**在批准 SQL 查询之前，务必仔细阅读并审核！**这对于可能修改或删除数据的破坏性操作尤其重要。在允许执行每个查询之前，请花时间了解其作用。

两级认证系统

服务器实现了复杂的身份验证系统：

  1. 组织级身份验证

    • 使用 Turso 平台 API 令牌

    • 管理数据库和组织级操作

    • 通过 Turso 仪表板获取

  2. 数据库级身份验证

    • 使用数据库特定的令牌

    • 使用组织令牌自动生成

    • 缓存以提高性能并根据需要轮换

配置

此服务器需要通过您的 MCP 客户端进行配置。以下是不同环境下的示例：

Cline/Claude 桌面配置

将其添加到您的 Cline/Claude Desktop MCP 设置中：

{
	"mcpServers": {
		"mcp-turso-cloud": {
			"command": "npx",
			"args": ["-y", "mcp-turso-cloud"],
			"env": {
				"TURSO_API_TOKEN": "your-turso-api-token",
				"TURSO_ORGANIZATION": "your-organization-name",
				"TURSO_DEFAULT_DATABASE": "optional-default-database"
			}
		}
	}
}

带有 WSL 配置的 Claude 桌面

对于 WSL 环境，将其添加到您的 Claude Desktop 配置中：

{
	"mcpServers": {
		"mcp-turso-cloud": {
			"command": "wsl.exe",
			"args": [
				"bash",
				"-c",
				"TURSO_API_TOKEN=your-token TURSO_ORGANIZATION=your-org node /path/to/mcp-turso-cloud/dist/index.js"
			]
		}
	}
}

环境变量

服务器需要以下环境变量：

  • TURSO_API_TOKEN ：您的 Turso 平台 API 令牌（必需）

  • TURSO_ORGANIZATION ：您的 Turso 组织名称（必填）

  • TURSO_DEFAULT_DATABASE ：未指定时使用的默认数据库（可选）

  • TOKEN_EXPIRATION ：生成的数据库令牌的到期时间（可选，默认值：'7d'）

  • TOKEN_PERMISSION ：生成令牌的权限级别（可选，默认值：“完全访问”）

API

服务器实现按类别组织的 MCP 工具：

组织工具

列出数据库

列出 Turso 组织中的所有数据库。

参数：无

响应示例：

{
	"databases": [
		{
			"name": "customer_db",
			"id": "abc123",
			"region": "us-east",
			"created_at": "2023-01-15T12:00:00Z"
		},
		{
			"name": "product_db",
			"id": "def456",
			"region": "eu-west",
			"created_at": "2023-02-20T15:30:00Z"
		}
	]
}

创建数据库

在您的组织中创建一个新的数据库。

参数：

  • name （字符串，必需）：新数据库的名称

  • group （字符串，可选）：将数据库分配到的组

  • regions （string[]，可选）：部署数据库的区域

例子：

{
	"name": "analytics_db",
	"group": "production",
	"regions": ["us-east", "eu-west"]
}

删除数据库

从您的组织中删除数据库。

参数：

  • name （字符串，必需）：要删除的数据库的名称

例子：

{
	"name": "test_db"
}

生成数据库令牌

为特定数据库生成新令牌。

参数：

  • database （字符串，必需）：数据库名称

  • expiration （字符串，可选）：令牌到期时间

  • permission （字符串，可选）：权限级别（“完全访问”或“只读”）

例子：

{
	"database": "customer_db",
	"expiration": "30d",
	"permission": "read-only"
}

数据库工具

列表表

列出数据库中的所有表。

参数：

  • database （字符串，可选）：数据库名称（如果未提供，则使用上下文）

例子：

{
	"database": "customer_db"
}

执行只读查询

对数据库执行只读 SQL 查询（SELECT、PRAGMA）。

参数：

  • query （字符串，必需）：要执行的 SQL 查询（必须是 SELECT 或 PRAGMA）

  • params （对象，可选）：查询参数

  • database （字符串，可选）：数据库名称（如果未提供，则使用上下文）

例子：

{
	"query": "SELECT * FROM users WHERE age > ?",
	"params": { "1": 21 },
	"database": "customer_db"
}

执行查询

对数据库执行具有潜在破坏性的 SQL 查询（INSERT、UPDATE、DELETE、CREATE 等）。

参数：

  • query （字符串，必需）：要执行的 SQL 查询（不能是 SELECT 或 PRAGMA）

  • params （对象，可选）：查询参数

  • database （字符串，可选）：数据库名称（如果未提供，则使用上下文）

例子：

{
	"query": "INSERT INTO users (name, age) VALUES (?, ?)",
	"params": { "1": "Alice", "2": 30 },
	"database": "customer_db"
}

描述表

获取表的架构信息。

参数：

  • table （字符串，必需）：表名称

  • database （字符串，可选）：数据库名称（如果未提供，则使用上下文）

例子：

{
	"table": "users",
	"database": "customer_db"
}

向量搜索

使用 SQLite 矢量扩展执行矢量相似性搜索。

参数：

  • table （字符串，必需）：表名称

  • vector_column （字符串，必需）：包含矢量的列

  • query_vector (number[]，必需)：用于相似性搜索的查询向量

  • limit （数字，可选）：最大结果数（默认值：10）

  • database （字符串，可选）：数据库名称（如果未提供，则使用上下文）

例子：

{
	"table": "embeddings",
	"vector_column": "embedding",
	"query_vector": [0.1, 0.2, 0.3, 0.4],
	"limit": 5,
	"database": "vector_db"
}

发展

设置

  1. 克隆存储库

  2. 安装依赖项：

npm install

  1. 构建项目：

npm run build

  1. 以开发模式运行：

npm run dev

出版

  1. 更新 package.json 中的版本

  2. 构建项目：

npm run build

  1. 发布到 npm：

npm publish

故障排除

API 令牌问题

如果遇到身份验证错误：

  1. 验证您的 Turso API 令牌是否有效并具有必要的权限

  2. 检查您的组织名称是否正确

  3. 确保您的令牌尚未过期

数据库连接问题

如果您在连接数据库时遇到问题：

  1. 验证数据库是否存在于您的组织中

  2. 检查你的 API 令牌是否可以访问数据库

  3. 确保数据库名称拼写正确

贡献

欢迎贡献代码！欢迎提交 Pull 请求。

执照

MIT 许可证 - 有关详细信息，请参阅LICENSE文件。

致谢

构建于：

Available Tools

9 tools
create_database✓ SAFE: Create a new database in your Turso organization. Database name must be unique.C

✓ SAFE: Create a new database in your Turso organization. Database name must be unique.

ParametersJSON Schema
NameRequiredDescriptionDefault
nameYesName of the database to create - Must be unique within organization
groupNoOptional group name for the database (defaults to "default")
regionsNoOptional list of regions to deploy the database to (affects latency and compliance)

TDQS

C2.4/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 'SAFE' but does not explain any behavioral traits such as mutability, error handling, permissions, or idempotency. The unique name constraint is the only behavioral hint.

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 extremely concise with a single sentence that conveys the core purpose. However, it is identical to the title, which could be seen as redundant.

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 no output schema, no annotations, and 3 parameters, the description should provide more context about return values or side effects. It does not address what happens after creation or any error conditions.

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

Parameters3/5

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

The input schema has 100% description coverage, so baseline is 3. The description adds the unique name constraint, which is already in the schema description. No additional context is provided for 'group' or 'regions' parameters.

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?

Tautological: description restates name/title.

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, nor does it mention prerequisites or when not to use it. It simply states what it does.

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

delete_database⚠️ DESTRUCTIVE: Permanently deletes a database and ALL its data. Cannot be undone. Always confirm with user before proceeding and verify correct database name.B

⚠️ DESTRUCTIVE: Permanently deletes a database and ALL its data. Cannot be undone. Always confirm with user before proceeding and verify correct database name.

ParametersJSON Schema
NameRequiredDescriptionDefault
nameYesName of the database to permanently delete - WARNING: ALL DATA WILL BE LOST FOREVER

TDQS

B3.3/5.0
Behavior4/5

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

With no annotations, the description carries the full burden. It explicitly states the destructive and irreversible nature: 'Permanently deletes' and 'Cannot be undone.' This sufficiently discloses the critical behavior, though it omits details like permissions or error handling. The warning about confirmation adds transparency.

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 sentence that is repeated from the title, which is concise but slightly redundant. It is front-loaded with a warning. While efficient, it could be more structured (e.g., separate into purpose and caution). Loses a point for repetition.

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 no output schema, the description should clarify what the tool returns (e.g., success confirmation). It lacks details on return value, error states, or post-deletion effects. For a destructive tool with a simple interface, it is moderately complete but could be improved.

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

Parameters3/5

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

Schema description coverage is 100%. The parameter description 'Name of the database to permanently delete - WARNING: ALL DATA WILL BE LOST FOREVER' adds emphasis but does not provide additional semantic meaning beyond the schema. Baseline 3 is appropriate.

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?

Tautological: description restates name/title.

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?

The description provides a strong usage guideline: 'Always confirm with user before proceeding and verify correct database name.' This directs the agent to take caution but does not explicitly state when to avoid using the tool or mention alternatives. The context of sibling tools implies it is only for deletion, so the guideline is clear but not comprehensive.

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

describe_tableGets schema information for a tableC

Gets schema information for a table

ParametersJSON Schema
NameRequiredDescriptionDefault
tableYesTable name
databaseNoDatabase name (optional, uses context if not provided)

TDQS

C2.4/5.0
Behavior2/5

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

Without annotations, the description carries the full burden of behavioral disclosure. It implies a read-only operation by using 'Gets', but it does not explicitly state that the tool is non-destructive, requires no special permissions, or has any side effects.

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 sentence with one verb and one phrase, making it very concise. It front-loads the purpose without extraneous information, though it could be slightly expanded to include behavioral 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?

Given the absence of an output schema and annotations, the description should compensate by explaining what the schema information includes (e.g., columns, types, constraints). It does not, leaving the agent to guess the return format, which is inadequate for effective tool selection.

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

Parameters3/5

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

The input schema covers 100% of parameters with descriptions, so the schema provides the necessary meaning. The description adds no extra information about parameters beyond what is already in the schema, which meets the baseline for this dimension.

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?

Tautological: description restates name/title.

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, nor does it mention prerequisites or exclusions. It only states what the tool does, leaving the agent to infer usage context from the tool name and sibling list.

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

execute_query⚠️ DESTRUCTIVE: Execute SQL that can modify/delete data (INSERT, UPDATE, DELETE, DROP, ALTER). Always confirm with user before destructive operations.C

⚠️ DESTRUCTIVE: Execute SQL that can modify/delete data (INSERT, UPDATE, DELETE, DROP, ALTER). Always confirm with user before destructive operations.

ParametersJSON Schema
NameRequiredDescriptionDefault
queryYesSQL query to execute
paramsNoQuery parameters (optional) - Use parameterized queries for security
databaseNoDatabase name (optional, uses context if not provided)

TDQS

C2.4/5.0
Behavior3/5

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

The description discloses that the tool is destructive and can modify/delete data, which is critical behavioral information. Without annotations, this is the primary disclosure, but it lacks further details on side effects, permissions, or error handling.

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

Conciseness3/5

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

The description is very short and gets to the point, but it is a verbatim repeat of the title, making it redundant. It is concise but not optimally structured as it wastes space.

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 destructive SQL execution tool with no output schema and no annotations, the description is too sparse. It does not explain return values, error behavior, or execution context, leaving significant gaps for an AI agent.

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

Parameters3/5

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

The input schema has 100% description coverage with clear descriptions for each parameter. The tool description does not add any parameter-specific meaning, so the schema handles this dimension adequately.

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?

Tautological: description restates name/title.

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 mentions confirming with the user before destructive operations, which is a useful guideline. However, it does not explicitly differentiate from the sibling 'execute_read_only_query' or state when not to use this tool.

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

execute_read_only_query✓ SAFE: Execute read-only SQL queries (SELECT, PRAGMA, EXPLAIN). Automatically rejects write operations.B

✓ SAFE: Execute read-only SQL queries (SELECT, PRAGMA, EXPLAIN). Automatically rejects write operations.

ParametersJSON Schema
NameRequiredDescriptionDefault
queryYesRead-only SQL query to execute (SELECT, PRAGMA, EXPLAIN only)
paramsNoQuery parameters (optional) - Use parameterized queries for security
databaseNoDatabase name (optional, uses context if not provided) - Specify target database

TDQS

B3.4/5.0
Behavior4/5

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

The description discloses the key behavioral trait of rejecting write operations, which is crucial for safety. No annotations are present, so the description carries the full burden. It does not cover error handling or performance.

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 sentence, identical to the title, which is very concise. However, the repetition could be better utilized to add extra detail.

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?

For a simple read-only query tool, the description adequately covers purpose and safety. Absence of output schema or annotation is mitigated by the clear statement of behavior, though error handling could be mentioned.

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

Parameters3/5

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

Schema coverage is 100% with detailed parameter descriptions. The tool description adds no additional meaning beyond the schema, so baseline 3 is appropriate.

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?

Tautological: description restates name/title.

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?

The description provides clear guidance to use this tool for read-only queries and highlights its automatic rejection of writes, but does not explicitly mention alternative tools or when not to use it.

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

generate_database_tokenGenerate a new token for a specific databaseC

Generate a new token for a specific database

ParametersJSON Schema
NameRequiredDescriptionDefault
databaseYesName of the database to generate a token for
permissionNoPermission level for the token

TDQS

C2.3/5.0
Behavior2/5

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

With no annotations, the description carries full burden but only states that a token is generated. It fails to disclose behavioral traits such as whether the token is immediately valid, if it overrides existing tokens, or if special permissions are required. The lack of side-effect information 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.

Conciseness3/5

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

The description is a single sentence, making it concise, but it is too brief and lacks substantive content. While not verbose, it sacrifices clarity for brevity. A slightly longer description with key details would improve understandability without being wasteful.

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 simplicity (2 parameters, no nested objects) and absence of annotations or output schema, the description is incomplete. It does not mention what the tool returns (e.g., the token string), any side effects, or potential errors. The description alone is insufficient for an agent to use the tool safely.

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

Parameters3/5

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

The input schema covers 100% of parameters with descriptions, so the description adds minimal extra meaning. The baseline is 3. The description does not elaborate on the 'permission' enum values or the format of the 'database' name, but the schema is already clear.

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?

Tautological: description restates name/title.

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, prerequisites, or situations where it should not be used. The description lacks any context about the tool's intended use case or limitations.

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

list_databasesList all databases in your Turso organizationA

List all databases in your Turso organization

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

A3.5/5.0
Behavior3/5

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

With no annotations, the description carries the burden of behavioral disclosure. It implies a read-only, safe operation, but does not explicitly state that it does not modify state or require special permissions. Adequate for a simple list, but lacks explicit disclaimers.

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

Conciseness5/5

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

The description is a single sentence of 9 words, perfectly concise with no wasted words. It delivers the essential information efficiently.

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 output schema, and a straightforward listing operation), the description provides complete context for an agent to understand its purpose and invocation.

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?

The input schema has 0 parameters, so the description does not need to explain parameters. Baseline for 0 parameters is 4, and it meets that without adding unnecessary detail.

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?

Tautological: description restates name/title.

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?

The description implicitly indicates when to use the tool: when you need to see all databases. It does not explicitly state when not to use it or provide alternatives, but for a simple list operation, no further guidance is necessary.

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

list_tablesLists all tables in a databaseC

Lists all tables in a database

ParametersJSON Schema
NameRequiredDescriptionDefault
databaseNoDatabase name (optional, uses context if not provided)

TDQS

C2.8/5.0
Behavior3/5

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

With no annotations, the description carries the full burden. It states the tool lists tables, implying a read-only operation, but does not disclose if it returns names only, includes system tables, or requires specific permissions. The behavior is minimally transparent.

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, clear sentence with no redundancy. Every word contributes to the purpose.

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?

For a simple list tool with one optional parameter and no output schema, the description is adequate but lacks details on return format, ordering, or limitations (e.g., whether all tables include temporary tables). Some gaps remain.

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

Parameters3/5

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

The input schema already describes the database parameter as optional and context-dependent. The description adds no further meaning beyond 'database', so baseline score of 3 applies (schema coverage is 100%).

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?

Tautological: description restates name/title.

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 (e.g., describe_table for a single table, list_databases to enumerate databases). There is no mention of prerequisites or context.

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. 9 tool updatesv0.0.2
    • Changedcreate_database5 fields changed
      • addedInput schema / $schema
        Added value: +"http://json-schema.org/draft-07/schema#"
      • addedInput schema / additionalProperties
        Added value: +false
      • changedInput schema / properties / group / description
        Previous value: -"Optional group name for the database"New value: +"Optional group name for the database (defaults to \"default\")"
      • changedInput schema / properties / name / description
        Previous value: -"Name of the database to create"New value: +"Name of the database to create - Must be unique within organization"
      • changedInput schema / properties / regions / description
        Previous value: -"Optional list of regions to deploy the database to"New value: +"Optional list of regions to deploy the database to (affects latency and compliance)"
    • Changeddelete_database3 fields changed
      • addedInput schema / $schema
        Added value: +"http://json-schema.org/draft-07/schema#"
      • addedInput schema / additionalProperties
        Added value: +false
      • changedInput schema / properties / name / description
        Previous value: -"Name of the database to delete"New value: +"Name of the database to permanently delete - WARNING: ALL DATA WILL BE LOST FOREVER"
    • Changeddescribe_table2 fields changed
      • addedInput schema / $schema
        Added value: +"http://json-schema.org/draft-07/schema#"
      • addedInput schema / additionalProperties
        Added value: +false
    • Changedexecute_query5 fields changed
      • addedInput schema / $schema
        Added value: +"http://json-schema.org/draft-07/schema#"
      • addedInput schema / additionalProperties
        Added value: +false
      • addedInput schema / properties / params / additionalProperties
        Added value: +{}
      • changedInput schema / properties / params / description
        Previous value: -"Query parameters (optional)"New value: +"Query parameters (optional) - Use parameterized queries for security"
      • addedInput schema / properties / params / propertyNames
        Added value: +{
+  "type": "string"
+}
    • Addedexecute_read_only_query
    • Changedgenerate_database_token2 fields changed
      • addedInput schema / $schema
        Added value: +"http://json-schema.org/draft-07/schema#"
      • addedInput schema / additionalProperties
        Added value: +false
    • Changedlist_databases3 fields changed
      • addedInput schema / $schema
        Added value: +"http://json-schema.org/draft-07/schema#"
      • addedInput schema / additionalProperties
        Added value: +false
      • removedInput schema / required
        Removed value: -[]
    • Changedlist_tables3 fields changed
      • addedInput schema / $schema
        Added value: +"http://json-schema.org/draft-07/schema#"
      • addedInput schema / additionalProperties
        Added value: +false
      • removedInput schema / required
        Removed value: -[]
    • Changedvector_search2 fields changed
      • addedInput schema / $schema
        Added value: +"http://json-schema.org/draft-07/schema#"
      • addedInput schema / additionalProperties
        Added value: +false
  2. 8 tool updatesv1.0.0
    • First observedcreate_database
    • First observeddelete_database
    • First observeddescribe_table
    • First observedexecute_query
    • First observedgenerate_database_token
    • First observedlist_databases
    • First observedlist_tables
    • First observedvector_search
Deploy Server
Shareable, User-Owned Context BackendPeople, applications, and agents read, write, and coordinate together in one context lake. Reach it over MCP, a CLI, a Python SDK, or REST.fulcradynamics.comAd

TDQS

B3.1/5.0

Scored across 9 tools

Disambiguation5/5

Each tool has a clearly distinct purpose: database CRUD, querying (read-only vs. destructive), schema inspection, token generation, listing resources, and vector search. No overlap or ambiguity.

Naming Consistency5/5

All tools follow a consistent verb_noun pattern in snake_case (e.g., create_database, execute_query, list_tables), making the set predictable and easy to navigate.

Tool Count5/5

9 tools is well-scoped for a cloud database service covering management, querying, schema, tokens, and vector search. No unnecessary tools and no deficit.

Completeness4/5

Core operations are covered (CRUD for databases, query execution, schema inspection, token generation). Minor gaps like listing or revoking tokens exist, but the surface is mostly complete for typical workflows.

Maintenance

ActivityMaintained
ResponsivenessUnresponsive

Resources

Related MCP Connectors

Related MCP Servers

  • MCP-Turso

    nbbaier
    A
    license
    A
    quality
    C
    maintenance
    A Model Context Protocol server that provides Claude access to Turso-hosted LibSQL databases, enabling database table listing, schema retrieval, and SELECT query execution.
    4
    47 npm
    6
    MIT

  • Supabase MCP Server

    Cappahccino
    A
    license
    Not graded
    quality
    D
    maintenance
    A Model Context Protocol server that enables Claude and other LLMs to perform database operations and invoke Edge Functions within Supabase through natural language.
    802 npm
    4
    MIT

  • @pilat/mcp-datalink

    pilat
    A
    license
    Not graded
    quality
    D
    maintenance
    MCP server for PostgreSQL, MySQL, and SQLite that gives AI assistants secure database access via the Model Context Protocol.
    55 npm
    5
    MIT

  • mcp-turso-cloud

    diegofornalha
    A
    license
    Not graded
    quality
    D
    maintenance
    An MCP server that integrates Turso databases with LLMs, supporting organization and database-level operations with two-level authentication.
    MIT

Appeared in Searches