signal-bureau

ask

Ask what the tracked record shows about a named entity or unfolding event (geopolitics, markets, tech, health): what changed, what the maintained record currently holds, and which sources corroborate it. 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 25 free asks for the life of the key on its own meter — not per day, and they do not reset; after them each Read meters at the published rate on a billing arrangement you open with create_order (item 'api'), never by default, and a used-up allowance answers with that step, never a dead end — never shared with your cloud or platform neighbors (universal keying, 2026-08-08; an unkeyed call returns the same one-step instruction). 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, and a served-from-record answer is still one Read on your meter (the maintained state IS what was bought); pass fresh:true to re-synthesize. 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

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

First observedAug 17, 2026

TDQS

A4.7/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 so thoroughly. It discloses authentication/key issuance, free-tier metering and billing behavior, shared-state consistency with servedFrom:'maintained-record', the effect of fresh:true, and the verification verdict logic (sourceChecked, caution list, graded claims). This is far beyond a minimal read/write label.

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

Conciseness3/5

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

The description is information-dense but overly long: it front-loads purpose, then spends many sentences on key issuance, meter details, billing, shared-state behavior, and verification rules. Some asides (e.g., 'universal keying, 2026-08-08') are tangential to using the tool. It is organized but would benefit from tighter structure.

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 tool with no output schema and no annotations, the definition covers essentially all needed context: valid question scope, result semantics, auth/metering, consistency behavior, verification output, and alternatives. There is no obvious missing piece for an agent to call it correctly.

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

Parameters4/5

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

The schema explains fresh in detail but leaves question as a bare string. The description compensates by defining what the question should address (named entity or unfolding event in tracked coverage) and what the answer will cover. It doesn't give explicit question examples or length constraints, so it's not a perfect 5, but it adds clear semantic guidance.

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 what the tracked record shows about a named entity or unfolding event.' It also names the output dimensions (what changed, current holdings, corroborating sources) and explicitly excludes historical facts/general knowledge, which differentiates it from generic Q&A and 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?

The description gives an explicit 'NOT for' boundary and directs an alternative for a different use case: 'For browsing what is moving, prefer get_signals/top_accelerating (cheap, 500/day).' It also specifies when to pass fresh:true ('re-synthesize') vs relying on shared state, giving clear selection guidance.

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?