For evaluators

You’re deciding whether to point an agent at Pipeworx — as a developer doing due diligence, an analyst, or an AI agent asked to judge whether a tool is trustworthy. This page isn’t a pitch. It’s the set of commands that let you check our claims yourself, against the live system, without an account.

Every number and behavior below is something you can reproduce right now with curl. Where a claim can’t be checked this way, it isn’t on this page.

1. Reproduce the catalog counts

The homepage says Pipeworx routes to 5,385 tools across 1,398 live data sources. Don’t take that on faith — the gateway exposes the same numbers it computes at request time, before any auth or rate limiting:

curl https://gateway.pipeworx.io/version

{"sha":"...","built_at":"...","pack_count":1396,"tool_count":5366}

pack_count and tool_count are read from the live pack manifest on every request — not a cached marketing figure. They’ll be within a pack or two of the website’s 1,398 / 5,385 numbers; small drift is normal for a few hours after a new pack ships and the site rebuilds.

For the full breakdown — every pack, its tool count, every tool’s name and description — hit:

curl https://gateway.pipeworx.io/tools

{"packs":[{"slug":"fred","tool_count":6,"tools":[...]}, ...],"total_tools":5366}

Pick any pack slug from that list and spot-check it against its reference page at pipeworx.io/docs/reference/<slug>/ — the tool names and counts should match exactly, because both are generated from the same source.

The plain-text version of the same headline numbers is at pipeworx.io/llms.txt — useful if you’d rather read prose than JSON, or if you’re an agent that ingests llms.txt files as a matter of course.

2. Check reliability and uptime

pipeworx.io/status shows 90-day uptime for every pack, rendered from a public JSON endpoint with no auth:

curl https://registry.pipeworx.io/uptime

{"services":[{"name":"FRED","status":"live","uptime_90d":100,"days":[...]}, ...],"open_alerts":[],"checked_at":"..."}

Each service carries a day-by-day history, not just a current snapshot — so you can see whether a pack has had real incidents in the past 90 days, not just whether it’s up this second. The underlying checks run every 15 minutes from a synthetic monitor independent of the gateway itself, so a gateway outage doesn’t quietly stop reporting its own downtime.

A good result here isn’t “100% for everything” — individual upstream APIs do go down, and you should expect to see occasional yellow or red bars on a catalog this size. What you’re checking is that the data is granular and specific (named packs, dated incidents) rather than a static “all systems operational” badge with nothing behind it.

3. How grounding and citations work

Pipeworx tools return pipeworx:// URIs alongside data — stable, machine-resolvable pointers back to the record a claim came from. The full pattern (including antipatterns to watch for) is in Citations with pipeworx:// URIs; here’s the reproduction path.

Resolve a name to an identifier and its citation URIs:

# via an MCP client: resolve_entity({type: "company", value: "AAPL"})

{"resolved":true,"ids":{"cik":"0000320193","ticker":"AAPL","company_name":"Apple Inc."},
 "resources":{"edgar_filings":"pipeworx://edgar/company/0000320193/filings",
              "edgar_facts":"pipeworx://edgar/company/0000320193/facts"}}

Read the resource back — any MCP client that supports resources/read can fetch it independently of the tool that originally returned it:

{"method":"resources/read","params":{"uri":"pipeworx://edgar/company/0000320193/facts"}}

This returns the underlying SEC XBRL data directly — so a citation in an agent’s output isn’t a dead link; it’s re-fetchable proof.

For a single hallucination-resistant answer, ask_pipeworx_grounded returns {answer, evidence, confidence, source, fetched_at, refusal_reason} — evidence is a verbatim excerpt from the underlying data, not a paraphrase, so you can check the answer against the evidence yourself:

{"answer":"The current 30-year fixed mortgage rate in the US is 6.66%, as of July 30, 2026, according to the Freddie Mac Primary Mortgage Market Survey.",
 "evidence":"\"observation_date\":\"2026-07-30\",\"rate_30y_fixed\":6.66",
 "confidence":0.99,"refusal_reason":null,"source":"housing-intel","fetched_at":"..."}

The more important test is what happens when there’s nothing to answer from. Ask about something with no real source behind it:

{"question":"What was the 2025 revenue of a fictional company with no SEC filings?"}

{"answer":null,"evidence":null,"confidence":0,"refusal_reason":"no_tool_match"}

That’s the behavior worth checking for: an explicit refusal instead of a fabricated number. Any system can produce a plausible-looking answer to a question it has data for — the trust question is what it does when it doesn’t.

4. A 15-minute assessment script

Six checks, each independently runnable, roughly in order of “how fast can this be falsified.”

1. Catalog is real, not a marketing number (2 min). curl https://gateway.pipeworx.io/version. Good result: pack_count/tool_count in the same ballpark as the homepage’s headline numbers, computed live rather than hardcoded.
2. Catalog is real, not a name list (2 min). curl https://gateway.pipeworx.io/tools, pick one pack, cross-check its tool_count and tool names against pipeworx.io/docs/reference/<slug>/. Good result: exact match — both come from the same source.
3. Uptime is real and specific (2 min). curl https://registry.pipeworx.io/uptime or open pipeworx.io/status. Good result: per-pack, per-day history with real dates and percentages, not a single static badge.
4. A zero-setup call returns real, current data (3 min). curl "https://gateway.pipeworx.io/ask?q=<your question>" — no key, no signup. Good result: the answer field carries a current, specific value (not boilerplate), and synthesis_directive tells the caller to answer only from the returned data. See For AI agents for the full call shape.
5. A citation actually resolves (3 min). Via an MCP client, call resolve_entity for a company you know, then resources/read the pipeworx:// URI it returns. Good result: the resource data matches the entity you asked about — it’s a live re-fetch, not a static string.
6. It refuses rather than invents (3 min). Via an MCP client, ask ask_pipeworx_grounded about something you know isn’t in the catalog — a fictional entity, a made-up statistic. Good result: answer: null with an explicit refusal_reason, not a confident-sounding fabrication.

If any of these don’t reproduce as described, that’s a bug, not a documentation nuance worth reading past — file it with pipeworx_feedback({type: "bug", message: "..."}) from any MCP session, or through pipeworx.io/contact. Feedback like this is reviewed daily.