Supply-Chain Map vs MCP vs API: Which Research Workflow Fits the Question?
August 31, 2026
Altsets
Research by Altsets Research
Choose a visual network, an LLM connected through MCP, or an API based on whether the research job is discovery, iterative synthesis, or repeatable analysis at scale.
Data used:Altsets Supply Chain Intelligence: 90k+ entities, 400k+ relationships, 20+ years of history.
Key findings
- The KLA to Micron relationship retains the same direction and economic metrics across interfaces, including 4.59% of KLA revenue, 693M USD relationship size, and 2.84% of Micron's cost base.
- A visual map is strongest for topology and discovery, MCP for iterative retrieval and synthesis, and an API for deterministic screens, historical research, and repeated calculations.
Use a visual map to explore and understand a network, MCP when an LLM should query relationships during research, and an API for repeatable, bulk, or historical analysis. The same underlying data can support all three workflows. In the supplied Altsets data, KLA is mapped as a supplier to Micron at 4.59% of KLA revenue, 693M USD of relationship size, and 2.84% of Micron's cost base.
Those facts do not change depending on whether the investor uses a visual map, an LLM connected through MCP, or an API. The right interface depends on what the investor wants to do next.
Use a visual map when the question is "what am I missing?"
A network view is strongest for discovery. Suppose the investor starts with Micron. A map makes it easier to notice several upstream semiconductor-equipment suppliers, downstream Nvidia exposure, server and hardware customers, shared counterparties, and second-order paths.
That spatial context is difficult to reproduce with one table. The point is not decoration. It is to help the researcher notice a relationship they did not know to query in advance. The free workspace is the simplest way to inspect this kind of surrounding network.
Use an LLM or MCP when the question is iterative
Once the relationship is known, the next questions often arrive conversationally. For example:
- How does KLA compare with Lam Research as a Micron supplier?
- Which Micron suppliers matter most by customer cost percentage?
- Which supplier relationships have missing metrics?
- What public evidence explains the supplier's function?
- What should I investigate next if Micron announces a new fab?
Those questions require several retrieval and reasoning steps. MCP is designed to let an AI application connect to external tools and data sources rather than rely only on model memory. An LLM can therefore request the relevant relationship data as the research conversation develops.
The important requirement is that the model preserve the returned metrics and their direction. The LLM grounding guide covers those safeguards.
Use an API when the question is repetitive
An API becomes more useful when the same operation must be performed many times. Examples include screen every portfolio holding for shared suppliers, rank hundreds of companies by one relationship metric, retrieve historical snapshots, build a repeatable factor, run nightly research jobs, and validate outputs automatically. Those tasks do not need a conversational model in the calculation loop.
The same relationship can be retrieved programmatically and processed under deterministic rules. The Altsets documentation covers the available endpoints and research interfaces.
The interface should not change the analytical contract
KLA to Micron remains KLA to Micron. Supplier revenue percentage remains supplier revenue percentage. Customer cost percentage remains customer cost percentage.
Missing data remains missing. Historical snapshots should remain point-in-time. A bad workflow is one where the interface changes the meaning of the data. A good workflow changes only how the researcher interacts with it.
The visual map is strongest at topology
A map answers questions such as: Who sits around this company? Which relationships share a node? Is there an unexpected customer or supplier? Where does a second-order path go? Do several holdings converge on the same company?
Those are graph-structure questions. They are often easiest to understand visually.
MCP is strongest at synthesis
An LLM can combine relationship retrieval with public research and reasoning. For example, after retrieving KLA to Micron, the model can separately look up what KLA sells, what Micron says about process-control requirements, and whether a current event makes the relationship relevant. That is useful when the research path is not known in advance. The model should still label which facts came from Altsets and which came from public sources.
The API is strongest at reproducibility
If an investor wants the same screen every week, a script is usually better than asking an LLM to reconstruct the procedure from scratch. The API can enforce exact filters, exact dates, exact metric definitions, stable sorting, stored outputs, and regression tests. The LLM can interpret the resulting table afterward. That division of labor is often cleaner.
A simple decision table
| Research job | Best starting interface |
|---|---|
| Explore one company's neighborhood | Visual map |
| Ask follow-up questions about a few relationships | LLM with MCP |
| Compare many companies repeatedly | API |
| Inspect a second-order path | Visual map or MCP |
| Run a historical backtest | API |
| Combine proprietary relationships with public context | MCP or manual research |
| Verify the exact returned record | API or direct data view |
These are starting points, not hard boundaries. A serious research workflow can use all three.
A practical combined workflow
One efficient sequence is:
- Use the map to discover an unexpected relationship.
- Use MCP or the research chat to ask why the relationship might matter.
- Validate important claims with public sources.
- Move the repeatable calculation into the API if the idea needs to scale.
- Return to the visual network when a new path or cluster needs inspection.
That prevents the workflow from forcing every research problem into the same interface.
The product question should follow the research question
A user evaluating supply-chain data does not need to decide whether they are a "map person," an "AI person," or an "API person." They need to decide what they are trying to learn. Discovery, synthesis, and scale are different jobs.
The interface should match the job. For data definitions and limitations, read the Altsets methodology. For implementation details, MCP access, and API usage, use the Altsets documentation. Browse Supply-Chain Data Use Cases for concrete questions that can be explored through any of the three interfaces.