데이터를 위한 안전한 정박지 -- AI 도구를 위한 데이터베이스 액세스.
Berth는 AI 어시스턴트에게 PostgreSQL, SQLite 및 MySQL 데이터베이스에 대한 안전하고 구조화된 액세스 권한을 제공하는 Model Context Protocol 서버입니다. 스키마 검사, 쿼리 실행, 데이터 관리, 마이그레이션 생성 및 백업 수행을 위한 13가지 도구를 제공하며, 이 모든 것은 실수로 인한 손상을 방지하는 3단계 안전 모델에 의해 관리됩니다.
Berth는 허용되는 SQL을 제어하는 세 가지 운영 모드를 적용합니다:
모드 | 기본값 | 허용 | 차단 |
read-only | 예 |
| 모든 쓰기 |
write | 아니요 |
|
|
admin | 아니요 | 모든 작업 | 파괴적인 작업은 확인 토큰(60초 만료) 필요 |
서버는 read-only 모드로 시작합니다. 쓰기 및 관리자 모드는 명시적으로 활성화해야 합니다. 관리자 모드에서의 파괴적인 작업은 60초 후에 만료되는 일회성 확인 토큰을 생성하며, AI는 의도를 확인하기 위해 토큰을 다시 입력해야 합니다.
Related MCP server: MCP SQL Server
도구 | 설명 | 주요 매개변수 |
| 서버 상태 확인 | -- |
| 데이터베이스 연결 |
|
| SELECT 쿼리 실행 (자동으로 LIMIT 1000 추가) |
|
| INSERT/UPDATE/DELETE 실행 (안전 모드 준수) |
|
| 테이블, 뷰 및 인덱스 나열 |
|
| 테이블의 컬럼 세부 정보 |
|
| 외래 키 관계 |
|
| 데이터베이스 및 테이블 크기 |
|
| 현재 실행 중인 쿼리 (PostgreSQL 전용) |
|
| 쿼리에 대해 EXPLAIN ANALYZE 실행 |
|
| 스키마 비교를 통해 마이그레이션 SQL 생성 |
|
| 데이터베이스 백업 생성 |
|
| 백업에서 복원 (관리자 모드 + 확인 토큰) |
|
generate_migration 도구는 두 스키마를 비교하여 하나에서 다른 하나로 마이그레이션하기 위한 다이얼렉트 인식 SQL을 생성합니다. 두 가지 운영 모드가 있습니다:
모드 1 — 라이브 데이터베이스 vs. 대상 DDL:
connection_id(활성 연결)와 target_sql(원하는 스키마를 설명하는 CREATE TABLE 문)을 제공합니다. Berth는 라이브 데이터베이스를 내부적으로 검사하고 파싱된 대상과 비교합니다.
모드 2 — 두 개의 라이브 데이터베이스:
from_connection과 to_connection(두 개의 활성 연결 ID)을 제공합니다. Berth는 둘 다 내부적으로 검사하고 소스를 대상으로 변환하기 위한 마이그레이션을 생성합니다.
생성 내용:
새 테이블에 대한 CREATE TABLE
새 컬럼에 대한 ALTER TABLE ADD COLUMN
유형, null 허용 여부 및 기본값 변경을 위한 ALTER TABLE ALTER COLUMN / MODIFY COLUMN
인덱스 변경을 위한 CREATE INDEX / DROP INDEX
외래 키 변경을 위한 ADD CONSTRAINT / DROP CONSTRAINT
DROP TABLE 및 DROP COLUMN은 경고와 함께 주석 처리됨 (안전 우선)
다이얼렉트 처리:
PostgreSQL -- ALTER COLUMN ... TYPE, SET/DROP NOT NULL, SET/DROP DEFAULT 사용
MySQL -- 모든 컬럼 변경에 MODIFY COLUMN, DROP INDEX ... ON table 사용
SQLite -- 지원되지 않는 작업에 대해 경고하고, 이를 필요로 하는 변경 사항(ALTER COLUMN, 이전 버전에서의 DROP COLUMN, 제약 조건 변경)에 대해 테이블 재구축 패턴을 포함함
PostgreSQL -- pg_stat_activity, EXPLAIN ANALYZE, pg_dump/psql 백업/복원을 포함한 전체 지원
SQLite -- PRAGMA 내부 검사, sqlite3 CLI를 통한 .backup/.restore를 포함한 전체 지원
MySQL -- information_schema 내부 검사, mysqldump/mysql 백업/복원을 포함한 전체 지원
PyPI에서:
pip install berth-mcp또는 격리된 환경에서:
pipx install berth-mcpMySQL 지원은 선택적 종속성이 필요합니다:
pip install berth-mcp[mysql]PostgreSQL(asyncpg) 및 SQLite(aiosqlite) 드라이버는 기본적으로 포함되어 있습니다.
서버 실행:
berthBerth는 MCP 프로토콜을 사용하여 stdio를 통해 통신합니다. 독립 실행형이 아닌 MCP 클라이언트에 의해 실행되도록 설계되었습니다.
claude mcp add berth -- berthclaude_desktop_config.json에 추가:
{
"mcpServers": {
"berth": {
"command": "berth",
"args": []
}
}
}가상 환경에 설치된 경우 전체 경로를 사용하세요:
{
"mcpServers": {
"berth": {
"command": "/path/to/venv/bin/berth",
"args": []
}
}
}변수 | 기본값 | 설명 |
| 현재 작업 디렉토리 | 백업 및 복원 경로를 위한 샌드박스 디렉토리. 모든 경로는 이 디렉토리 내에 유지되도록 검증됩니다. |
3단계 안전 모델 -- 기본적으로 읽기 전용, 쓰기는 명시적 동의 필요, 파괴적인 작업은 확인 토큰 필요
확인 토큰 -- DROP, TRUNCATE, ALTER DROP 및 전체 테이블 DELETE에 대해 60초 만료되는 일회성 UUID
SQL 인젝션 보호 -- PRAGMA 문에서 사용하기 전에 sqlite_master를 기준으로 테이블 이름 검증; 전체적으로 매개변수화된 쿼리 사용
경로 탐색 보호 -- 백업/복원 경로는 BERTH_BACKUP_DIR 내에 유지되도록 확인 및 검증됨; null 바이트 거부
비밀번호 마스킹 -- DSN 비밀번호는 모든 표시 출력 및 오류 메시지에서 마스킹됨
git clone https://github.com/seayniclabs/berth.git
cd berth
python -m venv .venv && source .venv/bin/activate
pip install -e ".[test]"
python -m pytest tests/ -qPostgreSQL 및 MySQL에 대한 통합 테스트는 Docker가 필요합니다:
docker compose -f tests/docker-compose.test.yml up -d
python -m pytest tests/ -q
docker compose -f tests/docker-compose.test.yml downCurrently running queries (PostgreSQL only — pg_stat_activity).
| Name | Required | Description | Default |
|---|---|---|---|
| connection_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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 data source (pg_stat_activity) but doesn't explain what 'currently running' means (e.g., real-time vs cached), whether this is read-only or has side effects, or any permissions/rate limits. This is inadequate for a tool that likely accesses system-level data.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (one sentence) and front-loaded with the core purpose. Every word earns its place, with no wasted text or redundancy, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (accessing system queries), no annotations, and an output schema (which reduces need to describe returns), the description is minimally adequate. It identifies the data source but lacks details on behavior, parameters, and usage context, leaving significant gaps for effective tool selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, so the description must compensate for the undocumented parameter. It adds no information about the 'connection_id' parameter—what it represents, how to obtain it, or its format. This leaves a critical gap for the single required parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: retrieving currently running queries from PostgreSQL's pg_stat_activity. It specifies the verb ('running queries') and resource ('PostgreSQL only'), but doesn't explicitly differentiate from siblings like db_query or db_execute, which might also involve query operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 prerequisites (e.g., needing an active connection), exclusions, or comparisons to siblings like db_query (for executing queries) or db_execute (for running commands).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a database backup.
PostgreSQL: uses pg_dump
MySQL: uses mysqldump
SQLite: uses .backup via sqlite3 CLI
Paths are sandboxed to BERTH_BACKUP_DIR (default: cwd).
| Name | Required | Description | Default |
|---|---|---|---|
| connection_id | Yes | ||
| output_path | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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 effectively describes key behaviors: the backup methods (pg_dump, mysqldump, sqlite3 CLI), the sandboxed path constraint (BERTH_BACKUP_DIR), and the default location (cwd). However, it doesn't mention potential side effects like performance impact during backup, permissions needed, or error handling, which are relevant for a backup operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose ('Create a database backup'), followed by bullet points for database-specific methods and a concise note about path constraints. Every sentence adds value without redundancy, making it efficiently structured and appropriately sized for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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, but with an output schema), the description is reasonably complete. It covers the purpose, methods, and path constraints, and since an output schema exists, it doesn't need to explain return values. However, it could benefit from more details on parameter usage or error scenarios to be fully comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the schema provides no parameter details. The description adds some context by mentioning 'Paths are sandboxed to BERTH_BACKUP_DIR', which relates to the output_path parameter, but it doesn't explain connection_id or provide format/syntax details for either parameter. This partial compensation results in a baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Create a database backup') and distinguishes it from siblings like db_restore (which restores backups) and db_query (which queries data). It also specifies the resource (database) and mentions the specific backup methods for different database types, providing clear differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by mentioning database types (PostgreSQL, MySQL, SQLite) and the sandboxed path constraint, but it doesn't explicitly state when to use this tool versus alternatives like db_restore or other database tools. No explicit exclusions or prerequisites are provided, leaving usage context somewhat implied rather than clearly defined.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Connect to a database.
Supported DSN formats:
postgresql://user:pass@host/db
sqlite:///path/to/file.db (or :memory:)
mysql://user:pass@host/db
Returns a connection_id used by all other tools.
| Name | Required | Description | Default |
|---|---|---|---|
| dsn | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses key behavioral traits: it establishes a database connection, supports specific DSN formats (PostgreSQL, SQLite, MySQL), and returns a connection_id for reuse. However, it lacks details on error handling, timeouts, authentication requirements, or rate limits, which are important for a connection tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded: the first sentence states the core purpose, followed by a bulleted list of DSN formats and a note on the return value. Every sentence earns its place by providing necessary information without redundancy, making it efficient and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (a foundational connection tool with 1 parameter), no annotations, and an output schema (implied by 'Has output schema: true'), the description is mostly complete. It covers the purpose, parameter details, and return value, but could improve by mentioning error cases or connection lifecycle management. The output schema likely handles return values, so the description doesn't need to explain them further.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage and only one parameter (dsn) with no schema-level details. The description compensates fully by explaining the dsn parameter's semantics: it lists supported DSN formats with examples (e.g., postgresql://user:pass@host/db), adding crucial meaning beyond the bare schema. This is essential for correct tool invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Connect to a database.' It specifies the action (connect) and resource (database), but does not explicitly differentiate from siblings like db_backup or db_restore, which might also involve database connections indirectly. The mention of returning a connection_id hints at its foundational role, but sibling differentiation is implicit rather than explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by stating it 'Returns a connection_id used by all other tools,' suggesting it should be invoked first to enable other database operations. However, it does not explicitly state when to use this tool versus alternatives (e.g., no mention of prerequisites or exclusions), nor does it name specific sibling tools as alternatives for connection-related tasks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Column details for a table: name, type, nullable, default, constraints.
| Name | Required | Description | Default |
|---|---|---|---|
| connection_id | Yes | ||
| table | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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 returns column details but doesn't cover critical aspects like whether it's read-only, requires authentication via connection_id, potential rate limits, error handling, or output format. For a tool with no annotation coverage, this leaves significant gaps in understanding its behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise and front-loaded, listing the key details returned in a single, efficient sentence. Every word earns its place by specifying the output content (name, type, nullable, default, constraints) without unnecessary elaboration. It's appropriately sized for a simple descriptive tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 required parameters, no annotations, but has an output schema), the description is partially complete. It clarifies the tool's purpose and output scope, but lacks usage guidelines, behavioral details, and parameter explanations. The presence of an output schema mitigates the need to describe return values, but other gaps remain, making it adequate but with clear room for improvement.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds no parameter semantics beyond what the input schema provides. With 0% schema description coverage, the schema only lists parameter names and types without explaining their meaning. The description doesn't compensate by clarifying what 'connection_id' or 'table' represent, leaving parameters minimally documented. Baseline 3 applies as the schema provides basic structure, but the description fails to enhance understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states what the tool does: 'Column details for a table' specifies the resource (table columns) and the action (describe details). It distinguishes from siblings like db_schema (overall schema) or db_relationships (foreign keys), though not explicitly named. However, it lacks a specific verb like 'retrieve' or 'list', 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.
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 prerequisites (e.g., needing an active connection), exclusions, or comparisons to siblings like db_schema or db_query. Without any usage context, the agent must infer from the name and description alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Execute INSERT/UPDATE/DELETE statements.
Respects the current safety mode:
read-only: rejects all writes
write: allows INSERT/UPDATE/DELETE, blocks DROP/TRUNCATE
admin: allows everything (destructive ops need a confirmation_token)
| Name | Required | Description | Default |
|---|---|---|---|
| connection_id | Yes | ||
| sql | Yes | ||
| confirmation_token | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and does so effectively. It discloses key behavioral traits: the tool's dependency on safety modes, restrictions on destructive operations (DROP/TRUNCATE), and the need for a confirmation_token in admin mode. This covers permissions, constraints, and workflow details, though it could mention error handling or transaction behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded, starting with the core purpose and immediately following with detailed safety mode guidelines. Every sentence earns its place by providing essential operational context without redundancy, making it efficient and well-structured for quick comprehension.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (database mutations with safety modes), no annotations, 0% schema coverage, but an output schema exists, the description is mostly complete. It covers purpose, usage, and key behaviors but lacks details on parameters like connection_id and sql. The output schema likely handles return values, so this gap is acceptable, though some parameter context would enhance completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 explains the confirmation_token's role in admin mode for destructive operations, adding meaning beyond the schema. However, it doesn't clarify connection_id (e.g., what it references) or sql (e.g., format or validation), leaving two of three parameters with minimal semantic context. The partial compensation justifies a baseline score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool executes INSERT/UPDATE/DELETE statements, providing a specific verb (execute) and resource (database statements). It distinguishes from siblings like db_query (likely for SELECT) and db_explain (for query analysis), though not by explicit naming. The purpose is well-defined but could be more explicit about sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidelines by detailing when to use based on safety modes: read-only (rejects writes), write (allows INSERT/UPDATE/DELETE, blocks DROP/TRUNCATE), and admin (allows everything with confirmation_token). It implicitly contrasts with db_query for read operations and references safety mode tools, offering clear context for when and how to invoke this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run EXPLAIN ANALYZE on a query and return the plan.
| Name | Required | Description | Default |
|---|---|---|---|
| connection_id | Yes | ||
| sql | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but only states the basic function. It doesn't disclose behavioral traits such as whether it's read-only, if it affects database performance, requires specific permissions, or has rate limits, leaving significant gaps for a tool that analyzes queries.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste, clearly front-loading the purpose. Every word earns its place, making it appropriately sized for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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, but with an output schema), the description is minimal. It states what the tool does but lacks details on usage, behavior, or parameters, though the output schema may cover return values, keeping it at a baseline adequacy.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 details about parameters. It implies 'sql' is the query to analyze and 'connection_id' identifies the database, but doesn't explain formats or requirements. Baseline 3 is appropriate as it doesn't fully compensate for the coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Run EXPLAIN ANALYZE') and the resource ('on a query'), specifying it returns the execution plan. It distinguishes from siblings like db_query or db_execute by focusing on query analysis rather than execution, though it doesn't explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 like db_query for actual query results or db_describe for schema details. The description implies usage for query optimization but lacks explicit context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Execute a SELECT query. Auto-adds LIMIT 1000 if no LIMIT clause present.
| Name | Required | Description | Default |
|---|---|---|---|
| connection_id | Yes | ||
| sql | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and does well by disclosing key behavioral traits: it's for SELECT queries (implying read-only) and auto-adds LIMIT 1000 if absent, which is crucial for safety and performance. It doesn't cover error handling, timeout, or result format, but the auto-LIMIT detail is significant and adds value beyond basic purpose.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (two sentences) and front-loaded with the core purpose ('Execute a SELECT query'), followed by a critical behavioral detail (auto-LIMIT). Every word earns its place, with no redundancy or fluff. It efficiently communicates essential information without over-explaining.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (database querying), no annotations, and an output schema present (which handles return values), the description is reasonably complete. It covers purpose and a key safety behavior (auto-LIMIT), but lacks details on parameter meanings, error cases, or connection requirements. The output schema reduces the need to explain returns, making this adequate but not exhaustive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 doesn't mention the two parameters (connection_id, sql) at all, leaving them undocumented. However, the description implies the sql parameter through 'SELECT query' and the auto-LIMIT behavior, adding some context. Since parameters are few (2) and the tool's purpose is clear, this meets the baseline but doesn't fully compensate for the coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Execute a SELECT query' specifies both the verb (execute) and resource (SELECT query). It distinguishes from siblings like db_execute (likely for non-SELECT queries) and db_describe/schema (metadata tools). However, it doesn't explicitly mention what database or system it queries, which prevents 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context through 'SELECT query' and the auto-LIMIT behavior, suggesting this is for read-only data retrieval. However, it doesn't explicitly state when to use this vs. alternatives like db_execute (for writes) or db_describe (for schema info), nor does it mention prerequisites like needing an established connection via db_connect. The guidance is present but not comprehensive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Foreign key relationships. Omit table to show all.
| Name | Required | Description | Default |
|---|---|---|---|
| connection_id | Yes | ||
| table | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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 hints at a read-only operation by describing a display of relationships, but doesn't specify if it requires specific permissions, how it handles large datasets, or what the output format entails. 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with two short sentences that are front-loaded and waste no words. Every part earns its place by stating the purpose and providing a key usage tip, making it efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema (which likely defines return values), the description doesn't need to explain outputs. However, with no annotations and low schema coverage, it partially compensates by clarifying parameter usage but leaves gaps in behavioral context and sibling differentiation. It's adequate for a simple read tool but could be more complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaningful context beyond the input schema: it explains that omitting the 'table' parameter shows all relationships, clarifying the optional nature and effect of this parameter. Since schema description coverage is 0%, this compensates well for the lack of schema details, though it doesn't fully document both parameters (e.g., 'connection_id' is not explained).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool shows 'foreign key relationships', which indicates its purpose, but it's vague about the exact action (e.g., list, retrieve, display) and doesn't distinguish it from siblings like 'db_schema' or 'db_describe', which might also provide database structural information. It mentions omitting a table to show all, adding some specificity but not enough for clear differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides minimal guidance: it says to omit the table parameter to show all relationships, implying usage for a specific table or all tables. However, it offers no explicit advice on when to use this tool versus alternatives like 'db_schema' or 'db_describe', nor does it mention prerequisites or exclusions, leaving the agent with little context for decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Restore a database from a backup file.
Requires admin mode and a confirmation token (destructive operation). Paths are sandboxed to BERTH_BACKUP_DIR (default: cwd).
| Name | Required | Description | Default |
|---|---|---|---|
| connection_id | Yes | ||
| input_path | Yes | ||
| confirmation_token | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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 effectively describes key behavioral traits: it's a 'destructive operation,' requires 'admin mode and a confirmation token,' and has path sandboxing constraints ('Paths are sandboxed to BERTH_BACKUP_DIR'). This covers safety, permissions, and environmental limits well.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise and front-loaded: the first sentence states the core purpose, followed by critical behavioral and usage details. Every sentence adds essential value with zero wasted words, making it easy for an AI agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given this is a destructive operation with 3 parameters and no annotations, the description does well by covering safety requirements and path constraints. The presence of an output schema means return values don't need explanation. However, it could better address parameter formats or error conditions for full completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 explains the purpose of 'confirmation_token' (required for this destructive operation) and clarifies that 'input_path' is sandboxed to BERTH_BACKUP_DIR. However, it doesn't mention 'connection_id' or provide format details for any parameters, leaving some gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Restore') and resource ('a database from a backup file'), making the purpose specific and unambiguous. It distinguishes itself from siblings like db_backup (which creates backups) and db_query/execute (which query/execute commands).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool ('Requires admin mode and a confirmation token') and implies it's for restoring databases from backups. However, it doesn't explicitly state when NOT to use it or name specific alternatives among siblings (e.g., when to use db_backup instead).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List tables, views, and indexes in the database.
| Name | Required | Description | Default |
|---|---|---|---|
| connection_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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 lists database objects, implying a read-only operation, but doesn't mention potential side effects, permissions required, rate limits, or output format. For a tool with no annotations, 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence: 'List tables, views, and indexes in the database.' It's front-loaded with the core action and resources, with zero wasted words. This makes it easy for an agent to parse and understand quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (listing database objects) and the presence of an output schema (which handles return values), the description is minimally adequate. However, with no annotations and incomplete behavioral context, it lacks details on permissions, side effects, or how it differs from siblings. It meets the basic requirement but has clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds no parameter semantics beyond what the input schema provides. With 0% schema description coverage and 1 parameter (connection_id), the schema alone defines the parameter without explanation. The description doesn't compensate by explaining what connection_id is or how it's used, but since there's only one parameter and the schema is simple, a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'List tables, views, and indexes in the database.' It specifies the verb ('List') and the resources ('tables, views, and indexes'), making it easy to understand what the tool does. However, it doesn't explicitly differentiate from siblings like db_describe or db_relationships, which might have overlapping scopes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 siblings such as db_describe (which might describe specific tables) and db_relationships (which might show table relationships), there's no indication of context, prerequisites, or exclusions. This leaves the agent without clear usage instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Database and table sizes.
| Name | Required | Description | Default |
|---|---|---|---|
| connection_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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 what information is returned ('Database and table sizes') without describing how it behaves—e.g., whether it's a read-only operation, requires specific permissions, has performance implications, or provides output format. This leaves critical behavioral traits unspecified.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise with just three words, which is efficient and front-loaded. However, it's under-specified rather than optimally concise, as it lacks necessary details. Every word earns its place, but more content would improve clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (likely a read operation with one parameter) and the presence of an output schema, the description is incomplete. It doesn't explain the purpose, usage, or behavior adequately, leaving the agent to rely heavily on the output schema and schema fields. For a tool with no annotations and low schema coverage, more descriptive content is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds no parameter semantics beyond the input schema, which has 0% description coverage. However, with only one parameter (connection_id), the baseline is 4 for zero parameters, but since there is one undocumented parameter, it's adjusted to 3. The description doesn't explain what connection_id is or how to obtain it, failing to compensate for the schema gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Database and table sizes' states what the tool returns but not what it does. It's a tautology that restates the name 'db_size' rather than specifying an action like 'retrieve' or 'calculate'. It doesn't distinguish from siblings like db_schema or db_describe, which might also provide size-related information.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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, context, or exclusions, such as whether it requires an active connection or how it differs from siblings like db_schema that might include size details. The agent must infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate migration SQL by comparing two schemas.
Two modes of operation:
Mode 1 — Compare live database against target DDL:
connection_id: source database connection
target_sql: CREATE TABLE statements describing the desired schema
Mode 2 — Compare two live databases:
from_connection: source database connection_id
to_connection: target database connection_id
Returns dialect-aware ALTER statements to migrate source -> target. Destructive operations (DROP TABLE, DROP COLUMN) are commented out for safety.
| Name | Required | Description | Default |
|---|---|---|---|
| connection_id | No | ||
| target_sql | No | ||
| from_connection | No | ||
| to_connection | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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 effectively describes key behavioral traits: the tool returns 'dialect-aware ALTER statements' and notes that 'destructive operations (DROP TABLE, DROP COLUMN) are commented out for safety.' This provides important context about output format and safety measures that wouldn't be apparent from the schema alone. However, it doesn't mention potential limitations like performance implications 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and efficiently organized. It begins with a clear purpose statement, then presents two modes in a bullet-point format that's easy to parse, and concludes with important behavioral notes. Every sentence adds value without redundancy, making it both comprehensive and concise for the agent to understand.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (schema comparison with multiple modes), zero annotation coverage, and 0% schema description coverage, the description provides excellent contextual completeness. It explains the tool's purpose, two operational modes with parameter semantics, output characteristics (dialect-aware ALTER statements), and safety features. With an output schema present, it doesn't need to detail return values, making this description complete for agent understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage and 4 parameters, the description must fully compensate. It successfully explains the semantic meaning of all parameters: connection_id is for 'source database connection' in Mode 1, target_sql contains 'CREATE TABLE statements describing the desired schema,' from_connection is 'source database connection_id' in Mode 2, and to_connection is 'target database connection_id.' This adds crucial context beyond the bare parameter names in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Generate migration SQL by comparing two schemas.' It specifies the exact action (generate SQL), resource (migration), and method (schema comparison). It distinguishes itself from sibling tools like db_schema (which likely describes schemas) or db_execute (which runs SQL) by focusing on migration generation through comparison.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly defines two distinct modes of operation with clear parameter combinations: Mode 1 uses connection_id and target_sql to compare a live database against target DDL, while Mode 2 uses from_connection and to_connection to compare two live databases. This provides explicit guidance on when to use each parameter set, helping the agent choose the correct mode based on available inputs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Server health check. Returns version and status.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
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 tool returns 'version and status', which implies a read-only, non-destructive operation, but does not specify details like authentication requirements, rate limits, error conditions, or the exact format of the returned data. This leaves gaps in understanding the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise and front-loaded, consisting of just one sentence that directly states the tool's purpose and output. Every word earns its place, with no redundant or vague language, making it efficient and easy to understand.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (0 parameters, simple purpose) and the presence of an output schema (which should detail the return values), the description is reasonably complete. It covers the core functionality but lacks context on usage scenarios or behavioral nuances. With annotations absent, it could benefit from more detail on operational aspects, but it suffices for a basic health check tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, so the schema fully documents the lack of inputs. The description does not add parameter-specific information, which is appropriate here. A baseline score of 4 is given as the description does not need to compensate for any parameter gaps, and it correctly implies no inputs are required for a health check.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose as performing a 'server health check' that returns 'version and status'. It uses specific verbs ('check', 'returns') and identifies the resource ('server'), but does not explicitly differentiate it from sibling tools like db_active_queries or safety_get_mode, which might also provide status information.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 does not mention prerequisites, timing (e.g., during troubleshooting or monitoring), or comparisons to sibling tools that might offer overlapping functionality, such as db_connect for database status or safety_get_mode for system safety status.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return the current safety mode without changing it.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
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 clearly indicates this is a read-only operation ('Return... without changing it'), which is adequate for a simple query tool. However, it doesn't mention potential authentication requirements, rate limits, or what happens if the safety mode isn't set.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that communicates the complete purpose with zero wasted words. It's appropriately sized for a simple, parameterless query tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read operation with no parameters and an output schema (which handles return values), the description is reasonably complete. It could be slightly improved by mentioning what format the safety mode is returned in or potential error conditions, but it covers the essential purpose adequately.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters (schema coverage 100%), so the baseline is 4. The description appropriately doesn't discuss parameters since none exist, which is correct for this tool configuration.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Return') and resource ('current safety mode') with the explicit constraint 'without changing it'. This distinguishes it from its sibling tool 'safety_set_mode' which would presumably change the safety mode.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context by specifying 'without changing it', which suggests this tool should be used when you need to read the safety mode rather than modify it. However, it doesn't explicitly mention when NOT to use it or name alternatives like 'safety_set_mode' for modification scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Switch the safety mode.
Accepts: "read-only", "write", or "admin". Returns the current mode after setting.
| Name | Required | Description | Default |
|---|---|---|---|
| mode | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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 mentions that the tool 'Returns the current mode after setting,' which adds some context about the return behavior. However, it lacks critical details such as permissions required, whether the change is reversible, side effects, or error conditions. For a mutation tool with zero annotation coverage, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise and well-structured: three short sentences with zero waste. The first states the purpose, the second defines parameter values, and the third describes the return behavior. Every sentence earns its place, and information is front-loaded appropriately.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (a mutation with 1 parameter), no annotations, and an output schema (which likely covers return values), the description is moderately complete. It covers the purpose, parameter values, and return behavior, but lacks usage guidelines, behavioral details like permissions or side effects, and deeper parameter semantics. The output schema reduces the need to explain returns, but gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 1 parameter with 0% description coverage, so the description must compensate. It adds meaningful semantics: 'Accepts: "read-only", "write", or "admin".' This specifies the allowed values for the 'mode' parameter, which is not covered in the schema. However, it doesn't explain the meaning or implications of each mode value, leaving some ambiguity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Switch the safety mode.' This is a specific verb ('Switch') and resource ('safety mode'), though it doesn't explicitly differentiate from its sibling 'safety_get_mode' (which presumably reads rather than sets the mode). The purpose is unambiguous but lacks sibling comparison.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 the sibling 'safety_get_mode' for reading the mode, nor does it specify prerequisites, contexts, or exclusions for setting the safety mode. Usage is implied only by the tool's name and purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Every tool has a clearly distinct purpose with no ambiguity. Tools like db_query (SELECT), db_execute (INSERT/UPDATE/DELETE), db_backup, db_restore, db_schema, and db_relationships each handle specific database operations without overlap. Even conceptually similar tools like db_active_queries and db_explain are differentiated by their focus on monitoring vs. query optimization.
The naming follows a highly consistent pattern throughout. All database-related tools use the 'db_' prefix followed by a descriptive verb or noun (e.g., db_query, db_backup, db_schema), while non-database tools like health, safety_get_mode, and safety_set_mode follow a clear, readable convention. There are no deviations in style or structure.
With 15 tools, the set is well-scoped for a database management server. Each tool earns its place by covering essential operations such as querying, schema inspection, backups, migrations, and safety controls. The count is neither too sparse nor bloated, aligning perfectly with the domain's complexity.
The tool surface provides complete CRUD and lifecycle coverage for database management. It includes query execution (db_query, db_execute), schema operations (db_schema, db_describe), maintenance (db_backup, db_restore), optimization (db_explain), and safety controls (safety_set_mode). There are no obvious gaps, and tools like generate_migration add advanced functionality without dead ends.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Explore, query, and inspect SQLite databases with ease. List tables, preview results, and view det…
Connect to PlanetScale databases, branches, schema, query insights, and execute SQL
Manage Supabase projects end to end across database, auth, storage, realtime, and migrations. Moni…
Your Supabase account in natural language: run SQL, apply migrations, manage tables, storage, edge f
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/seayniclabs/berth'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
