Custom MCP 수정 후 Web ChatGPT에 변경 사항을 반영하는 방법

1. 가장 중요한 결론

Custom MCP를 수정한 뒤 Web ChatGPT에서 변경 사항을 반영시키는 문제는 단순히

“터널을 재시작할까, MCP를 다시 등록할까?”

의 2가지 문제가 아닙니다.

실제로는 대략 다음 계층으로 나누어 생각해야 합니다.

MCP 소스 코드
    ↓
MCP 서버 프로세스
    ↓
공개 transport / tunnel
    ↓
MCP protocol discovery
    ↓
ChatGPT의 MCP 앱 등록 상태 / tool snapshot
    ↓
개별 ChatGPT 채팅에 주입된 tool definitions
    ↓
모델의 실제 named-tool invocation

그리고 인증이 별도의 횡단 계층으로 끼어 있습니다.

OAuth / auth metadata
       ↓
transport + app registration 둘 다에 영향

따라서 무엇을 변경했느냐에 따라 필요한 조치가 달라집니다.

가장 실용적으로 줄이면 이렇습니다.

내부 코드만 바뀜 → 서버 reload/restart.

연결 경로만 꼬임 → tunnel/transport reconnect.

tool contract가 바뀜 → ChatGPT 쪽 MCP 등록 상태를 새로 discovery하게 해야 함.

ChatGPT 등록 상태는 최신인데 기존 채팅만 구버전 → 새 채팅.

등록 상태 자체를 갱신할 방법이 현재 UI에 없음 → MCP 재등록.

이 마지막 부분이 특히 현재 Business Web ChatGPT 환경에서 중요합니다.

2. OpenAI 문서와 실제 Web UI를 분리해서 생각해야 합니다

현재 OpenAI 공식 문서는 상당히 흥미로운 상태입니다.

문서에는 custom MCP 앱을 구성하면서 endpoint를 입력하고 인증을 설정한 뒤 Scan Tools****를 클릭하라고 명시되어 있습니다. 동시에 Business에서는 게시된 앱의 tool/metadata를 현재 업데이트할 수 없고, 변경하려면 recreate/republish해야 한다고 설명합니다. (OpenAI Help Center)

그런데 실제 사용 중인 Business Web ChatGPT에는 **Scan Tools**라는 메뉴나 도구가 없습니다.

이 두 사실은 충돌해 보이지만, 문서 맨 위의 다음 설명과 연결됩니다.

Full MCP는 Business/Enterprise/Edu에 beta로 rollout 중이며 functionality, UI, permissions가 변경될 수 있다.

즉 현재 상황은 다음처럼 보는 것이 가장 안전합니다.

OpenAI documentation
    └─ 제품이 지향하는 개념적 workflow

실제 Business Web UI
    └─ 현재 해당 workspace/account에 실제 배포된 workflow

둘이 반드시 1:1 대응하는 것은 아닙니다. (OpenAI Help Center)

따라서 앞으로는 Scan Tools라는 UI 명칭 자체를 운영 개념으로 사용하면 안 됩니다.

대신 저는 다음 용어를 사용하는 것이 좋다고 봅니다.

registration-level tool rediscovery

즉,

“ChatGPT에 등록된 MCP app이 MCP 서버의 현재 tool definitions를 다시 발견하게 만드는 과정”

입니다.

현재 어떤 UI에서는 Refresh일 수 있고, 어떤 UI에서는 앱 재생성일 수 있고, 어떤 환경에서는 MCP를 삭제했다가 다시 등록해야 할 수도 있습니다.

핵심은 버튼 이름이 아니라 결과적으로 새로운 tool snapshot이 만들어졌느냐입니다.

3. OpenAI 문서에서 신뢰할 만한 부분과 덜 신뢰해야 할 부분

이 구분이 굉장히 중요합니다.

비교적 신뢰도가 높은 부분

OpenAI 문서는 현재 MCP 앱에 대해 **“frozen snapshot”**이라는 개념을 명시적으로 설명합니다.

관리자가 MCP 앱을 승인한 뒤에는 ChatGPT가 사용 가능한 tools와 inputs의 고정 snapshot을 사용하고, 개발자가 서버를 수정하더라도 변경 사항이 자동 적용되는 것은 아니라고 합니다. (OpenAI Help Center)

이것은 실제 경험과도 매우 잘 일치합니다.

또한 OpenAI는 live MCP와 frozen snapshot이 달라지면 tool call이 실패할 수 있고, optional parameter 추가처럼 backward-compatible한 변경은 계속 동작할 수도 있다고 명시합니다. (OpenAI Help Center)

이것도 실제 MCP 개발 경험과 정확히 맞습니다.

주의해서 봐야 하는 부분

반면 다음과 같은 것은 실제 UI에 그대로 존재한다고 전제하면 안 됩니다.

Scan Tools 버튼
메뉴 위치
특정 Settings 경로
Refresh 버튼의 존재 여부
Draft/Publish UX의 정확한 구조
각 플랜에서 동일하게 보이는 관리 화면

특히 공식 문서가 현재도 Scan Tools****를 명시하지만 실제 Business UI에는 없다는 것이 좋은 반례입니다.

따라서:

OpenAI 문서는 상태 모델과 제한사항을 이해하는 자료로 사용하고, UI 조작 순서는 실제 계정에서 검증한다.

이것이 현재 MCP 개발에서는 가장 안전한 접근입니다.

4. MCP 서버 프로세스 계층

가장 아래쪽부터 보겠습니다.

예를 들어 MCP tool이:

search_files(query)

이고 내부에서 실행하는 DB 쿼리만 변경했다고 하겠습니다.

기존:

SELECT ...

새 버전:

SELECT ... optimized ...

하지만 다음은 전혀 바뀌지 않았습니다.

tool name
description
inputSchema
outputSchema
annotations

이것은 runtime implementation change입니다.

ChatGPT가 알아야 할 내용이 없습니다.

필요한 것은 보통 MCP 서버 프로세스에 새로운 코드가 올라가게 하는 것뿐입니다.

code 변경
   ↓
server restart / hot reload

여기서 tunnel까지 재시작해야 할 이유는 원칙적으로 없습니다.

5. 그런데 왜 “터널만 껐다 켰는데 해결되는” 경우가 있는가

여기서 실제 경험과 이론이 어긋나는 것처럼 보입니다.

터널은 보통:

ChatGPT
    ↓
public URL
    ↓
tunnel
    ↓
localhost MCP

에서 transport 역할을 합니다.

터널 자체가 MCP의 inputSchema를 이해하는 것은 아닙니다.

그런데 터널을 restart하면 여러 일이 동시에 발생할 수 있습니다.

기존 HTTP 연결 종료
MCP transport session 종료
새 transport connection 생성
MCP initialize 재실행
server capability 재확인
server process와 새 연결
경우에 따라 tool discovery 재실행

따라서 겉으로는:

“cloudflared 껐다 켰더니 해결됐다.”

처럼 보입니다.

하지만 실제 원인이 꼭 Cloudflare tunnel의 캐시였다는 뜻은 아닙니다.

더 정확하게는:

transport reconnect가 MCP session/discovery를 부수 효과로 다시 발생시켰을 가능성

이 있습니다.

따라서 tunnel restart는 schema refresh API로 생각해서는 안 됩니다.

6. MCP protocol 자체에도 tool discovery라는 계층이 있습니다

MCP 서버는 자신이 제공하는 tool들을 클라이언트에게 공개합니다.

개념적으로:

tools/list

입니다.

MCP 공식 specification에는 서버 capability로:

tools:
    listChanged: true

를 광고할 수 있고, tool이 추가·제거·수정된 경우:

notifications/tools/list_changed

를 보낼 수 있도록 정의되어 있습니다. (Model Context Protocol)

즉 MCP 프로토콜 자체는:

tool이 변경됨
       ↓
서버가 client에 notification
       ↓
client가 tools/list 다시 요청

이라는 동적 갱신 구조를 가질 수 있습니다.

여기서 중요한 점이 하나 있습니다.

MCP protocol이 tool refresh를 지원한다는 사실과 ChatGPT가 그 변경을 워크스페이스에 자동 승인한다는 것은 전혀 다른 문제입니다.

7. MCP discovery와 ChatGPT의 보안/승인 snapshot은 다른 계층입니다

이것이 전체 문제의 중심입니다.

MCP protocol에서는 서버가:

render_chart 변경됨!

이라고 알려줄 수 있습니다.

하지만 ChatGPT 입장에서는 custom MCP가 조직에서 사용할 수 있는 action을 제공하므로:

서버가 새로운 tool을 추가했다
→ 자동으로 사용자에게 제공

해 버리는 것은 보안 측면에서 위험할 수 있습니다.

따라서 OpenAI는 승인된 app에 대해 frozen snapshot 개념을 둡니다. (OpenAI Help Center)

즉:

Live MCP server
tools/list
        ↓
ChatGPT registration/approval layer
        ↓
approved/frozen tool definitions

입니다.

그래서 MCP의 notifications/tools/list_changed가 정상 작동한다고 하더라도:

MCP protocol level
        =
변경 감지 가능

이지,

ChatGPT workspace level
        =
새 tool 자동 사용

을 의미하지는 않습니다.

8. Business에서는 이것이 더 중요합니다

현재 OpenAI 공식 문서는 Business에 대해:

게시된 앱의 tools 또는 metadata를 업데이트하려면 recreate and republish해야 한다.

고 설명합니다. (OpenAI Help Center)

이 제약 자체는 중요한 정보입니다.

하지만 앞서 설명한 것처럼 문서가 말하는 구체적인 UI:

Scan Tools
Draft
Publish
...

가 현재 Business UI와 정확하게 일치한다고 보기는 어렵습니다.

따라서 실제 Business 환경에서는 다음처럼 해석하는 것이 더 좋습니다.

서버 schema 변경
       ↓
현재 ChatGPT가 새 schema를 발견했는가?
       ↓
YES ─→ 새 채팅에서 검증
       ↓
NO
       ↓
현재 UI에 registration-level refresh 기능이 있는가?
       ↓
YES ─→ 그 기능 사용
NO  ─→ MCP 재등록

여기서 MCP 재등록은 단순한 편법이 아닙니다.

현재 Business UI에서 registration snapshot을 강제로 다시 만들 수 있는 가장 확실한 수단일 수 있습니다.

9. MCP를 “새로 등록하면” 무엇이 달라지는가

여기서 재등록의 의미를 이해하는 것이 중요합니다.

기존 MCP:

App registration A
    endpoint
    authentication
    tool snapshot v10

를 삭제하고 다시 등록하면 개념적으로:

App registration B
    endpoint
    authentication
    fresh MCP discovery
    tool snapshot v11

이 만들어집니다.

따라서 재등록은 여러 상태를 한 번에 초기화할 가능성이 있습니다.

MCP app identity
endpoint association
authentication state 일부
tool definitions
input schemas
output schemas
tool metadata
승인 snapshot

그래서 다음과 같은 상황에서는 터널 restart로 해결되지 않지만 재등록으로 해결되는 것이 자연스럽습니다.

서버         v11
터널         정상
tools/list   v11
ChatGPT app  v10 snapshot

터널을 아무리 껐다 켜도:

ChatGPT app = v10

이면 모델은 계속 v10 schema만 봅니다.

재등록:

ChatGPT app v10
        ↓
discard
        ↓
fresh registration
        ↓
ChatGPT app v11

이 되어야 해결됩니다.

10. 그리고 한 단계 더 있습니다: 개별 채팅의 tool definition

이것도 매우 중요합니다.

ChatGPT의 app registration이 이미 v11이라고 하더라도 현재 열려 있는 채팅은 v10 tool definition을 가지고 있을 수 있습니다.

구조를 단순화하면:

MCP server
   v11
    ↓
ChatGPT app registry
   v11
    ↓
Conversation 생성
    ↓
conversation tool-definition snapshot

입니다.

그래서 이런 상황이 가능합니다.

서버                    v11
ChatGPT MCP registration v11

기존 채팅                v10
새 채팅                  v11

이 경우 MCP를 재등록할 필요가 없습니다.

새 채팅만 만들면 됩니다.

앞선 local-blog Phase 13에서 정확히 이 형태가 관찰되었습니다. 기존 채팅의 tool-definition은 과거 schema를 가지고 있었지만 fresh chat에서는 render_diagram과 render_chart의 새로운 semantic parameters가 노출되었습니다.

11. 그래서 “새 채팅”과 “MCP 재등록”은 완전히 다른 조치입니다

이 구분을 명확히 해야 합니다.

새 채팅

해결하는 것:

conversation-local tool schema stale

해결하지 못하는 것:

ChatGPT app registration 자체가 stale

MCP 재등록

해결할 수 있는 것:

registration-level stale snapshot
endpoint metadata
tool discovery 상태
일부 auth/connection metadata

그리고 새로 등록한 후에는 fresh chat에서 검증하는 것이 안전합니다.

즉 재등록과 새 채팅은 경쟁 관계가 아닙니다.

registration refresh
       +
fresh conversation

처럼 서로 다른 캐시를 제거합니다.

12. 변경 종류별로 다시 분류해 보면

실무에서는 다음 표가 가장 유용합니다.

여기서 중요한 점은 현재 Business에는 Scan Tools****라는 실제 UI가 있다는 가정을 제거했다는 것입니다.

재-discovery가 필요할 경우 사용할 수 있는 실제 UI 기능이 없다면 MCP 재등록을 registration refresh 방법으로 사용하는 것이 현재 환경에서는 합리적입니다.

13. Optional parameter 추가가 가장 헷갈리는 사례입니다

예를 들어 기존 tool이:

{
  "query": "string"
}

이었다고 하겠습니다.

서버 v2:

{
  "query": "string",
  "limit": "number, optional"
}

으로 바뀝니다.

구버전 ChatGPT snapshot도:

{
  "query": "hello"
}

를 보내면 서버가 받을 수 있습니다.

그래서 tool 호출은 성공합니다.

OpenAI도 optional parameter 추가와 같은 backward-compatible 변경은 기존 frozen snapshot에서도 계속 작동할 수 있다고 설명합니다.

하지만 모델이 보는 schema가 아직:

query

뿐이라면 limit이라는 field는 사용할 수 없습니다.

이 때문에 개발자가 착각하기 쉽습니다.

“새 버전도 정상 작동하네. schema도 업데이트됐겠지.”

아닙니다.

정확한 결론은:

기존 schema와 새 서버가 호환된다

일 뿐입니다.

새 schema가 ChatGPT에 반영됐다는 증거가 아닙니다.

14. required parameter 추가는 바로 문제를 드러냅니다

기존 ChatGPT snapshot:

{
  "query": "hello"
}

새 서버:

{
  "query": "hello",
  "workspaceId": "required"
}

이면 ChatGPT는 계속:

{
  "query": "hello"
}

를 보내려고 합니다.

그리고 서버는:

INVALID_PARAMS
workspaceId required

를 반환합니다.

OpenAI 문서가 설명하는 live MCP와 frozen snapshot mismatch가 바로 이런 경우입니다.

이 상황에서:

tunnel restart
tunnel restart
tunnel restart

를 반복해도 app-level schema가 바뀌지 않으면 해결되지 않습니다.

현재 Business UI에 tool refresh 기능이 없다면 이 시점에서 MCP 재등록을 고려하는 것이 맞습니다.

15. Tool description만 변경했어도 중요할 수 있습니다

예를 들어:

search_files
"Search files."

에서:

search_files
"Semantically searches source content.
Use find_files instead when locating paths."

로 description을 변경했다고 하겠습니다.

JSON schema는 그대로입니다.

서버 호출도 정상입니다.

하지만 모델의 tool selection에는 큰 영향을 줄 수 있습니다.

LLM에게:

tool name
description
parameter description
schema

가 모두 tool-selection context이기 때문입니다.

따라서 description 변경은 protocol적으로는 가벼워 보여도 LLM behavior 관점에서는 contract change로 보는 것이 좋습니다.

16. Output schema도 contract입니다

이 부분도 종종 놓칩니다.

기존:

{
  "result": "..."
}

새 버전:

{
  "result": "...",
  "quality": {
    "status": "pass"
  }
}

정도라면 backward compatible할 수 있습니다.

하지만:

{
  "result": "..."
}

에서:

{
  "data": {
    "result": "..."
  }
}

으로 바꾸면 adapter가 이전 output contract를 기대할 경우 문제가 생길 수 있습니다.

따라서 다음 모두를 하나의 tool contract로 봐야 합니다.

tool name
description
inputSchema
outputSchema
annotations
read/write semantics

17. Tunnel URL이 바뀌면 이야기가 완전히 달라집니다

예를 들어 ChatGPT에:

https://abc.example.com/mcp

가 등록되어 있는데 tunnel restart 후 실제 endpoint가:

https://xyz.example.com/mcp

가 되었다면 이것은 cache 문제가 아닙니다.

등록된 endpoint 자체가 잘못된 것입니다.

이 경우:

새 채팅

은 아무 효과가 없습니다.

MCP 등록 정보 수정
또는
MCP 재등록

이 필요합니다.

그래서 custom MCP를 자주 수정한다면 public endpoint를 최대한 고정시키는 것이 매우 중요합니다.

이렇게 만들면:

ChatGPT
    ↓
https://local-blog.example.com/mcp
    ↓
stable tunnel
    ↓
현재 MCP server

서버를 열 번 바꿔도 ChatGPT 등록 endpoint는 그대로 유지됩니다.

18. OAuth/auth 변경은 별도 클래스입니다

다음은 schema 변경보다 훨씬 강한 변경으로 봐야 합니다.

OAuth issuer
authorization endpoint
token endpoint
scope
audience
client registration
인증 mechanism

이런 것을 바꾸면 ChatGPT가 가지고 있는:

authorization state
connection metadata
token
issuer discovery

가 현재 서버와 맞지 않을 수 있습니다.

따라서 auth 관련 구조 변경 후에는 tunnel restart보다 connection/app registration 재설정 가능성을 먼저 생각하는 것이 좋습니다.

19. 공식 문서가 틀렸다기보다 “레이어가 다르다”고 보는 것이 좋습니다

조금 더 정확하게 표현하면:

“OpenAI 문서가 실제 환경을 대표하지 못하는 경우가 있다.”

가 맞습니다.

특히 현재처럼 베타 롤아웃 중일 때는:

documentation version
backend rollout version
workspace feature flag
plan
account
UI experiment
region
client bundle version

등이 일치하지 않을 수 있습니다.

현재 공식 문서도 바로 그 가능성을 인정하며 UI와 permissions가 변경될 수 있다고 명시하고 있습니다.

그래서 MCP 문제를 디버깅할 때 증거 우선순위를 저는 이렇게 두는 것이 좋다고 봅니다.

1순위 — 실제 named-tool schema와 호출 결과

실제로 현재 ChatGPT에:

render_chart(template, data, ...)

가 보이는가?

그리고 호출되는가?

2순위 — MCP 서버 자체에서 관찰되는 현재 상태

server_version
tool_schema_version
build_sha
tools/list

3순위 — 실제 현재 Web ChatGPT UI

Refresh가 있는가? 재등록밖에 없는가?

4순위 — OpenAI 공식 문서

제품의 의도된 제약/개념을 이해하는 데 매우 중요하지만, 버튼명과 UI workflow는 실제 환경과 어긋날 수 있음.

이 순서가 실전에서는 가장 신뢰성이 높습니다.

20. 그래서 MCP마다 server_version과 tool_schema_version을 분리해야 합니다

이건 여러 custom MCP를 운용할 경우 거의 필수에 가깝다고 생각합니다.

예:

{
  "server_version": "1.5.0",
  "tool_schema_version": 11
}

왜 두 개를 나누느냐면:

server 1.5.1
schema 11

은 내부 구현만 변경된 것일 수 있습니다.

반대로:

server 1.6.0
schema 12

라면 ChatGPT가 알아야 하는 contract 변경이 있다는 뜻입니다.

그러면 디버깅할 때:

get_workspace_info
→ server=1.6.0
→ schema=12

인데 실제 ChatGPT tool definition은 schema 11 수준이라면 즉시 결론을 낼 수 있습니다.

서버 최신
transport 정상
ChatGPT-side tool snapshot stale

입니다.

터널을 조사할 필요가 크게 줄어듭니다.

21. 한 단계 더 나아가 schema_fingerprint도 추천합니다

예를 들어:

{
  "server_version": "1.5.0",
  "tool_schema_version": 11,
  "tool_schema_fingerprint": "sha256:53bd..."
}

처럼 두는 것입니다.

fingerprint는 예를 들어 다음을 canonicalize해서 계산합니다.

모든 tool name
description
inputSchema
outputSchema
annotations

그리고 tool 이름 순으로 정렬한 뒤 hash합니다.

그러면:

서버 fingerprint = ABC
ChatGPT가 실제 노출하는 schema = XYZ

같은 차이를 자동화된 검증으로 잡아낼 수 있습니다.

22. 변경을 세 종류로 나누는 것이 가장 좋습니다

A. Runtime change

ChatGPT가 알 필요 없는 변경입니다.

SQL
filesystem implementation
성능
logging
bug fix
내부 validation
dependency update

필요 조치:

server reload/restart

B. Contract change

ChatGPT가 알아야 하는 변경입니다.

tool 추가/삭제
tool rename
description
inputSchema
outputSchema
required/optional
annotations
tool semantics

필요 조치:

server update
    ↓
ChatGPT registration-level rediscovery
    ↓
fresh chat
    ↓
named-tool test

현재 Business UI에 명시적인 rediscovery/refresh 기능이 없고 기존 registration이 stale하다면:

MCP 재등록

이 현실적인 방법입니다.

C. Identity change

MCP 연결 자체의 정체성이 바뀐 경우입니다.

public URL
hostname
/mcp endpoint
OAuth issuer
auth scheme

이 경우:

connection/app 재구성

또는:

MCP 재등록

가능성이 매우 높습니다.

23. 실제 Business 환경에서 사용할 판단 트리

지금 상황을 기준으로 하면 이 절차가 가장 실용적입니다.

MCP를 수정했다
      │
      ▼
tool contract가 바뀌었는가?
      │
 ┌────┴────┐
 NO        YES
 │          │
 ▼          ▼
서버       서버 restart
restart      │
 │           ▼
 ▼       새 채팅 생성
테스트       │
             ▼
        새 schema가 보이는가?
             │
       ┌─────┴─────┐
      YES           NO
       │             │
       ▼             ▼
 named-tool       ChatGPT registration
 실제 호출        snapshot이 stale할 가능성
                      │
                      ▼
              현재 UI에 refresh/
              rediscovery 기능이 있는가?
                      │
                ┌─────┴─────┐
               YES           NO
                │             │
                ▼             ▼
             실행          MCP 재등록
                              │
                              ▼
                           새 채팅
                              │
                              ▼
                         named-tool 검증

여기에는 **Scan Tools**라는 단계가 없습니다.

그 버튼이 실제 환경에 존재하지 않기 때문입니다.

24. “터널만 재시작하면 되는 경우”를 정확하게 정의하면

다음과 같은 경우입니다.

MCP 등록 identity 동일
public URL 동일
tool contract 동일
ChatGPT snapshot도 사용할 수 있음
transport/session 또는 server process만 stale

예:

코드 bug fix
↓
server reload 안 됨
↓
tunnel reconnect 과정에서 server/session 재연결
↓
정상

또는:

MCP connection이 끊김
↓
tunnel restart
↓
새 transport connection
↓
정상

이것은 registration 문제와 다릅니다.

25. “MCP를 새로 등록해야 하는 경우”를 정확하게 정의하면

다음 조건이 특히 강한 신호입니다.

① 서버가 최신이라는 것이 확인됨

server_version = latest

② 호출도 서버까지 도달함

즉 tunnel은 정상.

③ 그런데 ChatGPT가 보여주는 tool schema가 옛날임

예:

server schema 11

ChatGPT:
render_chart(spec)

실제 최신:
render_chart(template, title, data, ...)

④ 새 채팅에서도 여전히 옛 schema

이 순간에는 conversation cache 문제가 아닙니다.

registration-level snapshot stale

을 강하게 의심할 수 있습니다.

⑤ 현재 Business UI에 refresh/rescan 기능이 없음

그렇다면 MCP 재등록이 가장 직접적인 해결책입니다.

이것이 현재 실제 환경을 반영한 판단입니다.

26. 반대로 새 채팅만 하면 되는 경우

다음 형태입니다.

서버 최신
ChatGPT registration 최신

기존 chat = old schema
새 chat    = new schema

이 경우:

MCP 삭제
MCP 재등록
tunnel restart

은 모두 과잉 대응입니다.

새 채팅이면 충분합니다.

27. local-blog Phase 13은 아주 좋은 진단 사례였습니다

당시 상태를 이 모델로 표현하면:

local-blog MCP server
1.5.0 / schema 11
          │
          │ 정상
          ▼
transport/tunnel
          │
          │ 정상
          ▼
ChatGPT MCP environment
          │
          ├─ 이전 대화: old tool-definition
          │
          └─ fresh chat: semantic schema 11

fresh chat에서는 실제:

render_diagram(
  template="linear-process",
  nodes=...
)

와:

render_chart(
  template="comparison",
  title=...,
  data=...
)

형태의 semantic named-tool 호출이 성공했습니다.

즉 이 사례에서는 서버를 다시 등록할 필요도, tunnel을 재설정할 필요도 없었고 conversation-level tool cache가 핵심이었습니다.

28. MCP protocol의 list-change notification도 만능 해결책은 아닙니다

서버 쪽에서는 가능하면:

tools.listChanged = true

를 지원하는 것이 좋습니다.

MCP specification은 tool list가 변경되었을 때 서버가 notifications/tools/list_changed를 보낼 수 있도록 공식 정의하고 있습니다.

그러나 이것을:

“이걸 구현하면 Web ChatGPT의 tool schema가 자동 갱신된다.”

라고 가정하면 안 됩니다.

정확한 의미는:

MCP client가 변경 사실을 감지할 수 있는 protocol mechanism이 있다.

입니다.

ChatGPT가:

MCP notification
        ↓
workspace approved snapshot
        ↓
conversation definitions

각 단계를 어떻게 관리하는지는 별개의 제품 정책입니다.

그리고 OpenAI의 frozen-snapshot 정책 때문에 서버가 임의로 새로운 action을 자동 활성화하지 않는 쪽이 오히려 자연스럽습니다.

29. 여러 custom MCP를 사용한다면 저는 공통 운영 계약을 이렇게 만들겠습니다

각 MCP에 최소한:

{
  "server_version": "1.5.0",
  "tool_schema_version": 11,
  "tool_schema_fingerprint": "sha256:...",
  "build_sha": "e9032b..."
}

를 노출합니다.

그리고 변경 전에 분류합니다.

RUNTIME
CONTRACT
IDENTITY

배포 후에는 다음 순서로 검증합니다.

1. MCP server version 확인
2. tool_schema_version 확인
3. public endpoint connectivity 확인
4. fresh ChatGPT conversation 생성
5. 실제 노출된 tool signature 확인
6. previewOnly/read-only named-tool 호출
7. schema가 stale하면 registration-level 문제로 분류
8. 현재 UI에 refresh가 없다면 MCP 재등록
9. 다시 fresh chat
10. 실제 named-tool 재검증

이렇게 하면 “일단 터널 껐다 켜 보기”에 의존하지 않아도 됩니다.

30. 가장 중요한 운영 원칙

앞으로는 세 문장만 기억해도 상당 부분 정리됩니다.

첫째, 서버 version과 ChatGPT가 알고 있는 tool schema는 같은 것이 아닙니다.

둘째, ChatGPT의 MCP 등록 snapshot과 개별 채팅의 tool-definition snapshot도 같은 것이 아닙니다.

셋째, OpenAI 공식 문서의 UI 절차와 현재 Business Web ChatGPT의 실제 UI도 같은 것이라고 가정하면 안 됩니다.

따라서 실전에서는:

공식 문서에 Scan Tools가 적혀 있다

보다:

내 Business UI에 실제로 그 기능이 있는가?

가 더 중요합니다.

현재 환경에는 없으므로 저는 앞으로 이 문제를 설명할 때:

Scan Tools를 실행한다

가 아니라

“ChatGPT 쪽 registration-level tool discovery를 새로 만들어야 하며, 현재 Business UI에서 별도 refresh/rescan 수단이 없다면 MCP를 재등록한다.”

라고 표현하는 것이 정확하다고 봅니다.

그리고 이 관점으로 보면 “어떤 때는 터널 재시작만으로 되고, 어떤 때는 재등록해야 한다”는 현상도 일관되게 설명됩니다.

터널 restart
= transport/session 계층 재설정

새 chat
= conversation tool-definition 계층 재설정

MCP 재등록
= ChatGPT app registration/tool-snapshot 계층 재설정

서로 완전히 다른 캐시와 상태를 초기화하는 작업이기 때문에, 변경 종류에 따라 필요한 조치가 달라지는 것입니다.