Skip to content

sharepoint embedded retrieval

Jump to bottom
Kazushi Kamegawa edited this page Oct 24, 2026 · 1 revision

SharePoint Embedded retrieval and standalone API setup

日本語

Summary

Add opt-in SharePoint Embedded text retrieval to ContextRelay with natural-language queries and named source selection. Keep the product flow inside ContextRelay, using Microsoft APIs directly. Approved in the user conversation on 2026-10-24.

Tracking

Type Issue
Parent Issue #287
Sub-issue Issue #288
Sub-issue Issue #289
Sub-issue Issue #290

Background

Current SharePoint and OneDrive searches use Graph Search; only connectors use Copilot Retrieval. Embedded content needs a container-type-scoped Retrieval request, app permissions and user access. A user-owned Loop container still belongs to the Loop application; arbitrary Microsoft-owned Loop access is not established.

Design

  • Add disabled-by-default contextRelay.embedded.enabled and named contextRelay.embedded.sources entries with name, containerTypeId and enabled.
  • /embedded <query> accepts a natural-language sentence. Select one enabled source by its friendly name when multiple are configured; use a sole source directly, and send no request after cancellation. GUIDs appear only in initial source setup.
  • Call Copilot Retrieval with sharePointEmbedded and the selected container type. Request delegated FileStorageContainer.Selected only when enabled; source registration, owner-granted app access, user access, pay-as-you-go billing and semantic indexing are prerequisites.
  • Only the owning application can register container-type app grants. Configuration alone does not grant access. Document this limitation for Microsoft-owned Loop rather than promising cross-workspace access.
  • Add sharepoint-embedded results. Keep all returned extracts for preview, pinning, handoff and chat additionalContext; do not treat Embedded URLs as ordinary file references. Use the existing result limit clamped to 1..25. Reject empty or over-1500-character queries before networking.
  • Keep Embedded cache in memory, isolated by authentication session, source, query and result limit; clear it on identity/configuration changes. Show source name and Preview/PAYG guidance; expose permission failures without cross-source fallback.
  • Configure pinned official SPE MCP in read-only mode for VS Code, Claude Code, Copilot CLI and Codex; isolate external state directories and exclude developer configuration from the VSIX.
  • Evaluate direct Work IQ REST/A2A only. Existing A2A returns generated text; REST provides synthesized responses and citations, not a documented raw-extract retrieve endpoint. Work IQ MCP and external agent requirements are out of scope. OneDrive Copilot Search preview is deferred.
  • Update English/Japanese specifications, setup, permission examples and API evaluation. Preserve existing app grants in registration instructions and distinguish product implementation, service requirements and unverified tenant behavior.

Implementation phases

  1. Implement retrieval, authentication, configuration, command selection, preview, pinning, grounding, cache and regression tests (#288).
  2. Configure read-only development MCP clients and validate launch/configuration/VSIX exclusion without provisioning (#289).
  3. Update bilingual design and setup, evaluate direct Work IQ APIs, and record honest verification evidence (#290).

Verification

Run compile, lint, full unit tests, dependency-security checks and diff checks. Inspect the built VSIX and actual built UI for source selection, result/preview, pinning and errors. Test invalid configuration, cancellation, blank/long queries, missing scores, no results, 403/404/429 and identity/source changes. Verify MCP handshake and advertised read-only tools separately from actual client integration. Real container/Loop, billing and permission-trimming checks need an authorized tenant and are recorded as not-run when unavailable; local tests do not prove live tenant success.

References

Clone this wiki locally