Use manifest-defined endpoints for tool routing

docs/contracts/tool-service-mcp/protocol-v0.2-bundle-discovery.md

@@ -4,7 +4,7 @@
 - 기준일: 2026-07-30
 - 대체 대상: push 등록 방식(v0.1). 채택하지 않은 이유는 §2
 - 조회 endpoint: `GET {manifestUrl}` — Tool Service가 제공
-- 실행 endpoint: `POST {baseEndpoint}/{toolName}` — 현재 구현
+- 실행 endpoint: Tool Service manifest의 top-level `endpoint` 또는 `_meta.endpoint` — 현재 구현
 
 ## 1. 계약 범위와 원칙
 
@@ -15,7 +15,7 @@ MCP Server는 자기 설정에 선언된 bundle의 매니페스트를 **주기
 |---|---|
 | MCP가 가져온다 | Tool Service는 매니페스트를 제공만 한다. MCP에 등록 요청을 보내지 않는다 |
 | 조회 대상은 설정이 정한다 | 어떤 bundle이 이 MCP에 속하는지는 배포 시점 YAML로 확정된다 |
-| **라우팅 주소는 설정이 소유한다** | 호출 대상 주소는 MCP 설정에서만 온다. 매니페스트가 바꿀 수 없다 |
+| **Tool Server domain은 포털이, Tool endpoint는 Tool Service가 소유한다** | 포털은 Tool Server의 `serviceDomain`과 `manifestPath`만 제공하고, 개별 Tool 실행 endpoint는 Tool Service manifest의 top-level `endpoint` 또는 `_meta.endpoint`에서 온다 |
 | 매니페스트는 전체 상태 | 응답은 그 bundle의 Tool 전체 목록이다. 증분 없음 |
 | 조회 성공이 생존 신호 | 별도 heartbeat·TTL 장치가 없다 |
 | bundle 단위 조회 격리 | 한 bundle의 조회 실패가 다른 bundle의 조회를 중단시키지 않는다 |
@@ -170,7 +170,7 @@ MCP는 이 경우 직전 매니페스트를 그대로 유지한다. **선택 기
 | `revision` | 아니오 | 매니페스트 버전. 변경 감지·로그·ETag에만 쓰인다 |
 | `tools` | 예 | 이 bundle이 노출하는 Tool 전체. 빈 배열은 "노출할 Tool 없음"이다 |
 
-`baseEndpoint`는 **매니페스트에 넣지 않는다.** 넣어도 MCP는 무시한다(§1 세 번째 원칙).
+Tool 실행 endpoint는 각 Tool의 top-level `endpoint` 또는 `_meta.endpoint`에 넣는다. 상대 경로를 쓰면 포털 registry의 `serviceDomain` 뒤에 붙고, 절대 URL을 쓰면 Tool Service manifest가 제공한 실행 주소 원천으로 그대로 사용한다. HTTP(S)가 아닌 scheme은 거부한다.
 
 ### `tools[]` 필드
 
@@ -299,7 +299,7 @@ management port(운영 기본 9090)에서 MCP가 알고 있는 bundle의 조회
 이미 구현되어 있는 계약이다. Tool Service는 아래를 받을 수 있어야 한다.
 
 ```text
-POST {baseEndpoint}/{toolName}
+POST {endpoint}
 Content-Type: application/json
 guid, x-request-id, mcp-session-id, employee-no, virtual-employee-no
 Authorization: <설정에 따라 전달>