signal-bureau

ask

Ask about FUTURE or unfolding events (geopolitics, markets, tech, health — will X happen, and what the tracked record shows). NOT for historical facts or general knowledge — grounding is live tracked coverage, and each call does real model work and rides your identified key: self-issue one FREE in a single call (POST /api/keys with {"label":"your agent name"} — instant, no human, no card; the response's key field, shown once, rides back as an x-api-key header) and it carries its own 25/day meter, never shared with your cloud or platform neighbors (universal keying, 2026-08-08; an unkeyed call returns the same one-step instruction, never a dead end). ASYNC BY DEFAULT: returns a claim ticket in ~1s ({status:'working', ticketId}); collect the finished answer with get_answer (typically ready in 30-120s, free to collect — the question was metered once at submit). Keep working while the desk works. If the ticket store is briefly unavailable the full answer comes back synchronously instead — handle both shapes. SHARED STATE: the same question asked again while the record's answer is recent returns the SAME stored answer immediately (servedFrom:'maintained-record', same permalink id) — that consistency is the product behaving as documented; pass fresh:true to force a new synthesis. VERIFICATION VERDICT (sourceChecked): true means every load-bearing claim was located in article-level coverage, at least one cited source is independent of Signal Bureau, AND no claim asserts a stronger operational state than the cited evidence supports (risk, disruption, incident and halt are graded, not interchangeable); a hard claim whose only support is a headline, or one stronger than its evidence, is listed in the caution list and caps the verdict and confidence — pass/fail is always disclosed, with what would change the read. For browsing what is moving, prefer get_signals/top_accelerating (cheap, 500/day). Informational only — not advice.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`fresh`	No	Force a new synthesis instead of the maintained record's recent answer to the same question (default false — shared state is the default)
`question`	Yes

TDQS

A4.9/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden and does it thoroughly: async default with ~1s ticket, 30-120s collect time, free collection, synchronous fallback when ticket store is unavailable, shared-state consistency with same permalink id, fresh:true behavior, and a detailed verification verdict explanation (sourceChecked, caution list, capped confidence). This is far beyond the minimum.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is dense with essential operational and security details (key issuance, metering, async semantics, verification grading). Most sentences earn their place, but the structure is a long stream of parentheticals and dashes, making it harder to scan. Slightly too verbose to be a 5, but still well-packed.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a complex tool with no output schema and no annotations, the description covers every aspect needed to invoke correctly: purpose, exclusions, async flow, result retrieval, shared state, fresh parameter, verification semantics, keying/metering, and the alternative tools. Nothing critical is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is only 50% (fresh is documented, question is not). The description fills the gap: defines what 'question' should contain ('FUTURE or unfolding events'), and gives meaning to 'fresh' ('Force a new synthesis instead of the maintained record's recent answer...'). It also clarifies the default shared state, which is not in the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb and resource: 'Ask about FUTURE or unfolding events (geopolitics, markets, tech, health — will X happen, and what the tracked record shows).' It also explicitly excludes mis-use: 'NOT for historical facts or general knowledge.' This clearly differentiates it from sibling tools like get_entity or get_record.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides explicit when-to-use vs alternatives: 'For browsing what is moving, prefer get_signals/top_accelerating (cheap, 500/day).' It also gives operational conditions: async returns a ticket to collect via get_answer, with a synchronous fallback, and describes the fresh:true parameter. This leaves no ambiguity about when and how to call.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All signal-bureau tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4/5.0

Disambiguation5/5

Each tool targets a distinct function: ask is async event queries, get_answer retrieves results, get_signals and top_accelerating provide different signal views, get_entity and search_entities cover entity details and search, etc. No two tools have overlapping purposes, and descriptions clearly separate them.

Naming Consistency4/5

The majority of tools follow a 'get_' prefix for retrieval (13 of 21) and other clear verbs like 'ask', 'create_order', 'propose_topic', 'send_feedback'. A few use noun phrases like 'todays_brief' and 'top_accelerating', which breaks the pattern slightly but are still intuitive. Overall consistent and predictable.

Tool Count5/5

21 tools cover the full scope of the server: exploration, querying, ordering, account management, feedback, and data records. Each tool serves a clear purpose without redundancy, and the count feels well-scoped for the domain.

Completeness4/5

The tool surface covers all major workflows: browsing signals, asking questions, getting detailed reports, ordering, providing feedback, and proposing new topics. Minor gaps exist (e.g., no explicit tool to cancel an order or manage watched topics directly), but core operations are present and agents can handle the domain effectively.

Resources

Need Help?