브라우저 에이전트가 실제로 쓸 수 있는 문서 편집기

사용 방법

1. WebMCP API를 제공하는 브라우저를 사용합니다(Chrome의 오리진 트라이얼).
2. 편집기를 일반 탭으로 엽니다 — 도구는 최상위 페이지에서만 등록됩니다.
3. 브라우저의 AI 에이전트에게 문서를 열거나 읽거나 변환하거나 내보내 달라고 요청합니다.
4. 에이전트가 도구를 직접 호출합니다. 작업은 기기에서 이루어지고 아무것도 업로드되지 않습니다.

대부분의 웹 앱은 AI 에이전트에게 불투명합니다. 버튼이 늘어선 페이지가 보일 뿐이라 어느 것이 파일을 변환하는지 추측하고, 클릭이 제대로 들어갔기를 바라야 합니다. W3C Web Machine Learning Community Group의 제안인 WebMCP는, 페이지가 자신이 할 수 있는 일을 타입이 붙은 입력을 가진 구조화된 호출 가능 도구로 선언하게 해 그 추측을 통째로 없앱니다. 이 편집기는 일곱 개를 선언합니다.

도구는 open_document_url, open_document_buffer, create_document, save_document, get_document_text, set_readonly, get_document_state입니다. 별도 구현이 아니라 버튼이 호출하는 것과 같은 기기 내 코드를 호출하며, iframe 임베드 API가 다루는 것도 같은 코드입니다. 그래서 에이전트는 사람과 정확히 같은 기능을 같은 보장 아래 사용합니다 — 변환 엔진은 탭 안에서 도는 WebAssembly이고 파일은 기기를 벗어나지 않습니다.

에이전트 접근이 여기서 합리적인 이유가 바로 그 성질입니다. 보통 문서를 에이전트에게 준다는 것은 그 에이전트가 통신하는 서버에 준다는 뜻입니다. 여기서는 에이전트가 조율만 하고 문서는 그대로 있습니다 — 디스크에서 탭으로 읽히고, 탭 안에서 변환되고, 다시 기록됩니다. 계약서 본문을 읽어 질문에 답하는 에이전트도 그 계약서를 어디에도 올리지 않습니다.

의도한 제약이 두 가지 있습니다. 도구는 편집기가 최상위 페이지일 때만 등록됩니다 — 교차 출처 iframe에서는 임베드하는 페이지가 allow="tools"를 부여해야 하는데 이는 임베드의 취지와 충돌하므로, 임베드된 편집기는 postMessage API로 다룹니다. 그리고 전문 읽기는 워드 문서에서 제공됩니다. 스프레드시트와 프레젠테이션은 이 엔진에서 전문을 공개하지 않으므로, 에이전트가 「빈 파일」로 오해할 수 있는 빈 응답 대신 그 사실을 분명히 알립니다.

자주 묻는 질문