Azure 문서를 AI가 직접 찾아보게 하는 Microsoft Learn MCP, 키도 비용도 없다

$ microsoft_docs_search  query="azure functions timeout consumption plan"
 1  doc  azure-functions/functions-scale#function-app-timeout-duration        1,658 chars
 2  doc  azure-functions/functions-scale#function-app-timeout-duration        2,822 chars
 3  doc  durable-task/common/durable-task-timers#use-durable-timers-...       2,055 chars
 4  Q&A  answers/a/1907003  "Best approach to run Azure function for 24h"    2,818 chars
 5  doc  azure-functions/flex-consumption-plan#considerations                 2,474 chars
 ... 6~10번: 문서 2칸, Q&A 3칸

Consumption 플랜의 타임아웃을 물었을 때 돌아온 열 칸 가운데 앞 다섯 칸입니다. 1번과 2번은 같은 문서의 같은 절이고, 4번은 공식 문서가 아니라 사용자가 올린 질문 글입니다. 열 칸 전체로는 네 칸이 Q&A 게시글이었습니다. “공식 문서를 찾아 준다”는 소개와 “검색 한 번에 열 건”이라는 설명이 이 한 화면에서 이미 조금씩 어긋나 보입니다.

Microsoft Learn MCP 서버는 AI 에이전트가 Microsoft Learn(공식 기술 문서 사이트)의 문서와 코드 샘플을 검색하고 읽어 가게 하는 원격 MCP 서버입니다. 주소는 https://learn.microsoft.com/api/mcp 하나이고 도구는 문서 검색, 문서 가져오기, 코드 샘플 검색 세 가지입니다. 공식 문서는 인증이 필요 없고 요금도 없다고 밝힙니다. 서버 설정과 스킬이 든 GitHub 저장소 MicrosoftDocs/mcp는 별이 약 2천 개, 포크가 275개입니다. 이 서버를 소개하는 글과 공식 문서가 하는 말은 대체로 같습니다. 공식 문서를 근거로 답하게 하고, 무료이고, 데이터가 매일 갱신된다는 것입니다.

이 글은 그 말을 그대로 옮기는 대신 같은 서버를 직접 호출해 하나씩 대조했습니다. 2026-10-26 UTC 저녁에 공개 엔드포인트로 인증 헤더 없이 도구 호출 54번을 보냈고, 모두 읽기 전용입니다. 검색 14번(질의 8개와 예산 6단계), 코드 샘플 검색 13번, 페이지 가져오기 27번입니다. 순위와 개수는 그 시점의 값입니다.

소개 문구 여섯 개와 판정

확인한 문구는 공식 개요·FAQ·README·도구 설명에서 골랐고, 판정은 아래 절들에서 근거와 함께 풀어 씁니다.

#	소개 문구	실험	판정
1	공식 문서를 찾아 준다	질의 8개, 검색 결과 80조각	74조각이 문서, 6조각이 Microsoft Q&A. 증상형 질의 2개에서만 섞였다
2	검색 한 번에 열 건을 돌려준다	조각이 가리키는 서로 다른 페이지 수	열 건은 열 문서가 아니라 열 조각. 페이지는 1~8개, 8개 질의 합 37개
3	토큰 예산을 걸면 응답이 줄어든다	예산 6단계로 같은 질의 반복	맞다. 다만 조각 단위 계단이고 8000에서는 효과가 없다. 가져오기에는 적용되지 않는다
4	공식 코드 샘플을 찾아 준다	C# 샘플 10개의 코드 안 클래스	6개가 현재 방식, 4개가 이전 세대 클래스. 설명 칸 표기와 코드가 어긋난 칸이 있다
5	문서 페이지를 마크다운으로 가져온다	주소 10여 종	맞다. 범위는 microsoft.com 계열 HTML 페이지로, 문서 사이트보다 넓다
6	데이터가 매일 갱신된다	질문 날짜, 문서 판 경로	최신 판이 들어 있다는 뜻이지 옛 글과 옛 판이 없다는 뜻이 아니다

열 칸을 80번 열어 보니

질의 여덟 개를 한 번씩 보내 받은 열 칸을 순위대로 늘어놓았습니다. 파랑은 그 질의에서 처음 나온 문서 페이지, 점선은 이미 나온 페이지의 다른 대목, 주황은 Microsoft Q&A 게시글입니다.

그림 1. 파랑 첫 등장 문서, 점선 반복, 주황 Q&A. 오른쪽은 서로 다른 페이지 수(Q&A 포함)

주황은 두 줄에만 있습니다. “functions timeout”(타임아웃이 왜 안 늘어나는지 묻는 질의)에서 네 칸, “blob upload 403”(오류를 해결하려는 질의)에서 두 칸입니다. 나머지 여섯 질의(파티션 키 설계, 관리 ID 설정, 쿼터, 마이그레이션, 라이선스, PowerShell 명령)는 60칸이 모두 공식 문서였고, 합치면 80칸 중 74칸이 문서입니다. Q&A가 나온 두 질의는 둘 다 증상이나 오류를 묻는 문장이었습니다. 질의 8개로 본 경향이므로, 문제 상황을 묻는 질의에서는 에이전트가 근거로 든 주소를 확인하는 습관이 필요합니다.

두 번째로 눈에 띄는 것은 점선입니다. 열 칸이 열 문서가 아니라는 사실이 그림에서 바로 읽힙니다. 8개 질의의 서로 다른 페이지 수는 8, 4, 7, 4, 3, 6, 1, 4개로 합이 37개이고, 질의당 평균 4.6개입니다. PowerShell 질의는 열 칸이 모두 Get-AzVM 명령 문서 한 페이지에서 나왔고(주소에 문서 판 azps-16.4.0이 붙어 있습니다), EF Core 마이그레이션 질의는 세 페이지가 열 칸을 채웠습니다. 검색 단위가 문서가 아니라 절 단위 조각이라서(주소 끝의 #앵커가 그 절을 가리킵니다), 한 페이지가 질의에 잘 맞으면 그 페이지의 여러 대목이 연달아 올라옵니다. 조각 하나의 길이는 739자에서 3,302자, 평균 1,905자였습니다. 폭넓은 근거가 필요하면 질의를 다르게 바꿔 여러 번 보내야 하고, 한 번의 검색이 열 갈래 근거를 주는 것은 아닙니다.

주황 칸은 이 두 가지로 구별됩니다.

묵은 답변이 검색 순위에 앉는 방식

Q&A 조각을 가져오기로 열면 본문 맨 위에 질문이 올라온 시각이 찍혀 있습니다. 타임아웃 질의의 Q&A 네 건에서 그 날짜를 읽어 서버의 이력과 나란히 놓았습니다.

그림 2. 질문 날짜(UTC). 네 건 중 세 건은 서버가 처음 공개되기 전에 쓰인 글

네 건 중 세 건이 2025-06-12의 서버 출시보다 앞선 질문이고, 가장 오래된 것은 2024-11-06입니다. 이것이 글이 틀렸다는 뜻은 아닙니다. 2025-03-20의 질문은 “동적(Consumption) 플랜에서 제한이 5분”이라고 말하고, 2024-11-06의 질문은 “문서에 230초 제한이 있다”고 말하는데, 두 값 모두 이번에 가져온 현재 문서의 표(Consumption 기본 5분, HTTP 트리거 응답 230초)와 같습니다. 판정에서 얻을 것은 따로 있습니다. 공식 문서는 갱신 주기에 따라 새로 고쳐지지만 Q&A 글은 질문 날짜에 멈춰 있어서, 플랜 이름이나 한도가 바뀐 분야에서는 같은 순위에 오래된 글이 앉을 수 있다는 점입니다. 에이전트의 답에 /answers/ 주소가 근거로 붙어 있으면 그 글의 날짜를 한 번 열어 보는 것이 가장 싼 점검입니다.

예산 숫자와 응답 길이는 비례하지 않는다

README는 maxTokenBudget을 서버 주소 뒤에 붙이면 검색 도구의 응답을 그 예산에 맞게 잘라 준다고 안내합니다. 실험 기능이라고 표시되어 있습니다. 같은 타임아웃 질의에 주소를 https://learn.microsoft.com/api/mcp?maxTokenBudget=N 꼴로 바꿔 가며 보내고, 돌아온 조각 본문의 글자 수를 쟀습니다.

그림 3. 같은 질의의 응답 본문 글자 수. 회색은 같은 서버의 페이지 가져오기 한 번

세 가지가 보입니다. 첫째, 예산은 글자를 문장 단위로 깎는 것이 아니라 조각 단위로 순위 앞에서부터 본문을 남기고 나머지는 제목과 주소만 남깁니다(응답에 content_omitted: true). 예산 500은 1위 조각 하나만, 1000은 둘, 2000은 넷을 남겼고, 4000에서는 마지막 1,768자 조각 하나만 빠졌습니다. 둘째, 8000은 효과가 없습니다. 이 질의의 본문 총량 21,019자가 이미 예산 안에 들어가기 때문입니다. 셋째, 예산은 순위만 보고 남깁니다. 예산 2000에서 본문이 남은 네 칸은 문서 셋(1·2·3번)과 Q&A 하나(4번)이고, 5번(Flex Consumption 문서)과 6번(Consumption 플랜 문서)은 제목만 남았습니다. 폭은 지키되 깊이를 낮추는 장치이니, 공식 문서 조각이 순위 아래에 있으면 에이전트가 가져오기로 직접 열어야 합니다.

README는 이 값이 “검색 도구 응답”에 적용된다고 적고, 검색 도구는 둘입니다. 코드 샘플 검색도 확인해 보니 예산 500에서 upload blob(csharp) 결과의 코드 본문이 8,386자에서 1,638자로 줄고 열 건 중 여섯 건이 content_omitted로 바뀌었습니다. 반면 같은 연결에서 페이지 가져오기는 예산 500에서도 28,539자를 그대로 돌려줬습니다. 예산 500이 허용한 검색 응답(1,658자)의 17배입니다(편집부 계산). 예산을 낮게 잡은 에이전트가 한 턴에 가져오기를 두세 번 부르면 문맥은 예산이 아니라 가져온 페이지 수가 정합니다.

같은 질의에서 옛 클래스 넷이 섞인 샘플 열 개

코드 샘플 검색에 질의 upload blob, 언어 csharp을 주고 돌아온 열 개를 코드 안에서 쓰는 클래스 이름으로 갈랐습니다. BlobServiceClient·BlobContainerClient·BlobClient는 지금의 Azure.Storage.Blobs 계열이고, CloudBlockBlob·CloudStorageAccount는 그 이전 세대 라이브러리의 클래스입니다.

순위	코드 안의 클래스	설명 칸의 package 표기	세대	출처 문서
1	blob.UploadAsync(설명은 BlobClient)	없음	현재	Key Vault 암호화 업로드
2	CloudBlockBlob	Microsoft.WindowsAzure.Storage.Blob	이전	UWP 앱 제출 API
3	BlobServiceClient, BlobContainerClient	Azure.Storage.Blobs, Azure.Identity	현재	동기 I/O 안티패턴
4	CloudBlockBlob	Microsoft.WindowsAzure.Storage.Blob	이전	UWP 부가 기능 제출
5	CloudBlockBlob	Azure.Storage.Common	이전	Cloud Services(extended support) 배포
6	BlobServiceClient	Azure.Storage.Blobs	현재	Data Explorer 이벤트 그리드 연결
7	CloudStorageAccount, CreateCloudBlobClient	Azure.Storage.Blobs	이전	Data Explorer 이벤트 그리드(SDK)
8	BlobContainerClient	Azure.Storage.Blobs, Azure.Identity	현재	웹앱의 Storage 접근(Entra)
9	BlobClient, BlobContainerClient	Azure.Storage.Blobs, Azure.Identity	현재	고객 제공 키
10	BlobContainerClient	없음	현재	App Service 앱의 Storage 접근

공식 샘플이라는 말은 사실이지만 “현재 방식”이라는 말은 아닙니다. 열 개 중 넷이 이전 세대이고, 2번과 4번은 코드 안 SAS 주소의 만료 날짜가 2016년인 오래된 샘플입니다. 더 위험한 것은 5번과 7번입니다. 설명 칸에 Azure.Storage.Common, Azure.Storage.Blobs처럼 새 패키지 이름이 적혀 있는데 코드는 옛 클래스를 씁니다. 문서 페이지가 현재 제품(Cloud Services 확장 지원, Data Explorer)을 다루더라도 그 안의 샘플이 옛 라이브러리일 수 있다는 뜻이고, 설명 칸만 보고 복사하면 안 되며 코드 안의 클래스 이름을 봐야 합니다.

질의를 바꾸면 달라지는지도 봤습니다. BlobClient UploadAsync Azure.Storage.Blobs로 바꿔 보내자 열 개 모두 현재 방식이었고 옛 클래스는 하나도 없었습니다. 언어를 지정하지 않고 upload blob만 보내면 azurecli 4개, javascript 3개, bash·java·typescript 각 1개로 C#과 Python이 아예 없었습니다. 언어를 python이나 javascript로 지정하면 열 개 모두 azure-storage-blob, @azure/storage-blob 같은 현재 라이브러리 샘플이었습니다(코드 안 import와 클래스 이름으로 확인). 한 가지 더, 서버 안내문은 코드 샘플 검색이 “최대 20개”를 돌려준다고 적지만 이번 13번의 호출은 전부 10개였습니다.

이 때문에 저장소의 microsoft-code-reference 스킬은 11 버전의 CloudBlobClient와 12 버전의 BlobServiceClient처럼 버전이 섞이는 경우를 검증 대상으로 꼽고 세 단계를 권합니다.

1. 메서드나 패키지가 실제로 있는지 검색으로 확인한다. 예: BlobClient UploadAsync Azure.Storage.Blobs
2. 같은 이름의 정의가 여럿이거나 인자가 복잡하면 문서를 가져오기로 열어 전체 시그니처를 본다
3. 작업을 설명하는 질의와 언어를 주어 샘플을 찾고, 가져온 코드와 내 코드를 견준다

가져오기가 받아 주는 주소와 거절하는 주소

도구 설명은 가져오기가 microsoft.com 도메인의 HTML 문서 페이지만 받고 PDF·DOCX·이미지는 받지 못한다고 안내합니다. 주소를 하나씩 넣어 돌아온 첫 줄을 확인했습니다.

그림 4. 가져오기에 넣은 주소와 응답. 빨강은 도메인·형식 거절, 노랑은 없는 페이지

설명대로이면서 범위는 “문서 사이트”보다 넓습니다. learn.microsoft.com의 문서와 Q&A 글은 물론 devblogs.microsoft.com(27,234자)과 azure.microsoft.com의 가격 페이지(35,871자)도 마크다운으로 돌아왔습니다. 반대로 github.com과 .pdf 주소는 같은 거절 문장을 받았고, 없는 페이지는 다른 문장(404이거나 네트워크 오류일 수 있다)이 나왔습니다. http:// 주소와 ?view=azure 같은 쿼리를 붙인 주소는 https 원본과 같은 28,539자였습니다. 에이전트에게 임의의 웹 주소를 읽히는 통로가 아니라 Microsoft 계열 페이지 전용 가져오기라고 보면 맞습니다.

여기서 하나 짚을 점은 가져온 글이 에이전트의 문맥에 그대로 들어간다는 것입니다. 공식 문서는 Microsoft가 쓴 글이지만 Q&A 글은 누구나 쓴 글이라서, 글 안의 명령문처럼 보이는 문장을 에이전트가 따르지 않게 해야 합니다. 앞에서 본 것처럼 Q&A는 검색 결과에도 실제로 섞여 들어옵니다.

최신이라는 말이 가리키는 범위

공식 개요는 지식 서비스가 내용이 바뀌면 점진적으로 반영하고 하루에 한 번 전체를 새로 고친다고 설명하고, FAQ는 데이터가 대개 매일 바뀐다고 적습니다. 이번 호출에서 눈으로 확인한 것은 “최신 판이 있다”와 “옛 판도 있다”가 함께라는 점입니다.

Azure OpenAI 쿼터 질의가 그 예입니다. 결과 열 칸 중 1·4·10번은 /azure/ai-foundry/openai/how-to/quota, 5·6번은 /azure/foundry/openai/how-to/quota였습니다. 둘을 가져와 보니 앞의 것은 첫 줄에 “(classic)” 표시와 “새 Foundry 포털 판으로 전환” 안내가 붙은 기존 포털 판(34,824자)이고, 뒤의 것은 새 포털 판(34,449자)이었습니다. 같은 주제의 두 판이 한 색인에 있고 둘 다 가져와집니다. 에이전트가 어느 판을 근거로 삼았는지는 주소로만 알 수 있습니다.

모델의 기억에 없던 사실이 문서로 들어오는 사례도 같은 가져오기에서 나왔습니다. 타임아웃 질의의 1·2번 문서(Azure Functions hosting options)를 통째로 가져오자 플랜별 표(Flex Consumption·Premium·Dedicated·Container Apps는 기본 30분에 상한 없음, Consumption은 기본 5분에 최대 10분)와 HTTP 트리거의 230초 한계 각주, 그리고 Linux에서 Consumption 플랜으로 호스팅하는 옵션이 2028-09-30에 종료된다는 공지가 함께 들어 있었습니다. 질문에 “시간제한만” 물었는데 마이그레이션 경고까지 받아 오는 것이 이 서버가 기억을 조회로 바꾸는 장면입니다.

확인 결과를 설정으로 옮기면

모든 MCP 클라이언트가 같은 주소를 씁니다. 표준 설정에 예산을 붙인 형태입니다.

{
  "servers": {
    "microsoft-learn": {
      "type": "http",
      "url": "https://learn.microsoft.com/api/mcp?maxTokenBudget=2000"
    }
  }
}

예산 없이 쓰려면 ?maxTokenBudget=2000만 빼면 됩니다. 앞에서 본 것처럼 예산 2000은 상위 네 칸만 본문을 남기므로 공식 문서 조각이 5위 아래에 있는 질의에서는 가져오기가 한 번 더 필요하다는 점을 감안해서 고릅니다. 클라이언트별 설치는 README에 15종이 적혀 있고, 자주 쓰는 세 가지는 한 줄입니다.

# Claude Code (서버와 스킬이 함께 설치, 설치 뒤 재시작)
/plugin install microsoft-docs@claude-plugins-official

# Codex
codex mcp add "microsoft-learn" --url "https://learn.microsoft.com/api/mcp"

# GitHub Copilot CLI
/plugin install microsoftdocs/mcp

VS Code는 확장 검색창의 @mcp learn, Cursor는 저장소의 한 번 클릭 설치 버튼, Visual Studio(2022 17.13 이상과 2026)는 “Microsoft Learn”이 내장되어 있습니다. Gemini CLI는 .gemini/settings.json에 httpUrl로, ChatGPT는 개발자 모드에서 커넥터를 만들고 인증을 “인증 없음”으로 두고 주소를 넣습니다. Claude Code에서 마켓플레이스를 먼저 등록하는 방식(/plugin marketplace add microsoftdocs/mcp 다음 /plugin install microsoft-docs@microsoft-docs-marketplace)도 공식 시작하기 문서에 있고 같은 플러그인이 깔립니다. 브라우저 주소창에서 이 주소를 열면 405 Method Not Allowed가 나오는데 MCP 클라이언트 전용 엔드포인트라서이고 오류가 아닙니다.

Visual Studio에서 같은 이름(microsoft-learn)의 서버를 수동으로 또 추가하면 내장 서버가 가려져 “Eclipsed”로 표시됩니다. 일치 기준이 주소가 아니라 이름이라서 microsoft-learn이든 Microsoft Learn이든 이름이 같은 수동 항목을 .mcp.json에서 지우면 내장 서버가 살아납니다. 2026-09-02에 이 내용이 README의 문제 해결 표에 추가되었습니다(이슈 #100은 VS 2026에서 서버가 보이지 않는다는 다른 보고가 함께 있어서 열려 있습니다).

앞의 판정들을 지침 한 단락으로 옮기면 에이전트의 규칙 파일에 이렇게 적을 수 있습니다. 모델이 도구를 기본으로 부르지 않는 경우가 있다는 것은 README 문제 해결 절이 인정하는 내용이므로 이런 지침이 필요합니다.

C#, ASP.NET Core, Azure 같은 Microsoft 기술은 답하기 전에 microsoft_docs_search로 확인한다.
코드는 microsoft_code_sample_search에 언어를 지정하고, 클래스 이름이 현재 SDK인지 코드에서 확인한다.
근거로 든 주소가 /answers/ 이면 공식 문서가 아니라 사용자 글이라고 밝히고 날짜를 적는다.
본문이 모자라면 microsoft_docs_fetch로 해당 페이지를 연다.

도구가 실제로 불렸는지는 처음 몇 번 눈으로 확인합니다. 사내에 직접 만든 에이전트에 붙일 때도 같습니다. Copilot Studio 실습(Agent Academy의 “Operation Open Book”, 약 15분)은 MCP 탭에서 도구 세 개를 각각 켜고 끌 수 있다고 안내하고, 다른 지식 원본을 끊은 상태에서 “초콜릿 케이크 레시피” 같은 범위 밖 질문을 던져 근거를 못 찾았다고 답하는지 확인하라고 합니다. Foundry에서는 도구 추가에서 Custom, MCP를 고르고 주소와 인증 “Unauthenticated”를 지정합니다.

스킬 세 개와 터미널 CLI

같은 저장소에는 에이전트가 도구를 쓰는 때와 방법을 가르치는 Agent Skills 세 개가 있습니다. microsoft-docs는 개념·튜토리얼·한도·모범 사례, microsoft-code-reference는 API 조회·샘플 검색·오류 해결·검증, microsoft-skill-creator는 특정 Microsoft 기술에 맞춘 스킬을 만드는 메타 스킬입니다. README는 모든 경우에 세 개를 다 설치하거나, 코딩이면 microsoft-code-reference만, 사실 확인이면 microsoft-docs만 고르라고 안내합니다. 앞 절의 샘플 문제는 microsoft-code-reference가 맡는 영역입니다.

MCP를 붙일 수 없는 환경에는 npm의 @microsoft/learn-cli가 같은 세 기능을 터미널에서 줍니다. 최신 버전은 1.0.0(npm 게시 2026-09-10, MIT)이고 Node.js 22 이상이 필요합니다. 저장소에는 9월 4일에 CLI 1.0.0 릴리스 커밋과 에이전트 탐색 설정 추가가 올라갔습니다.

# 설치 없이 바로 실행
npx @microsoft/learn-cli search "azure functions timeout"

# 전역 설치 후에는 mslearn 명령
npm install -g @microsoft/learn-cli
mslearn fetch "https://learn.microsoft.com/azure/azure-functions/functions-versions" --section "Function app timeout duration"
mslearn code-search "cosmos db change feed processor" --language csharp
mslearn doctor

fetch의 --section <제목>은 한 절만, --max-chars <숫자>는 길이를 자르므로 앞에서 본 가져오기 한 번이 문맥을 크게 쓰는 문제를 직접 줄일 수 있습니다. search와 code-search는 --json을 주면 원본 JSON을 내어 jq 같은 도구에 잇기 좋습니다. mslearn setup --cli는 감지된 Copilot·Claude Code·Codex에 “MCP가 없을 때 CLI로 조회하라”는 스킬을 설치합니다. 사용자 폴더에 깔고 --project를 주면 현재 저장소에 깔며, 이 명령은 MCP를 구성하지 않고, 둘을 함께 깔면 에이전트는 MCP를 먼저 쓰고 CLI 스킬은 대비책으로 씁니다. 지우려면 mslearn remove --cli입니다.

같은 질문을 다른 길로 보내 보기

앞의 판정은 이 서버가 맡지 못하는 일도 알려 줍니다. Microsoft 바깥의 오픈소스 프레임워크 문서가 필요하면 Context7이 한 길입니다. resolve-library-id로 라이브러리 식별자를 얻고 query-docs로 문서를 가져오는 두 단계 구조이고, README는 무료 API 키를 받으면 키 없이 쓸 때보다 높은 한도를 준다고 안내합니다(Claude Code 설정은 npx ctx7 setup --claude, Node.js 22.13 이상). 라이브러리 문서는 커뮤니티가 기여·유지하므로 정확성과 완전성을 Context7이 보증하지 않는다고 README가 적고, Microsoft 문서는 Microsoft가 쓴 글이라는 점이 두 길의 성격을 가릅니다. Microsoft 기술과 오픈소스를 함께 쓰는 프로젝트라면 둘을 같이 등록해 질문의 대상에 따라 나눠 쓰는 구성이 가능합니다.

Microsoft 문서가 대상이면서 MCP를 붙일 수 없다면 mslearn CLI가 같은 지식 서비스를 부르고, 정확히 한 페이지만 읽히고 싶다면 주소를 직접 전달하거나 가져오기에 그 주소를 주는 것이 가장 단순합니다. Q&A 같은 사용자 글까지 넓게 보려면 일반 웹 검색 도구가 맞습니다. 이 서버로 Q&A 글까지 받게 되는 경우에는 에이전트가 근거 주소를 달아 공식 문서와 구분해 알려 주게 하는 쪽이 낫습니다.