MongoDBProblem & solution
Fixed-tool document agents suffer multiple round trips and context window bloat because each call returns raw data, and cross-document relationships require pulling all files into the context. The author’s solution lets the agent write a MongoDB aggregation pipeline instead of arbitrary code, avoiding the security risks of a code interpreter. A handler validates the pipeline, prepends a tenancy filter, and executes it server-side, returning only the reshaped result. The agent uses a two-pass approach, often computing booleans or concatenating fields with $addFields so comparisons happen in the database. Limitations include regex not being semantic search and $limit silently truncating results, but the bounded language of nine permitted stages improves both safety and accuracy.
The post describes the challenges of using fixed MCP tools for a document agent that answers questions about contracts. These tools cause multiple round trips and context window bloat, and cannot handle cross-document relationships without pulling all documents into the context. The author presents a solution where the agent writes a MongoDB aggregation pipeline instead of arbitrary code, avoiding the security risks of a code interpreter. The approach has been in production for five months and is also reused for observability.
The agent authors a MongoDB aggregation pipeline. A handler validates the pipeline, prepends a tenancy filter, executes it server-side against the workspace’s documents, and returns only the reshaped result. The permitted stages are $match, $unwind, $project, $group, $sort, $limit, $skip, $count, and $addFields. Stages like $out and $merge are rejected, making the tool read-only. The agent uses a two-pass approach: a first pipeline to survey the data, then a targeted pipeline that often uses $addFields to compute booleans or concatenate fields. This collapses multiple round trips into one and filters data at the source.
Fixed tools for document agents cause context window bloat because each tool call returns raw data, and cross-document relationships require pulling all documents into the context, making the approach unscalable.
Letting the agent write a MongoDB aggregation pipeline instead of arbitrary code collapses multiple round trips into one, filters data at the source, and avoids the security risks of a code interpreter.
The bounded language of nine permitted stages improves safety and accuracy, but limitations include regex not being semantic search and $limit silently truncating results, requiring prompt-level compensations.
The agent writes a MongoDB aggregation pipeline instead of arbitrary code. A handler validates the pipeline, prepends a tenancy filter, and executes it server-side. The permitted stages are allow-listed, and stages like $out and $merge are rejected, making the tool read-only by construction.
Regex is not semantic search, so retrieval quality depends on the agent thinking of the right synonym. Also, $limit can silently truncate results, making a subset look like a complete answer. The prompt compensates with synonym sweeps and coverage checks, but the floor remains.
The agent writes a single pipeline that touches every file in the folder, pulls out only relevant sections, and returns them side by side with their source document. Cross-document comparisons happen in the database using stages like $unwind and $group, not in the context window.
Summaries are generated from the original by a language model. Check the original before relying on it.
See the idea
A four-step pattern for letting a document agent write validated aggregation pipelines instead of arbitrary code, so results come back shaped and tenancy stays enforced.
Keep reading
The Good Stuff
Paid picks we use ourselves. Links carry a referral code — a subscription through one earns us a commission at no extra cost to you.
One useful email. Unsubscribe anytime.
