io.github.evolutionlabs-dev/signal-bureau
REMOTE · API.SIGNALBUREAU.AI · SCANNED OCT 4
SigB (Signal Bureau): maintained, source-traced record of entities and events in your named domain.
Available components
How this component scores in each security and reliability category. Every signal is checked automatically against the live server, and we only credit what we can confirm. How we score → Why this is hard to score →
Endpoint Security57
- The endpoint's TLS certificate is valid, in date, and uses a strong key. View diagnostics → Pass
- Authorisation not fully verified: no authorisation is required to call this server, and 22 tool(s) never declared a destructiveHint. The MCP spec treats an absent hint as destructive by default, so we cannot call this surface safe. See how to fix → View diagnostics → Unverified
- HTTPS is enforced; there's no plaintext access path. View diagnostics → Pass
- HSTS check failed: the Strict-Transport-Security header is absent. See how to fix → View diagnostics → Fail
- DNSSEC check failed: this domain isn't protected by DNSSEC. See how to fix → View diagnostics → Fail
Transport & Reachability100
- Verified streamable-http transport via a live MCP handshake. View diagnostics → Pass
Schema Quality & AI Usability79
- 100% of prompts and resources have a non-trivial description (not blank, and not just the item's name).Pass
- AI-judged instruction clarity (excellent).Pass
- Context-footprint check failed: tool/resource definitions use about 4923 tokens (~164/item across 30 items; 22 tools + 8 resources), over budget; trim descriptions and params. See how to fix → Fail
- Usage-examples check failed: none of the tools include examples. See how to fix → Fail
Stability & Change Management90
- Stability check failed: schema churn in the 30 days we've observed: 2 tool removals, 0 breaking changes, 0 auth/transport breaks, 3 additions. See how to fix → Fail
Tool Coverage97
- 100% of tools have a non-trivial description (not blank, and not just the tool's name).Pass
- 92% of tool parameters carry a description.Partial
Tool Safety75
- No prompt-injection markers were found in the server instructions, tool names or descriptions we captured.Pass
- 0 of 1 tool(s) whose name or description implies an irreversible operation declare an MCP destructiveHint annotation; "send_feedback" implies "send" and declares no destructiveHint at all, which the MCP spec reads as destructive by default. See how to fix → Fail
- An AI judge read all 23 captured unit(s) of tool text and found none that tries to manipulate the model reading it.Pass
Capabilities100
- Implements a supported MCP spec version (2025-11-25); the latest is 2026-07-28.Pass
How do I install the io.github.evolutionlabs-dev/signal-bureau MCP server?
io.github.evolutionlabs-dev/signal-bureau is a hosted endpoint at https://api.signalbureau.ai/api/mcp, so there is nothing to install locally. Ready-made configuration for Claude, Cursor, VS Code, Codex and 5 more is on this page, copied from each client's own documentation.
remote · api.signalbureau.ai
claude mcp add --transport http evolutionlabs-dev-signal-bureau 'https://api.signalbureau.ai/api/mcp'
{
"mcpServers": {
"evolutionlabs-dev-signal-bureau": {
"url": "https://api.signalbureau.ai/api/mcp"
}
}
} {
"servers": {
"evolutionlabs-dev-signal-bureau": {
"type": "http",
"url": "https://api.signalbureau.ai/api/mcp"
}
}
} [mcp_servers.evolutionlabs-dev-signal-bureau] url = "https://api.signalbureau.ai/api/mcp"
{
"$schema": "https://opencode.ai/config.json",
"mcp": {
"evolutionlabs-dev-signal-bureau": {
"type": "remote",
"url": "https://api.signalbureau.ai/api/mcp",
"enabled": true
}
}
} openclaw mcp add evolutionlabs-dev-signal-bureau --url 'https://api.signalbureau.ai/api/mcp' --transport streamable-http
mcp_servers:
evolutionlabs-dev-signal-bureau:
url: "https://api.signalbureau.ai/api/mcp" {
"McpServers": {
"evolutionlabs-dev-signal-bureau": {
"Transport": "http",
"Url": "https://api.signalbureau.ai/api/mcp"
}
}
} assistant mcp add evolutionlabs-dev-signal-bureau -t streamable-http -u 'https://api.signalbureau.ai/api/mcp'
{
"mcpServers": {
"evolutionlabs-dev-signal-bureau": {
"type": "http",
"url": "https://api.signalbureau.ai/api/mcp"
}
}
} The mcpServers block is a cross-client convention. Remote transports vary, so check your client's docs.
Every change we have recorded for this component, newest first. Security-relevant changes are always shown. ▲ marks a change for the better, ▼ a change for the worse; unmarked changes are neutral.
- 4 Oct 26 0
- Tool “get_signals” rewrote its description, which is the text the model reads security
- Tool “get_topic_record” rewrote its description, which is the text the model reads security
- 3 Oct 26 0
- A breaking change shipped without a version bump: still 0.6.0 ▼ security
- Tool “get_truth_record” was removed ▼ security
- Tool “get_signals” rewrote its description, which is the text the model reads security
- New tool “get_topic_record” functional
- 2 Oct 26 0
- Tool “get_signals” rewrote its description, which is the text the model reads security
- Tool “get_truth_record” rewrote its description, which is the text the model reads security
- 1 Oct 26 0
- Tool “get_signals” rewrote its description, which is the text the model reads security
- Tool “get_truth_record” rewrote its description, which is the text the model reads security
- 30 Sept 26 0
- Tool “get_signals” rewrote its description, which is the text the model reads security
- Tool “get_truth_record” rewrote its description, which is the text the model reads security
- 29 Sept 26 0
- Tool “get_signals” rewrote its description, which is the text the model reads security
- Tool “get_truth_record” rewrote its description, which is the text the model reads security
- 28 Sept 26 0
- We updated how we score, so this day's move reflects our rubric, not a change to the server See what changed → functional
- 27 Sept 26 0
- Tool “get_signals” rewrote its description, which is the text the model reads security
- Tool “get_truth_record” rewrote its description, which is the text the model reads security
Diagnostic detail from the automated scan of this channel: what the scanner observed at each step, so you can see exactly where a check passed or failed. It is informational only and never changes the trust score.
Captured 6 Oct 2026 · Probed https://api.signalbureau.ai/api/mcp
TLS valid
Negotiated TLS 1.3 with TLS_AES_128_GCM_SHA256 .
| Subject | Issuer | Valid from | Valid until | Key | Signature | Serial |
|---|---|---|---|---|---|---|
| CN=api.signalbureau.ai | CN=YE1,O=Let's Encrypt,C=US | 8 Aug 2026 | 6 Nov 2026 | ECDSA 256 | ECDSA-SHA384 | 68b6a1cf334bf960e068d31f0dc4f36fc13 |
| SANs: api.signalbureau.ai | ||||||
| CN=YE1,O=Let's Encrypt,C=US (CA) | CN=Root YE,O=ISRG,C=US | 3 Sept 2025 | 2 Sept 2028 | ECDSA 384 | ECDSA-SHA384 | 5ddd70dd31f801c85c186a7a04b80afe |
| CN=Root YE,O=ISRG,C=US (CA) | CN=ISRG Root X2,O=Internet Security Research Group,C=US | 13 May 2026 | 2 Sept 2032 | ECDSA 384 | ECDSA-SHA384 | 872165fc34b6e5fba8add5b3705fb53a |
| CN=ISRG Root X2,O=Internet Security Research Group,C=US (CA) | CN=ISRG Root X1,O=Internet Security Research Group,C=US | 13 May 2026 | 2 Sept 2032 | ECDSA 384 | SHA256-RSA | 6c8f1dc727c7117f7baf853ac980f9cd |
Background: What to check on a remote MCP endpoint →
DNSSEC insecure
Validation of api.signalbureau.ai. — Not signed
| Zone | DS | Keys | Algorithms | Outcome |
|---|---|---|---|---|
| . | trust_anchor | 20326, 38696 | 8, 8 | Verified |
| ai. | present | 3799 | 8 | Verified |
| signalbureau.ai. | absent | Unsigned (proven) parent-signed NSEC/NSEC3 proves an unsigned delegation |
Authentication No authorisation required
The endpoint answered without asking for a token. Anyone who knows the URL can reach it.
| Result | No authorisation required |
|---|---|
| HTTP status | 200 |
Background: How OAuth 2.1 works in the 2026 MCP spec →
Transports 2 probes
| Transport | URL | Outcome | Status | Location |
|---|---|---|---|---|
| streamable-http | https://api.signalbureau.ai/api/mcp | Verified | 200 | |
| http (plaintext) | http://api.signalbureau.ai/api/mcp | HTTPS enforced | 301 | https://api.signalbureau.ai/api/mcp |
The tools this component advertises to a client, with an estimated token cost for each. Expand a tool to see its parameters and schema. The per-tool counts are indicative and are not scored directly; the schema's total context footprint is one signal in Schema Quality & AI Usability. A tool's description is untrusted text the model reads on every call, which is what makes this list a security surface and not just an inventory: how tool poisoning works →
ask ~255
Ask what the tracked record shows about a named entity or unfolding event: what changed, what the record holds now, and which sources corroborate it. Not general knowledge or history — grounding is live tracked coverage. 25 questions a day per network address need no key; then each costs one Read on a free key (POST /api/keys). Async — a ticket in ~1s, collected with get_answer.
| Name | Type | Req | Description |
|---|---|---|---|
| fresh | boolean | – | Force a new synthesis instead of the maintained record's recent answer to the same question (default false — shared state is the default) |
| observer | string | – | Optional. The observer this question is asked as (e.g. an observer list_standard_watches names). Recorded as declared on the answer's `replay` block; default "public". A malformed value is named in `… |
| question | string | yes | – |
| watch | string | – | Optional. The Watch this question is asked under. Recorded as declared on the answer's `replay` block. A malformed value is named in `replay.declared.rejected`, never applied. Same field as POST /api… |
No output schema declared.
No examples provided.
create_order ~785
Assemble a basket and get exact prices plus Stripe checkout links. Checkout runs on Stripe's hosted page, completed by whoever holds the payment credentials. Pass dryRun:true to REHEARSE: same validation, same price math, clearly labeled, no order recorded, no links issued, nothing billed — integration-test the full flow risk-free. Item ids — plans: 'pilot', 'desk-private', and 'api' (the Metered API account: your identified key — self-issue one FREE at POST /api/keys, no human in the loop — with billing activated by the desk on this order, usage billed monthly at tariff rates, nothing preset — get_quote prices your exact basket first, get_account shows the live statement); unit: 'watch' (reads of the watched question included); and 'balance' — a BALANCE on your own key, funded once with an `amount` in USD (min $5, max $500) and drawn down at the flat published Read rate as you ask. Reads are metered per use at the flat tariff rate and are never sold as PREPAID PACKS — a pack is a discounted bundle sized to your guess about how much you will use, and we do not sell one. A BALANCE is a different thing and is sold: the same meter funded in advance, at LIST, no discount, no expiry, no minimum draw, unused balance refundable in full on request. It exists so your principal fills a card form ONCE, ever, instead of once per purchase. Live UNIT prices come from /api/tariff and this description states none of them — the balance band above is a limit on what you may FUND, not a price. Watch topics are SELF-SERVE end to end: pass `topics` and every one comes back with a checkout link at the published Watch rate — including a topic nobody watches yet, whose price the desk mints on demand with no human in the loop (that one needs your identified key, free and self-issued in one call at POST /api/keys, and arrives in minutes; poll get_order or the statusUrl on the line). The api line still records intent and the desk activates the account. Every line states its own state and wha…
| Name | Type | Req | Description |
|---|---|---|---|
| dryRun | boolean | – | true → rehearse: validate + price the basket, record nothing, issue no links, bill nothing |
| string | – | Contact email to attach to the order intent (optional) | |
| idempotencyKey | string | – | Optional client key (≤128 chars): makes the orderId deterministic and a retried call return the original intent instead of recording a second one — safe machine retries |
| items | array | yes | Array of {id, quantity?, amount?} — catalog ids above; `quantity` applies to unit items only, and `amount` (USD, min 5 / max 500) applies to the 'balance' item only and is required on it |
| quoteId | string | – | Optional: the quoteId from get_quote — recorded on the order intent so the desk provisions against that exact quote. |
| topics | array | – | Optional: the quoted topic names (or 1-based topic numbers as strings) this order's Watch lines cover — carried verbatim onto the recorded intent so scoped concerns survive the quote→order handoff. M… |
No output schema declared.
No examples provided.
get_account ~104
Your meter-account statement, live: month-to-date metered Reads counted at the published tariff, your watched topics with billing/billing status and their acceptance evidence, and your daily cap. Requires your identified key on the request (x-api-key header, or authorization: Bearer sb_live_...). Without a key this tool explains how to get one — every read surface stays available in the free anonymous lanes either way. Recognition is opt-in via credential: no key, no tracking.
Input schema present but exposes no named parameters.
No output schema declared.
No examples provided.
get_answer ~93
Collect an async answer by ticketId (from ask). Free and unmetered — the work was paid for once at submit. status:'working' → poll again after pollAfter seconds; 'done' → the complete answer rides in this response; 'failed' or 'lost' → the reason, stated plainly, and asking again is the remedy.
| Name | Type | Req | Description |
|---|---|---|---|
| ticketId | string | yes | The uuid the ask tool returned |
No output schema declared.
No examples provided.
get_calibration ~177
Deprecated: this tool is winding down — for evaluating or reading the maintained record, use get_topic_record, get_entity/search_entities, and todays_brief instead. Still served here: the grading dataset for the market sensor we cite, and only that — the prediction-market price (`crowd`) and the naive null it is scored against (`base_rate`), against how reality resolved (Brier score, log loss, skill vs base rate, 95% CIs), each price captured while its market was OPEN and graded as it matured, so the grade cannot be back-filled. No forecaster of ours is published, here or in the full dataset: we sell a maintained, source-traced record and cite market prices as one graded sensor, not a forecast of ours. Full dataset with reliability bins: GET /api/calibration-data.
Input schema present but exposes no named parameters.
No output schema declared.
No examples provided.
get_corroborated ~270
What separate sources agreed on in the published window — the maintained record's corroboration layer. Each event carries the claim as its sources state it, the corroboration tier, two counts — publisherCount (distinct outlets that carried it) and originCount (separate evidentiary origins: a wire republished by fifteen outlets, two pages behind one address, or three outlets relaying what one named outlet reported each count once) — the publishers by name with wires marked, the earliest report date when the run carries one, and the entities. The tier is computed from originCount. Neither count is verification: an outlet that names no upstream still counts as its own origin, and many outlets echoing one official statement is consensus. independentOrigins is a deprecated alias of the publisher count. No probability here is ours. Returns state="cannot-measure" with a reason when the corroboration pass could not be read — never an empty list dressed as a quiet week.
| Name | Type | Req | Description |
|---|---|---|---|
| limit | number | – | How many events (default 20, max 60) |
| tier | string | – | Optional filter: 'strong' (carried from 4 or more separate origins) or 'moderate' (2 or 3 separate origins). An unknown value is refused, never answered with an empty list. |
No output schema declared.
No examples provided.
get_desk_feed ~246
A newsletter DESK's machine feed at one predictable, slug-addressable location: up to 14 days of the desk's observed items (title, url, source), newest-first, from the same panel the human edition reads. Unlike watch topics, the desk roster is PUBLIC PRODUCT — the desks are: cognitive-investor, tax-nexus, crc-kras, crc-digest, space-economy, paradise-valley, lyt-intel, aztc-aasd, newspace-asu, lq-listening, jedi-knowledge, ud-articles, ecomm-news — so an unknown-desk reply lists them freely. Delivery is keyed (your self-issued key, x-api-key): identified delivery is the standard shape for standing feeds. Desks are priced as labeled topic bundles at the published Watch rate — see DESK_BUNDLES on /api/tariff and get_quote for your exact basket. Each feed's payload declares its own coverage state.
| Name | Type | Req | Description |
|---|---|---|---|
| days | number | – | How many recent days to return (1-14, default 14) |
| desk | string | yes | The desk slug (e.g. 'space-economy') |
No output schema declared.
No examples provided.
get_entity ~36
Full dossier for one entity: signal count, verticals it's spreading across, and why it's surfacing.
| Name | Type | Req | Description |
|---|---|---|---|
| name | string | yes | – |
No output schema declared.
No examples provided.
get_events ~90
Tracked world events (situations, races, negotiations) the engine follows as named arcs — each with its entities, related market-question count, cross-domain mention volume, and first/last-seen dates. Optional query filters by name or entity.
| Name | Type | Req | Description |
|---|---|---|---|
| limit | number | – | How many (default 20, max 50) |
| query | string | – | Filter by event name or entity (optional) |
No output schema declared.
No examples provided.
get_feedback_status ~75
The state of a report you filed via send_feedback, by its feedbackId: filed, working, or resolved — with its work-order reference. A report filed in the last few hours may still read 'filed'; the response states where it is.
| Name | Type | Req | Description |
|---|---|---|---|
| feedbackId | string | yes | The feedbackId returned by send_feedback |
No output schema declared.
No examples provided.
get_order ~112
Re-read an order intent created by create_order — the recorded basket and its honest status. Poll it after forwarding create_order's `handoff` note: it re-resolves each topic's payment link against the current registry, so a link still being minted shows up here when ready. Payment truth for checkout purchases lives with Stripe (the payer's receipt is authoritative); metered work is receipted on your meter account and readable via get_account.
| Name | Type | Req | Description |
|---|---|---|---|
| order_id | string | yes | The UUID returned by create_order |
No output schema declared.
No examples provided.
get_quote ~360
Feed in your requirements — free-form concerns, questions, whole areas of interest — and get back an enumerated quote: your requirements intelligently grouped and disambiguated into well-formed watched topics, then checked BY CODE, topic by topic, against what we actually read: a topic is priced ($20/topic/month at the opening rate) ONLY when a desk, a Watch we keep or a standard Watch reads it from sources with an item in the last 7 days. Every topic carries `coverage` — its state (covered, gap, or cannot-check with the reason), the sources, how many and how fresh. Gaps come back under `coverageRequests` at $0, never billed, each with the free propose_topic call that asks us to start keeping it; `coverage.summary` says it in one line. A model proposes the topics; it never decides what is sold. The count is disclosed in BOTH directions: overlaps are merged, broad requirements are split into the separate daily reports they actually need, and `billing.expansion` states the requirement-to-topic ratio outright so a split is as visible as a merge. Large baskets are resolved in batches, so a requirement the desk cannot place does not sink the rest: you get a quote for everything it could place, `partial: true`, and `unresolvedRequirements` naming what it could not and why — never a topic invented to cover a gap. A quote is not a charge, needs no contact details, and holds for 30 days. Real model work: ~10 quotes/day per network address (shared egress shares the allowance).
| Name | Type | Req | Description |
|---|---|---|---|
| requirements | string | yes | What you want watched, in your own words — one blob of text or bullet points; the desk does the grouping |
No output schema declared.
No examples provided.
get_record ~125
Deprecated: this tool is winding down — for evaluating or reading the maintained record, use get_topic_record, get_entity/search_entities, and todays_brief instead. Still served here: the correction record — the flagged-vs-control repricing regression at population level (estimate, 95% CI, cohort sizes, window, as-of), plus the dated retirement object for the case-study track record we withdrew in 2026 when re-measurement put it under our own publication bar. Appended, never edited — including about ourselves. Same object: GET /api/record-data.
Input schema present but exposes no named parameters.
No output schema declared.
No examples provided.
get_signals ~238
START HERE for browsing — the cheap read (500/day, no model work). The full machine-readable signal feed (same payload as GET /api/signals): every entity currently flagged by the attention engine, with trajectory, domains, desk membership, and an explicit evidenceStatus (receipted rows carry source-attributed evidence URLs; unreceipted rows are labeled leads). Measured property: Measured association: flagged markets repriced materially at 1.47x the rate of matched unflagged controls (95% CI 1.35-1.62, shock-days excluded, controls reweighted to the flagged cohort; n=2769 flagged vs 110528 controls, window 2026-03-29 to 2026-10-06, as of 2026-10-06). An attention-leads-movement association — never a directional claim.
| Name | Type | Req | Description |
|---|---|---|---|
| direction | string | – | Filter by trajectory regime: rising|fading|steady|new|insufficient_history. An unknown value is refused, never answered with an empty list. |
| limit | number | – | How many signals (default all flagged) |
No output schema declared.
No examples provided.
get_topic_record ~1,159
The maintained record for one subject — the ONE file its /exhibit page renders from and GET /api/record/{slug} serves (the earlier names get_truth_record and GET /api/truth/{slug} answer identically, permanently), so their numbers agree by construction and a value-parity gate fails the build if they stop: what the subject is, the first-party documents we read, the claims and how many separate publishers carried each, our own attention, the prediction-market prices we cite (never a probability of ours) split into `live`, `historical` (deadline passed) and `undated` questions, the change log, and what this record cannot see. `currency` is never better than its weakest layer; `currency.layers` gives each layer's own data cutoff, compute date and state (current, behind, cannot-measure). Every subject on the publication registry carries one. Free — public record, no key, no charge. With no argument you get the flagship record (hormuz today, and it rotates). Three answers, never two: `served` with the record; `not-registered` when we read the registry and do not maintain that subject (a measured absence); `cannot-measure` when the record store could not be read (the record may well exist — we could not look). Subjects served today: hormuz, interest-rates, us-midterms-2026, ai-model-race, israel-iran-conflict, russia-ukraine-war, gaza-ceasefire, brazil-election, us-presidential-2028, strait-of-hormuz, fed-rate-decision, venezuela-crisis, uk-election, us-recession-2026, disaster-event-hurricane, disaster-event-atlantic-hurricane, product-launch-spacex-starlink, election-michigan-republican, product-launch-spacex, election-republican-republicans, election-alabama-republican, election-arkansas-republican, election-brazil, election-brazil-senate, legal-ruling-supreme-court, election-republican, election-republican-republican-party, ceasefire-peace-iran, election-michael, election-darline-graham-graham, election-darline-graham-republican, economic-indicator-inflation, election…
| Name | Type | Req | Description |
|---|---|---|---|
| claims | string | – | Unfold one consensus list a page at a time instead of fetching the record: kernel (the who/what/when/where claims), frames or retired. By default those lists come folded: a count, a first page and a… |
| cursor | string | – | A nextCursor from a previous answer, exactly as returned. Implies its list. |
| pageSize | integer | – | Rows per page when unfolding, 1-100 (default 25). |
| subject | string | – | Which subject, by slug or name — "Interest Rates", "interest_rates" and "interest-rates" all reach the same record. Omit for the flagship. |
| topic | string | – | The name this parameter had under get_truth_object. Still accepted, always will be. |
No output schema declared.
No examples provided.
get_watch_feed ~272
The structured daily delivery for a machine-watched topic: up to 14 days of observed items (title, url, source, date) newest-first, plus the topic's live coverage-acceptance report, which grades the coverage and shows the evidence (it does not gate billing — billing starts when the Watch starts, and the month you are in is refundable in full, any time you ask, for any reason). Delivery is pull: poll daily or on demand. Topics not yet watched: get_quote prices them.
| Name | Type | Req | Description |
|---|---|---|---|
| days | number | – | How many recent days to return (1-14, default 14) |
| since | string | – | Optional. What changed since then: an ISO time (2026-10-01 or 2026-10-01T12:00:00Z) or the readingId a previous call returned. Adds a `delta` block listing the items first seen after it, by canonical… |
| topic | string | yes | The watched topic name (as quoted/ordered) |
No output schema declared.
No examples provided.
list_saved_watches ~52
Watches: configure and unfurl free; saving is the paid step. Your saved Watches, newest version of each, active and retired. Needs your key. Same content as GET /api/v1/watches.
Input schema present but exposes no named parameters.
No output schema declared.
No examples provided.
list_standard_watches ~77
Watches: configure and unfurl free; saving is the paid step. The free standard Watches, each with every coordinate explicit, plus the published terms: what saving a Watch costs (read from the tariff), what it includes, and its limits. Free; no key. Same content as GET /api/v1/watches/standard.
Input schema present but exposes no named parameters.
No output schema declared.
No examples provided.
propose_topic ~138
Propose NET-NEW coverage — a topic, entity, or standing question we don't track yet. Files into the coverage-request queue humans review; accepted topics enter the provisional coverage lane and start appearing in the signal feed. Needs your human principal's contact email for follow-up. Free.
| Name | Type | Req | Description |
|---|---|---|---|
| string | yes | Your human principal's contact email, used only to follow up on this request | |
| requester | string | – | Name to file the request under (optional) |
| topic | string | yes | What to cover — a topic, entity, or standing question |
| why | string | – | Why this coverage matters (optional — helps the review) |
No output schema declared.
No examples provided.
recall_watch ~130
Watches: configure and unfurl free; saving is the paid step. Recall a saved Watch: its reading now (sb.watch-reading.v1) and what changed since the last time it was delivered to you. Recording this delivery is what makes the next recall's change exact. Needs your key. Same content as GET /api/v1/watches/%7BwatchId%7D.
| Name | Type | Req | Description |
|---|---|---|---|
| expand | string | – | Override the Watch's depth for this call: 0, 1, 2 ... or full. |
| watchId | string | yes | The saved Watch's id (sw_...). |
No output schema declared.
No examples provided.
retire_watch ~97
Watches: configure and unfurl free; saving is the paid step. Retire a saved Watch: it stops being recallable and frees its paid slot. Nothing is deleted; its versions and deliveries are kept. Needs your key. Same content as POST /api/v1/watches/%7BwatchId%7D with {"action":"retire"}.
| Name | Type | Req | Description |
|---|---|---|---|
| watchId | string | yes | The saved Watch's id (sw_...). |
No output schema declared.
No examples provided.
save_watch ~510
Watches: configure and unfurl free; saving is the paid step. Save a Watch to your key so you can recall it from any door and be told what changed since your last delivery. Saving is the paid step, at the published Watch rate per saved Watch per month (see list_standard_watches terms); with no free paid slot the answer is a plain payment-required with the next step, and nothing is saved or charged. Pass watchId to edit a Watch you saved: that is a new version and costs nothing more. Either start from a standard Watch (base; these read the Strait of Hormuz record) or name your own domain (domain + topics, from get_quote). For a domain, the coverage check runs again here and only covered topics are kept; no reading builder is published for this domain yet, so its reading is cannot-measure per topic and it is never served a standard Watch's reading. A domain Watch is saved free, as pending coverage, until a reading for it is published; a domain with no covered topic is refused with the reason and nothing is charged. Needs your key. Same content as POST /api/v1/watches.
| Name | Type | Req | Description |
|---|---|---|---|
| base | string | – | The standard Watch to start from: std.hormuz.maritime-operator, std.hormuz.energy-desk, std.us-iran.geopolitical-analyst. Leave it out when you name a domain. |
| coordinates | object | – | The coordinates you want to change from the base Watch; every one you leave out takes the base Watch's value. Keys: observer, question, domain, interval, language, depth, cadence, selection, threshol… |
| domain | string | – | Your domain in your own words, e.g. Arizona startup ecosystem. Use with topics instead of base. |
| label | string | – | Your own name for the Watch. |
| quoteId | string | – | The quoteId get_quote returned. Recorded with the Watch; the coverage is checked again here either way. |
| topics | array | – | The topics your domain splits into (get_quote proposes them), as names or {name, scope}; 1 to 40. Only the ones coverage we keep reads are kept; the rest come back as free coverage requests. |
| watchId | string | – | Edit this saved Watch (a new version) instead of saving a new one. |
No output schema declared.
No examples provided.
search_entities ~35
Find tracked entities/topics by name or vertical (e.g. 'iran', 'semiconductors').
| Name | Type | Req | Description |
|---|---|---|---|
| query | string | yes | – |
No output schema declared.
No examples provided.
send_feedback ~223
File structured feedback with the desk: a bug, an improvement, a complaint, praise, or a question about the service itself. Free, no contact details required; limits stated up front: 5/minute, 20/day per network address (shared egress shares the allowance). A complaint that names a real defect becomes our work order — house policy — and get_feedback_status lets you watch the state move by feedbackId. Include `ref` (a quoteId/ticketId/orderId from your own records) to tie the report to a specific interaction. The response says honestly whether the report was durably recorded.
| Name | Type | Req | Description |
|---|---|---|---|
| about | string | – | Which tool/endpoint/page this concerns (optional) |
| detail | string | – | The full story — reproduction steps, expected vs observed (optional) |
| kind | string | yes | bug | improvement | complaint | praise | question |
| ref | string | – | A quoteId, ticketId, or orderId to tie this to (optional) |
| summary | string | yes | One sentence: what happened or what you want |
No output schema declared.
No examples provided.
start_here ~87
START HERE — first call, no arguments, no key, no charge. Who Signal Bureau is and what we are not, the tests you can run to check that claim yourself, what is free (most of it), what is paid (Watches and Reads) at live published prices, how to propose coverage we don't carry, and how buying works. Read this before evaluating anything else here.
Input schema present but exposes no named parameters.
No output schema declared.
No examples provided.
todays_brief ~98
Today's morning brief — the daily synthesized narrative of what moved across the information environment and what to watch, from the engine's cross-domain analysis. Same content as the public /today page. Carries `gaps` (where prediction-market money and the day's coverage disagree) and `watch` (what would change the story); every market figure in either arrives with the contract URL behind it, or the figure is withheld and the row says so.
Input schema present but exposes no named parameters.
No output schema declared.
No examples provided.
top_accelerating ~45
The entities/topics accelerating most across the information environment right now, ranked by cross-domain attention.
| Name | Type | Req | Description |
|---|---|---|---|
| limit | number | – | How many (default 10, max 50) |
No output schema declared.
No examples provided.
traverse ~525
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. Walk the maintained record node to node. Opens ONE node (schema sb.node.v1): an entity, a situation, a corroborated claim or a co-mention relation, with its identity, standing (five separate records, never one score), as-of cutoff, provenance, and its neighbours folded as counts plus the first page of typed refs. Follow any returned id, or pass a returned cursor, to open the next level. Start from a name: id "entity:hormuz" or "event:strait-of-hormuz"; or from an id: "sb:e/…", "sb:p/…", "sb:r/…". Same object as GET /api/v1/node/{kind}/{hex}. Free, no key. Limits are published in every node: One level per call: depth is 1 and only 1, and there is no whole-graph dump. pageSize 1-50 (default 10); a page limit is a cursor, never an edge. Members are listed up to 50. At most 60 traverse calls a minute per caller (runaway-loop protection, not a meter). One knowledge cutoff is served: the deploy's. A level we could not read says cannot-measure with the reason, never an empty list; an unknown id is a 404 with code node_not_found. Projected from today's graphs (build.plane), not the maintained world state.
| Name | Type | Req | Description |
|---|---|---|---|
| asOf | string | – | The knowledge cutoff to read at. Only the deploy's cutoff is served; another value is refused with code as_of_unavailable. |
| cursor | string | – | A cursor from a previous node's children or relations, exactly as returned. |
| depth | number | – | Must be 1 (one level per call). Anything else is refused with code depth_limit. |
| edgeKind | string | – | Only relations of this kind. |
| id | string | – | A node id (sb:e/<hex>, sb:p/<hex>, sb:r/<hex>) or a starting point by name (entity:<label>, event:<slug>). Optional when cursor is given. |
| level | string | – | node (default): the node with the first page of children and relations; children or relations: page through that level only. |
| pageSize | number | – | Items per level, 1-50 (default 10). |
No output schema declared.
No examples provided.
unfurl_watch ~417
Watches: configure and unfurl free; saving is the paid step. Configure a Watch and run it once, without saving: the governed reading (sb.watch-reading.v1) plus a line per coordinate saying whether it was applied. Free, as often as you like; no key. Either start from a standard Watch (base; these read the Strait of Hormuz record) or name your own domain (domain + topics, from get_quote). For a domain, the coverage check runs again here and only covered topics are kept; no reading builder is published for this domain yet, so its reading is cannot-measure per topic and it is never served a standard Watch's reading. Same content as POST /api/v1/watches/unfurl.
| Name | Type | Req | Description |
|---|---|---|---|
| base | string | – | The standard Watch to start from: std.hormuz.maritime-operator, std.hormuz.energy-desk, std.us-iran.geopolitical-analyst. Leave it out when you name a domain. |
| coordinates | object | – | The coordinates you want to change from the base Watch; every one you leave out takes the base Watch's value. Keys: observer, question, domain, interval, language, depth, cadence, selection, threshol… |
| domain | string | – | Your domain in your own words, e.g. Arizona startup ecosystem. Use with topics instead of base. |
| expand | string | – | Override the Watch's depth for this call: 0, 1, 2 ... or full. |
| quoteId | string | – | The quoteId get_quote returned. Recorded with the Watch; the coverage is checked again here either way. |
| topics | array | – | The topics your domain splits into (get_quote proposes them), as names or {name, scope}; 1 to 40. Only the ones coverage we keep reads are kept; the rest come back as free coverage requests. |
No output schema declared.
No examples provided.
What is the io.github.evolutionlabs-dev/signal-bureau MCP server?
io.github.evolutionlabs-dev/signal-bureau is an MCP server listed in the public MCP registry as io.github.evolutionlabs-dev/signal-bureau. SigB (Signal Bureau): maintained, source-traced record of entities and events in your named domain. This page covers its hosted endpoint (https://api.signalbureau.ai/api/mcp).
Is the io.github.evolutionlabs-dev/signal-bureau MCP server safe to use?
io.github.evolutionlabs-dev/signal-bureau scores 76 out of 100 on VerifyMCP. That is a record of what we were able to check automatically, not an endorsement. The category breakdown on this page shows every signal behind the number, including the ones we could not confirm.
What tools does the io.github.evolutionlabs-dev/signal-bureau MCP server expose?
io.github.evolutionlabs-dev/signal-bureau exposes 29 tools: start_here, traverse, search_entities, get_entity, get_topic_record, and 24 more. Their descriptions and schemas cost roughly 6,831 tokens of context every time the server is loaded.
Does the io.github.evolutionlabs-dev/signal-bureau MCP server require authentication?
No. We connected to io.github.evolutionlabs-dev/signal-bureau without credentials and it answered, so anything it exposes is reachable by anyone who knows the address.
Is the io.github.evolutionlabs-dev/signal-bureau MCP server still maintained?
io.github.evolutionlabs-dev/signal-bureau is still listed as active in the MCP registry. We last reached this channel on 4 October 2026. Those dates come from our own scans of the registry and the channel itself, not from anything the publisher announced.