One agent, many tools, one outcome

To build a working knowledge store, an agent orchestrated several tools in a single flow. It called LLM Prover’s MCP tools, the REST API, and its own filesystem and HTTP tools, routing each step to the tool that fit, and chained them into one outcome: a store created, a document loaded, and the content confirmed ingested and queryable.

No single tool could do this alone. The result came from the agent composing them, guided by one of our MCP recipes: a copy-paste playbook that tells the agent which tool to reach for at each step.

MCP is a tool, not the toolbox

The interesting part is not that LLM Prover has an MCP server. It is that MCP was only one of the surfaces the agent used, and it deliberately was not the one that moved the file.

MCP is a JSON-RPC protocol. It is excellent for structured calls like “create a store” and “tell me the store’s status,” but it is not built to stream file bytes. A capable agent does not treat that as a wall. It keeps the store lifecycle on MCP, requests a short-lived upload URL from the REST API, and PUTs the raw bytes straight to storage with its own HTTP tool. Each step goes to the surface that fits it.

That is the pattern worth taking away. The agent that gets real work done is not locked to a single integration. It composes: MCP here, REST there, its own local tools in between, in one continuous task.

What each surface did

• MCP ran the store lifecycle: create_rag_store to make it, get_rag_store to confirm it finished ingesting.
• The client’s own tools held the file on disk and made the HTTP PUT of the raw bytes to the presigned URL.
• The REST API issued the presigned upload URL (POST /files/upload-url) and registered the file (POST /files/{file_id}/confirm).

Pairing purpose: rag_context with the store_id on the upload request is what makes the bytes a RAG ingest rather than a loose file. The store lifecycle stays on MCP; the bytes take the path built for bytes.

The step that is easy to miss

Landing the bytes in storage does not load the store. The PUT puts the object where it belongs, but the store does not know the file exists until the agent calls POST /files/{file_id}/confirm. That call registers the file and triggers chunking and embedding.

This matters because of how the system reports status. A store with nothing in it still returns sync_status: ready. If an agent trusted that flag alone, it would declare success over an empty store. So the recipe does not trust it: success means a chunk count above zero, not a status flag. In this run the agent polled until chunk_count came back non-zero, confirming the document was actually chunked and embedded. Status is a claim. The chunk count is the proof.

Why this generalizes

Swap “grab a file from local disk” for “fetch the public regulation documents and load them,” and the same flow builds a compliance knowledge base, agent-driven, no dashboard. The composition does not change. Only the source of the bytes does.

That is what “agent-native” looks like past the demo stage. Not a single tool an agent calls, but a dependable node your agent plugs into alongside everything else it already uses. The agent brings its own filesystem and HTTP; LLM Prover brings the store and the measurement. Together they build something neither does alone.

The recipe, “Load a File Into a RAG Store, End to End,” is live in the Recipes section. It declares the two client capabilities it needs up front and fails fast if your client cannot do them, so you never end up with a half-built store.

What’s next