ShipMCP is a specialized MCP server that helps LLMs accurately understand and work with Korean/English shipbuilding terminology.
Tools
Search terms: Search shipbuilding terminology by keyword in English or Korean, returning IDs, names, abbreviations, and descriptions
Get term details: Retrieve full details (description, category, synonyms, related terms) by term ID, English name, or Korean name (e.g., '용골' → Keel)
Browse by category: List all terms within a specific category across 14 available categories (e.g., hull-structure, propulsion, navigation, cargo, safety)
List categories: Get all available terminology categories with their IDs, names, and descriptions
Translate terms: Translate shipbuilding terms between English and Korean in either direction
Get statistics: Retrieve database stats including total term count (364), category count (14), and per-category distribution
Resources
Access static/queryable data including category listings, individual term data, search results, and a full glossary via shipmcp:// URIs
Prompts
Use built-in reusable templates to learn a term, generate a Korean-English glossary, explain shipbuilding documents, or compare two terms
Deployment
Supports stdio (local), streamable HTTP, or SSE transport, with Docker support and persistent database storage
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., "@ShipMCP What is a keel?"
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.
조선/선박 전문 용어를 LLM이 정확히 이해하도록 돕는 MCP 서버입니다.
Korean + English shipbuilding terminology
조선소 실무에서 자주 쓰는 설계/생산/선급/IMO 용어 포함
MCP 표준 Primitive(Resources, Tools, Prompts) 제공
클라이언트가 컨텍스트로 로드할 수 있는 정적/조회형 데이터입니다.
shipmcp://categories
shipmcp://category/{category_id}
shipmcp://term/{term_id}
shipmcp://search/{query}
shipmcp://glossary
모델이 호출할 수 있는 실행형 함수입니다.
search_ship_terms(query, max_results=10)
get_term_detail(term_id_or_name)
list_terms_by_category(category_id)
list_categories_tool()
translate_term(term, from_lang="en", to_lang="ko")
get_term_statistics()
재사용 가능한 프롬프트 템플릿입니다.
learn_term(term_name)
korean_english_glossary(category="all")
explain_document(text)
compare_terms(term1, term2)
Related MCP server: Bible MCP
현재 데이터 기준:
Categories: 14
Terms: 364
카테고리 목록:
ship-types
hull-structure
propulsion
navigation
cargo
safety
shipbuilding-process
ship-dimensions
design
marine-engineering
mooring-anchoring
electrical
classification
welding-fabrication
용어 데이터는 로컬 SQLite 파일 DB로 관리됩니다.
기본 DB 경로: ship_mcp/data/ship_terms.db
환경변수: SHIP_MCP_DB_PATH
CLI 옵션: --db-path
사용자 DB 경로를 지정했을 때 파일이 비어 있으면, 패키지 기본 DB를 복제해 초기화합니다.
예시:
# PowerShell
$env:SHIP_MCP_DB_PATH = "C:\path\to\ship_terms.db"
uv run ship-mcp
# 또는 옵션 사용
uv run ship-mcp --db-path C:\path\to\ship_terms.dbPython 3.10+
uv (권장) 또는 pip
Docker (컨테이너 실행 시)
git clone <your-repo-url>
cd ShipMCP
uv syncpip 사용 시:
pip install .기본(권장) STDIO 모드:
uv run ship-mcp모듈 직접 실행:
uv run python -m ship_mcp.serverHTTP 모드 예시:
# Streamable HTTP
uv run ship-mcp --transport streamable-http --host 0.0.0.0 --port 8000
# SSE
uv run ship-mcp --transport sse --host 127.0.0.1 --port 8000이미지 빌드:
docker build -t ship-mcp:latest .기본 실행(HTTP, 8000 포트):
docker run --rm -p 8000:8000 ship-mcp:latestDB를 호스트에 영속화:
docker run --rm -p 8000:8000 -v shipmcp-data:/data ship-mcp:latest실행 옵션 변경(환경변수):
docker run --rm -p 9000:9000 \
-e SHIP_MCP_TRANSPORT=streamable-http \
-e SHIP_MCP_HOST=0.0.0.0 \
-e SHIP_MCP_PORT=9000 \
-e SHIP_MCP_DB_PATH=/data/ship_terms.db \
-v shipmcp-data:/data \
ship-mcp:latest참고: Docker 이미지는 기본적으로 HTTP 배포용(streamable-http)으로 설정되어 있습니다.
claude_desktop_config.json 예시:
{
"mcpServers": {
"shipmcp": {
"command": "uv",
"args": ["run", "--directory", "C:\\path\\to\\ShipMCP", "ship-mcp"],
"env": {}
}
}
}claude mcp add shipmcp -- uv run --directory "C:\\path\\to\\ShipMCP" ship-mcppython -m unittest discover -s tests -v권장 호출 순서:
search_ship_terms 로 후보 검색
get_term_detail 로 상세 정보 조회
필요 시 translate_term 으로 번역
예시 질의:
용골이 뭐야?
DWT 뜻 알려줘
Bulk Carrier와 Tanker 차이 비교
이 문단의 조선 용어를 풀어서 설명해줘
ShipMCP/
├─ Dockerfile
├─ pyproject.toml
├─ README.md
├─ tests/
│ ├─ test_repository.py
│ └─ test_server_tools.py
└─ ship_mcp/
├─ __init__.py
├─ server.py
└─ data/
├─ __init__.py
├─ repository.py
└─ ship_terms.db엔트리포인트: ship-mcp = ship_mcp.server:main
기본 전송 프로토콜: stdio
지원 전송 프로토콜: stdio, sse, streamable-http
데이터 계층: ship_mcp/data/repository.py
MIT
Get detailed information about a specific shipbuilding term. IMPORTANT: Call this after search_ship_terms() to get FULL details. Works with Korean names too! e.g. get_term_detail("용골") returns keel details.
Args: term_id_or_name: The term's unique ID (e.g. 'bulk-carrier'), English name, or Korean name (e.g. '용골', '벌크선')
Returns: Detailed term information including descriptions, category, synonyms, and related terms
| Name | Required | Description | Default |
|---|---|---|---|
| term_id_or_name | 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 bears the full burden. It discloses that the tool returns detailed information including descriptions, category, synonyms, and related terms, and mentions support for Korean names. It does not mention any side effects, authentication, or error handling, but the tool is a simple read operation, so this is adequate.
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 with an introductory sentence, an important note, and clear Args/Returns sections. It is concise but includes useful examples. Could be slightly more terse, but overall effective.
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 simplicity and the existence of an output schema (so return format details are not needed), the description covers purpose, usage, parameter details, and what the output contains. It is complete enough for an agent to use the tool correctly.
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 coverage is 0%, so the description must compensate. It thoroughly explains the single parameter 'term_id_or_name' by listing acceptable values (unique ID, English name, Korean name) with concrete examples, adding significant meaning beyond 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 it retrieves detailed information about a specific shipbuilding term. It explicitly distinguishes itself from the sibling 'search_ship_terms' by noting it should be called after that for full details, and provides an example with Korean names.
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 guidance: 'Call this after search_ship_terms() to get FULL details.' It also offers examples for Korean names and describes the acceptable input types (ID, English name, Korean name), helping the agent decide when 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.
Get statistics about the shipbuilding terminology database.
Returns: Count of terms, categories, and category-wise distribution
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only states what is returned (counts, categories, distribution) but does not mention performance, authentication needs, data freshness, or any side effects. For a read-only statistics tool, this is minimal but acceptable; however, full burden on description warrants a 2.
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 covering purpose and return structure. Every word contributes value, and the key information (what it does, what it returns) is front-loaded. No wasted text.
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?
With an output schema present, the description does not need to explain return values, but it still does succinctly. The tool is simple (no parameters, no nested objects), so the description covers the essential purpose and output. Minor omission: no mention of data scope (e.g., all terms or filtered). Otherwise 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 tool has 0 parameters, and schema coverage is 100% trivially. The description adds no parameter-specific meaning, but it does describe the output, which is partially related. Baseline 3 is appropriate given no parameter information is needed.
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 retrieves statistics about the shipbuilding terminology database, specifying the return type (count of terms, categories, distribution). It distinguishes from siblings like get_term_detail or search_ship_terms, though not explicitly. A score of 4 reflects clarity without explicit 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 no guidance on when to use this tool versus alternatives like list_categories_tool or list_terms_by_category. It does not mention prerequisites, when-not to use, or related tools. The context signals list siblings, but the description itself lacks usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all shipbuilding terminology categories.
Returns: All available categories with their IDs, names, and descriptions
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| 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. It states that it lists all categories and returns IDs, names, and descriptions. It does not disclose any behavioral traits like read-only hint, caching, or side effects. For a simple list operation, this is minimally sufficient.
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 concise with two sentences: one for the action and one for the return value. No extraneous information. Every word earns its place.
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 that the tool has no parameters, has an output schema, and is a simple list operation, the description provides enough context: it lists categories and their attributes. It could optionally mention the structure or hierarchy of categories, but it is not necessary for correct usage.
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?
There are no parameters in the input schema, and schema description coverage is 100% (trivially). The description does not need to add parameter semantics, so baseline 4 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 'List all shipbuilding terminology categories' with a specific verb and resource, and further clarifies the return structure (IDs, names, descriptions). It is distinct from sibling tools which focus on terms, details, statistics, search, or translation.
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 explicit guidance on when to use this tool versus alternatives is provided. However, the context of sibling tools implies that this tool is for category-level retrieval, while others are for terms. A score of 3 reflects adequate but not explicit usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all shipbuilding terms in a specific category.
Args: category_id: The category ID. Available: ship-types, hull-structure, propulsion, navigation, cargo, safety, shipbuilding-process, ship-dimensions, design, marine-engineering, mooring-anchoring, electrical, classification, welding-fabrication
Returns: A list of terms in the category with basic info
| Name | Required | Description | Default |
|---|---|---|---|
| category_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 burden. It states it returns a list with basic info but does not disclose read-only nature (implied), pagination, or rate limits. Adequate but incomplete.
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 with Args and Returns sections, though slightly verbose. It is concise enough and front-loaded with key action.
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 tool with one parameter and an existing output schema, the description provides category enumeration and return type. Lacks pagination/limit info but is largely 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 lists all valid category_id values, adding significant meaning beyond the schema (which only provides a title 'Category Id'). Schema coverage is 0%, so description compensates well.
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 lists all shipbuilding terms in a specific category, using a specific verb and resource. It distinguishes from siblings like get_term_detail (single term) and search_ship_terms (search).
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 when needing terms by category but does not explicitly state when not to use or provide alternatives. Sibling names give hints but description lacks direct guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search shipbuilding terminology by keyword. IMPORTANT: Use this for ANY shipbuilding question, including Korean terms!
Searches across English terms, Korean terms (한국어), abbreviations, and descriptions. Example: search_ship_terms("용골") will find "Keel" Example: search_ship_terms("DWT") will find "Deadweight Tonnage"
Args: query: The keyword or phrase to search for (English or Korean — both work!) max_results: Maximum number of results to return (default 10, max 50)
Returns: A list of matching terms with id, English, Korean, abbreviation, and description
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | ||
| max_results | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Discloses that it searches across English, Korean, abbreviations, and descriptions. Does not mention destructive behavior or authentication needs, but as a search tool, read-only nature is inferred.
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?
Well-structured with IMPORTANT note, examples, and Args section. Some redundancy, but overall efficient for a search tool with multilingual capability.
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 complex multilingual search and presence of output schema, description explains return fields (id, English, Korean, abbreviation, description). Provides sufficient context for an agent to use effectively.
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 coverage is 0%, but description adds full semantics: query can be English or Korean, max_results has default 10 and max 50. Provides concrete examples that illustrate parameter usage.
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?
Clearly states it searches shipbuilding terminology by keyword, with explicit mention of Korean language support. Distinguishes from siblings like get_term_detail and translate_term by positioning itself as the primary search for any shipbuilding question.
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?
Explicitly states to use this for ANY shipbuilding question, including Korean terms, with examples. Does not explicitly mention when not to use, but context implies alternatives for specific detail or translation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Translate a shipbuilding term between English and Korean.
Args: term: The term to translate (English or Korean) from_lang: Source language ('en' or 'ko', default 'en') to_lang: Target language ('en' or 'ko', default 'ko')
Returns: The translated term and related information
| Name | Required | Description | Default |
|---|---|---|---|
| term | Yes | ||
| to_lang | No | ko | |
| from_lang | No | en |
| 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 for behavioral disclosure. It only mentions that the tool translates and returns information, but does not specify read-only nature, error handling, or permissions needed. This lack of side-effect and constraint information reduces 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 concise (around 80 words) and well-structured with a clear first sentence defining the tool's purpose, followed by a docstring-style breakdown of arguments and return value. No redundant or irrelevant information.
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?
The tool is simple, and the description covers basic functionality and parameters. However, it lacks context on edge cases (e.g., term not found), behavior for invalid inputs, and whether the operation is safe. The existence of an output schema reduces the need to detail return values, but completeness is only moderate given these 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 input schema has 0% parameter description coverage, so the description must compensate. It explains each parameter: 'term' is the term to translate (English or Korean), and 'from_lang'/'to_lang' accept 'en' or 'ko' with defaults. This adds value beyond the schema's minimal titles and types.
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 action: 'Translate a shipbuilding term between English and Korean.' This specific verb+resource+scope distinguishes it from sibling tools like get_term_detail or search_ship_terms, which serve different purposes.
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 for translation tasks but provides no explicit guidance on when to use this tool versus siblings, such as get_term_detail for term details or search_ship_terms for broader searches. No alternatives or exclusions are mentioned.
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.
v0.1.0get_term_detailget_term_statisticslist_categories_toollist_terms_by_categorysearch_ship_termstranslate_termScored across 6 tools
Each tool has a distinct, non-overlapping purpose: detailed term lookup, database statistics, category listing, category-specific term listing, keyword search, and translation. No ambiguity.
All tools follow a verb_noun pattern with snake_case, though 'list_categories_tool' has a redundant '_tool' suffix and 'translate_term' omits the second underscore. Still, the pattern is clear and predictable.
6 tools is well-scoped for a terminology reference server. Each tool serves a necessary function without redundancy or bloat.
The tools provide full read-only coverage: search, list by category, get details, translate, and view statistics. No CRUD gaps since the server likely only exposes a read-only database. All common lookup workflows are supported.
Versioned documentation registry and semantic search for AI tools and coding assistants.
Neuronto Agentic Resource Discovery ARD Index. Search every ARD registry + 31,411 verified tools.
Structured knowledge base for AI agent solutions. Search, explore, and retrieve build logs.
Code intelligence for coding agents: semantic, AST, graph, and full-text search. 279+ languages.