Don't make every agent rediscover what your tools can already tell them.
30 seconds to understand the idea. A little longer to explore what it could mean for AI agents, developers, and token costs.
Project: "Sentinel-IR-MCP on npm" (https://www.npmjs.com/package/sentinel-ir-mcp) · "Source code on GitLab" (https://gitlab.com/jakubrojicek11/sentinel-ir-mcp) · "Core library: Sentinel-IR" (https://gitlab.com/jakubrojicek11/sentinel-ir)
⚡ The 30-second idea
Imagine using three AI agents on the same JavaScript project.
One investigates a bug. One reviews security-sensitive code. One helps implement a new feature.
Different tasks. Same codebase.
But how much time and context does each agent spend discovering the project's basic structure?
What if we gave agents a compact structural map before asking them to investigate?
That is the idea behind Sentinel-IR.
"Sentinel-IR-MCP" (https://www.npmjs.com/package/sentinel-ir-mcp) makes this structural analysis available to MCP-compatible AI clients.
Instead of starting with the entire source code, an agent can first inspect imports, exports, routes, filesystem and network operations, process execution, and other detected facts.
The potential benefit is straightforward:
Less repeated discovery. More targeted investigation. Potentially less unnecessary context.
Would that make a multi-agent workflow cheaper?
That is a question worth measuring, not a number I will invent.
🤖 Why this matters when you have multiple agents
AI agents are useful because they can approach different parts of a task.
However, splitting a task between agents does not automatically split the cost efficiently.
If several agents independently explore the same repository, some of their work may overlap. Each might need to discover where functionality lives, what modules depend on each other, and which files deserve attention.
The question is not whether multiple agents are useful.
It is whether every agent needs to rediscover the same basic facts from raw source code.
Consider a possible workflow:
- Agent 1: Maps the project's JavaScript structure and identifies relevant files.
- Agent 2: Investigates a bug using the structural facts and then reads the necessary source.
- Agent 3: Reviews selected files and checks the evidence relevant to the proposed changes.
The agents have different jobs. They do not necessarily need the same amount of context.
A shared structural report could help avoid repeating some discovery work, provided the surrounding workflow actually shares that report.
There is an important distinction here: Sentinel-IR-MCP provides analysis tools. It does not itself coordinate these agents, maintain a shared cross-agent cache, or guarantee that each agent will reuse the same analysis.
That part depends on the architecture around it.
🗺️ What Sentinel-IR contributes
Sentinel-IR extracts compact structural facts from supported JavaScript files.
Sentinel-IR-MCP exposes three tools through the Model Context Protocol:
Tool| Purpose
"analyze_directory"| Get an overview of a directory's JavaScript files.
"analyze_file"| Inspect the structural facts for one permitted file.
"analyze_code"| Analyze JavaScript source supplied as text.
A compatible AI client can use the results to decide where deeper inspection is needed.
The server is read-only in its analysis behavior. It does not modify the analyzed files or execute the JavaScript. It supports ".js", ".mjs", and ".cjs" files, not TypeScript.
This is not a replacement for source-code review. It is a way to make selected evidence available before the agent commits its attention to reading more code.
💰 Could this reduce the cost of multiple agents?
Possibly. But the real answer depends on what the agents do.
A compact report still consumes tokens. Analysis calls take time. Different tasks may require different levels of detail. And if every agent independently requests the same analysis, that work may still be repeated.
The relevant comparison is:
Repeated raw-source discovery versus structural analysis plus targeted source inspection.
To determine whether the approach saves money, measure both workflows on the same repository and tasks.
Track the input tokens used, the number of source files read, the time required, the number of repeated investigations, and whether each agent completed its task successfully.
If the structural approach uses fewer tokens without reducing task quality, that is useful evidence.
If it does not, that is useful evidence too.
I am interested in the experiment, not in inventing a universal savings percentage.
🔬 An experiment in discovery
This article has a second purpose.
I want to see whether a straightforward, structured explanation of an open-source tool helps people and automated discovery systems find it.
The question is simple:
Will publishing a focused explanation of Sentinel-IR-MCP be followed by an increase in npm downloads?
I will compare the public download counts before and after publication.
That will not prove that this article caused any change, or tell me which reader or system discovered the package. It is one observable signal, not definitive attribution.
Still, it is a practical experiment.
If you build AI coding agents, MCP tools, or multi-agent workflows, I would be interested in your perspective.
Would you give your agents compact structural facts first, or let every agent explore the source independently?
🔗 Explore the project
- "Install Sentinel-IR-MCP from npm" (https://www.npmjs.com/package/sentinel-ir-mcp)
- "Read the source code on GitLab" (https://gitlab.com/jakubrojicek11/sentinel-ir-mcp)
- "Explore the Sentinel-IR library" (https://gitlab.com/jakubrojicek11/sentinel-ir)
- "Read the original introduction and practical guide" (https://dev.to/jackymencz/sentinel-ir-mcp-give-your-ai-agent-a-map-not-the-whole-codebase-5hd5)
One codebase. Multiple agents. Less repeated discovery, if the measurements support it.
That is the hypothesis. Let's test it.
Top comments (0)