Content & Resources

The content model

A server's knowledge base is built out of four nouns:

Content record
   ├── Category    (label)
   ├── Group       (logical bundle, many-to-many)
   └── Relation    (source -> type -> target)
       └── exposed at request time as content://<slug>

Each content record has a unique slug; that slug is the join key everywhere. Categories, groups, and relations all reference content by slug — never by an opaque database identifier.

Three content sources

• File upload — drop a file (Markdown, plain text, and other supported formats) into the Contents tab. Vectoralix stores only the body in the database; there is no S3 and no metadata layer.
• Typed content — paste or write straight into the in-dashboard editor. Saved as a database record, identical in shape to an uploaded file.
• Repository import — sync from GitHub, Bitbucket, or GitLab via Source Integrations. Imported files become regular content records, keyed by slug like the other two sources.

For the repository path, see the Source Integrations group; this page covers the in-dashboard tabs only.

Contents tab

Where you create, rename, edit, and delete records. Each row carries the record's name, slug, source type, and category assignment. Slugs must be unique within the server. You can also assign a record to a category here without leaving the row.

Categories tab

Categories are user-defined labels scoped to a single server. They surface to AI clients via the File Search list_categories capability — when an AI asks "what kinds of material are on this server", the answer is your category list.

Groups tab

Groups are logical bundles. A record can belong to many groups (and vice versa) through a pivot. Each group carries an optional description; File Search's list_groups capability returns groups with their descriptions, so an AI client can pick the right narrow slice of your knowledge base instead of receiving a flat list.

Relations tab

Relations link two content records — a source, a relation type (e.g. "depends-on"), and a target. They are immutable once saved: to change one, delete it and create a new one. There is also a per-row "Relations" quick-add action on the Contents tab as a shortcut for adding a relation from a known source row.

How content becomes an MCP resource

At request time, every content record in the active version is exposed to AI clients as an MCP resource:

• URI: content://<slug>
• MIME type: text/plain
• Body: the raw content as stored in the database.

Clients that speak the resource side of the MCP protocol can list and read these directly; clients that only call tools see the same content surfaced through File Search.

How structure feeds File Search

• list_categories returns the unique category names you defined.
• list_groups returns groups with their descriptions.
• list_files lists content with a configurable preview snippet.
• full_text_search runs keyword search across the content body.
• search_related traverses your relations to surface neighbouring records.

A "flat" server with no categories, groups, or relations works — but the AI on the other end has to read everything to answer anything. Adding structure pays off the moment your content grows past a handful of records.

What happens when you cut a version

Cutting a version freezes content into a denormalised snapshot. The snapshot stores the content body, the category name (denormalised at cut time so renaming a category later does not rewrite history), the group memberships, and the relations. Relations are stored by slug rather than by ID, so they remain meaningful even after the underlying record IDs change.

One caveat — relations whose target lives on a different server are skipped in the snapshot, since the external record would not be reachable from this version.