Open Index

What is Open Index?

Open Index is an MIT-licensed, self-hosted structured context layer for AI agents. Instead of handing an agent a folder of prose, you model a domain as a 'brain' built from four primitives — doc_type (a concept you track, e.g. service, customer, issue), doc_schema (the fields for that type), entity (one instance, stored per its schema), and connector (an optional source you extract entities from). Every entity links to others through a related_to target plus a free-text relationship_edge_meaning that carries the edge semantics, so the result is a searchable context graph without running a graph database. Agents reach it through an MCP context layer that both reads and writes, so accumulated learnings go back into the same validated structure.

Key features

• Four modelling primitives — doc_type, doc_schema, entity, connector — with entity-to-entity links carrying free-text edge meaning, giving a navigable graph without a separate graph database.
• SQLite + FTS5 as the default backend for local and single-writer use, with semantic search up to roughly 10,000 entities.
• OpenSearch backend for concurrent writers and deployments past ~10k entities, adding native fuzzy matching and k-NN semantic search.
• MCP context layer over stdio via `open-index mcp`: reads through search_brain(), get_entity() and navigation_guidelines(); writes through put_entity(), put_entities() and create_doc_type(), all validated against the schema and storage policy.
• `--read-only` flag on the MCP server to expose the brain to an agent without granting write access.
• `open-index serve` publishes the same MCP tools over HTTP with bearer-token auth for remote agents, and `--brains` serves every brain under a directory from one process.
• `open-index mcp-config` prints the connection block to paste straight into an agent's MCP config.
• Explorer UI (`open-index ui`) with Explore, Map, Analytics and Jobs tabs, plus optional Python connectors under connectors/*.py that ingest entities from other MCP servers on a schedule.

Who it's for

• Give a domain agent a navigable entity graph — services, customers, issues — instead of an unversioned pile of markdown that contradicts itself.
• Let an agent write what it learned back into a schema-validated store, so accumulated context stays structured rather than drifting into free text.
• Share one context store across several agents, moving from SQLite to OpenSearch at the point where a second agent needs to write.
• Expose a brain to remote agents over HTTP with bearer-token auth, or in --read-only mode to agents you do not want writing back.
• Keep the store fed automatically by scheduling connectors that pull entities from other MCP servers via `open-index ingest` / `open-index run`.

When not to use it

The default SQLite backend does a brute-force cosine scan for semantic search and is single-writer, so it tops out around 10,000 entities — past either line you have to stand up and operate OpenSearch yourself, and there is no hosted tier to fall back on because this is a self-hosted Python package only.

FAQ