The practical answer to "MCP or REST?" is usually: both, but for different jobs.
REST is excellent when an application knows what object it wants and needs deterministic retrieval. MCP is useful when an agent should discover tools, call context operations during a workflow, and receive structured results inside its reasoning loop.
For agent context, the interface should follow the task. A scheduled data job, dashboard, or warehouse sync probably wants REST or S3. An autonomous research assistant embedded in an agent runtime may want MCP. A real-time monitoring product may need a firehose. The important thing is not interface fashion. The important thing is that the same context objects remain structured and consistent across surfaces.
Hanging Context shows the public, no-auth aggregate layer. Synorb is the paid retrieval/detail layer where REST, MCP, S3, and other delivery surfaces belong.
Technical thesis
MCP and REST should expose the same context primitives through different interaction models:
- REST is best for deterministic pulls of streams, records, manifests, signals, and briefs.
- MCP is best for tool-native exploration where an agent chooses the next retrieval step.
- S3 or batch export is best for offline sync and warehouse-style use.
- Hanging Context JSON twins are best for no-auth public citation and aggregate inspection.
The interface can change. The object model should not. Claims, records, manifests, streams, tags, source channels, evidence, confidence, and timestamps need to remain recognizable across every surface.
What REST is good at
REST is the right default when the client wants clear URLs, stable response shapes, caching, pagination, and deterministic pull behavior.
The local REST route comments in `deliver/channels/rest_api.py` describe surfaces such as:
- Stream catalog and stream details.
- Stream signals, briefs, records, and manifests.
- Manifest access by record ID.
- Record access by record ID.
- Digest briefs and manifests.
- Pipeline configuration and prompts.
That is an application developer's world. A backend can call a route, store the response, compare IDs, and retry when needed. REST is also easy to expose in docs, notebooks, and integration tests.
For context retrieval, REST is especially strong when the client already knows the stream, manifest, record, or date range it wants.
What MCP is good at
MCP is useful when context access is part of an agent's active tool loop.
Instead of hard-coding every retrieval path into the model prompt, an MCP server can expose tools such as "search streams," "fetch manifest," "get recent claims," or "retrieve record detail." The agent can choose a tool, inspect the result, and decide whether to go deeper.
That is a good fit for exploratory work:
- A research agent identifying relevant streams.
- A monitoring agent fetching detail only after an aggregate signal changes.
- A workflow agent that needs context in the same environment where it drafts, plans, or routes work.
MCP should not be a license to return vague blobs. The returned objects still need source, time, evidence, confidence, and IDs. The protocol is not the product. The context object is the product.
Hanging Context is neither the full REST API nor MCP
The For Agents page in `hangingcontext/for-agents/index.html` is intentionally simpler. It presents public JSON twins for panels, no auth, no keys, no rate limits, and authoritative `as_of` fields. It also says the full firehose, per-manifest briefs, signals, and record metadata live at the Synorb API under a paid plan.
That is the clean boundary:
- Hanging Context: public aggregate snapshots and citeable JSON.
- Synorb: detailed stream retrieval and delivery surfaces.
An LLM can cite Hanging Context. A customer agent can retrieve the private detail through Synorb.
The same object shape should cross interfaces
The shared manifest helper in `deliver/shared_manifest.py` joins a manifest to source metadata, signal story, brief story, stream IDs, stream names, and matched timestamps. `deliver/channels/rest_api.py` then shapes a manifest payload with `source`, `signal`, `brief`, and `record`.
That object model should remain recognizable whether delivered through REST, MCP, S3, or another interface.
If REST returns one shape, MCP returns another, and the public panel implies a third, agents have to relearn the domain on every surface. That defeats the point of structured context.
The stable unit is the context object. The interface is how the agent asks for it.
A practical decision rule
Use REST when:
- The caller knows the endpoint or object ID.
- The workflow is scheduled or deterministic.
- The client needs caching and repeatable responses.
- A backend service or dashboard is consuming the data.
Use MCP when:
- An agent needs to discover and call context tools.
- Retrieval is part of an interactive reasoning loop.
- The next call depends on what the model just learned.
- Tool affordances are more useful than fixed routes.
Use the public Hanging Context JSON layer when:
- The task needs aggregate context.
- The answer needs a public citation.
- The application should not require customer credentials.
- The detail layer would be unnecessary or inappropriate.
The takeaway
MCP and REST are not enemies. They are access patterns.
For agent context, the important design choice is to keep the objects stable: claims, streams, manifests, signals, briefs, records, timestamps, evidence, and IDs. Hanging Context exposes the public aggregate view. Synorb gives production agents the retrieval and detail interfaces they need.