Your agent burns tokens joining your data. Hand it the context already joined.
Postgres, GitHub, OpenTelemetry, documents, correlated into one timeline per entity, served over MCP. One call, then your agent reasons.
Connect a source once. Every agent can use it immediately.
Point Tares at a database, a folder of documents, an API, and it becomes part of one queryable, correlated surface that any MCP agent can read. Here is what that buys you:
A connector, not another server.
Adding a source is ingest config: point Tares at the database, the folder, the API. No MCP server to write, ship, and keep on call for each one.
Records arrive already correlated.
The Postgres row, the API enrichment, and the document about the same customer land on one keyed timeline. Agents spend their context on the task, not on joining.
Your sources stay calm.
Agents read from the Tares store, so your production database and rate-limited APIs see one well-behaved reader, no matter how many agents you run.
Memory comes standard.
Everything an agent reads or writes about an entity stays on its timeline, so the next task starts from what is already known.
One correlated read per incident. The baseline needed four to nine, depending on how hard the fault was to pin down.
We built the incident-response version first. same diagnosis.
An SRE agent burns most of its calls fanning out across metrics, logs, deploys, and config. We rebuilt Anthropic's SRE cookbook into a four-fault testbed and ran the same agent both ways: 24 reads became 4 across the set, the root cause was found in all eight runs, and it came out about 1.3× cheaper at roughly $0.02 an incident.
One endpoint, every framework. harnesses included.
Tares serves standard MCP, so nothing about your agent is prescribed. Point Claude Code or Codex at it and your whole data estate becomes tools they already know how to call, or wire it into a custom loop through any MCP client.
- claude codeclaude mcp add
- codexcodex mcp add
- claude desktopmcp config
- cursormcp config
- agent sdksmcp client
- your own loophttp + sse
Your agent gets the whole toolkit. set up, enrich, derive insights.
Everything the console can do is an MCP tool. Your agent can connect a new source, profile its real fields, declare the enriched view, set the trigger, and query the result, all in one conversation, without you wiring anything by hand.
- inspect
Discover every source, view, and trigger that exists, with schema, lineage, and freshness included. No tribal knowledge to hand it first.
catalog_list()catalog_describe()source_fields() - create
Add a source, test it, and shape the enriched view it wants to read.
create_source()test_source()derive()update_view() - watch
Set a condition over live data and choose who it wakes.
create_trigger()update_trigger()subscribe() - read
Pull the correlated timeline for any entity, and write back what was learned.
query()read()remember()
How it fits your stack. the common questions.
More detail in the docs, or email hello@glassflow.ai.
Does this replace my warehouse or my pipelines?
No. Your pipelines keep landing data in Postgres or Redshift for BI. Tares sits beside them as the read path for agents, and treats the warehouse itself as one more source. Analysts keep SQL; agents get MCP.
Is this only for logs and metrics?
No. Observability was one vertical; the plane is general. Anything that can be pulled, received, or extracted becomes a source: database rows, API responses, documents, files, webhooks. If it has an entity and a timestamp, it correlates.
Do my agents query my sources directly?
Never. Tares ingests each source once into its own store, and agents read from Tares. Your production database and your rate-limited APIs see one well-behaved reader instead of a fleet of agents.
Connect any source. Query it from an agent minutes later.
Pick the source your agents keep guessing about. One command, on your laptop, and nothing on the source side changes.