SigB (Signal Bureau): maintained, source-traced record of entities and events in your named domain.
Scored across 22 tools
Several tools occupy close conceptual territory: get_signals/top_accelerating are both entity-attention reads, get_desk_feed/get_watch_feed are nearly identical observed-item feeds, and get_truth_record/get_entity/ask all return tracked-record information. The descriptions are detailed and do help, but an agent could easily select the wrong one without careful reading.
The naming is mostly consistent: read operations use get_* (get_account, get_entity, get_truth_record, get_watch_feed) and actions use imperative verbs (create_order, propose_topic, send_feedback, start_here). Minor exceptions like todays_brief and top_accelerating break the verb pattern, but the overall convention is predictable.
At 22 tools, this is on the heavy side for an MCP server, even though the scope spans data access, purchase flow, feedback, and coverage proposals. Many tools are justified, but the presence of deprecated tools and several near-duplicate feed readers suggests the surface could be trimmed to around 15.
The server covers the main lifecycle well: discovery (start_here), browsing (get_signals, get_events, todays_brief), detailed lookup (get_entity, get_truth_record, get_corroborated), paid watch setup (get_quote, create_order, get_order, get_watch_feed), and feedback (send_feedback, get_feedback_status). Minor gaps exist such as no direct cancel/refund tool and no explicit tariff-listing tool, but agents can work around them.
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. Costs one Read on an identified key (self-issue one free: POST /api/keys). Async — a ticket in ~1s, collected with get_answer.
| 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 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It explicitly mentions the cost ('Costs one Read on an identified key'), the async nature ('Async — a ticket in ~1s, collected with get_answer'), and a prerequisite ('self-issue one free: POST /api/keys'). It also clarifies the scope (live tracked coverage) and the default behavior (shared state from recent answer), which adds transparency beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with zero fluff. The first sentence front-loads the core purpose and the key distinctions. The second sentence covers cost, async behavior, and the alternative for collecting results. Every sentence earns its place, and the structure is well-organized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with only 2 parameters and no output schema, the description covers all necessary aspects: purpose, scope, cost, async behavior, prerequisite, and the follow-up tool. It leaves no ambiguity about how to invoke it correctly or what to expect in terms of result collection. An agent has enough context to call this tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50% (fresh has a description, question does not). The description adds meaning to both parameters: for 'question', the tool's purpose implies it should be a query about a tracked entity/event; for 'fresh', the description explains it 'Force a new synthesis instead of the maintained record's recent answer... default false — shared state is the default'. This compensates for the schema's missing description on question and enhances understanding of fresh beyond its basic boolean type.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: '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.' This is a specific verb and resource with an explicit scope. It also distinguishes itself by stating 'Not general knowledge or history — grounding is live tracked coverage,' which differentiates it from general-purpose Q&A and clarifies it is specifically about tracked records.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool: when you need live tracked coverage about an entity or event, not general knowledge. It also mentions that results are collected via get_answer, implying a workflow. However, it does not explicitly name alternative tools for cases like retrieving raw records (e.g., get_entity or get_record), nor does it state when NOT to use it beyond the general knowledge distinction. Still, the context is clear enough for an agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 what to do next.
| Name | Required | Description | Default |
|---|---|---|---|
| No | Contact email to attach to the order intent (optional) | ||
| items | 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 | |
| dryRun | No | true → rehearse: validate + price the basket, record nothing, issue no links, bill nothing | |
| topics | No | 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. Max 12, each ≤200 chars. | |
| quoteId | No | Optional: the quoteId from get_quote — recorded on the order intent so the desk provisions against that exact quote. | |
| idempotencyKey | No | 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 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden, and it delivers richly. It discloses side effects of the normal flow (order recorded, links issued, billing activated), explicitly contrasts dryRun (no record, no links, no billing), explains balance funding and refundability, describes the self-serve key issuance, and notes that the api line records intent. It even discloses idempotency behavior (retried calls return original intent). This exceeds typical transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but each sentence carries specific, non-redundant information. It front-loads the core purpose and dryRun explanation, then systematically covers item types, pricing, and topics. Some sentences are dense and could be tightened, but the complexity of the tool justifies the length. It does not waste words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 6 parameters, no output schema, and no annotations, the description is remarkably complete. It explains the entire order lifecycle, points to related tools (get_quote, get_account, get_order), and even mentions the statusUrl and polling. It also clarifies edge cases like self-issued keys and no-human-in-the-loop scenarios. Nothing essential for correct invocation is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Even though schema coverage is 100%, the description adds substantial meaning beyond field names: it explains each catalog id ('pilot', 'desk-private', 'api', 'watch', 'balance'), the constraints on `amount` (min $5, max $500), that `quantity` applies only to unit items, and how `topics` are carried verbatim. It also clarifies the difference between funding a balance and buying a prepaid pack. This goes well beyond the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a precise verb and resource: 'Assemble a basket and get exact prices plus Stripe checkout links.' This clearly distinguishes it from siblings like get_quote (pricing only) and get_account (statements), and it internally differentiates the balance item from prepaid packs. The purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit when-to-use and when-not-to-use guidance: it recommends calling get_quote first to price the basket, notes that live prices come from /api/tariff rather than being embedded here, and explains that dryRun:true is the rehearsal mode for integration testing. It also spells out when to use 'balance' instead of 'packs' (packs are explicitly not sold), and when to pass topics. This leaves no ambiguity about alternative tools or conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does well: it discloses authentication methods (x-api-key or Bearer sb_live_...), behavior without a key (explains how to get one), privacy stance ('no key, no tracking'), and what data is returned. It implies read-only via 'read surface' and 'statement' but could be more explicit about not modifying anything; it does not mention error handling or rate limits, so not a 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded: it starts with the main output ('Your meter-account statement, live'), then details the contents, followed by authentication requirements and fallback behavior. Each sentence adds essential information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no parameters and no output schema, the description is quite complete: it enumerates the return contents, explains authentication, and covers the no-key case. It lacks explicit return format (e.g., JSON vs text) or possible failure responses, but given the simplicity, it is sufficiently complete for an agent to select and invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters and the schema is empty (100% coverage by default). The description adds context about authentication headers (x-api-key, Bearer) which is not in the schema, aiding the agent in constructing the request. Since there are no parameters, the baseline is 4, and the description adds no unnecessary parameter info.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as providing a meter-account statement with specific contents: month-to-date metered Reads, tariff, watched topics with billing status, acceptance evidence, and daily cap. It distinguishes from sibling get_* tools by focusing on account/billing-specific data, using the phrase 'your meter-account statement' which is distinct from other tools like get_entity or get_watch_feed.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context on when to use the tool: it requires an identified key, and without a key it explains how to get one. It also mentions that read surfaces remain available in free anonymous lanes, giving an alternative access path. However, it does not explicitly compare to sibling tools or state exclusions for specific scenarios, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 | Required | Description | Default |
|---|---|---|---|
| ticketId | Yes | The uuid the ask tool returned |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden and succeeds. It discloses the cost model ('free and unmetered'), the asynchronous status lifecycle, the fact that 'done' includes the complete answer, and the action needed for failures. This is far beyond minimal disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded: the first phrase states exactly what the tool does, and every subsequent clause earns its place by explaining polling behavior, cost, and terminal states. No filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter tool with no output schema, the description fully explains the integration point (from ask), the response states, the polling interval, the cost implication, and the failure remedy. The agent has everything needed to invoke and interpret the result correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% because the only parameter, ticketId, is already described as 'The uuid the ask tool returned'. The description's reference to 'ticketId (from ask)' adds no new semantic detail beyond what the schema provides, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Collect') with a clear resource ('async answer by ticketId'), explicitly ties to the 'ask' tool, and differentiates itself from sibling get_* tools by focusing on asynchronous result retrieval. The status-based outcome states make the purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides explicit conditional guidance: poll after pollAfter seconds when status is 'working', and treat the response as final when status is 'done'. For 'failed' or 'lost', it states the remedy ('asking again'), establishing when to use this tool versus re-submitting via ask.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Deprecated: this tool is winding down — for evaluating or reading the maintained record, use get_truth_object, 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.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It adds significant context: deprecated status, what data is served (grading dataset for market sensor), that it is scored while open and graded as matured (cannot be back-filled), and that no forecaster is published. However, it does not explain behavior like response format or potential errors, but for a deprecated tool, the disclosure is fairly thorough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a long single block of text, somewhat dense and not front-loaded. It is informative but could be broken into clearer sections (e.g., deprecation notice, what it returns, what it does not return). It earns its place but could be more structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool is simple (no parameters, no output schema), the description covers the key aspects: deprecation, alternatives, what data is included, and what is not included. It also points to a full dataset endpoint. This is complete enough for the agent to decide if and how to use it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, and schema coverage is 100% (trivially, since there are no parameters). The description adds context about what data is returned (fields like crowd, base_rate, Brier score, log loss, etc.), which is useful for the agent to understand the output even without an output schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states it is deprecated and what it serves: the grading dataset for the market sensor (crowd and base_rate) with performance metrics. It clearly identifies the resource and distinguishes it from siblings by explicitly naming alternatives (get_truth_object, get_entity/search_entities, todays_brief).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states the tool is deprecated and tells users to use specific alternatives for maintained data. It also clarifies what is not included (no forecaster published) and directs to a full dataset endpoint. This provides clear when-to-use and when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
What independent 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, how many INDEPENDENT origins reported it (a wire republished by fifteen outlets counts once — echoes are collapsed, not summed), the origins by name with wires marked, the earliest report date when the run carries one, and the entities. Corroboration counts independent origins, not truth: many outlets echoing one official statement is consensus, not verification. 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 | Required | Description | Default |
|---|---|---|---|
| tier | No | Optional filter: 'strong' (independently corroborated) or 'moderate' (corroborated) | |
| limit | No | How many events (default 20, max 60) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and excels. It discloses that corroboration counts independent origins (echoes are collapsed), that counts are not truth, that no probability is the tool's own, and that the tool returns state='cannot-measure' with a reason instead of an empty list. These are non-obvious behaviors that prevent misinterpretation and false confidence.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but every sentence earns its place. It front-loads the core purpose, then systematically explains the meaning of the output fields, the counting logic, and the failure state. It is well-structured and avoids fluff, using precise phrasing that packs significant information into a readable paragraph.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given there is no output schema, the description provides a thorough account of what the tool returns: claims, tier, independent origin count, origin names with wire marks, earliest report date, and entities. It also covers the edge case of unreadable data. This is unusually complete for a tool with no structured output schema, leaving little ambiguity for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers both parameters (tier, limit) with descriptions, so schema coverage is 100%. The description does not add extra semantic detail about how tier filtering behaves or how limit interacts with the results beyond what the schema already states. The baseline of 3 applies because the schema handles the parameters adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns 'what independent sources agreed on' — a specific resource (corroboration layer) with a precise scope. It distinguishes this from raw event lists or truth by explicitly defining what corroboration means and what it does not mean (consensus vs verification). This is more than a simple verb+resource; it establishes the tool's unique semantic niche among the many get_* siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context (e.g., when you need corroboration data rather than raw events or truth), and it warns about the limitations (not truth, not counting echoes). However, it never names an alternative tool or states explicit conditions for when to choose this over a sibling like get_events or get_truth_object. The 'when-not' is partially implied but not made actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 | Required | Description | Default |
|---|---|---|---|
| days | No | How many recent days to return (1-14, default 14) | |
| desk | Yes | The desk slug (e.g. 'space-economy') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses ordering ('newest-first'), time window ('up to 14 days'), item fields, keyed authentication ('x-api-key'), behavior for unknown desks, and that payload declares coverage state. It does not explicitly state read-only semantics, but the feed nature strongly implies it.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is moderately long but each sentence contributes unique information: purpose, roster, delivery, pricing, and coverage state. It is front-loaded with the core function, though the desk list and pricing details add extra length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description covers retrieval scope, authentication, differentiation from watch topics, and pricing. It does not detail error cases or exact response envelope, but the mention of 'payload declares its own coverage state' mitigates some uncertainty.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already covers both parameters with descriptions and examples. The description adds the full list of valid desk slugs and clarifies the days parameter as a lookback window, enriching the parameter meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns a desk's machine feed: 'up to 14 days of the desk's observed items (title, url, source), newest-first'. It also distinguishes itself from sibling tools by explicitly contrasting with 'watch topics' and naming the public desk roster.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides context for when to use: 'identified delivery is the standard shape for standing feeds' and contrasts with watch topics. It also directs to get_quote for pricing, but does not explicitly state 'use this instead of X' except through the watch topic differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Full dossier for one entity: signal count, verticals it's spreading across, and why it's surfacing.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the burden. It discloses the kind of return data (signal count, verticals, why surfacing) but does not state read-only behavior, error handling, or side effects. Adequate for a simple getter but incomplete on safety context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence that efficiently communicates the tool's purpose and key output components with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter getter, the description covers what it does and what it returns. Given the large sibling set, adding a note about when not to use it would aid completeness, but the current description is nearly sufficient for selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema only has a bare 'name' string with no description (0% coverage). The description compensates by indicating that the parameter identifies a single entity, adding meaning beyond the schema field.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it returns a 'full dossier for one entity' with specific contents: signal count, verticals, and why it's surfacing. This distinguishes it from sibling tools like get_signals or get_record by emphasizing a comprehensive, single-entity view.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use when a deep dive on one entity is needed, but it does not explicitly state when to use this tool versus alternatives like search_entities or get_signals. No exclusions or alternative tool names are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 | Required | Description | Default |
|---|---|---|---|
| limit | No | How many (default 20, max 50) | |
| query | No | Filter by event name or entity (optional) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden; it details the event structure (entities, market-question count, across-domain mention volume, dates) and optional filters. However, it does not explicitly disclose read-only behavior, return format, or ordering/pagination details beyond the schema's limit parameter.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, directly states the core content and the available filter, with no redundant wording. It front-loads the purpose and avoids filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, so the description compensates by enumerating what each event includes. It covers the main use case and filter capability, though it could be clearer about the response being a list and any default ordering.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides 100% coverage for both parameters (limit and query), so the baseline is 3. The description adds that 'query' filters by name or entity, which mirrors the schema and provides no additional syntax or format details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as returning tracked world events, describing them as named arcs with entities and metrics, which distinguishes it from sibling tools like get_entity or get_record. The verb is implied via the tool name 'get', and the scope is well-defined.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies it should be used to retrieve world events, but does not explicitly contrast it with any of the many sibling get_* tools. It gives context about events being engine-tracked arcs, so an agent can infer when to use it, but no explicit when/where-not guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 | Required | Description | Default |
|---|---|---|---|
| feedbackId | Yes | The feedbackId returned by send_feedback |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the possible status values, the inclusion of a work-order reference, and the fact that recent reports may still show 'filed'. This provides meaningful behavioral context beyond just saying 'get status'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core function, and contains no fluff. It efficiently conveys the status values and a relevant caveat.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given a single required parameter and no output schema, the description provides the status set, the work-order reference, and a timing nuance. This is sufficient for an AI agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already describes feedbackId as the value returned by send_feedback (100% coverage). The description adds no new format or syntax details, so it does not improve on the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns the state of a report filed via send_feedback, listing the possible statuses (filed, working, resolved) and mentioning the work-order reference. It distinguishes itself from sibling get_* tools by focusing specifically on feedback status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when a feedbackId from send_feedback is available, and provides a temporal caveat about recent reports potentially still reading 'filed'. It does not explicitly name alternatives, but the context is clear given the sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Re-read an order intent created by create_order — the recorded basket and its honest status. 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 | Required | Description | Default |
|---|---|---|---|
| order_id | Yes | The UUID returned by create_order |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that the operation is a re-read, specifies the output (basket and honest status), and adds important context about payment truth residing with Stripe. It does not mention side effects, but none are expected for a read operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no wasted words. The first sentence states the core purpose, and the second provides necessary caveats. Information is front-loaded and easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-by-id tool with one parameter and no output schema, the description adequately explains what the tool returns ('recorded basket and its honest status') and provides essential caveats. No additional information seems necessary for an agent to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the parameter is documented as 'The UUID returned by create_order'. The description adds no significant new meaning beyond the schema, merely echoing 'created by create_order'. Baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 're-read' and identifies the resource as 'an order intent created by create_order', which clearly indicates its function. It also distinguishes itself from siblings by stating that payment truth and metered work receipts reside elsewhere.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when this tool is appropriate (reading an order intent) and explicitly notes alternative sources for payment truth (Stripe) and metered work (get_account). However, it does not explicitly state 'use this when you need the basket', relying on inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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, each priced flat from the published tariff ($20/topic/month at the opening rate). 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 | Required | Description | Default |
|---|---|---|---|
| requirements | Yes | What you want watched, in your own words — one blob of text or bullet points; the desk does the grouping |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses numerous behaviors: merging/splitting logic, partial quotes with unresolvedRequirements, rate limits, no contact details, and holding period. This is especially valuable given no annotations are provided.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but well-structured, front-loading the core purpose and then adding necessary detail. It's longer than average but every sentence adds critical information for a complex tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description explains key return fields (billing.expansion, partial, unresolvedRequirements) and the behavior under partial resolution. It also covers rate limits and validity period, making it highly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already describes the 'requirements' param well, and the description reinforces it with examples and explains how the requirements are processed (grouped, disambiguated). It adds value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the function: feed in requirements and receive an enumerated quote with grouped watched topics and pricing. The verb 'get back' and resource 'quote' are explicit, and the detailed account of grouping/pricing distinguishes it from siblings like ask or create_order.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explains that this is for requirements that need to be priced and grouped into watched topics, and notes that a quote is not a charge and holds for 30 days. It doesn't explicitly mention alternatives or when not to use, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Deprecated: this tool is winding down — for evaluating or reading the maintained record, use get_truth_object, 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.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses that the data is 'Appended, never edited' and that the tool is being deprecated, which are important behavioral traits. It also implies a read-only operation via 'GET /api/record-data', though it doesn't cover auth or rate limits. This is sufficient for a read-only tool with no side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is moderately long but front-loads the deprecation and alternatives immediately. Each sentence adds value: deprecation notice, what is still served, integrity guarantee, and API reference. It could be slightly trimmed but is well-structured and not wasteful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, so the description must convey what the tool returns. It does so by detailing the correction record (with estimate, CI, cohort sizes, etc.) and the retirement object. It also mentions the append-only nature. This is complete for a no-param read tool, though it omits example response format.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the schema has 100% coverage (empty object). Per the rubric, a baseline of 4 applies since no parameters exist. The description doesn't need to explain parameters, and it doesn't, so the baseline holds.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool is deprecated and explicitly defines its remaining purpose: serving the correction record and retirement object. It names specific content (repricing regression with statistical details) and points to alternatives, making it distinct from sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly says 'Deprecated: this tool is winding down' and lists alternative tools (get_truth_object, get_entity/search_entities, todays_brief) for maintained access. It also conditions when to still use this tool ('Still served here...'), giving clear usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.50x the rate of matched unflagged controls (95% CI 1.39-1.65, shock-days excluded, controls reweighted to the flagged cohort; n=2701 flagged vs 105699 controls, window 2026-03-29 to 2026-09-26, as of 2026-09-26). An attention-leads-movement association — never a directional claim.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | How many signals (default all flagged) | |
| direction | No | Filter by trajectory: rising|fading|steady|new |
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 well. It discloses that this is a read, defines the evidenceStatus behavior (receipted rows carry source-attributed evidence URLs; unreceipted rows are labeled leads), and adds the critical interpretation guardrail that the measured association is 'never a directional claim'. It also reveals the 500/day quota.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the most actionable information ('START HERE', cheap read) and packs meaningful payload semantics into the middle. The statistical 'Measured property' block is verbose and slightly awkward, but it earns its place as a transparency safeguard, so the overall size is acceptable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema and no annotations, yet the description gives an agent enough to call and interpret the tool: payload parity, output fields, evidenceStatus semantics, quota, and an explicit caveat about the association not being directional. Nothing critical for deciding whether or how to use this read-only feed is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for both `limit` and `direction`, so the baseline is 3. The description adds no additional meaning for either parameter and does not mention them at all, relying entirely on the schema to define them.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies a clear resource — the 'full machine-readable signal feed' — and specifies what it contains: every entity flagged by the attention engine, with trajectory, domains, desk membership, and evidenceStatus. It is specific and useful, but it does not explicitly name or contrast sibling tools like get_desk_feed or top_accelerating, so the differentiation is only implicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives strong usage guidance: 'START HERE for browsing' and positions the tool as 'the cheap read (500/day, no model work)'. This tells an agent when to reach for it, but it does not state when not to use it or name alternatives for more specific/expensive reads.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The maintained record for one subject — the ONE file its /exhibit page renders from and GET /api/truth/{slug} serves, 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), the change log, and what this record cannot see. 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). Two of these subjects also have a full public exhibit page a human can read: hormuz, interest-rates, ai-model-race, us-government-shutdown, israel-iran-conflict, russia-ukraine-war, brazil-election, strait-of-hormuz, us-presidential-2028, us-midterms-2026, gaza-ceasefire, fed-rate-decision, venezuela-crisis, uk-election, us-recession-2026, disaster-event-hurricane, disaster-event-atlantic-hurricane, product-launch-spacex, product-launch-falcon-space-force, product-launch-falcon-spacex, product-launch-space-force-spacex, product-launch-spacex-starlink, election-michigan-republican, election-republican-republicans, regulatory-action-hawaii-high-court, election-republican, election-republican-republican-party, ceasefire-peace-iran, election-michael, legal-ruling-supreme-court, regulatory-action-congress, economic-indicator-inflation, disaster-event-earthquake, funding-round-spacex, bitcoin-price-level, product-launch-xai, election-france, election-serbia, product-launch-anthropic, election-british-columbia-united-kingdom, election-democratic-party, election-germany, funding-round-stripe, election-israel, funding-round-perplexity, product-launch-anthropic-claude-opus, economic-indicator-argentina-inflation, election-mecklenburg-vorpommern, election-swedish, economic-indicator-unemployment, election-parliament, election-parliament-russia, election-quebec, funding-round-kraken. Complementary to get_entity, which returns the broader live entity dossier.
| Name | Required | Description | Default |
|---|---|---|---|
| topic | No | The name this parameter had under get_truth_object. Still accepted, always will be. | |
| subject | No | Which subject, by slug or name — "Interest Rates", "interest_rates" and "interest-rates" all reach the same record. Omit for the flagship. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses free/no-key/no-charge access, the three possible answers (`served`, `not-registered`, `cannot-measure`), the rotating flagship default, and that cited prediction-market prices are never the tool's own probability. It omits rate limits and exact record shape, but covers key behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is bloated with a very long, unnecessary list of exhibit-page subjects. While the core purpose and behavior are front-loaded, the extensive enumerations detract from conciseness and do not support correct tool invocation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description partially compensates by summarizing record contents and return states, but it does not describe the exact structure of the returned record or mention error/limit behavior. It is adequate for a simple lookup tool but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds that 'with no argument you get the flagship record (hormuz today, and it rotates),' which goes beyond the schema's 'Omit for the flagship' and clarifies the default behavior for the subject parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: it returns 'the maintained record for one subject' and explicitly contrasts with get_entity, which returns 'the broader live entity dossier.' An agent can distinguish this tool from its siblings based on the purpose alone.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied through 'Complementary to get_entity' and the note that omitting the subject returns the flagship record. However, the description does not explicitly state when to prefer this tool over get_entity or other siblings, nor does it provide exclusions or when-not conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 | Required | Description | Default |
|---|---|---|---|
| days | No | How many recent days to return (1-14, default 14) | |
| topic | Yes | The watched topic name (as quoted/ordered) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does well. It discloses delivery mode (pull), output structure (newest-first items, grading report), and billing behavior (does not gate billing, month refundable). This goes beyond basic read-only/write categorization and provides useful operational context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single long paragraph with the billing policy embedded, which is tangential to tool invocation. While dense with useful information, it lacks front-loading and includes extra commercial details that could be trimmed without losing operational clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description adequately covers return contents (observed items with fields, coverage report), ordering, delivery mode, and billing implications. With no output schema, it effectively explains what the tool returns. Minor gaps like error handling or missing-topic behavior keep it from a 5.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for both parameters, so baseline is 3. The description adds minor context like 'up to 14 days' matching the schema and 'newest-first' which describes output ordering, not parameter meaning. It doesn't meaningfully enrich parameter semantics beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: it delivers a structured daily feed for a machine-watched topic, including up to 14 days of observed items and a coverage-acceptance report. This specific verb+resource (get/feed) distinguishes it from siblings like get_quote and get_desk_feed.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly says when NOT to use this tool: 'Topics not yet watched: get_quote prices them.' This provides a clear alternative for unwatched topics and implies this tool is for already-watched topics. Also notes delivery is pull (poll daily or on demand), giving clear usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 | Required | Description | Default |
|---|---|---|---|
| why | No | Why this coverage matters (optional — helps the review) | |
| Yes | Your human principal's contact email, used only to follow up on this request | ||
| topic | Yes | What to cover — a topic, entity, or standing question | |
| requester | No | Name to file the request under (optional) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It transparently describes the workflow: files into a queue, humans review, accepted topics enter provisional lane and appear in signal feed. It also mentions 'Free' and the email purpose. Missing are details on rejection behavior, duplicates, or rate limits, but it covers the core process well.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, tightly worded, and front-loaded with the core purpose. Every clause adds value: the net-new scope, the queue outcome, the provisioning lane, the email requirement, and the cost. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (4 params, no output schema, no annotations), the description sufficiently explains the request lifecycle, including human review and acceptance outcomes. It is missing some edge-case behavior (e.g., duplicate handling, rejection response), but overall an agent can select and invoke this tool with confidence.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and each parameter has a clear description. The tool description adds slight semantic nuance (e.g., 'topic, entity, or standing question' for the 'topic' field) and explains why email is needed, but most meaning is already captured in the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb 'Propose' and a precise resource: 'NET-NEW coverage — a topic, entity, or standing question we don't track yet.' It distinguishes from siblings by emphasizing 'net-new' and the queue/lane workflow, making its unique role obvious.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on when to use the tool: when proposing something not yet tracked ('we don't track yet'). It also states a prerequisite ('Needs your human principal's contact email') and a cost signal ('Free'). However, it does not explicitly name alternatives or exclusion cases, though the 'net-new' condition implicitly excludes existing coverage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find tracked entities/topics by name or vertical (e.g. 'iran', 'semiconductors').
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states the core action without revealing whether the operation is read-only, what it returns (e.g., list or single entity), or any constraints like case sensitivity or partial matching. This lack of transparency could lead to incorrect assumptions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads the action ('Find') and immediately specifies the resource and method, followed by examples. Every word earns its place; there is no redundancy or unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and no output schema, the description covers the basic purpose and query format. However, it does not describe the return value (e.g., list of entities, matched fields) or any behavioral edge cases, leaving some uncertainty for the agent about what to expect from the response.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema only defines a 'query' string with no description, giving 0% schema coverage. The description compensates by explaining that the query can be a name or vertical and provides concrete examples ('iran', 'semiconductors'), adding meaningful semantic context beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function with a specific verb ('Find'), a resource ('tracked entities/topics'), and a method ('by name or vertical'), complete with examples. It effectively distinguishes itself from sibling tools like get_entity by emphasizing a search across entities/topics rather than retrieval of a specific one.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for search scenarios (e.g., finding entities by name or vertical) but does not explicitly state when to use it over alternatives like get_entity or propose_topic. There is no exclusionary guidance, so the agent must infer the appropriate context from the action keyword 'search'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 | Required | Description | Default |
|---|---|---|---|
| ref | No | A quoteId, ticketId, or orderId to tie this to (optional) | |
| kind | Yes | bug | improvement | complaint | praise | question | |
| about | No | Which tool/endpoint/page this concerns (optional) | |
| detail | No | The full story — reproduction steps, expected vs observed (optional) | |
| summary | Yes | One sentence: what happened or what you want |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full transparency burden and excels. It discloses rate limits (5/minute, 20/day per network address), the work-order policy for complaints naming real defects, and the response's honesty about durable recording. These are substantive behavioral details beyond the typical mutation description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is five dense sentences, each adding distinct information: purpose, constraints, behavioral consequence, ref usage, and response guarantee. It is compact, non-redundant, and front-loaded with the core action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given five parameters, no output schema, and no annotations, the description covers purpose, rate limits, side effects, parameter context, and response behavior. The 'honestly' clause partially addresses failure/durability, making the tool's behavior remarkably well-specified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds a small clarification for ref ('from your own records') and re-lists the kind values, but these do not meaningfully exceed the schema's existing descriptions for any parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'File structured feedback with the desk', a specific verb+resource that clearly states the tool's purpose. It enumerates the accepted kinds (bug, improvement, complaint, praise, question) and distinguishes this tool from the sibling get_feedback_status by framing it as the follow-up status tracker.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear when-to-use context: it is for filing structured feedback, with constraints (free, no contact details, rate limits) and ref usage guidance. It explicitly names get_feedback_status for tracking, but it does not address potential overlap with siblings like ask, leaving minor ambiguity for service-related questions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It discloses 'no arguments, no key, no charge' – key operational facts. It also sets expectations about content ('what we are not', 'tests to check that claim'). While it doesn't mention rate limits or response format, the tool is purely informational, so coverage is strong.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, long sentence but front-loads the critical 'START HERE' and 'no arguments, no key, no charge' information. It is dense but efficient; slight verbosity in enumerating topics is acceptable for an onboarding tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For an intro tool with no parameters or output schema, the description covers all essential aspects: identity, verification tests, pricing, content proposals, and purchase process. Nothing critical is missing for an agent to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so baseline is 4. The description reinforces that no arguments are needed, adding clarity without redundancy.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description states a specific purpose: it is the entry point for learning about Signal Bureau. The verb 'START HERE' and content list (who we are, tests, free/paid, buying) clearly define the resource. It distinguishes itself from sibling tools by being the mandatory first call.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs 'first call' and 'Read this before evaluating anything else here', providing unambiguous timing and priority relative to other tools. No alternative is needed since it is the intended initial step.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the transparency burden, and it does so well: it discloses the presence of gaps and watch fields and explains how market figures are handled (URL included or withheld). It does not mention rate limits or side effects, but for a zero-parameter read-style brief tool the most important behavior is covered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one dense but well-organized sentence, front-loading the core purpose ('Today's morning brief') before adding structural details. It could be split for readability, but every clause adds useful information and nothing is wasted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool with no output schema, the description is nearly complete: it explains what the brief contains, how gaps and watch items work, and how market figures are rendered. The only minor gap is the lack of an explicit statement that the tool returns the brief content directly, but that is strongly implied.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters and 100% schema description coverage, so there are no parameter semantics to clarify. The description's references to gaps and watch are output semantics, not parameters, which is appropriate here.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource: today's daily synthesized brief with narrative, gaps, and watch items, and it provides distinctive content details like prediction-market links. It doesn't explicitly name sibling alternatives, but the resource is distinct enough from siblings like get_watch_feed or get_desk_feed to be identifiable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use it — when a daily cross-domain brief is needed — and notes it matches the public /today page, giving context. However, it does not explicitly say when not to use it or point to alternative tools for other feed types.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The entities/topics accelerating most across the information environment right now, ranked by cross-domain attention.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | How many (default 10, max 50) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It explains what is returned, but does not disclose behavioral traits such as data freshness, filtering behavior, potential rate limits, or whether results are dynamic. The phrase 'right now' implies real-time but lacks specifics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that directly conveys the tool's core purpose. There is no redundant or extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description gives a clear high-level purpose but is somewhat incomplete given no output schema. It does not specify what fields are returned (e.g., names, scores, timestamps), which could be useful for an agent. For a simple list tool, it is adequate but has room for improvement.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully describes the only parameter 'limit' with a clear meaning and default. The description adds no additional parameter context, but the schema coverage is 100%, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns entities/topics ranked by acceleration and cross-domain attention. It is specific about the resource and ranking, though it lacks an explicit verb like 'list' or 'get', which slightly reduces clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The sibling tools include other list/search tools, but the description does not mention any conditions or exclusions, leaving the agent to infer usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Provenance-first database for teams and agents: every value carries sources, rules and coverage.
Bitcoin-anchored, tamper-evident audit log for AI agents — record, disclose and verify actions.
Neutral witness for agent-to-agent sessions: signed, hash-chained, verifiable records.
Machine-readable entity discovery with provenance, trust and verified source evidence.
Add one secure layer between your agents and this server.
