Integrates with KakaoCloud OpenAPI to manage compute resources (VMs, volumes), network (VPC, subnets, security groups), load balancers, transit gateways, container clusters (Kubernetes), and databases (MySQL).
Integrates with KakaoCloud Container Pack to create and manage Kubernetes clusters and node pools.
Integrates with KakaoCloud Data Store to create and manage managed MySQL databases.
Click on "Install 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., "@KakaoCloud OpenAPI MCP Server Show me my running VM instances"
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.
카카오클라우드 OpenAPI 문서를 AI 코딩 어시스턴트(Claude Code, Codex 등)에서 쉽게 활용할 수 있도록 하는 MCP(Model Context Protocol) 서버입니다.
카카오클라우드에서 VM을 만들거나 VPC를 구성할 때, API 문서를 일일이 찾아가며 코딩하는 것은 번거롭습니다.
이 MCP 서버를 설치하면 AI 어시스턴트가 자동으로 카카오클라우드 API 정보를 조회하여 정확한 코드를 생성해줍니다.
사용자: "카카오클라우드에서 VM 만드는 파이썬 스크립트 작성해줘"
AI → MCP 서버에서 VM 생성 API 정보 조회
AI → VPC, Subnet, Security Group, Keypair 등 사전 조건 파악
AI → 인증 방법 포함한 완전한 파이썬 스크립트 생성Related MCP server: GreenNode MCP Server
서비스 | 설명 | 엔드포인트 수 |
BCS (Beyond Compute Service) | VM, 볼륨, 이미지, 스냅샷, 키페어 (인스턴스 상태 변경 통합 액션 API 포함) | 54 |
VPC | VPC, 서브넷, 보안 그룹, 라우트 테이블, 공인 IP | 28 |
Load Balancer | 로드 밸런서, 리스너, 대상 그룹 (생성 시 대상 그룹/리스너 동시 구성 지원) | 6 |
Transit Gateway | VPC 간 네트워크 연결 | 4 |
Container Pack | 관리형 Kubernetes (K8s Engine) | 16 |
Data Store | 관리형 MySQL | 18 |
총 126개 API 엔드포인트 + 5개 워크플로우 가이드
모든 OpenAPI 호출은 카카오클라우드 CloudTrail에 자동 기록되며, 콘솔에서 'OpenAPI' 서비스 이벤트로 조회할 수 있습니다.
Python 3.12+
uv (Python 패키지 매니저)
별도 클론 없이 바로 사용할 수 있습니다.
# uv가 없다면 먼저 설치
curl -LsSf https://astral.sh/uv/install.sh | sh설치 확인:
uvx kakaocloud-openapi-mcp --help소스코드를 직접 받아서 사용하거나 수정하고 싶을 때 사용합니다.
# 저장소 클론
git clone https://github.com/chals-go/kakaocloud-openapi-mcp.git
cd kakaocloud-openapi-mcp
# 의존성 설치
uv syncPyPI 설치 (추천):
claude mcp add kakaocloud -- uvx kakaocloud-openapi-mcpGitHub 설치:
claude mcp add kakaocloud -- uv --directory /path/to/kakaocloud-openapi-mcp run kakaocloud-openapi-mcpclaude_desktop_config.json 파일에 추가:
PyPI 설치 (추천):
{
"mcpServers": {
"kakaocloud": {
"command": "uvx",
"args": ["kakaocloud-openapi-mcp"]
}
}
}GitHub 설치:
{
"mcpServers": {
"kakaocloud": {
"command": "uv",
"args": ["--directory", "/path/to/kakaocloud-openapi-mcp", "run", "kakaocloud-openapi-mcp"]
}
}
}설정 파일 위치:
macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%\Claude\claude_desktop_config.json
.vscode/settings.json에 추가:
PyPI 설치 (추천):
{
"mcp": {
"servers": {
"kakaocloud": {
"command": "uvx",
"args": ["kakaocloud-openapi-mcp"]
}
}
}
}GitHub 설치:
{
"mcp": {
"servers": {
"kakaocloud": {
"command": "uv",
"args": ["--directory", "/path/to/kakaocloud-openapi-mcp", "run", "kakaocloud-openapi-mcp"]
}
}
}
}Cursor Settings > MCP에서 추가하거나, .cursor/mcp.json에:
PyPI 설치 (추천):
{
"mcpServers": {
"kakaocloud": {
"command": "uvx",
"args": ["kakaocloud-openapi-mcp"]
}
}
}GitHub 설치:
{
"mcpServers": {
"kakaocloud": {
"command": "uv",
"args": ["--directory", "/path/to/kakaocloud-openapi-mcp", "run", "kakaocloud-openapi-mcp"]
}
}
}MCP 서버는 5개의 도구를 제공합니다. AI 어시스턴트가 자동으로 적절한 도구를 선택하여 호출합니다.
search_kakaocloud_api키워드로 카카오클라우드 API를 검색합니다. 한국어와 영어 모두 지원합니다.
입력: { "query": "VM 생성" }
출력: 관련 API 엔드포인트 목록 (서비스, method, path, 설명)사용 예시:
"VM 생성" → BCS 인스턴스 생성 API + 관련 워크플로우
"load balancer" → 로드 밸런서 관련 API 목록
"보안 그룹" → VPC 보안 그룹 CRUD API 목록
get_api_detail특정 API 엔드포인트의 상세 스펙을 조회합니다.
입력: { "service": "bcs", "endpoint_id": "create-instance" }
출력: 파라미터, 요청/응답 바디, 전체 URL, 인증 방법, 예제서비스 별칭 지원:
vm, instance, compute → BCS
vpc, 네트워크 → VPC
lb, 로드밸런서 → Load Balancer
k8s, kubernetes → Container Pack
mysql, db → Data Store
get_service_overview서비스의 전체 개요와 엔드포인트 목록을 조회합니다.
입력: { "service": "vm" }
출력: 서비스 설명, Base URL, 전체 엔드포인트 테이블, 관련 서비스get_workflow특정 작업의 전체 API 호출 흐름을 단계별로 안내합니다.
입력: { "task": "VM 인스턴스 생성" }
출력: 인증 → VPC → 서브넷 → 보안 그룹 → 키페어 → 인스턴스 생성 순서제공 워크플로우:
워크플로우 | 설명 |
| VM 인스턴스 생성 (VPC/서브넷/보안그룹/키페어 포함) |
| VPC 네트워크 전체 구성 |
| 로드 밸런서 설정 (대상 그룹, 리스너 포함) |
| Kubernetes 클러스터 생성 및 노드 풀 구성 |
| 관리형 MySQL 데이터베이스 생성 |
get_auth_guide카카오클라우드 API 인증 방법을 안내합니다.
입력: (없음)
출력: 토큰 발급 방법, 코드 예제 (Python, curl), 토큰 사용법정적 참조 데이터를 Resource URI로 조회할 수 있습니다.
URI | 설명 |
| 전체 서비스 목록 (JSON) |
| 특정 서비스의 전체 API 스펙 (JSON) |
| 인증 가이드 데이터 (JSON) |
아래는 Claude Code에 이 MCP를 연결한 후 실제로 대화한 내용입니다.
사용자 요청:
카카오클라우드에 vm을 만드는 python 스크립트 만들어줘,
test-vpc, test-subnet1에 만들어주고
우분투 24.04, 윈도우 2022 두개 만들거고
vm이름은 test-ubuntu, test-window 로 해줘
그리고 security group은 test-ubuntu-sg, test-window-sg 로 만들고
ubuntu 서버는 22port 인바운드, 윈도우서버는 3389 인바운드 설정되게 해줘AI가 MCP를 통해 자동으로 수행한 작업:
get_workflow("VM 인스턴스 생성") → 인증 → VPC 조회 → 보안 그룹 → 인스턴스 생성 흐름 파악
get_auth_guide() → IAM 토큰 발급 코드 작성
get_api_detail("bns-vpc", "create-security-group") → 보안 그룹 생성 파라미터 확인
get_api_detail("bns-vpc", "create-security-group-rule") → 인바운드 규칙 파라미터 확인
get_api_detail("bcs", "create-instance") → VM 생성 필수 파라미터 확인
AI가 생성한 코드:
"""
카카오클라우드 VM 생성 스크립트
- test-vpc / test-subnet1 에 Ubuntu 24.04, Windows 2022 VM 2대 생성
- 각 VM에 보안 그룹 생성 및 인바운드 규칙 설정
"""
import os
import sys
import requests
# ──────────────────────────────────────────────
# 설정값 (환경변수 또는 직접 입력)
# ──────────────────────────────────────────────
ACCESS_KEY_ID = os.environ.get("KAKAO_ACCESS_KEY_ID", "YOUR_ACCESS_KEY_ID")
SECRET_KEY = os.environ.get("KAKAO_SECRET_KEY", "YOUR_SECRET_KEY")
UBUNTU_2404_IMAGE_ID = os.environ.get("UBUNTU_2404_IMAGE_ID", "YOUR_UBUNTU_24.04_IMAGE_ID")
WINDOWS_2022_IMAGE_ID = os.environ.get("WINDOWS_2022_IMAGE_ID", "YOUR_WINDOWS_2022_IMAGE_ID")
KEY_NAME = os.environ.get("KAKAO_KEY_NAME", "YOUR_KEYPAIR_NAME")
FLAVOR = os.environ.get("KAKAO_FLAVOR", "m2a.large")
# ──────────────────────────────────────────────
# API 엔드포인트
# ──────────────────────────────────────────────
IAM_URL = "https://iam.kakaocloud.com/identity/v3/auth/tokens"
BNS_BASE = "https://bns.kr-central-2.kakaocloud.com/api/v1"
BCS_BASE = "https://bcs.kr-central-2.kakaocloud.com/api/v1"
HEADERS = {"Content-Type": "application/json"}
def get_token():
"""IAM 인증 토큰 발급"""
payload = {
"auth": {
"identity": {
"methods": ["application_credential"],
"application_credential": {
"id": ACCESS_KEY_ID,
"secret": SECRET_KEY,
},
}
}
}
resp = requests.post(IAM_URL, json=payload, headers=HEADERS)
resp.raise_for_status()
token = resp.headers["X-Subject-Token"]
print("[OK] 토큰 발급 완료")
return token
def auth_headers(token):
return {"X-Auth-Token": token, "Content-Type": "application/json"}
def find_vpc(token, name="test-vpc"):
"""VPC 이름으로 ID 조회"""
resp = requests.get(f"{BNS_BASE}/vpcs", headers=auth_headers(token))
resp.raise_for_status()
for vpc in resp.json().get("vpcs", []):
if vpc.get("name") == name:
print(f"[OK] VPC 발견: {name} ({vpc['id']})")
return vpc["id"]
sys.exit(f"[ERROR] VPC '{name}'을 찾을 수 없습니다.")
def find_subnet(token, name="test-subnet1"):
"""서브넷 이름으로 ID 조회"""
resp = requests.get(f"{BNS_BASE}/subnets", headers=auth_headers(token))
resp.raise_for_status()
for subnet in resp.json().get("subnets", []):
if subnet.get("name") == name:
print(f"[OK] Subnet 발견: {name} ({subnet['id']})")
return subnet["id"]
sys.exit(f"[ERROR] Subnet '{name}'을 찾을 수 없습니다.")
def create_security_group(token, name, vpc_id, description=""):
"""보안 그룹 생성"""
payload = {"name": name, "vpc_id": vpc_id, "description": description}
resp = requests.post(f"{BNS_BASE}/security-groups", json=payload, headers=auth_headers(token))
resp.raise_for_status()
sg = resp.json()
sg_id = sg.get("id") or sg.get("security_group", {}).get("id")
print(f"[OK] 보안 그룹 생성: {name} ({sg_id})")
return sg_id
def add_inbound_rule(token, sg_id, port):
"""보안 그룹에 TCP 인바운드 규칙 추가"""
payload = {
"direction": "inbound",
"protocol": "tcp",
"port_range_min": port,
"port_range_max": port,
"remote_ip_prefix": "0.0.0.0/0",
}
resp = requests.post(f"{BNS_BASE}/security-groups/{sg_id}/rules", json=payload, headers=auth_headers(token))
resp.raise_for_status()
print(f"[OK] 인바운드 규칙 추가: port {port} (0.0.0.0/0)")
def create_instance(token, name, image_id, subnet_id, sg_id, key_name=None):
"""VM 인스턴스 생성"""
payload = {
"instance_name": name,
"image_id": image_id,
"flavor": FLAVOR,
"networks": [{"subnet_id": subnet_id, "security_groups": [sg_id]}],
}
if key_name:
payload["key_name"] = key_name
resp = requests.post(f"{BCS_BASE}/instances", json=payload, headers=auth_headers(token))
resp.raise_for_status()
instance = resp.json()
instance_id = instance.get("id") or instance.get("instance", {}).get("id")
print(f"[OK] 인스턴스 생성 요청: {name} ({instance_id})")
return instance_id
def main():
print("=" * 50)
print("카카오클라우드 VM 생성 스크립트")
print("=" * 50)
# 1. 인증
token = get_token()
# 2. VPC / Subnet 조회
vpc_id = find_vpc(token, "test-vpc")
subnet_id = find_subnet(token, "test-subnet1")
# 3. 보안 그룹 생성
print("\n--- 보안 그룹 생성 ---")
ubuntu_sg_id = create_security_group(token, "test-ubuntu-sg", vpc_id, "Ubuntu SSH 접근용")
add_inbound_rule(token, ubuntu_sg_id, 22)
windows_sg_id = create_security_group(token, "test-window-sg", vpc_id, "Windows RDP 접근용")
add_inbound_rule(token, windows_sg_id, 3389)
# 4. VM 인스턴스 생성
print("\n--- VM 인스턴스 생성 ---")
ubuntu_id = create_instance(token, "test-ubuntu", UBUNTU_2404_IMAGE_ID, subnet_id, ubuntu_sg_id, KEY_NAME)
windows_id = create_instance(token, "test-window", WINDOWS_2022_IMAGE_ID, subnet_id, windows_sg_id)
# 5. 결과 요약
print("\n" + "=" * 50)
print("생성 완료 요약")
print("=" * 50)
print(f" Ubuntu VM : test-ubuntu ({ubuntu_id})")
print(f" - 이미지 : Ubuntu 24.04")
print(f" - 보안그룹: test-ubuntu-sg (SSH 22)")
print(f" Windows VM : test-window ({windows_id})")
print(f" - 이미지 : Windows Server 2022")
print(f" - 보안그룹: test-window-sg (RDP 3389)")
print(f" VPC : test-vpc ({vpc_id})")
print(f" Subnet : test-subnet1 ({subnet_id})")
print("=" * 50)
print("\n※ 인스턴스 생성은 비동기 처리됩니다. 콘솔에서 상태를 확인하세요.")
if __name__ == "__main__":
main()실행 방법:
# 환경변수 설정
export KAKAO_ACCESS_KEY_ID="발급받은_ACCESS_KEY_ID"
export KAKAO_SECRET_KEY="발급받은_SECRET_KEY"
export UBUNTU_2404_IMAGE_ID="Ubuntu_24.04_이미지_ID"
export WINDOWS_2022_IMAGE_ID="Windows_2022_이미지_ID"
export KAKAO_KEY_NAME="SSH_키페어_이름"
# 실행
pip install requests
python create_vms.py스크립트 동작 흐름:
1. IAM 토큰 발급
2. test-vpc, test-subnet1 이름으로 VPC/Subnet ID 조회
3. 보안 그룹 생성
├── test-ubuntu-sg → TCP 22 (SSH) 인바운드
└── test-window-sg → TCP 3389 (RDP) 인바운드
4. VM 인스턴스 생성
├── test-ubuntu — Ubuntu 24.04 + SSH 키페어
└── test-window — Windows Server 2022사용자는 한 줄의 요청만 했지만, AI가 MCP를 통해 카카오클라우드 API의 인증 방식, 엔드포인트 URL, 파라미터 형식을 자동으로 파악하여 바로 실행 가능한 스크립트를 생성했습니다.
# VPC 네트워크 구성
"카카오클라우드에서 VPC를 만들고, 퍼블릭/프라이빗 서브넷을 구성하는 코드를 작성해줘."
# Kubernetes 클러스터 배포
"카카오클라우드에서 Kubernetes 클러스터를 생성하고, 워커 노드 3대로 구성하는 스크립트를 만들어줘."
# MySQL 데이터베이스 생성
"카카오클라우드에서 MySQL 8.0 데이터베이스를 생성하는 코드 작성해줘."
# 로드 밸런서 설정
"카카오클라우드에서 로드 밸런서를 만들고 2대의 웹 서버에 트래픽을 분산하는 코드 작성해줘."uv run pytest tests/ -vuv run mcp dev src/kakaocloud_mcp/server.pyMCP Inspector가 브라우저에서 열리며, 각 도구를 직접 호출하고 결과를 확인할 수 있습니다.
uv run kakaocloud-openapi-mcp서버는 stdio 모드로 동작하므로, MCP 클라이언트가 stdin/stdout을 통해 통신합니다.
kakaocloud-openapi-mcp/
├── pyproject.toml # 프로젝트 설정 및 의존성
├── src/
│ └── kakaocloud_mcp/
│ ├── server.py # MCP 서버 진입점
│ ├── tools/ # MCP Tool 구현
│ │ ├── search.py # search_kakaocloud_api
│ │ ├── detail.py # get_api_detail
│ │ ├── overview.py # get_service_overview
│ │ ├── workflow.py # get_workflow
│ │ └── auth.py # get_auth_guide
│ ├── resources/
│ │ └── services.py # MCP Resource 핸들러
│ ├── data/
│ │ ├── loader.py # JSON 데이터 로더 + 검색 인덱스
│ │ ├── auth.json # 인증 가이드 데이터
│ │ ├── workflows.json # 워크플로우 데이터
│ │ └── services/ # 서비스별 API 스펙 JSON
│ │ ├── bcs.json
│ │ ├── bns-vpc.json
│ │ ├── bns-load-balancer.json
│ │ ├── bns-transit-gateway.json
│ │ ├── container-pack.json
│ │ └── data-store-mysql.json
│ └── utils/
│ └── search.py # 키워드 검색 유틸리티
└── tests/
├── test_search.py # 검색 + 데이터 로더 테스트
└── test_tools.py # Tool 함수 테스트각 서비스의 API 스펙은 src/kakaocloud_mcp/data/services/ 디렉토리의 JSON 파일에 정의됩니다.
새 엔드포인트를 추가하려면:
해당 서비스의 JSON 파일을 열고 endpoints 배열에 추가
keywords 필드에 한국어/영어 검색 키워드를 충분히 포함
uv run pytest tests/ -v 로 테스트 통과 확인
엔드포인트 구조:
{
"id": "create-instance",
"method": "POST",
"path": "/instances",
"summary": "VM 인스턴스 생성",
"summaryKo": "VM 인스턴스 생성",
"keywords": ["vm 생성", "인스턴스 만들기"],
"parameters": [],
"requestBody": { ... },
"responses": { "202": { "description": "..." } }
}MIT License
특정 카카오클라우드 API 엔드포인트의 상세 스펙을 조회한다.
Args:
service: 서비스 ID 또는 별칭 (예: "bcs", "vm", "vpc")
endpoint_id: 엔드포인트 ID (예: "create-instance", "list-volumes")
| Name | Required | Description | Default |
|---|---|---|---|
| service | Yes | ||
| endpoint_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. The description does not disclose behavioral traits such as authentication requirements, rate limits, or what constitutes 'detailed specifications'. It only says it queries specs, which is insufficient for full 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 with a single purpose sentence followed by parameter descriptions. It is front-loaded with the core action and immediately useful example values. No redundant or irrelevant content.
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 (2 string params, output schema exists), the description is adequate but not thorough. It lacks usage context, output structure hints (though output schema covers that), and any explanation of 'detailed specifications'. Missing guidance on when to use over siblings.
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?
Although schema description coverage is 0%, the description adds meaning by providing concrete examples for both parameters: service ('bcs', 'vm', 'vpc') and endpoint_id ('create-instance', 'list-volumes'). This helps the agent understand plausible values beyond the schema's plain string type.
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 queries detailed specifications of a specific KakaoCloud API endpoint ('특정 카카오클라우드 API 엔드포인트의 상세 스펙을 조회한다'). It distinguishes from siblings like 'get_auth_guide', 'get_service_overview', 'get_workflow', and 'search_kakaocloud_api' by focusing on a specific endpoint's specs.
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 on when to use this tool versus alternatives. The description does not mention prerequisites, when not to use it, or conditions for effectiveness. Sibling tools are present but not referenced.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
카카오클라우드 API 인증 방법, 토큰 발급, 코드 예제를 반환한다.
| 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 provided; description implies a read-only retrieval but does not explicitly confirm safety or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with clear action and content; no unnecessary words.
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?
Output schema exists; description is adequate for a simple reference tool, though could mention it's a guide.
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?
No parameters exist, and schema coverage is 100%; description adds meaningful context about the content (auth, tokens, examples).
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?
Description specifies the tool returns authentication methods, token issuance, and code examples, clearly distinguishing it from sibling tools like 'get_api_detail' or 'get_service_overview'.
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; usage is implied but not stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
카카오클라우드 서비스의 전체 개요와 엔드포인트 목록을 조회한다.
Args:
service: 서비스 ID 또는 별칭 (예: "bcs", "vm", "vpc", "lb", "mysql")
| Name | Required | Description | Default |
|---|---|---|---|
| service | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are absent, leaving the description to handle behavioral transparency. The description only states the retrieval action, with no information about read-only nature, auth requirements, latency, or side effects. Behavioral traits beyond the basic action are not disclosed.
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 and includes a structured Args section. Every sentence adds value, and the key information is front-loaded. There is no fluff or redundancy.
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 presence of an output schema (not detailed here), the description need not fully explain return values. However, it lacks guidance on error conditions, permission requirements, or how the tool fits with siblings. The 0% schema coverage and no annotations leave gaps in 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. The description adds examples of valid service values (e.g., 'bcs', 'vm') and explains that the parameter is a service ID or alias, providing context beyond the bare schema. However, format constraints or default behaviors are not specified.
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 an overview and endpoint list for a KakaoCloud service. It uses a specific verb-resource combination and is distinguishable from sibling tools like get_api_detail or search_kakaocloud_api, which focus on different aspects.
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 an overview or endpoint list is needed, but it does not explicitly specify when to use this tool versus alternatives like get_api_detail or get_auth_guide. No when-not or exclusion criteria are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
특정 작업(예: VM 생성, VPC 구성)의 전체 API 호출 흐름을 조회한다.
Args:
task: 작업 설명 (예: "VM 인스턴스 생성", "VPC 네트워크 구성")
| Name | Required | Description | Default |
|---|---|---|---|
| task | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description fails to disclose behavioral traits such as authentication requirements, side effects, or any constraints. As a read operation with no clear side effects, the description should still note if it is safe or destructive, but it does not.
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 stating purpose and one line for the parameter. Every word adds value, and the structure is 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 a single parameter and an output schema, the description gives the core idea but omits behavioral context or any caveats. It is functional but minimal.
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 has 0% description coverage for the single parameter 'task'. The description provides examples (e.g., 'VM 인스턴스 생성') and a brief description ('작업 설명'), adding meaning beyond the schema. However, it lacks details on format or constraints.
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 the entire API call flow for a specific task, which is a specific verb and resource. It is distinct from sibling tools like get_api_detail (details of a single API) and get_service_overview.
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. The description only states what it does, leaving the agent to infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
카카오클라우드 API를 키워드로 검색하여 관련 엔드포인트 목록을 반환한다.
Args:
query: 검색어 (예: "VM 생성", "로드밸런서", "vpc subnet")
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description does not disclose any behavioral traits such as rate limits, authorization requirements, or side effects. It only explains the function, leaving the agent uninformed about operational constraints.
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 short and to the point, with a docstring style. It uses minimal text to convey the core function, though it could be slightly more 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 presence of an output schema, the lack of return value description is acceptable. However, for a search tool, additional context about result ordering, limits, or search behavior would improve 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 coverage is 0%, but the description adds example queries for the 'query' parameter, which helps understanding. However, it doesn't provide full semantic richness beyond examples, such as expected format or accepted values.
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 searches for KakaoCloud APIs by keyword and returns related endpoints. It uses specific verb 'search' and resource 'API'. However, it doesn't differentiate from siblings like get_api_detail, leaving some ambiguity.
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 on when to use this tool vs alternatives. It doesn't mention what scenarios are appropriate or when to use other tools like get_api_detail. No exclusions or comparisons provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Each tool targets a distinct facet of the API documentation: specific endpoint details, authentication guide, service overview, workflow sequences, and keyword search. No overlap.
All tools follow a consistent 'verb_noun' pattern with snake_case (e.g., get_api_detail, search_kakaocloud_api). Names are predictable and clearly indicate the action and resource.
With 5 tools, the server covers the essential documentation needs without excess or deficiency. Each tool serves a clear purpose and earns its place.
The tool set covers overview, details, authentication, workflows, and search. A minor gap is the lack of a tool to list all available services without prior knowledge, though search can partially compensate.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Provides capabilities that let LLM agents perform a range of infrastructure management tasks.
Manage HepCloud (Turkish cloud) servers and managed PostgreSQL from your AI assistant. OAuth 2.1.
Manage Rackspace Spot Kubernetes Cloudspaces, node pools, and VMs from your AI assistant.
Korea-native MCP gateway: Korean commerce, payments, messaging, gov & finance APIs for AI agents.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/chals-go/kakaocloud-openapi-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
