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., "@korea_weather What's the weather in Seoul right now?"
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.
본 MCP 서버는 기상청 단기예보 조회서비스 API를 기반으로 동작하는 MCP 서버입니다.
Korea Weather MCP Server는 기상청의 날씨 정보를 수집하여, MCP 프로토콜을 통해 Claude나 Cursor와 같은 MCP 클라이언트(Host)에 제공합니다. 이 서버는 기상 정보를 활용하는 다양한 응용 서비스에 쉽게 연동될 수 있습니다.
Related MCP server: MCP Weather Free
기상청 단기예보 API 연동
MCP 형식의 기상 정보 제공
data.go.kr에서 기상청 단기예보 API를 신청하고 API 키를 발급받습니다.
다음 명령어를 사용해 Smithery에서 서버를 설치하고 Claude Desktop에 등록합니다. 설치 과정에서 API 키 입력을 요구하면 발급받은 키를 입력합니다.
npx -y @smithery/cli mcp add ohhan777/korea_weather --client claudeClaude Desktop을 재시작하여 사용하면 됩니다.
소스코드를 클론하고 의존성을 설치합니다.
git clone https://github.com/ohhan777/korea_weather.git
cd korea_weather
uv sync환경변수에 API 키를 설정합니다.
export KOREA_WEATHER_API_KEY="발급받은_API_키"개발 서버를 실행합니다.
# HTTP 모드로 실행 (http://localhost:8081)
uv run smithery dev
# 또는 Smithery Playground로 대화형 테스트
uv run smithery playgrounddata.go.kr에서 기상청 단기예보 API 활용 신청 후 API 키를 발급받습니다.
github에서 소스코드를 다운받아 실행해봅니다.
git clone https://github.com/ohhan777/korea_weather.git
cd korea_weather
uv sync
uv run korea_weather.pyMCP 클라이언트(Host)에 서버를 등록합니다.
Claude Desktop의 설정 파일은 보통 아래 경로에 위치합니다.
C:\Users\[사용자 이름]\AppData\Roaming\Claude\claude_desktop_config.json
(파일이 없다면 새로 생성)
Cursor의 경우: 상단의 톱니바퀴 아이콘 → MCP → Add new global MCP server 선택
아래 예시와 같은 형식으로 설정 파일을 작성합니다. (디렉토리 경로와 API 키는 환경에 맞게 수정)
{
"mcpServers": {
"korea_weather": {
"command": "uv",
"args": [
"--directory",
"C:\\ai\\PyProjects\\korea_weather",
"run",
"korea_weather.py"
],
"env": {
"KOREA_WEATHER_API_KEY": "Input Your API Key Here!"
}
}
}
}GitHub에 코드를 푸시한 후, smithery.ai/new에서 GitHub 저장소를 연결하면 Smithery가 자동으로 서버를 빌드하고 호스팅합니다.
>> 제주 국제 공항 현재 날씨를 알려줘.
>> 내일 오후에 서울 남대문에 놀러가려고 하는데 우산을 챙겨야할까?
>> 오늘 오후에 세차하기에 괜찮은 날씨일까?pyproject.toml 참고
본 프로젝트는 내부 시험용으로 개발되었으며, 별도의 라이선스 규정 없이 자유롭게 배포 및 수정이 가능합니다.
개발자: 한국항공우주연구원 오한 (ohhan@kari.re.kr)
2026-02: Smithery v4 연동 — smithery dev/smithery playground 로컬 개발 지원, create_server() 팩토리 패턴 도입
2026-02: 서버 구조를 리팩터링하고(공통 API 요청 처리, 좌표 변환 캐시), MCP 도구 설명을 보강했습니다.
2026-02: httpx/dotenv 미설치 환경에서도 동작하도록 표준 라이브러리 기반 HTTP fallback 경로를 추가했습니다.
2026-02: 오프라인 환경에서도 실행 가능한 단위 테스트(tests/test_korea_weather.py)를 추가했습니다.
특정 좌표의 초단기(6시간) 예보를 조회합니다.
| Name | Required | Description | Default |
|---|---|---|---|
| lat | Yes | ||
| lon | 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 of behavioral disclosure. It mentions 'queries' which indicates a read operation, and specifies the 6-hour forecast horizon, providing some context. However, it does not mention any potential side effects, authentication requirements, or coordinate system details, which leaves gaps in behavioral 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 clear sentence that is front-loaded with the key action and resource. It contains no unnecessary 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?
Given the low complexity of the tool (two number parameters, output schema present), the description covers the essential purpose and context (6-hour forecast at a coordinate). It could be more complete by noting the coordinate format or that it is read-only, but these are partially implied by 'queries' and the output schema.
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 two parameters (lat, lon) with no descriptions, and the description adds only that it targets a 'specific coordinate' without explaining the format, units, or ranges. This minimal addition fails to compensate for the 0% schema description 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 tool 'queries' the 'very short-term (6-hour) forecast' for 'a specific coordinate', using a specific verb and resource. It distinguishes from siblings by specifying the 6-hour horizon, which sets it apart from observations or longer-term forecasts.
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 use for very short-term forecasts but does not explicitly mention when to use it over the sibling tools like get_nowcast_observation or get_short_term_forecast. There are no exclusion criteria or alternative recommendations, so usage guidance is only implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
특정 좌표의 현재 관측 날씨를 조회합니다.
| Name | Required | Description | Default |
|---|---|---|---|
| lat | Yes | ||
| lon | 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 for behavioral disclosure. It only states that current observed weather is retrieved, without revealing any details about data source, update timing, units, response format, or potential errors. This lack of transparency is a significant gap for a tool with zero annotations.
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, concise sentence that immediately states the action and object. It is front-loaded and contains no redundant or filler language, making it highly efficient.
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 two parameters and an output schema, the core purpose is adequately stated. However, the description lacks usage guidelines and parameter semantics, which would make it more complete. The presence of sibling tools makes the missing usage guidance more notable, but the description is not wholly incomplete.
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 describes 'lon' and 'lat' as numbers with 0% description coverage. The description says '특정 좌표' (specific coordinates), which implies the two parameters are latitude and longitude, but does not add units, format, or range constraints. This minimal addition only partially compensates for the lack of schema-level descriptions.
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 identifies the action ('조회합니다' / retrieves) and the resource ('현재 관측 날씨' / current observed weather) at specific coordinates. It distinguishes itself from sibling forecast tools by explicitly stating '관측' (observation).
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. The description does not mention the sibling tools or explain that this is for observational data rather than forecasts. The only inference comes from the tool name, which is not explicit within the description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
특정 좌표의 단기(3~5일) 예보를 조회합니다.
| Name | Required | Description | Default |
|---|---|---|---|
| lat | Yes | ||
| lon | 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 full burden. It only indicates a read-only 'retrieval' action, but does not disclose any behavioral traits such as data update frequency, geographic coverage, units, or any limitations. For a simple read operation, this is minimal and lacks useful context.
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, front-loaded sentence that directly states the action, resource, and scope with no filler or redundancy. It is efficiently concise 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?
For a low-complexity tool with an output schema, the description covers the essential purpose and time range. However, it lacks any mention of forecast intervals, units, or data source, and the absence of annotations leaves some behavioral gaps. It is adequate but not 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 description must compensate. It mentions 'specific coordinates' which generically relates to both lon and lat, but does not clarify coordinate format, order, allowable ranges, or other constraints. The parameter names themselves are self-explanatory, but the description adds little beyond that.
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 a specific action ('조회합니다' - retrieves) on a specific resource ('단기(3~5일) 예보' - short-term 3-5 day forecast) with a clear scope ('특정 좌표' - specific coordinates). The time range '3~5일' distinguishes it from nowcast siblings, making the purpose unambiguous.
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 short-term (3-5 day) forecasts at given coordinates, but does not explicitly state when to use this tool instead of the nowcast siblings or provide exclusions. The context is clear but guidance is only implicit, not direct.
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.2.0get_nowcast_forecastget_nowcast_observationget_short_term_forecastScored across 3 tools
Each tool targets a distinct temporal scope: current observation, 6-hour nowcast, and 3-5 day forecast. No overlap in purpose.
All tool names follow the get_ prefix with descriptive qualifiers and nouns, using snake_case consistently. The naming pattern is uniform and predictable.
With only 3 tools, the server is tightly scoped to its purpose of providing weather data. Each tool covers a necessary aspect, and the count falls within the ideal 3-15 range.
The core weather data needs are covered: current conditions, short-term nowcast, and multi-day forecast. Minor gaps like long-range forecasts or alerts exist, but the primary use case is well-served.
MCP server for weather with reasoning — umbrella advice, outdoor checks, city comparisons.
An MCP server for weather information by @kulybaba
An MCP server for weather information by @kulybaba
Hosted MCP server for Xweather weather data: conditions, forecasts, alerts, and more.