de en es ja ko ru zh

mcp-turso-cloud

Name: mcp-turso-cloud
Author: spences10

by spences10

Overview Schema Source Related Servers Discussions Admin

TypeScript

Remote

mcp-turso-cloud

LLM을 위한 Turso 데이터베이스와의 통합을 제공하는 모델 컨텍스트 프로토콜(MCP) 서버입니다. 이 서버는 조직 수준 및 데이터베이스 수준 작업을 모두 처리하는 2단계 인증 시스템을 구현하여 LLM에서 직접 Turso 데이터베이스를 쉽게 관리하고 쿼리할 수 있도록 합니다.

특징

🏢 조직 수준 운영

데이터베이스 목록 : Turso 조직의 모든 데이터베이스를 확인하세요.
데이터베이스 생성 : 사용자 정의 가능한 옵션으로 새 데이터베이스를 생성합니다.
데이터베이스 삭제 : 조직에서 데이터베이스를 제거합니다.
데이터베이스 토큰 생성 : 특정 데이터베이스에 대한 인증 토큰을 생성합니다.

💾 데이터베이스 수준 작업

테이블 목록 : 특정 데이터베이스의 모든 테이블 보기
읽기 전용 쿼리 실행 : SELECT 및 PRAGMA 쿼리(읽기 전용 작업)를 실행합니다.
쿼리 실행 : 잠재적으로 파괴적인 SQL 쿼리(INSERT, UPDATE, DELETE 등)를 실행합니다.
테이블 설명 : 데이터베이스 테이블에 대한 스키마 정보 가져오기
벡터 검색 : SQLite 벡터 확장을 사용하여 벡터 유사성 검색을 수행합니다.

Related MCP server: Supabase MCP Server

⚠️ 중요: 쿼리 실행 보안 ⚠️

이 서버는 읽기 전용 데이터베이스 작업과 파괴적 데이터베이스 작업 간에 보안 중심 분리를 구현합니다.

SELECT 및 PRAGMA 쿼리(안전하고 읽기 전용 작업)에 대해 execute_read_only_query 사용합니다.
데이터를 수정하는 INSERT, UPDATE, DELETE, CREATE, DROP 및 기타 작업에 대해 execute_query 사용하세요.

이러한 분리를 통해 다양한 권한 수준과 승인 요구 사항이 허용됩니다.

읽기 전용 작업은 여러 컨텍스트에서 자동 승인될 수 있습니다.
파괴적인 작업에는 안전을 위한 명시적인 승인이 필요할 수 있습니다.

SQL 쿼리를 승인하기 전에 항상 주의 깊게 읽고 검토하세요! 이는 특히 데이터를 수정하거나 삭제할 수 있는 파괴적인 작업의 경우 매우 중요합니다. 각 쿼리가 어떤 작업을 하는지 충분히 이해한 후 실행을 허용하세요.

2단계 인증 시스템

서버는 정교한 인증 시스템을 구현합니다.

조직 수준 인증
- Turso 플랫폼 API 토큰을 사용합니다.
- 데이터베이스와 조직 수준의 운영을 관리합니다.
- Turso 대시보드를 통해 획득
데이터베이스 수준 인증
- 데이터베이스별 토큰을 사용합니다
- 조직 토큰을 사용하여 자동 생성됨
- 성능을 위해 캐시되고 필요에 따라 회전됨

구성

이 서버를 사용하려면 MCP 클라이언트를 통한 구성이 필요합니다. 다음은 다양한 환경에 대한 예시입니다.

클라인/클로드 데스크톱 구성

Cline/Claude Desktop MCP 설정에 다음을 추가하세요.

지엑스피1

WSL 구성을 사용한 Claude Desktop

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 : 생성된 토큰에 대한 권한 수준(선택 사항, 기본값: 'full-access')

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 (문자열[], 선택 사항): 데이터베이스를 배포할 지역

예:

{
	"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 (숫자[], 필수): 유사성 검색을 위한 쿼리 벡터
limit (숫자, 선택 사항): 최대 결과 수(기본값: 10)
database (문자열, 선택 사항): 데이터베이스 이름(제공되지 않으면 컨텍스트 사용)

예:

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

개발

설정

저장소를 복제합니다
종속성 설치:

npm install

프로젝트를 빌드하세요:

npm run build

개발 모드에서 실행:

npm run dev

출판

package.json의 버전 업데이트
프로젝트를 빌드하세요:

npm run build

npm에 게시:

npm publish

문제 해결

API 토큰 문제

인증 오류가 발생하는 경우:

Turso API 토큰이 유효하고 필요한 권한이 있는지 확인하세요.
귀하의 조직 이름이 올바른지 확인하세요
토큰이 만료되지 않았는지 확인하세요

데이터베이스 연결 문제

데이터베이스에 연결하는 데 문제가 있는 경우:

조직에 데이터베이스가 있는지 확인하세요
API 토큰이 데이터베이스에 액세스할 수 있는지 확인하세요.
데이터베이스 이름이 올바르게 입력되었는지 확인하세요.

기여하다

기여를 환영합니다! 풀 리퀘스트를 제출해 주세요.

특허

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.

Name	Required	Description
`name`	Yes	Name of the database to create - Must be unique within organization
`group`	No	Optional group name for the database (defaults to "default")
`regions`	No	Optional 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.

Name	Required	Description	Default
`name`	Yes	Name 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

Name	Required	Description	Default
`table`	Yes	Table name
`database`	No	Database 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.

Name	Required	Description
`query`	Yes	SQL query to execute
`params`	No	Query parameters (optional) - Use parameterized queries for security
`database`	No	Database 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.

Name	Required	Description
`query`	Yes	Read-only SQL query to execute (SELECT, PRAGMA, EXPLAIN only)
`params`	No	Query parameters (optional) - Use parameterized queries for security
`database`	No	Database 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

Name	Required	Description	Default
`database`	Yes	Name of the database to generate a token for
`permission`	No	Permission 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

Name	Required	Description	Default
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

Name	Required	Description	Default
`database`	No	Database 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.

vector_searchPerforms vector similarity searchD

Performs vector similarity search

Name	Required	Description
`table`	Yes	Table name
`vector_column`	Yes	Column containing vectors
`query_vector`	Yes	Query vector for similarity search
`limit`	No	Maximum number of results (optional, default 10)
`database`	No	Database name (optional, uses context if not provided)

TDQS

D1.6/5.0

Behavior1/5

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

No annotations are provided, and the description contains no behavioral traits such as read-only nature, authentication requirements, or side effects. It completely lacks transparency.

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?

The description is one short sentence, but it is under-specified. It fails to convey essential information, making it too brief to be useful.

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?

With 5 parameters and no output schema, the description should explain the tool's behavior and return values. It provides none of these, making it severely incomplete.

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%, so the baseline is 3. The description adds no additional meaning beyond what the schema already provides, so no improvement.

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?

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 offers no guidance on when to use this tool versus its siblings (e.g., execute_query, list_tables). It fails to specify contexts or alternatives.

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.

9 tool updatesv0.0.2May 6, 2026

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

8 tool updatesv1.0.0Mar 20, 2025
- 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 2026-05-06 12:10 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

hithereiamaliff-mcp-nextcloud
ai.smithery
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
Cloud Storage File Systems Workplace & Productivity
238
https://server.smithery.ai/@hithereiamaliff/mcp-nextcloud/mcp
AI2SQL
io.ai2sql
Text-to-SQL MCP server: read-only queries on PostgreSQL, MySQL and SQL Server with your real schema
Databases Developer Tools
1
https://builder.ai2sql.io/api/chatgpt-mcp
Supabase
com.supabase
MCP server for interacting with the Supabase platform
Cloud Platforms Databases Developer Tools
32,990
https://mcp.supabase.com/mcp
mcp A
io.github.butterbase-ai
Butterbase MCP server — manage your backend: schemas, auth, functions, storage, RAG, deploys.
Databases RAG Systems Cloud Platforms
23,034
https://api.butterbase.ai/mcp

Related MCP Servers

MCP-Turso
Databases RAG Systems
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.
Updated a year ago (2025-11-03 02:36 UTC)
4
24 npm
6
MIT
Supabase MCP Server
Databases Code Execution RAG Systems
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.
Updated 2 years ago (2025-03-21 20:13 UTC)
980 npm
4
MIT
@pilat/mcp-datalink
Databases Developer Tools
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.
Updated 3 days ago (2026-11-02 02:13 UTC)
48 npm
5
MIT
mcp-turso-cloud
Databases Vector Databases
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.
Updated a year ago (2025-08-02 10:27 UTC)
MIT

Appeared in Searches

Information about 'dex' or related topics