smithery/isnow890-data4library-mcp

우리가 부른 주소는 여러 서버가 함께 쓰는 공용 게이트웨이(server.smithery.ai)다. 여기서 나온 오류는 게이트웨이의 것이지 이 저장소의 결함이 아닐 수 있다 — 우리가 그 둘을 갈라 재지 못했다.

“확인 못 함”은 그 서버의 판정이 아니라 우리 호출의 결과다. 2026-09-03에 두드리개를 MCP 규격에 맞췄다 — 그전까지 이 명단에는 살아 있는데 우리가 규격을 못 지켜 거절당한 서버가 섞여 있었다.

지금 하는 것

• initialize JSON-RPC + notifications/initialized 핸드셰이크를 먼저 하고, 서버가 준 Mcp-Session-Id·협상된 MCP-Protocol-Version을 이어 쓴다
• POST의 307·308 리다이렉트를 method와 본문을 보존한 채 따라간다(파이썬 표준 urllib은 안 따라간다)
• Streamable HTTP가 안 되면 구 HTTP+SSE 전송(GET + Accept: text/event-stream → endpoint 이벤트)으로 한 번 더 물어본다
• 4xx를 사망으로 읽지 않는다 — 400·404·405·406·415는 전송 방식이 틀렸다는 신호라 다른 전송으로 재시도한다. 연결 실패·5xx는 같은 전송으로 1회 재시도한다
• 서버가 보낸 오류 본문을 버리지 않고 원자료에 남긴다

그래도 못 하는 것 — 코드로 확인한 것만 적는다.

• OAuth·API 키가 필요한 서버는 인증을 못 한다(401/403은 살아있음의 증거로 읽되 도구 목록은 못 본다)
• stdio 전송만 지원하는 서버는 원격으로 잴 수 없다
• 무료 티어의 콜드스타트가 우리 타임아웃보다 길면 못 본다
• 측정 지점이 한국 한 곳이다 — 지역 차단·지연은 못 가른다

그래서 어휘를 셋으로 가른다: 살아있음 확인(MCP 응답을 실제로 받았다) · 확인 못 함(우리 호출로 확인이 안 됐다 — 죽었다는 뜻이 아니다) · 죽음 확인(DNS 미해결·연결 거부처럼 호스트가 없다는 직접 증거가 있을 때만).