Signals for Systems · MCP-native

Current entity and event state, machine-readable

SigB maintains source-backed entity and event state for systems whose answers change when the world changes. This page is the full integration contract: stable schemas, an explicit evidenceStatus on every signal (receipted rows carry the source URL behind each claim; unreceipted rows are labeled as leads), and freshness stamps your agent can check rather than trust. No key and no login for reads. The guided map for agents — orient-first, the async ask pattern, the promises we make a machine guest — is the machine front door.

1 · Pull the signal feed (REST)

One GET, no key. Returns the current flags — each with name, trajectory (direction + % change), the domains it's spreading across, desk membership, top evidence with source URLs, and a pre-phrased follow-up question for the Answer Engine. The envelope carries asOf and a methodology block so a downstream agent can cite honestly. Schema sb.signals.v1: additive changes only — fields are never renamed or removed within a version.

GET /api/signals
curl -s "https://sigb.ai/api/signals?limit=5"

Filters: ?limit=N caps the list; ?direction=rising (or fading, steady, new) filters by trajectory. Responses are edge-cached for 10 minutes; the underlying snapshot is rebuilt on a multiple-times-daily schedule (three timed builds today) and every payload stamps its own generatedAt — trust the stamp, not this sentence.

Freshness, defined per layer. We read every subject area we cover at least once a day; prediction-market prices and fast-moving desks are read again during the day. Entity and event state updates with the daily build and with updates during the day. The published feed is the snapshot above, rebuilt on that schedule. Answers are computed when you ask, against the latest build.

Three coverage counts. The coverage object in the feed reports how many subject areas are set up (registered), how many are being read on schedule today (activelyScraped), and how many the currently flagged entities draw evidence from (spannedByFlaggedEntities, which moves with the news). Where a page shows one number, it is one of these three.

2 · Or connect your AI over MCP

SigB speaks MCP over Streamable HTTP: each JSON-RPC 2.0 message is its own HTTP POST, answered with plain JSON (no SSE stream to hold open; a standalone GET returns 405). The server is stateless and issues no session ids. Protocol version is negotiated at initialize: current revisions through 2025-11-25 are fully supported, and the 2024-11-05 message version is accepted for clients that can initialize over this endpoint — the deprecated 2024-era HTTP+SSE transport is not provided. Standard clients follow the normal lifecycle (initialize → notifications/initialized → tools/list → tools/call). As a SigB convenience extension, direct tools/call without the handshake also works for lightweight stateless integrations. No key for the read tools.

mcp config
{
  "mcpServers": {
    "signal-bureau": {
      "url": "https://api.signalbureau.ai/api/mcp"
    }
  }
}

The config above points at https://api.signalbureau.ai — the machine door: the same API on a host with no browser checks, where any User-Agent is welcome. If you ever get a 403 mentioning code 1010, you are on the apex host; switch to api. and it clears. You never need to disguise your client as a browser.

Don't take our word for it: look this server up in the official MCP registry — the registry's own search for our name, answered by their host, not ours. Where else machines find us, and what our own check last saw on each, is listed at the foot of this page.

tools/list serves 29 tools today, listed below in its order. To see how the record fits together, start at an entity or event (e.g. Hormuz) and traverse its maintained relationships; each step returns its relation type, receipts, standing and time. The tool is traverse; start with {"id": "entity:hormuz"}.

  • start_hereCall this first — the front door for first contact — who we are, what's free, the live rate card with real prices, how to propose coverage, and how buying works. No side effects, costs nothing.
  • top_acceleratingThe entities accelerating most across the information environment right now, ranked by cross-domain attention.
  • search_entitiesFind tracked entities by name or subject area (e.g. "iran", "semiconductors").
  • get_entityFull dossier for one entity: signal count, the subject areas it's spreading across, and why it's surfacing.
  • get_topic_recordThe maintained record for one subject (hormuz today, the default) — the same record the public exhibit page renders: primary operational sources with verified-as-of dates, attributed reporting, our coverage measure, the prediction-market price history we cite, our own assessment (labeled as ours), where the reporting agrees, and state history, as one JSON object with the layers kept apart and labeled. Free; same payload as GET /api/truth/hormuz. Earlier names get_truth_object and get_truth_record keep answering, permanently. Complementary to get_entity's broader live dossier.
  • askWhat the tracked record shows about an entity or unfolding event (not historical lookup) — does real model work and rides a free identified key: self-issue one in a single call (POST /api/keys, instant, no card) and it carries 25 free asks for the life of the key on its own meter (not per day — they do not reset), never shared with your cloud or office neighbors. Returns an answer checked against sources (pass/fail disclosed on every response) with what would change it. Informational only.
  • get_answerCollect an async answer by ticketId (ask is async by default: submit gets a claim ticket in ~1s; collecting is free — the question was metered once at submit).
  • get_signalsStart here for browsing — the cheap read (500/day, no model work). The full machine-readable signal feed: every flagged entity with trajectory, domains, desk membership, and an explicit evidenceStatus (receipted rows carry source-attributed evidence URLs; unreceipted rows are labeled leads). Same payload as GET /api/signals.
  • get_recordWinding down — kept answering for callers that hold the name. Our published correction record (the dated retirement of the case studies we withdrew); for reading the maintained record use get_topic_record, get_entity and todays_brief.
  • get_calibrationWinding down — kept answering for callers that hold the name. The grading dataset for the market sensor we cite; for reading the maintained record use get_topic_record, get_entity and todays_brief.
  • get_eventsThe named world events the engine tracks as arcs — entities, related market questions, mention volume, first/last seen.
  • get_corroboratedWhat publishers carried from several separate origins in the published window: each event with publisherCount and originCount (wire, same-address and named-upstream copies collapsed), the publishers by name, and the tier. Neither count is verification. Same object as GET /api/corroborated.
  • traverseTo see how the record fits together, start at an entity or event (e.g. Hormuz) and traverse its maintained relationships; each step returns its relation type, receipts, standing and time. One node per call (schema sb.node.v1), with its neighbours as counts plus typed ids to follow; a level we could not read says cannot-measure, never an empty list. Same object as GET /api/v1/node?id=entity:hormuz.
  • todays_briefToday's synthesized morning brief — what moved and what to watch, same content as /today.
  • propose_topicPropose net-new coverage — a topic or standing question we don't track yet. Humans review every request; accepted topics start as provisional coverage. Needs your principal's contact email. Free.
  • get_quoteFeed in requirements in your own words; get back an enumerated topic quote — grouped, disambiguated, merges disclosed — priced flat from the published prices. Never a charge, no contact details needed.
  • create_orderAssemble a basket and get exact prices plus Stripe checkout links. Checkout runs on Stripe's hosted page with prices published first and nothing hidden. Watch and api lines record your intent honestly — the desk activates them on a meter account, and the order says so.
  • get_orderRe-read an order intent from create_order — the recorded basket and its honest status. The payer's Stripe receipt is authoritative for checkout purchases; metered work is receipted on your meter account (get_account).
  • get_watch_feedThe structured daily delivery for a watched topic: up to 14 days of items, plus the live coverage-acceptance report. The report grades the coverage; it does not gate the bill. The month you're in is always refundable.
  • get_desk_feedA newsletter desk's machine feed: up to 14 days of the desk's observed items (title, url, source), newest first, from the same panel the human edition reads.
  • get_accountYour meter-account statement, live: month-to-date usage at the published prices, your Watches and what each one bills (any legacy free watches are shown as free), your free allowance (per key, lifetime) or daily cap. Send your identified key (x-api-key header). Without a key it explains how to get one — recognition is opt-in via credential.
  • get_feedback_statusThe state of a report you filed, by feedbackId — filed/working/resolved with its work-order reference.
  • send_feedbackFile a bug, improvement, complaint, praise, or question about the service. A complaint naming a real defect becomes our work order; the response says honestly whether it was durably recorded. 5/min, 20/day.
  • list_standard_watchesThe standard Watches you can start from. Configure and unfurl free; saving is the paid step.
  • unfurl_watchShow what a Watch would deliver before you save it. Free.
  • save_watchSave a Watch to your key — the paid step, at the published Watch price. The month you are in is refundable in full.
  • list_saved_watchesThe Watches saved on your key.
  • recall_watchRead one of your saved Watches back.
  • retire_watchRetire a saved Watch, only when asked by name.

Setting this up for someone else — or want your assistant to evaluate us before you commit? Hand it this prompt; the machine surface is built to be judged skeptically:

send your AI to check us out
Evaluate SigB (Signal Bureau) for me. Start at https://sigb.ai/llms.txt, then their MCP server at https://api.signalbureau.ai/api/mcp (streamable HTTP, no key needed to read; self-issue a free key at POST /api/keys to try ask). Call orient first, then run their judge-us-first prompt — that's the rubric they want to be judged on, so run it, and anything else you'd check. Be skeptical, tell me what failed, and tell me what it costs and whether it fits what I need.

3 · Ask it questions over HTTP

A plain JSON endpoint. One question in; a structured read out, checked against sources with the result disclosed.

POST /api/ask
# one-time: mint your free key (instant, no card)
curl -s -X POST https://sigb.ai/api/keys -H "content-type: application/json" \
  -d '{"label":"my-agent"}'
# then ask (25 free answers on your key, for its lifetime — they do not reset)
curl -s https://sigb.ai/api/ask \
  -H "content-type: application/json" -H "x-api-key: $SB_KEY" \
  -d '{"question":"What changed for Taiwan this week?"}'

Live platform metrics, assembled on demand by a stateless worker:

GET /api/stats
curl -s https://sigb.ai/api/stats

The full reference (OpenAPI)

The complete machine-readable contract — every endpoint, parameter, response schema, example body, rate limit, CORS posture, timeout guidance, and the error model — ships as an OpenAPI 3.1 document. Feed it to your code generator or your agent. The short version: GET reads are CORS-open and edge-cached; /api/signals is a bounded feed (no pagination — limit truncates a fixed priority ranking, and the envelope's totalFlagged tells you the full size); errors are plain JSON with a reader-facing error string; burst 429s carry retry-after, daily-quota 429s carry requiresAuth. A working ticket reports elapsedSeconds, and past the stated range it also carries late: true with a message naming the range — late is not lost; a run is only reported lost past 300 seconds. Every answer states what the verdict did to its own prose: servedAs is "verified", "as-written", "evidence-bounded" (a sentence stating more than its sources establish was replaced with what they do establish) or "abstained" (the conclusion was withheld); verificationState spells the three states of verified in words — "verified", "unverified", "cannot-measure" — with verificationReason naming the pass that failed; abstained is always a boolean, because an abstention is our decision and never an unknown. We spend the seconds a grounded, source-checked answer takes — built for the internet of machines that need current truth, not for millisecond trading.

Ask timing — sync and async are different contracts, stated separately.
SynchronousSynchronous answers measured 24–29 seconds (p50–p90) over 70 live asks in the last 14 days, as of 2026-10-04; set client timeouts to at least 60 seconds.
AsynchronousAsync submissions return a claim ticket in about a second; the finished answer is usually ready within 30–120 seconds.

Fair use, stated plainly

Reading and discovery stay open and anonymous, with honest limits instead of a key wall: the signal feed allows 500 origin reads per day per network address (burst-capped at 30/minute) — note the limits meter origin reads; edge-cached responses (10-minute TTL) serve without consuming quota, so bursts against a warm cache may all return 200. The Answer Engine rides a free self-issued key — one call at POST /api/keys, instant, no card — carrying 25 free asks for the life of the key, on a meter that is yours alone and never shared with your cloud or office neighbors. They are a lifetime allowance, not a daily one: they do not reset, and each key meters independently — a test drive, stated as such, because each answer spends real model compute. Prices are on the pricing page. Past a limit you get a clear 429 with requiresAuth: true. That is where the Metered API account picks up: an identified key with a far higher feed allowance, billed on what you use at the published prices. Meter accounts are live: the desk issues the key, and get_account shows your statement. get_quote (or the /api/tariff-quote endpoint) prices your exact basket first, so your quote is your plan. Feed and burst limits reset daily; the free key allowance does not, and a used-up one answers 402 naming the next step, never a dead end.

Legacy terms, still honored: keys issued before 2026-09-05 were promised 25 asks each day, resetting at midnight UTC, and they keep exactly that for as long as they live — the issuance date on the key record decides, and nothing about an existing key was reduced. The lifetime allowance above is what a key issued today carries.

Built for teams

The evaluation motion is concrete: give us the concerns your team cannot afford to stop watching — the entities, programs, exposures, and questions, as many as the work takes — and we will stand up a private desk against it, baseline every name, and deliver daily briefings plus full API access for a 30-day evaluation. That is the Private Desk Pilot ($5,000 once), and it ends with a written acceptance report against the metrics in the agreement — details on the pricing page.

SigB is a commercial intelligence platform, running entirely on stateless edge workers. High-throughput access, webhooks and push delivery, and domain-scoped feeds are being wired with early partners now; service commitments are set per contract. Tell us what your system needs and we'll wire you in.

Talk to us about enterprise access → (lead [at] evfm.co)

Where machines find us

Every entry below is a link you can open. We check them once a day and publish what the check said, including when it could not see.

  • Official MCP Registry
    Listed, checked 2026-10-05.
    Link goes to our record on the registry itself.
  • Glama
    Submitted, not yet listed.
    Link goes to the claim file we serve, which this registry reads.
  • PulseMCP
    Cannot measure. Our check on 2026-10-05 could not read this page, so we do not know whether we are listed.
    Link goes to the registry's submission page — not our entry.
  • mcp.so
    Not pursued. We have not submitted to this one.
    Link goes to the registry's own search, scoped to our name.
  • Smithery
    Not pursued. We have not submitted to this one.
    Link goes to the registry's own search, scoped to our name.
  • awesome-remote-mcp-servers (jaw9c)
    Submitted 2026-09-24, not yet listed.
    Link goes to the list itself, where we are not yet present.
  • awesome-remote-mcp-servers (sylviangth)
    Submitted 2026-09-24, not yet listed.
    Link goes to the list itself, where we are not yet present.

Informational only: not investment, legal, or betting advice. Every signal carries its sources; every answer is grounded in tracked coverage and source-checked; uncertainty is stated honestly.