Context Store Connectors

Use Context Store when an agent needs fast, searchable, read-only context from connector-like sources. It materializes connector records into the handle knowledge base, tracks source/entity status, and exposes read tools through API and MCP.

For OpenAnalyst and Smartwork project workflows, start with Company Context for OpenAnalyst. It explains when to use approved manual 10xKB documents, when to use Context Store, and how to keep 10Xmemory project/user memories separate from company context.

Context Store is one integration lane, not the whole connector system:

How it works

1. An operator creates a handle-scoped context source.
2. The source sync worker reads connector pages and writes normal knowledge documents.
3. Records become searchable through context_store_search and direct API search.
4. Agents use Context Store only when source/entity status is READY or PREVIEW.
5. Agents use direct function bindings or provider tools for writes, missing entities, or real-time freshness.

The handle is always the authorization boundary. projectId narrows search within the handle; it never grants access across handles.

Connector scopes

10xDotIn exposes connector facade objects at two explicit scopes:

Handle-scoped connectors are not automatically visible inside a project. A project must explicitly attach or create its own scoped connector before a project-scoped agent can use it.

curl -sS "${API_BASE}/v2/handles/${HANDLE}/connectors" \
  -H "authorization: Bearer ${JWT_TOKEN}"

curl -sS -X POST "${API_BASE}/v2/handles/${HANDLE}/connectors/ctx_src_global/search" \
  -H "authorization: Bearer ${JWT_TOKEN}" \
  -H "content-type: application/json" \
  -d '{
    "entity": "pages",
    "query": "pricing",
    "limit": 5
  }'

Auth and scopes

Create sources

Set environment variables:

export API_BASE="https://ai.10x.in"
export HANDLE="acme"
export JWT_TOKEN="<jwt-token>"

Web crawl

Use web_crawl for configured public pages.

curl -sS -X POST "${API_BASE}/v2/handles/${HANDLE}/context-sources" \
  -H "authorization: Bearer ${JWT_TOKEN}" \
  -H "content-type: application/json" \
  -d '{
    "sourceId": "docs_site",
    "projectId": "proj_launch",
    "connectorKey": "web_crawl",
    "selectedEntities": ["pages"],
    "refreshPolicy": { "mode": "manual" },
    "config": {
      "urls": [
        "https://example.com/docs",
        "https://example.com/pricing"
      ],
      "pageSize": 10
    }
  }'

Expected outcome: 201 with source, entities, and syncQueued.

GitHub docs

Use github_docs for repository docs or source files supplied as raw URLs or inline file records.

curl -sS -X POST "${API_BASE}/v2/handles/${HANDLE}/context-sources" \
  -H "authorization: Bearer ${JWT_TOKEN}" \
  -H "content-type: application/json" \
  -d '{
    "sourceId": "repo_docs",
    "projectId": "proj_launch",
    "connectorKey": "github_docs",
    "selectedEntities": ["documents", "code"],
    "config": {
      "rawUrls": [
        "https://raw.githubusercontent.com/acme/app/main/README.md",
        "https://raw.githubusercontent.com/acme/app/main/src/catalog.ts"
      ],
      "pageSize": 25
    }
  }'

Markdown-like paths are indexed as documents; other files are indexed as code.

Upstream MCP resource exports

Use upstream_mcp_resource for read-only exported records from an upstream resource. In v1, this connector materializes provided records or resource URLs. It does not carry provider credentials, call arbitrary remote MCP tools, or proxy upstream MCP sessions.

curl -sS -X POST "${API_BASE}/v2/handles/${HANDLE}/context-sources" \
  -H "authorization: Bearer ${JWT_TOKEN}" \
  -H "content-type: application/json" \
  -d '{
    "sourceId": "crm_export",
    "connectorKey": "upstream_mcp_resource",
    "selectedEntities": ["records"],
    "config": {
      "records": [
        {
          "id": "acct_123",
          "entity": "records",
          "title": "Acme renewal account",
          "content": "Renewal owner: Maya. Contract renewal date: 2026-07-01.",
          "fields": {
            "accountId": "acct_123",
            "stage": "renewal"
          }
        }
      ],
      "pageSize": 50
    }
  }'

For live CRM writes or real-time account lookup, use a provider-backed function binding instead of putting credentials in a context-source config.

Check status and refresh

curl -sS "${API_BASE}/v2/handles/${HANDLE}/context-sources" \
  -H "authorization: Bearer ${JWT_TOKEN}"

curl -sS "${API_BASE}/v2/handles/${HANDLE}/context-sources/repo_docs/entities" \
  -H "authorization: Bearer ${JWT_TOKEN}"

curl -sS -X POST "${API_BASE}/v2/handles/${HANDLE}/context-sources/repo_docs/sync" \
  -H "authorization: Bearer ${JWT_TOKEN}" \
  -H "content-type: application/json" \
  -d '{}'

Status values:

Search

Structured listing:

curl -sS -X POST "${API_BASE}/v2/handles/${HANDLE}/context-store/search" \
  -H "authorization: Bearer ${JWT_TOKEN}" \
  -H "content-type: application/json" \
  -d '{
    "projectId": "proj_launch",
    "sourceId": "repo_docs",
    "entity": "documents",
    "fields": ["title", "preview", "documentId", "metadata"],
    "limit": 10
  }'

Text search:

curl -sS -X POST "${API_BASE}/v2/handles/${HANDLE}/context-store/search" \
  -H "authorization: Bearer ${JWT_TOKEN}" \
  -H "content-type: application/json" \
  -d '{
    "projectId": "proj_launch",
    "entity": "documents",
    "query": "How does the repo configure catalog routes?",
    "limit": 5
  }'

Responses include executionPath: "context_store" and source status metadata so agents can explain whether they used replicated context or should fall back to a direct request.

MCP usage

Grant the connector:

• mcp.connect
• context_store.search
• context_store.manage only when the assistant should be allowed to request refreshes
• binding.invoke:* or binding.invoke:{bindingKey} when the assistant should call direct function bindings

Useful prompts:

• "Check Context Store status for this handle before answering from connector data."
• "Search project proj_launch Context Store records for deployment runbook requirements."
• "If the source is not READY or PREVIEW, use the live provider binding instead."
• "Refresh source repo_docs, then report the source/entity status."

Pair with function bindings

Use this pairing when a connector has both a searchable corpus and live operations:

Provider-backed bindings are the recommended way to expose a stable external HTTPS API as hosted MCP tools. Context Store should reference only read-only source config and replicated content.

Use webhooks to trigger refreshes

10x webhooks are outbound event deliveries. They do not write directly into Context Store. A webhook-assisted refresh uses your receiver or automation worker as the bridge:

1. 10x sends an outbound webhook event to your HTTPS receiver.
2. Your receiver decides which source is stale.
3. Your receiver calls the MCP sync route with a PAT that has mcp.connect and context_store.manage.
4. The Context Store worker refreshes asynchronously.

Example receiver action:

export PAT_TOKEN="patv1_<tokenId>.<secret>"
export SOURCE_ID="repo_docs"

curl -sS -X POST "${API_BASE}/v2/mcp/${HANDLE}/context-store/sources/${SOURCE_ID}/sync" \
  -H "authorization: Bearer ${PAT_TOKEN}" \
  -H "content-type: application/json" \
  -d '{}'

For provider-originated webhooks, terminate and verify the provider webhook in your own receiver first, then call the same Context Store sync route. Do not put provider webhook secrets into a Context Store source.

Related

• Knowledge Base for Handles
• Knowledge Base Usage Guide
• Company Context for OpenAnalyst
• Provider-Backed MCP Bindings
• Webhook Delivery and Failure Handling
• MCP Tools Reference