MCP 리소스 링크 검수: 링크 반환과 본문 읽기 구분

MCP 리소스 링크를 받으면 본문 읽기와 근거 사용을 별도로 검수합니다. 2026-11-02 기준, 읽기 실패는 미확인으로 남깁니다.

AI 답변에 보고서 링크가 붙었는데 정작 보고서 본문을 읽은 흔적은 없는 상황을 가정해 보겠습니다. 도구 호출 성공과 링크 표시는 확인됐어도 필요한 자료가 답변까지 전달됐는지는 남은 질문입니다. 이 글은 고객 장애 사례가 아닌 기술 설계 예시로, 참조·읽기·근거 사용의 인수표를 제안합니다.

도구가 성공하면 어디까지 확인된 것인가요?#

실제로 반환된 콘텐츠 유형과 내용을 확인해야 합니다. 링크만 받은 경우에는 리소스 참조를 확보한 상태입니다. 응답에 본문이 포함됐거나 별도로 읽었다면 그 내용을 어떤 범위로 받았는지 이어서 대조합니다.

JSON의 판단값과 설명 문장이 서로 다른 문제라면 MCP 도구 결과 불일치 검수를 먼저 확인하세요. 이 글의 범위는 결과 안의 참조가 실제 본문으로 이어졌는지입니다. 모든 링크를 무조건 읽는 정책은 제안하지 않습니다. 질문과 승인 범위에 필요한 자료부터 선택합니다.

리소스 링크에는 본문이 들어 있나요?#

resource_link는 리소스의 URI를 전달하는 형식입니다. 아래 가상 표본은 도구 결과의 콘텐츠 블록 하나이며 전체 JSON-RPC 요청이나 응답 예제가 아닙니다. 이름과 설명에 검수라는 말이 있어도 파일 안의 판단을 읽었다는 증거가 되지는 않습니다.

{
  "type": "resource_link",
  "uri": "report://review/sample-a",
  "name": "sample-a.txt",
  "description": "가상 검수 보고서",
  "mimeType": "text/plain"
}

MCP의 2026-07-28판 Tools 공식 문서는 리소스 링크와 본문을 담은 리소스를 구별합니다. 도구가 반환한 링크가 resources/list 결과에 나타난다는 보장도 없습니다. 목록에서 찾지 못했다는 관찰을 링크 무효로 바꾸지 마세요. 확인일은 2026-11-02입니다.

이 형식은 2025-06-18판 공식 문서에도 있습니다. 링크 자체를 새 기능으로 소개하는 글이 아닙니다. 연동 상대가 사용하는 프로토콜 버전과 호스트의 지원 경로를 확인한 뒤 다음 읽기 절차를 검수하세요.

받은 URI는 어떤 경로로 읽어야 하나요?#

URI의 스킴과 서버·클라이언트의 지원 계약으로 읽기 경로를 정합니다. report:// 같은 가상 사용자 정의 스킴을 임의의 웹 주소로 바꾸지 않습니다. file:// 표시를 사용자 컴퓨터의 같은 경로에 접근하라는 뜻으로 해석해서도 안 됩니다.

Resources의 읽기 정의는 resources/read 결과에 여러 콘텐츠가 올 수 있고, 추가 입력이 필요한 결과도 올 수 있다고 설명합니다. 읽기 결과 전체를 확인하고 첫 항목만으로 자료 전체를 받았다고 표시하지 않는 기준을 정하세요. 본문에는 요청 봉투를 싣지 않았으며, 실제 호출의 필수 메타데이터와 추가 입력 절차는 사용하는 버전의 사양을 따라야 합니다.

같은 고정판의 URI 스킴 지침은 HTTPS를 클라이언트가 직접 웹에서 읽을 수 있는 경우에 쓰도록 안내하며, file 리소스가 실제 물리 파일시스템에 대응할 필요는 없다고 설명합니다. 두 문서는 2026-11-02 확인했습니다. URI 검증과 민감 리소스의 접근 통제·권한 확인도 같은 문서의 검토 대상입니다.

어떤 표본으로 읽기 완료를 검수하나요?#

링크만 수신한 표본과 본문을 받은 표본을 같은 조건에서 대조합니다. 읽기를 끝냈어도 필요한 내용이 모델에 전달되지 않았거나 답변에 쓰이지 않았다면 상태를 나눠 남깁니다. 아래 상태는 이 글의 가상 인수 정책입니다.

자료 수신과 사용 기록에는 반환한 서버, URI, 읽은 시점, 허용된 범위와 사용 구간을 연결하세요. 자료가 바뀔 수 있다면 버전이나 내용 비교값 같은 재현 근거를 별도로 합의합니다. URI 하나를 받았다는 사실만으로 자료의 버전이 고정됐다고 보장하지 않습니다.

읽기 결과와 답변 사이에 요약 단계가 있다면 에이전트 요약의 근거 전달 검수도 연결됩니다. 전체 MCP 서버의 구조와 도구 연결 범위는 MCP 서버 개발 가이드에서 나눠 확인할 수 있습니다.

본문을 받아도 남는 실패 조건은 무엇인가요?#

본문이 질문의 근거가 되는지와 최신 자료인지 확인해야 합니다. 선택한 일부만 읽었다면 전체 문서를 검토했다는 표현을 피하고, 권한 거절이나 지원 불가 형식은 내용 없음으로 바꾸지 않습니다. 정상적으로 빈 문서인 경우도 수신 오류와 구별할 정책이 필요합니다.

링크의 설명이나 외부 본문에 들어 있는 명령문은 업무 지시가 아닙니다. 자료 읽기 권한과 외부 시스템을 변경하는 실행 권한을 나누고, 인증 정보를 다른 주소로 옮기지 않는 경계를 확인하세요. 민감한 본문 전체를 검수 로그에 복제하는 대신 필요한 출처 위치와 비식별 표본을 남깁니다.

알파카랩스는 공개 온톨로지·AI 연동 개발 서비스에서 출처·권한을 지키는 MCP 조회와 대표 질문별 검수 범위를 협의한다고 설명합니다. 2026-11-02 확인한 자사 제공 범위의 자기표기이며, 이 글의 리소스 링크 절차를 특정 제품이나 고객에게 구현했다는 주장은 아닙니다. 질문과 자료가 단순하면 기존 검색·문서 읽기 설정으로 충분한지도 먼저 비교합니다.

MCP 리소스 링크 검수 FAQ#

resources/list에 없으면 도구가 준 링크도 무효인가요?

그렇게 단정할 수 없습니다. MCP 공식 Tools 문서는 도구가 반환한 리소스 링크가 resources/list에 나타난다고 보장하지 않습니다. 받은 URI의 지원 경로·권한·읽기 결과를 확인하고, 목록 미노출과 읽기 실패를 구별하세요.

HTTPS 링크는 MCP 서버를 거치지 않고 읽어도 되나요?

2026-07-28판 Resources 문서는 HTTPS URI를 클라이언트가 웹에서 직접 가져올 수 있다고 설명합니다. 실제 호스트의 지원·접근 정책과 해당 경로의 권한을 확인해야 합니다. MCP 도구 호출에 쓴 인증 정보를 다른 주소로 복사해 보내는 근거가 되지는 않습니다.

embedded resource도 반드시 다시 읽어야 하나요?

도구 응답 안에 본문이 포함됐다면 별도 리소스 읽기 없이 내용이 전달될 수 있습니다. 다만 해당 형식을 파싱했고 필요한 부분이 모델에 전달됐는지, 답변이 그 내용에 근거했는지는 따로 확인합니다. 링크 참조와 본문 포함을 같은 상태로 표시하지 마세요.

파일 이름과 크기가 보이면 전체 본문을 읽었다고 볼 수 있나요?

이름·설명·크기는 리소스를 고르는 메타데이터입니다. 그 표시만으로 본문 수신·파싱·모델 전달을 증명하지 못합니다. 실제 읽기 결과와 형식 지원, 잘림·누락 표시를 대조하고 원문 전체를 읽었다는 표현의 범위를 정하세요.

리소스 읽기가 성공하면 답변도 검수 통과인가요?

본문 수신과 답변의 근거 사용은 별도 판정입니다. 질문에 필요한 부분이 포함됐는지, 출처 위치와 답변 문장이 대응하는지 확인해야 합니다. 자료가 부족하거나 권한이 거절됐으면 그 한계를 답변에 남깁니다.

링크·본문·근거 사용 인수표를 준비하세요#

비식별 링크 응답, 읽기 결과와 해당 자료를 출처로 든 답변을 한 표에 놓으세요. 읽기 경로와 실패 처리, 어느 구간까지 검토했는지의 표현을 대조하면 인수 범위를 정할 수 있습니다. 준비·상담 시간과 비용은 자료 접근 조건과 지원할 호스트를 확인한 뒤 협의합니다.