Junê (june-mcp)

june-mcp

에이전트에 기억을 부여하세요. june-mcp는 Junê의 공식 MCP 서버입니다. — 모든 MCP 호스트(Claude Desktop, Claude Code 등)를 June 지식 그래프에 연결하여, 에이전트가 공유되고 인용되며 테넌트별로 격리된 메모리를 대상으로 질문하고, 검색하고, 기억할 수 있게 합니다.

이 패키지는 얇고 로직이 없는 커넥터입니다. 모든 검색, 그래프 구성, 응답은 지정한 June 엔드포인트에서 이루어집니다. 엔진 코드는 여기에 없습니다. 그래서 한 번에 읽을 수 있을 만큼 작습니다.

Claude Desktop / Claude Code  ──stdio──▶  june-mcp  ──HTTPS──▶  your June endpoint
                                                                 (graph · retrieval · answers)

설치

pip install june-mcp          # just the connector   (or: pipx install june-mcp)
pip install june-ai           # umbrella: june-mcp + june-bench (the benchmark suite)
pip install "june-bench[mcp]" # the bench, with the connector as an extra

June 엔드포인트 지정

june-mcp는 모든 June 서비스와 통신합니다. 서비스를 확보하는 세 가지 방법:

1. Junê 데스크톱 앱(로컬 우선). Junê 앱을 실행하고 로컬 엔진에 연결하세요. 파일, 그래프, 키는 모두 사용자 머신에 유지됩니다.
2. 자체 June 서비스. Pro/Team 고객이 june-local 엔진 패키지를 실행하는 경우 JUNE_BASE_URL를 자체 서버에 연결합니다.
3. 호스팅(Team). 콘솔의 API 키를 사용하여 호스팅된 June 워크스페이스 엔드포인트를 지정합니다.

구성

서버는 기본적으로 실패 시 종료(fail-closed) 방식입니다. 연결 대상과 사용자 신원을 모르면 시작을 거부하며, 한 번에 하나씩이 아니라 모든 누락 사항을 한 메시지로 알려줍니다.

환경 변수	필수	의미
JUNE_BASE_URL	✅	June 엔드포인트, 예: http://localhost:8000
JUNE_CANVAS	✅	이 연결을 바인딩할 캔버스(워크스페이스) — 이름(work) 또는 캔버스 ID. 이름은 시작 시 ID로 확인되며, 모호한 이름은 실패로 처리됩니다
JUNE_CANVAS_CREATE	선택	1는 첫 실행 시 이름이 지정된 캔버스가 없으면 생성합니다(읽기 전용 모드에서는 거부됨)
JUNE_API_KEY	✅	June API 키(JUNE_ALLOW_ANON=1는 키 없는 로컬 설정에서 명시적으로 제외)
JUNE_LLM_KEY	선택	인용 답변을 위한 BYO LLM 키 — 요청별로 헤더로 전달되며, 기록되지 않고 서비스에 저장되지 않습니다
JUNE_READONLY	선택	1는 모든 쓰기 도구를 숨기고 거부합니다(메모리가 읽기 전용이 됨)
JUNE_TOOL_PROFILE	선택	compact(기본값), full, 또는 lean. compact는 17개의 관련 도구를 op를 받는 7개의 패밀리 도구로 접습니다. Pro 읽기-쓰기 연결에서 37개 대신 20개 도구, 13,236 대신 11,359 프롬프트 토큰이 나열됩니다. 모든 호출은 이전과 동일한 코드로 전달되므로 게이트, 캔버스 규칙, 영수증, 2단계 확인은 변경되지 않습니다. 기본값이 되기 전에 4개 호스트에서 측정됨: Claude Code 1.000 작업 성공(기준 0.987), GPT-5.4 직접 0.983(0.957), Codex 0.922(0.763), 모든 팔에서 안전하지 않은 삭제 0건. full은 37개 멤버를 각각의 이름으로 나열합니다 — 동일한 코드, 각각 하나의 이름. lean은 코딩 에이전트가 사용하는 6개의 동사만 노출합니다(june_answer / june_context / june_search / june_remember / june_learn / june_usage) — 한 단락 핸드셰이크 포함, 약 2.5k 토큰 — 질문하고 기억하기만 하면 되는 세션용
JUNE_FILES_ROOT	선택	운영자가 승인한 디렉토리로, 에이전트가 june_ingest_file를 통해 파일을 업로드할 수 있음 — 설정하지 않으면 해당 도구가 존재하지 않음
JUNE_TIMEOUT_READ / JUNE_TIMEOUT_RETRIEVAL / JUNE_TIMEOUT_ANSWER	선택	동사 클래스별 시간 예산(기본값 15초 / 90초 / 120초): 빠른 읽기; 모든 후보를 재순위화하는 june_context; 모델 호출을 수반하는 답변
JUNE_TOOL_CONCURRENCY	선택	이 연결에서 동시에 실행되는 최대 도구 호출 수(기본값 8). 호스트는 하나의 스트림으로 요청을 파이프라인 처리합니다. 이는 명시적 상한이며, 초과 호출은 대기열에 들어가고 러시하지 않습니다
JUNE_DOCS_CANVAS	선택	에이전트 문서(상시 지침/스킬 — 아래 에이전트 메모리 참조)를 보유한 캔버스. 기본값 agent_docs; 첫 번째 june_doc_save에서 생성됨
JUNE_DOCS_REFRESH	선택	0는 주기적인 standing_docs 다이제스트를 비활성화합니다(기본값 켜짐 — 망각 방지 안전망)
JUNE_DOCS_REFRESH_CALLS / JUNE_DOCS_REFRESH_MINUTES	선택	다이제스트 주기: N번의 도구 호출마다(기본값 12) 또는 M분마다(기본값 10), 먼저 도래하는 기준
JUNE_DOCS_DIGEST_CHARS	선택	직렬화된 다이제스트 크기 상한(기본값 2000)
JUNE_EXPORT_ROOT	선택	에이전트가 June 페이지/문서를 파일로 내보낼 수 있는 옵트인 저장소 디렉토리(아래 저장소 동기화 참조) — 설정하지 않으면 3개의 저장소 동기화 도구가 존재하지 않음
JUNE_EXPORT_GIT	선택	1는 각 내보내기가 작성한 정확한 파일만 커밋합니다(경로 지정 제한, 푸시하지 않음)
JUNE_EXPORT_DIR	선택	루트 내부의 에이전트 문서 하위 트리(기본값 docs/agent)
JUNE_LOG_LEVEL	선택	로깅은 설계상 stderr 전용입니다 — stdout은 MCP 와이어입니다

에이전트가 사용하기 전에 확인

JUNE_BASE_URL=http://localhost:8000 JUNE_API_KEY=... JUNE_CANVAS=work june-mcp --doctor

의사(doctor)는 순서대로 확인합니다: 구성 → 서비스 연결 가능 → 캔버스 확인(캔버스 이름 → ID, 예: name "work" → 9147bee6-…) → 검색 연결부 상태 → 도구 매니페스트, 각 확인에 대해 PASS/FAIL을 매핑된 힌트와 함께 출력합니다(예: 이름이 없으면 존재하는 캔버스 목록을 나열하고 JUNE_CANVAS_CREATE=1를 가리킴). 의사는 모든 확인이 통과할 때만 0로 종료합니다(그 외에는 1). 서버 자체는 구성 오류 시 반쯤 연결된 상태로 시작하는 대신 2로 종료합니다. 먼저 의사를 실행하세요. 에이전트가 서버를 보기 전에 모든 일반적인 잘못된 구성을 잡아냅니다.

Claude에 연결

Claude Desktop — claude_desktop_config.json에 병합(설정 → 개발자):

{
  "mcpServers": {
    "june": {
      "command": "june-mcp",
      "env": {
        "JUNE_BASE_URL": "http://localhost:8000",
        "JUNE_API_KEY": "your-key",
        "JUNE_CANVAS": "work",
        "JUNE_LLM_KEY": "your-llm-provider-key"
      }
    }
  }
}

Claude Code:

claude mcp add june -e JUNE_BASE_URL=http://localhost:8000 \
  -e JUNE_API_KEY=your-key -e JUNE_CANVAS=work \
  -e JUNE_LLM_KEY=your-llm-provider-key -- june-mcp

호스트를 완전히 다시 시작하고(macOS에서 Cmd+Q), 서버에 20개 도구가 표시되는지 확인하세요 — 0.4.2부터 기본값인 compact 표면입니다. JUNE_TOOL_PROFILE=full는 37개의 개별 이름 도구와 동일한 기능을 나열합니다(june_ingest_file를 JUNE_FILES_ROOT를 통해 옵트인하면 38개).

도구

기본 표면은 compact입니다: 20개 도구, 그중 7개는 op 인수 뒤에 관련 작업을 그룹화합니다. JUNE_TOOL_PROFILE=full는 37개 멤버를 각각의 이름으로 나열합니다 — 동일한 기능, 동일한 게이트, 동일한 동작.

패밀리 도구	작업	접힌 도구
june_graph	neighborhood, subgraph, backlinks	june_neighborhood, june_subgraph, june_backlinks
june_maintain	enrich, resolve	june_enrich, june_resolve
june_page_read	list, get, removed, grammar	june_page_list, june_page_get, june_page_removed (+ 필요 시 블록 문법)
june_page_edit	create, append, update, insert, move, rename, meta, restore	june_page_create, june_page_append, june_page_update, june_page_insert, june_page_move, june_page_rename, june_page_meta, june_page_restore
june_canvas_read	list, current, use	june_canvas_list, june_canvas_current, june_canvas_use
june_canvas_erase	clear, delete	june_canvas_clear, june_canvas_delete
june_docs_read	refresh, list, get	june_docs_refresh, june_doc_list, june_doc_get

나머지는 각자의 이름을 유지합니다: june_answer, june_search, june_enumerate, june_context, june_usage, june_remember, june_ingest, june_page_write, june_page_delete, june_canvas_create, june_doc_save, june_doc_delete, june_learn. 무언가를 제거할 수 있는 동사는 그럴 수 없는 동사와 절대 접히지 않습니다. 따라서 june_page_write와 june_page_delete는 june_page_edit와 분리되어 유지되며, 각 패밀리는 하나의 정직한 destructiveHint를 갖습니다.

저장된 에이전트 문서에서 이전 이름은 계속 작동합니다: compact 핸드셰이크는 이전 이름 → 새 이름 매핑을 전달하며, 접힌 이름에 대한 호출은 정확한 대체 이름과 함께 거부됩니다(june_page_get is not a tool on this surface (compact): call june_page_read with op='get').

각 작업이 수행하는 기능:

도구	에이전트가 얻는 것
june_answer	그래프에서 근거가 있고 인용된 답변 — 추측보다는 기권
june_search	쿼리에 대한 순위가 매겨진 증거(멀티홉 지원)
june_context	토큰 예산 내에서 조립된 컨텍스트 팩
june_neighborhood	한 노드 주변의 그래프
june_subgraph	제한된 하위 그래프 내보내기
june_backlinks	한 노드로 들어오는 링크(들어오는 에지)
june_remember	사실/메모를 그래프에 작성(즉시 검색 가능 + 인용 가능). 긴 텍스트는 엔진 작업으로 실행됩니다: {state: running, job_id}의 결과는 june_remember(job_id=…)로 수집됩니다 — 텍스트를 다시 보내지 마세요. 붙여넣은 텍스트는 엔진에서 콘텐츠 주소 지정(v0.0.13)되므로 동일한 텍스트를 다시 보내면 동일한 노드가 업서트됩니다. 중복될 수 없습니다
june_ingest	구조화된 노드/에지 수집
june_enumerate	"모든 X 나열" 질문에 대한 조건자와 일치하는 노드(상위 k 아님). exhaustive: true만 목록이 완전함을 증명합니다. 그것 없이 짧거나 빈 결과는 다른 것이 일치하지 않음을 증명하지 않습니다
june_ingest_file	운영자가 승인한 폴더에서 로컬 파일 하나 업로드(pdf/docx/xlsx/csv/html/md/이미지/오디오) — JUNE_FILES_ROOT를 설정한 경우에만 존재
june_enrich	Pro: 더 풍부한 엔진으로 캔버스의 백그라운드 재추출(멱등성, 작업 + 폴링, 무료 요금제에서 403)
june_resolve	유지 관리: 가역적인 same_as 에지를 통해 중복 엔터티 병합(서버 측 실행, strong_only=false는 Pro에서 의미론적 계층 잠금 해제)
june_docs_refresh / june_doc_list / june_doc_get	에이전트의 상시 문서 읽기 — 전체 다이제스트, 레지스트리 목록, 한 문서의 본문
june_doc_save / june_doc_delete / june_learn	작성 — 문서 또는 스킬 생성/교체, 2단계 삭제, 날짜가 있는 교훈 하나 추가
june_page_insert / june_page_move	이름이 지정된 블록 뒤에 새 블록 배치, 또는 ID로 블록 재정렬 — 페이지를 다시 보내지 않고(positions 페이지 기능이 있는 엔진 필요)
june_page_rename / june_page_meta	페이지 제목 변경, 또는 페이지 목록에서 고정/그룹 설정 — 블록은 변경되지 않음
june_page_removed / june_page_restore	페이지가 잃은 것 확인, 원래 ID와 위치로 블록 복원
june_usage	사용량 영수증 — June이 실제로 제공한 것, 명명된 토크나이저로 측정, 추정 아님. 전체 영수증 하나(receipt_id) 또는 기간 요약(window); 절약 수치는 두 공급자 보고 사용량이 실제로 측정된 호출에 대해서만 표시됩니다

모든 읽기에 대한 영수증

엔진이 JUNE_USAGE=1로 실행될 때(데스크톱: 설정 → 사용량 영수증), 모든 june_answer / june_context / june_search 결과에는 receipt와 한 줄의 receipt_footer도 포함됩니다:

receipt r_7f…: served 812 tokens (exact, tiktoken:cl100k_base) from 3 blocks across 2 docs
· 1 doc this session already had — june_usage(receipt_id="r_7f…") shows it in full

커넥터는 서버 프로세스당 X-June-Source: mcp와 하나의 X-June-Session ID를 보내므로 엔진은 이 에이전트 세션이 이미 보유한 문서를 기록할 수 있습니다(피한 재읽기). 바닥글은 "저장됨"이라고 말하지 않습니다. 그 단어는 측정된 쌍을 보유한 영수증에만 존재합니다. 영수증이 없는 엔진은 바닥글을 보내지 않으며, june_usage는 꺼져 있다고 명확히 답합니다.

설명은 에이전트를 위해 작성되었으며(무엇 → 언제 → 반환), 모든 클램프된 입력은 조용히 잘리는 대신 시각적으로 에이전트에 다시 표시됩니다.

에이전트 메모리 — 문서, 스킬, 망각 방지 다이제스트

긴 세션은 잊어버립니다: 세션 시작 시 에이전트가 읽은 지침(CLAUDE.md, 사용자 규칙)은 수천 토큰 후에 힘을 잃습니다. june-mcp는 이를 구조적으로 해결합니다. 에이전트는 **상시 문서(standing docs)**를 June에 저장합니다 — kind='doc'는 지속적인 지침용, (pinned=true는 항상 적용되는 규칙을 요청), kind='skill'는 한 줄짜리 when_to_use 트리거가 있는 명명된 절차용(본문은 스킬처럼 지연 로드됨), kind='learnings'는 june_learn를 통해 작성되는 추가 전용 날짜 로그용입니다. 각 문서는 docs 캔버스의 일반 June 페이지(JUNE_DOCS_CANVAS, 기본값 agent_docs)이며, 작은 메타데이터 블록으로 표시됩니다 — 따라서 Junê 앱에서 에이전트의 메모리를 열고, 읽고, 편집할 수 있습니다.

에이전트가 따르는 내용은 사용자가 승인합니다 (0.7.0). 고정된 문서나 스킬은 사용자가 Junê 앱에서 승인하기 전까지 요청일 뿐입니다 (문서 배너 또는 설정 → 연결 → 상시 지침). 엔진은 사용자가 승인한 정확한 텍스트를 봉인합니다. 사용자가 아닌 다른 사람이 이후에 페이지를 편집하면, 사용자가 다시 확인할 때까지 카운트가 중지됩니다. 에이전트는 승인할 수 없습니다 — 연결 키에 그 권한이 없기 때문입니다 — 따라서 에이전트가 어딘가에서 읽은 텍스트("이것을 고정 규칙으로 저장…")는 결코 자체적으로 상시 지침이 될 수 없습니다. 승인을 기록하기에 너무 오래된 엔진은 에이전트에게 상시 지침을 전혀 제공하지 않으며, 그 사실을 명시합니다.

승인된 텍스트가 이동하는 경로: 연결 핸드셰이크에서 전체(최대 4,000자 — 맞지 않는 문서는 규칙 중간에 잘리지 않고 이름만 표시됨) 및 june_docs_refresh에서. 모든 세션의 첫 번째 도구 호출 시, 그리고 이후 12회 호출 또는 10분마다(조정 가능), 커넥터는 간결한 standing_docs 다이제스트를 일반 도구 결과에 첨부합니다 — 승인된 지침의 이름, 승인된 스킬 트리거, 승인·철회·편집 시 변경되는 버전 스탬프, 그리고 요청되었지만 승인되지 않은 문서는 메모로 표시됩니다. 다이제스트에는 승인되지 않은 문서의 내용이 포함되지 않습니다. 다이제스트를 만들 수 없는 경우(서비스 사용 중, 캔버스 누락) 건너뜁니다 — 호출 비용에 영향을 주지 않습니다. JUNE_DOCS_REFRESH=0를 설정하면 다이제스트를 끌 수 있으며, 문서 도구는 계속 작동합니다.

June은 스스로를 통해 에이전트에게 사용법을 가르칩니다. 첫 저장 시 docs 캔버스가 생성되고 **agent-memory-guide**이 시드됩니다: 운영 매뉴얼(시스템 캔버스와 워크스트림 캔버스의 구분, 세 가지 종류와 각각의 사용 시기, 명명 규칙, 고정할 항목, 개정 규율, 저장소 동기화). 이 매뉴얼은 모든 레지스트리와 다이제스트에 나열되며, 에이전트는 확신이 없을 때 june_doc_get('agent-memory-guide')로 읽습니다 — 그리고 편집 가능한 일반 페이지입니다. 아무것도 저장되기 전에는 빈 상태가 어깨를 으쓱하는 대신 setup 워크스루를 반환하고, june_memory_setup 프롬프트는 에이전트가 사용자를 인터뷰하고 사용자의 관례를 첫 문서로 저장하게 합니다.

June을 자동으로 만들기 — 에이전트가 지시 없이도 의존하게 하기

"June을 사용하세요"라고 말할 필요가 없어야 합니다. 세 가지 메커니즘이 쌓여 사용을 자동화하며, 각각 이전 메커니즘의 사각지대를 보완합니다:

1. 호스트 훅(콜드 스타트 해결). 서버는 에이전트의 첫 호출 전까지 말할 수 없습니다 — 따라서 호스트가 매 세션 기본적으로 로드하는 파일에 June의 상시 지침을 설치하세요:

   JUNE_EXPORT_ROOT=/path/to/project june-mcp --install-instructions            # → CLAUDE.md
   JUNE_EXPORT_ROOT=/path/to/project june-mcp --install-instructions AGENTS.md  # other agents
   

   이는 관리 섹션으로 작성되며(사용자 콘텐츠는 건드리지 않음, 재실행 시 제자리에서 업데이트), june-first 자세 — 무지를 주장하기 전에 June 확인, 요청 없이 사실 기억, 교훈을 즉시 학습 — 를 시스템 프롬프트 자체에 넣습니다.

2. 선제적 도구 설명(결코 낡지 않음). 핵심 동사의 설명은 모델에게 요청 없이 언제 사용해야 하는지 알려줍니다 — 설명은 모든 MCP 호스트에서 매 턴마다 다시 읽히며, 협력이 필요 없습니다.

3. 핸드셰이크의 june-first 자세. June의 기본 자세는 연결 지침에 내장되어 있습니다 (0.7.0, 이전 릴리스는 고정 문서로 시드 — 수정되지 않은 시드는 이제 숨겨지고, 수정된 시드는 사용자의 것이며 다른 문서와 마찬가지로 승인이 필요합니다).

어떤 MCP 서버도 — 솔직히 — 호스트가 행동하도록 강제할 수 없습니다: 호스트가 SERVER_INSTRUCTIONS를 숨기고 그리고 지침 파일이 없고 그리고 June 호출을 한 번도 하지 않는 에이전트는 콜드 상태로 남습니다. 메커니즘 1은 정확히 그 경우가 실제로 발생하지 않도록 하기 위해 존재합니다.

저장소 동기화 — June이 아는 내용으로 저장소를 최신 상태로 유지

JUNE_EXPORT_ROOT=<your repo>로 옵트인하면 세 가지 도구가 더 나타납니다:

도구	기능
june_docs_export	모든 에이전트 문서를 docs/agent/<name>.md에 미러링 — 저장소는 항상 현재 상시 지침을 보유
june_page_export	모든 페이지를 관리 파일로 내보내기, 또는 기존 파일 내부의 마커 사이에 삽입된 관리 섹션으로 내보내기 (path=KNOWHOW.md section=june-learnings) — 표시된 영역만 수정됨
june_page_import	반대 방향: 편집기에서 내보낸 파일을 편집하고 June 페이지로 다시 가져오기 — 에이전트 문서는 정체성을 유지하며, 오래된 파일은 최신 지식을 덮어쓰는 대신 거부됨

모든 안전 규칙은 코드로 강제되고 테스트로 고정됩니다: 모든 경로는 루트 내부로 펜싱됩니다(어휘적 .. 검사 및 심볼릭 링크 해석). june-mcp가 작성하지 않은 파일은 절대 덮어쓰지 않으며, 아무것도 삭제되지 않습니다. JUNE_EXPORT_GIT=1를 사용하면 각 내보내기는 작성한 파일만 정확히 커밋합니다 — pathspec으로 제한되어 스테이징된 작업이 휩쓸리지 않으며, 푸시는 절대 발생하지 않습니다. 내보낸 파일은 frontmatter를 가지며 바이트 결정적이므로, 변경되지 않은 문서는 동일한 파일로 재내보내기되어 git은 조용히 유지됩니다.

매니페스트(.june-export.json)는 최신 상태 확인을 가능하게 합니다 — CI용 두 가지 CLI 모드:

june-mcp --export         # sync agent docs + every managed page/section, commit if enabled
june-mcp --export-check   # write NOTHING; exit 1 if the repo has drifted from June

CI에서 --export-check는 "문서가 최신인가?"라는 희망을 실패하는 빌드로 바꿉니다.

Free vs Pro — june-pro 태그

june-mcp은 모든 사람을 위한 하나의 패키지입니다. 별도의 "프로 빌드"는 없습니다. Pro는 커넥터가 아닌 엔드포인트의 속성입니다: Pro 활성화 June(앱의 Pro 라이선스, 호스팅 워크스페이스의 Pro 키)에 연결하면 동일한 도구가 Pro급 결과를 제공합니다: 모든 june_remember 및 june_ingest_file 쓰기는 더 풍부한 엔터티/엣지 엔진을 자동으로 실행하며(결과는 어떤 engine가 실행되었는지 보고), june_resolve은 의미론적 매칭으로 업그레이드되고, june_enrich은 업그레이드 전 무료 계층에서 작성된 메모리를 백필합니다. 터미널은 현재 어떤 세계에 있는지 보여줍니다: --doctor는 edition 줄을 출력하고 서버의 시작 배너는 연결을 태그합니다 —

june-mcp: connected http://localhost:8000 canvas name "work" → 11d2… [june-pro]

태그는 서비스 자체의 /v1/whoami에서 읽힙니다(Pro 라우트를 서버 측에서 게이트하는 동일한 엔타이틀먼트 상태), 따라서 실제로 받는 것과 불일치할 수 없습니다 — 그리고 표시 전용입니다: 엔타이틀먼트는 클라이언트가 무엇을 출력하든 서비스에서 강제됩니다. /v1/whoami가 없는 이전 서비스는 태그를 표시하지 않습니다.

보안 모델

도구 표면은 캔버스/워크스페이스 매개변수를 노출하지 않습니다 — 워크스페이스는 연결 컨텍스트에서 서버 측에 바인딩되며, 실패 시 닫힙니다. 교차 테넌트 읽기는 실패 시 열릴 수 있는 권한 검사가 아니라 클라이언트에서 표현 불가능합니다. JUNE_READONLY=1은 읽기 전용 배포를 위한 두 번째 펜스를 추가합니다. 사용자 소유 LLM 키는 각 답변 요청에 헤더로 포함되며 서비스에 의해 저장되거나 기록되지 않습니다.

오류

모든 업스트림 실패는 유형화되고 편집된 오류 페이로드로 매핑됩니다(예외 유형 + HTTP 상태에서만 구성 — 응답 본문에서는 절대 아님), 따라서 서버는 엔드포인트가 던지는 모든 것을 견디고 에이전트는 깔끔하고 실행 가능한 메시지를 볼 수 있습니다.

라이선스

MIT. Junê 엔진 자체는 별도의 폐쇄 소스 제품입니다 — 이 커넥터는 설계상 공개된 부분입니다.