How do I use K-Targo Subway MCP Server?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@K-Targo Subway MCP Server show me the timetable for Gangnam Station going northbound" 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.

K-Targo Subway MCP Server

by slicequeue

Overview Schema Related Servers Score Discussions

TypeScript

Remote

🇰🇷 K-Targo Subway MCP Server

한국 지하철 정보를 제공하는 MCP (Model Context Protocol) 서버입니다.

🚇 주요 기능

지하철역 검색: 역명으로 지하철역 정보 검색
열차 시간표 조회: 특정 역의 열차 시간표 조회
실시간 지하철 정보: Tago API를 통한 실시간 데이터 제공
MCP 표준 준수: Model Context Protocol 표준을 따르는 도구 제공

Related MCP server: subway-congestion-mcp

🛠️ 설치 및 사용

Installing via Smithery

To install k-targo-subway-mcp-server for Claude Desktop automatically via Smithery:

npx -y @smithery/cli install @slicequeue/k-targo-subway-mcp-server --client claude

1. 공공데이터 API 키 설정

이 서버는 국토교통부_(TAGO)_지하철정보 API를 사용합니다. 사용하기 전에 API 키를 설정해야 합니다.

API 정보

API 명: 국토교통부_(TAGO)_지하철정보
API URL: https://www.data.go.kr/data/15098554/openapi.do
제공기관: 국토교통부
데이터 형식: JSON

API 키 발급

공공데이터포털에 가입
"국토교통부_(TAGO)_지하철정보" API 신청
승인 후 발급받은 API 키를 환경변수로 설정

환경변수 설정

# Windows
set GOV_API_KEY=your_api_key_here

# macOS/Linux
export GOV_API_KEY=your_api_key_here

# .env 파일 사용 (권장)
echo "GOV_API_KEY=your_api_key_here" > .env

2. npx로 즉시 실행 (권장)

npx k-targo-subway-mcp-server

3. npm으로 설치

npm install k-targo-subway-mcp-server

4. 글로벌 설치

npm install -g k-targo-subway-mcp-server

📦 MCP 도구

1. 지하철역 검색 (`search_subway_station`)

지하철역명으로 역 정보를 검색합니다.

입력 파라미터:

stationName (string): 검색할 역명

사용 예시:

// "강남" 역 검색
const result = await searchSubwayStationTool.handler({
  stationName: "강남"
}, {});

2. 열차 시간표 조회 (`get_station_timetable`)

특정 역의 열차 시간표를 조회합니다.

입력 파라미터:

stationCode (string): 역 코드
direction (string): 방향 (상행/하행)

사용 예시:

// 강남역 상행 시간표 조회
const result = await getStationTimetableTool.handler({
  stationCode: "0222",
  direction: "상행"
}, {});

🏗️ 프로젝트 구조

src/
├── config/           # 설정 파일
│   └── index.ts
├── external/         # 외부 API 연동
│   ├── common/       # 공통 유틸리티
│   └── tago-subway/  # Tago 지하철 API
│       ├── api.ts    # API 클라이언트
│       ├── service.ts # 비즈니스 로직
│       ├── dtos/     # 데이터 전송 객체
│       └── types/    # 타입 정의
├── tools/           # MCP 도구들
│   ├── subway.ts    # 지하철 관련 도구
│   ├── index.ts     # 도구들 통합
│   └── types.ts     # 도구 타입 정의
├── utils/           # 유틸리티
│   ├── PackageJsonUtil.ts
│   └── ResponseUtil.ts
└── index.ts         # 메인 진입점

🔧 개발 환경 설정

1. 의존성 설치

npm install

2. API 키 설정

# .env 파일 생성
echo "GOV_API_KEY=your_api_key_here" > .env

# 또는 환경변수로 설정
export GOV_API_KEY=your_api_key_here  # macOS/Linux
set GOV_API_KEY=your_api_key_here     # Windows

.env 파일 예시

# 국토교통부_(TAGO)_지하철정보 API 키
# 공공데이터포털(https://www.data.go.kr/)에서 발급받은 API 키를 설정하세요
# API URL: https://www.data.go.kr/data/15098554/openapi.do
GOV_API_KEY=your_public_data_api_key_here

# 예시:
# GOV_API_KEY=abc123def456ghi789jkl012mno345pqr678stu901vwx234yz567

3. 개발 서버 실행

npm run dev

4. 빌드

npm run build

5. 테스트

# 전체 테스트
npm test

# API 테스트
npm run test:api

# 특정 역 테스트
npm run test:api:station

📡 API 연동

국토교통부_(TAGO)_지하철정보 API

API 명: 국토교통부_(TAGO)_지하철정보
API URL: https://www.data.go.kr/data/15098554/openapi.do
제공기관: 국토교통부
기본 URL: https://api.tago.go.kr
인증: 공공데이터 API 키 기반 인증 (GOV_API_KEY 환경변수)
데이터 형식: JSON
API 키 발급: 공공데이터포털에서 "국토교통부_(TAGO)_지하철정보" 신청

환경변수 설정

# 필수 환경변수
GOV_API_KEY=your_public_data_api_key_here

주요 엔드포인트

GET /subway-station/search: 지하철역 검색
GET /subway-station/{stationCode}/timetable: 열차 시간표 조회

🎯 사용 예제

MCP 클라이언트 설정

MCP 클라이언트에서 이 서버를 사용하려면 다음과 같이 설정하세요:

{
  "mcpServers": {
    "k-targo-subway": {
      "command": "npx",
      "args": ["k-targo-subway-mcp-server"],
      "env": {
        "GOV_API_KEY": "your_targo_api_key_here"
      }
    }
  }
}

MCP 클라이언트에서 사용

// 지하철역 검색
const searchResult = await mcpClient.callTool('search_subway_station', {
  stationName: '강남'
});

// 시간표 조회
const timetableResult = await mcpClient.callTool('get_station_timetable', {
  stationCode: '0222',
  direction: '상행'
});

CLI에서 직접 실행

# npx로 실행 (권장)
npx k-targo-subway-mcp-server

# 글로벌 설치 후 실행
k-targo-subway-mcp-server

# 또는 npm 스크립트로 실행
npm start

🔄 개발 워크플로우

새 기능 추가: src/tools/에 새 도구 파일 생성
API 연동: src/external/에 외부 API 클라이언트 추가
타입 정의: 필요한 타입들을 정의
테스트: test/ 디렉토리에 테스트 코드 작성
빌드 및 배포: npm run build 후 배포

📚 주요 개념

MCP Tool

사용자가 호출할 수 있는 함수입니다. 입력 스키마와 핸들러 함수로 구성됩니다.

TAGO API

국토교통부에서 제공하는 지하철 정보 API입니다. 공공데이터포털을 통해 제공됩니다.

지하철역 코드

각 지하철역은 고유한 코드를 가지고 있습니다 (예: 강남역 = "0222").

🚀 배포

# 빌드
npm run build

# npm 배포
npm publish

# 실행
node dist/index.js

📄 라이선스

MIT License

🤝 기여하기

Fork the Project
Create your Feature Branch (git checkout -b feature/AmazingFeature)
Commit your Changes (git commit -m 'Add some AmazingFeature')
Push to the Branch (git push origin feature/AmazingFeature)
Open a Pull Request

📞 문의

GitHub: https://github.com/slicequeue/k-targo-subway-mcp-server
Issues: https://github.com/slicequeue/k-targo-subway-mcp-server/issues

🙏 감사의 말

국토교통부_(TAGO)_지하철정보 - 지하철 정보 제공
공공데이터포털 - API 서비스 제공
Model Context Protocol - MCP 표준
Node.js - 런타임 환경

Available Tools

3 tools

get_all_subway_timetablesget_all_subway_timetablesC

지하철역의 모든 요일, 모든 방향의 시간표를 한 번에 조회합니다. 평일/토요일/일요일, 상행/하행 모든 조합을 제공합니다.

ParametersJSON Schema

Name	Required	Description
`stationId`	Yes	지하철역 ID (search_subway_station 도구로 먼저 검색하여 얻을 수 있음)
`pageNo`	No	페이지 번호 (기본값: 1)
`numOfRows`	No	한 페이지당 결과 수 (기본값: 100)
`filterNonArrive`	No	정차하지 않는 열차 필터링 여부 (기본값: true)
`delayMsec`	No	API 호출 간 지연 시간 (밀리초, 기본값: 1000)

TDQS

C2.9/5.0

Behavior2/5

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 describes what data is returned (all combinations of days/directions) but doesn't mention pagination behavior, rate limits, authentication requirements, error conditions, or response format. For a tool with 5 parameters and no annotations, 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.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise - just two sentences that efficiently convey the tool's comprehensive scope. Every word earns its place, with no redundant information. The structure is front-loaded with the core purpose followed by details about what combinations are included.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with 5 parameters, no annotations, and no output schema, the description is insufficiently complete. It doesn't explain the pagination system (pageNo, numOfRows), the implications of filterNonArrive, or what the delayMsec parameter controls. The agent would struggle to understand the full behavior and output format from this description alone.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 100% schema description coverage, the baseline is 3. The description doesn't add any parameter-specific information beyond what's already documented in the schema. It mentions the need to obtain stationId from another tool, but this is already covered in the schema's parameter description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

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 all timetables for a subway station across all days and directions. It specifies the scope ('모든 요일, 모든 방향') and the comprehensive nature of the results. However, it doesn't explicitly differentiate from the sibling 'get_subway_timetable' tool, which likely provides more specific filtering options.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

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_subway_timetable'. It mentions that stationId can be obtained from 'search_subway_station', but this is parameter documentation rather than usage context. There's no explicit when/when-not guidance or comparison with sibling tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_subway_timetableget_subway_timetableC

지하철역의 시간표를 조회합니다. 요일별, 상하행별 시간표를 제공합니다.

ParametersJSON Schema

Name	Required	Description
`stationId`	Yes	지하철역 ID (search_subway_station 도구로 먼저 검색하여 얻을 수 있음)
`dailyType`	Yes	요일 구분 (WEEKDAY: 평일, SATURDAY: 토요일, SUNDAY: 일요일/공휴일)
`upDownType`	Yes	상하행 구분 (UP: 상행/서울방향, DOWN: 하행/서울반대방향)
`pageNo`	No	페이지 번호 (기본값: 1)
`numOfRows`	No	한 페이지당 결과 수 (기본값: 20)
`filterNonArrive`	No	정차하지 않는 열차 필터링 여부 (기본값: true)

TDQS

C2.9/5.0

Behavior2/5

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 what the tool does (retrieves timetables) but lacks critical behavioral details: it doesn't mention pagination behavior (implied by pageNo/numOfRows parameters), filtering behavior (implied by filterNonArrive), response format, error conditions, or rate limits. For a read operation with multiple parameters, 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.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise and front-loaded: two short sentences that directly state the tool's purpose and scope. There is no wasted language or redundancy, making it efficient for an agent to parse.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity (6 parameters, no annotations, no output schema), the description is incomplete. It doesn't address key aspects like pagination, filtering, response format, or error handling. For a tool with multiple operational parameters and no structured output definition, the description should provide more context to guide effective use.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The description adds minimal parameter semantics beyond the schema. It mentions '요일별, 상하행별 시간표' (timetables by day type and direction), which aligns with the dailyType and upDownType parameters, but doesn't explain the other parameters (stationId, pageNo, numOfRows, filterNonArrive). With 100% schema description coverage, the baseline is 3, and the description doesn't significantly enhance understanding.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: '지하철역의 시간표를 조회합니다' (retrieves subway station timetables). It specifies the resource (subway station timetables) and scope (by day type and direction). However, it doesn't explicitly differentiate from sibling tools like 'get_all_subway_timetables' or 'search_subway_station', which would be needed for 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.

Usage Guidelines2/5

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 sibling tools like 'get_all_subway_timetables' or 'search_subway_station', nor does it specify prerequisites (e.g., that stationId must be obtained from another tool first, as hinted in the schema but not in the description). This leaves the agent without clear usage context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

search_subway_stationsearch_subway_stationA

지하철역 이름으로 역 정보를 검색합니다. 역 ID, 역 이름, 노선 정보를 반환합니다. '역' 접미사는 자동으로 제거됩니다 (예: '강남역' → '강남').

ParametersJSON Schema

Name	Required	Description
`stationName`	Yes	검색할 지하철역 이름 (예: 강남, 강남역, 홍대입구, 홍대입구역)
`pageNo`	No	페이지 번호 (기본값: 1)
`numOfRows`	No	한 페이지당 결과 수 (기본값: 10)

TDQS

A3.9/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries full burden of behavioral disclosure. It effectively describes key behaviors: the search functionality, the return data structure (station ID, name, line information), and the automatic suffix removal feature. However, it doesn't mention potential limitations like search accuracy, error conditions, or pagination behavior beyond the parameters.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is perfectly sized with two focused sentences. The first sentence states the core purpose, the second adds important behavioral detail about suffix handling with a clear example. Every element earns its place with zero wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a search tool with 3 parameters, 100% schema coverage, but no output schema or annotations, the description provides adequate but not complete context. It covers the main functionality and a key behavioral feature (suffix removal), but doesn't describe the return format in detail or potential error scenarios that would help an agent use it effectively.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents all three parameters thoroughly. The description adds minimal value beyond the schema - it mentions the automatic suffix removal which relates to 'stationName' parameter processing, but doesn't provide additional semantic context about parameter interactions or usage patterns.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the specific action ('검색합니다' - searches), resource ('지하철역 정보' - subway station information), and scope ('역 이름으로' - by station name). It distinguishes itself from sibling tools like 'get_all_subway_timetables' and 'get_subway_timetable' by focusing on station information search rather than timetable retrieval.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage context (searching by station name) but doesn't explicitly state when to use this tool versus the sibling timetable tools. It provides some guidance about the automatic suffix removal feature, but lacks explicit 'when-to-use' or 'when-not-to-use' comparisons with alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

3 tool updatesv1.0.0Jan 13, 2026
- First observedget_all_subway_timetables
- First observedget_subway_timetable
- First observedsearch_subway_station

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.5/5.0

Disambiguation5/5

Each tool has a clearly distinct purpose: get_all_subway_timetables retrieves comprehensive timetables for all days and directions, get_subway_timetable provides filtered timetables by day and direction, and search_subway_station finds station information. There is no overlap or ambiguity between these functions.

Naming Consistency5/5

All tool names follow a consistent snake_case pattern with a clear verb_noun structure: get_all_subway_timetables, get_subway_timetable, and search_subway_station. The naming is predictable and readable throughout.

Tool Count3/5

With only 3 tools, the server feels thin for a subway domain that might benefit from additional operations like route planning or real-time status. However, the tools cover core timetable and station search functions, making it borderline but functional.

Completeness4/5

The tools provide good coverage for timetable retrieval and station search, but there are minor gaps such as missing operations for route calculation, fare information, or real-time updates. Agents can work around these with the available tools for basic queries.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

Need Help?

Reddit Discussion

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

onebusaway-mcp-server A
io.github.cyanheads
Real-time transit stops, routes, arrivals, vehicle positions, and schedules via OneBusAway APIs.
Travel & Transportation Location Services
1521
Wmata A
io.github.pipeworx-io
Washington Metro real-time + static rail/bus data. Free key required.
Travel & Transportation Location Services
412
Korea Flight MCP A
io.github.kimnchai
14 Korean airports flight info + Incheon arrival/departure congestion + facility search.
Travel & Transportation Location Services
82
arjunkmrm-lta-mcpOAuth
ai.smithery
Provide real-time transportation data including bus arrivals, train service alerts, carpark availa…
Travel & Transportation Location Services
22

Related MCP Servers

NS Travel MCP Server
Travel & Transportation Location Services
lauragift21
F
license
Not graded
quality
D
maintenance
Provides real-time Dutch Railways (NS) data for journey planning, live departures, disruptions, and station search.
Updated a year ago (2025-06-09 21:52 UTC)
3
-
subway-congestion-mcp
Travel & Transportation Location Services Search
jinjukimink
A
license
Not graded
quality
D
maintenance
Provides real-time and predicted congestion data, route optimization, and train arrival information for Seoul subway lines 1-8, helping users choose the best travel times.
Updated 7 months ago (2026-01-23 08:04 UTC)
MIT
realestate-mcp
Real Estate Government Data Open Data
hlucent
A
license
A
quality
B
maintenance
Provides South Korean real estate transaction price lookup (sales and rent) for apartments, row houses, single-family homes, and officetels via MCP tools using public data from data.go.kr.
Updated 14 days ago (2026-08-23 14:00 UTC)
8
51
MIT
airkorea-forecast-alert-mcp
Weather Services Government Data Open Data
hlucent
A
license
Not graded
quality
C
maintenance
Enables querying Korean air quality forecasts, weekly ultrafine dust forecasts, high-concentration PM2.5 forecasts, particulate matter alarm statuses, ozone advisories, and yellow dust advisories from the AirKorea OpenAPI.
Updated 14 days ago (2026-08-23 13:59 UTC)
MIT

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/slicequeue/k-targo-subway-mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server

🇰🇷 K-Targo Subway MCP Server

🚇 주요 기능

🛠️ 설치 및 사용

Installing via Smithery

1. 공공데이터 API 키 설정

API 정보

API 키 발급

환경변수 설정

2. npx로 즉시 실행 (권장)

3. npm으로 설치

4. 글로벌 설치

📦 MCP 도구

1. 지하철역 검색 (search_subway_station)

2. 열차 시간표 조회 (get_station_timetable)

🏗️ 프로젝트 구조

🔧 개발 환경 설정

1. 의존성 설치

2. API 키 설정

.env 파일 예시

3. 개발 서버 실행

4. 빌드

5. 테스트

📡 API 연동

국토교통부_(TAGO)_지하철정보 API

환경변수 설정

주요 엔드포인트

🎯 사용 예제

MCP 클라이언트 설정

MCP 클라이언트에서 사용

CLI에서 직접 실행

🔄 개발 워크플로우

📚 주요 개념

MCP Tool

TAGO API

지하철역 코드

🚀 배포

📄 라이선스

🤝 기여하기

📞 문의

🙏 감사의 말

Available Tools

Tool Schema Changelog

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

MCP directory API

1. 지하철역 검색 (`search_subway_station`)

2. 열차 시간표 조회 (`get_station_timetable`)