Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Tibero MCP Server show me the schema for the customers table"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Tibero 데이터베이스와 AI 어플리케이션 간의 안전한 통신을 제공하는 Model Context Protocol(MCP) 서버입니다.
기존 타 DB의 MCP를 참고하여 재구성한 MCP입니다. 실제 사용 시 SELECT 이외에는 유의해야합니다.
Related MCP server: Oracle MCP Server
리소스 제공: 데이터베이스 테이블과 뷰를 MCP 리소스로 노출
SQL 실행: SELECT, INSERT, UPDATE, DELETE, DDL 쿼리 실행
스키마 정보: 테이블 구조, 제약조건, 인덱스 정보 조회
샘플 데이터: 테이블당 최대 100행의 샘플 데이터 제공
Python 3.11+
Java Runtime Environment 8+
Tibero JDBC 드라이버 (tibero6-jdbc.jar) (*drivers 내부에 탑재 필요)
pip install -r requirements.txtclaude_desktop_config.json 파일에 추가:
{
"mcpServers": {
"tibero": {
"command": "python",
"args": ["/path/to/tibero_mcp_server/src/tibero_mcp_server/server.py"],
"env": {
"TIBERO_HOST": "localhost",
"TIBERO_PORT": "8629",
"TIBERO_SID": "tibero",
"TIBERO_USER": "username",
"TIBERO_PASSWORD": "password",
"CLASSPATH": "/path/to/tibero6-jdbc.jar"
}
}
}
}테이블: tibero://TABLE_NAME/data - 테이블 스키마 + 샘플 데이터 (최대 100행)
뷰: tibero://VIEW_NAME/view - 뷰 스키마 + 샘플 데이터
SQL 쿼리를 실행합니다.
SELECT/SHOW/DESC: CSV 형태 결과 반환
INSERT/UPDATE/DELETE: 영향받은 행 수 반환, 명시적 커밋
DDL: 실행 결과 반환
테이블 상세 정보를 조회합니다.
컬럼 정보 (이름, 타입, 길이, NULL 허용)
제약조건 (PRIMARY KEY, UNIQUE, FOREIGN KEY, CHECK)
인덱스 정보 (이름, 유니크 여부)
# 직접 실행
python src/tibero_mcp_server/server.py
# 모듈로 실행
python -m tibero_mcp_server.serverjaydebeapi를 사용하여 Tibero JDBC 드라이버로 연결합니다. DML 쿼리 실행 후 명시적으로 commit하며, 안전을 위해 AutoCommit=False로 설정됩니다.
Execute an SQL query on the Tibero server
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | The SQL query to execute |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states the action but doesn't mention critical traits like whether this is read-only or destructive, what permissions are needed, error handling, or result formatting. For a database execution tool, 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 a single, efficient sentence with zero wasted words. It's appropriately sized for a simple tool and front-loads the essential information without unnecessary elaboration.
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 database execution tool with no annotations and no output schema, the description is insufficient. It doesn't explain what happens after execution (e.g., returns results, affects data), error conditions, or security implications, leaving the agent with incomplete context for safe and effective use.
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 100%, with the single parameter 'query' fully documented in the schema. The description adds no additional meaning about parameter syntax, valid SQL types, or constraints beyond what the schema provides, meeting the baseline for high schema coverage.
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 ('Execute') and target ('SQL query on the Tibero server'), providing specific verb+resource information. However, it doesn't differentiate from the sibling tool 'get_table_info', which might also involve SQL queries or database operations, so it doesn't fully distinguish from 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?
The description provides no guidance on when to use this tool versus alternatives like 'get_table_info'. There's no mention of appropriate contexts, exclusions, or prerequisites for executing SQL queries, leaving the agent without usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed information about a table
| Name | Required | Description | Default |
|---|---|---|---|
| table_name | Yes | The name of the table |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. While 'Get detailed information' implies a read-only operation, it doesn't specify what 'detailed information' includes, whether there are permission requirements, rate limits, error conditions, or what format the information comes in. This leaves significant behavioral gaps.
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 gets straight to the point with zero wasted words. It's appropriately sized for a simple tool with one parameter and is perfectly front-loaded.
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 tool with no annotations and no output schema, the description is insufficient. It doesn't explain what 'detailed information' means in terms of return values, doesn't address potential errors or constraints, and doesn't help differentiate from the sibling SQL execution tool. The context demands more completeness than provided.
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 100% with the single parameter 'table_name' well-documented in the schema. The description doesn't add any parameter-specific information beyond what's in the schema, so it meets the baseline for high schema coverage without adding extra value.
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 ('Get detailed information') and target resource ('about a table'), making the purpose immediately understandable. However, it doesn't differentiate from the sibling tool 'execute_sql' which could also provide table information through SQL queries, so it doesn't reach the highest score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 the sibling 'execute_sql' tool, nor does it mention any prerequisites, context, or exclusions. It simply states what the tool does without helping the agent choose between alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
execute_sqlget_table_infoScored across 2 tools
The two tools have clearly distinct purposes: execute_sql handles arbitrary SQL queries, while get_table_info provides metadata about a specific table. There is no overlap or ambiguity between them.
Both tools follow a consistent verb_noun pattern (execute_sql and get_table_info). The naming is predictable and readable throughout the set.
With only 2 tools, the server feels thin for a database interaction domain. Core operations like listing tables, describing schemas, or managing connections are missing, making it under-scoped for typical database workflows.
The tool surface is severely incomplete for a Tibero database server. It lacks basic CRUD lifecycle coverage (e.g., no tools for listing databases/tables, creating/dropping tables, or managing transactions), which will cause significant agent failures in database tasks.
Draxlr's remote MCP server connects AI assistants to your SQL databases and dashboards. Explore schemas, run read-only queries, manage saved queries and dashboards, and export results, all with row-level security so each user sees only their own data.
The BigQuery remote MCP server is a fully managed service that uses the Model Context Protocol to connect AI applications and LLMs to BigQuery data sources. It provides secure, standardized tools for AI agents to list datasets and tables, retrieve schemas, generate and execute SQL queries through natural language, and analyze data—enabling direct access to enterprise analytics data without requiring manual SQL coding.
Tigris MCP Server seamlessly connects AI agents to Tigris bucket and object management.
PostgreSQL, MySQL, and SQL Server in one session. 26 read-only MCP tools for AI agents.
