Skip to main content
Agent integration: AI agents connect to Mixpeek via MCP, SDK, or REST to access ingest, search, classify, and monitor capabilities
Mixpeek exposes its entire platform as agent-callable tools. Connect via MCP for zero-code setup, use the built-in Agent Runtime for stateful conversations, or wire retrievers into LangChain, OpenAI, or any framework via REST.

Connect your agent to your own data

Create a namespace to get your API key and MCP endpoint, then give your agent search, ingest, and classify tools over your own content.

MCP (Model Context Protocol)

The fastest way to connect an AI agent to Mixpeek. Four hosted servers expose different tool scopes:

Per-Retriever Server

For a focused search agent, scope the MCP server to a single retriever. It reads your retriever’s input_schema and generates a typed search tool:
Exposes three tools: search (typed to your schema), describe (retriever metadata), and explain (pipeline walkthrough). Full MCP reference →

Agent Sessions

Mixpeek’s built-in agent runtime gives you stateful, multi-turn conversations backed by your data. Each session runs as a dedicated process with tool access, conversation memory, and SSE streaming.
The agent reasons through a analyze → plan → execute → synthesize workflow, calling tools as needed and streaming events back:

Available Tools

Sessions persist for 7 days and automatically rehydrate after idle periods. Agent Sessions API →

LangChain

The langchain-mixpeek package provides a retriever, individual tools, and a full toolkit:

Toolkit Tools

Scope tools to what your agent needs with toolkit.get_tools(actions=["search", "ingest"]). Full LangChain guide →

OpenAI Function Calling

Define a Mixpeek retriever as an OpenAI function schema:
Works with both the Chat Completions API and Assistants API. Full OpenAI guide →

Any Framework (REST)

The same pattern works with CrewAI, LlamaIndex, Haystack, Autogen, or plain HTTP — wrap the retriever execute endpoint as a tool:
Retriever Execute API →

Let an agent build the namespace

An agent can build a namespace end to end through the API: read the catalog, generate a manifest from a description, read its price, apply it, index files and grade the result. Give the agent an API key and this section. An agent given only this section and the billing page built a searchable namespace over 200 photos with the script below; its quote, its batch estimate and its charge were each $0.40.
1

Read the catalog

GET /v1/discovery returns the extractors, the models, the retriever stages and the manifest schema, with an example manifest and the authoring loop. GET /v1/public/templates/namespaces lists the templates.
2

Generate a manifest and its quote

POST /v1/manifest/generate takes description, manifest_name, and optionally inventory (files per bucket) and queries_per_month. The answer carries manifest (YAML), validation, suggested templates and models, and quote. When the manifest has one bucket and inventory has one entry, the quote prices that entry as the bucket and says so first in quote.assumptions. With several buckets, quote.error lists the bucket names. cost_estimate is a catalog figure at a stated volume (10,000 items and 100,000 queries a month); quote is the price for your files.
3

Edit the manifest

Read the YAML before applying it. A generated manifest can declare a storage connection and a bucket sync that need cloud credentials; remove them to upload files through the API. Add a field to the bucket schema and to the collection’s field_passthrough for anything you grade by, such as a file name. A retriever’s final_top_k caps every evaluation at that k, so raise it to at least twice your largest relevant set before grading. An edit can change the price, so quote the edited YAML again with POST /v1/organizations/billing/estimate; that quote is the one the batch is charged.
4

Validate, diff and dry-run

Send the YAML as the multipart file field manifest_file to POST /v1/manifest/validate, POST /v1/manifest/diff and POST /v1/manifest/apply?dry_run=true. The diff lists resources outside your manifest under in_system_only; apply leaves them alone, and the dry run’s would_create_count confirms it.
5

Apply, index and read the charge

POST /v1/manifest/apply returns each resource with its id. Each bucket also gets a system collection, mvs_bucket_<bucket_id>, which holds one document per object and costs nothing. Add objects, batch them, price the batch, submit it and poll it until its status is COMPLETED, COMPLETED_WITH_ERRORS, FAILED or CANCELED. The batch’s cost.cost_usd is what it was charged; GET /v1/organizations/billing/transactions lists the same charge.
6

Grade the retriever

Create a dataset, then start an evaluation with the metrics inside evaluation_config, and read it until its status is completed.
The whole loop in Python, with the shapes each call takes:
Python
query_input takes the retriever’s input fields (here its query input). f1_at_1r grades each query at k equal to its number of relevant documents, and f2_at_2r at twice that. On 200 COCO photos and five object queries, the run above scored F1 0.62 at k = R and F2 0.69 at k = 2R.

Choosing an Integration