Bitcoin-anchored sealed-forecast record: search, grades, calibration, luck test. Read-only, no key.
Scored across 13 tools
Most tools have clearly distinct purposes, and the descriptions actively route the agent (e.g. neural_search vs search_sealed_forecasts, ask_the_record vs search). However there is mild overlap: five analytics tools (calibration, corpus_insights, information_yield, luck_test, regrade_kit) all report on corpus quality, and ask_the_record shares scope with neural_search's site-corpus coverage, so boundaries require careful reading.
A strong get_*/list_*/search_* verb_noun pattern dominates (get_advisory, get_luck_test, list_open_calls, search_sealed_forecasts). Minor deviations exist: ask_the_record uses a different verb phrasing and neural_search is adjective-first as a named feature, but the set is largely predictable.
13 tools sit comfortably in the well-scoped 3-15 range for a forecasting-corpus server. Each tool appears to earn its place (retrieval, single-record fetch, and distinct analytic lenses), with no obvious redundancy or filler.
The surface covers retrieval (text + semantic), single-record fetch, open/unresolved listings, per-event timelines, and multiple analytic/verification lenses plus governance, which is broad for the domain. A minor gap is the absence of a general filtered listing of all/graded calls beyond open ones, though search largely compensates.
Ask any question about JYOTINT / Vijay Jyotish and get back the most relevant VERBATIM passages of the operator's own published site copy — never generated, never paraphrased, so it cannot hallucinate. This is the operator answering in his own words, drawn only from the public record (method, doctrine, the five pillars, mission-assurance fit, objections, pricing, heritage, etc.). Prefer this for any 'what does JYOTINT say about X' / 'why' / 'how does it work' question. Each passage cites its source page. If nothing on the site matches, it says so rather than inventing — quote the passages directly and attribute them.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max passages (default 3, max 6). | |
| query | Yes | The question, in natural language. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnlyHint, idempotentHint, non-destructive, closed-world), and the description adds real behavioral context beyond them: results are verbatim never generated/paraphrased, each passage cites its source page, and it reports failure explicitly when no site copy matches rather than inventing. Useful disclosure of return semantics and failure mode.
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?
Front-loads what it does and the verbatim guarantee, then layers usage guidance and attribution instructions. Some phrasing is promotional ('so it cannot hallucinate') and slightly redundant, but every sentence serves a routing or behavioral purpose.
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 two-parameter retrieval tool with no output schema, the description adequately explains what comes back (verbatim passages, source citations) and how it behaves when there is no match. Safety and idempotency are covered by annotations, so little 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?
Schema description coverage is 100%, and the schema already documents both query and limit (default 3, max 6). The description adds no additional syntax or format guidance for the parameters, so baseline 3 applies since the schema carries the load.
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?
States a specific verb (ask) and resource (the operator's published site copy / 'the record'), and describes the exact return type: verbatim passages with source attribution. An agent can distinguish this retrieval tool from siblings like neural_search or search_sealed_forecasts without opening a schema.
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 says to 'prefer this for any what does JYOTINT say about X / why / how does it work question,' giving clear positive routing guidance. It stops short of naming which sibling to use when the question is NOT about operator doctrine/copy, so alternates are implied rather than spelled out.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch one sealed forecast by its id (e.g. 'IA-RU-008', 'LA-011', 'IA-MKT-002'). Returns the full record incl. verbatim claim, grade, outcome, sources, and seal hash.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Advisory id. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so safety and repeatability are covered. The description adds useful return-content context (verbatim claim, grade, outcome, sources, seal hash). It does not describe auth needs or rate limits, but with annotations covering the safety profile, a 3 is appropriate.
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, zero waste, front-loaded with the retrieval action and immediately followed by the record contents. Every element earns its place.
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?
Complete for a single-record lookup whose annotations already carry safety and idempotency, with a 100% covered schema and no output schema. The description tells the agent what id looks like and what comes back, which is everything needed to call 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 description coverage is 100%, so the 'id' parameter is already documented as 'Advisory id.' The description adds example id formats ('IA-RU-008', 'LA-011', 'IA-MKT-002') which provide helpful syntax context beyond the schema. Baseline 3 is correct when the schema does the heavy lifting.
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?
States a specific verb and resource ('Fetch one sealed forecast by its id') and distinguishes itself from the sibling 'search_sealed_forecasts' by emphasizing retrieval of a single record by id. The example id formats make the intended key type 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?
Implied usage is clear: use when you already have the advisory id. However, no explicit when-to-use or when-to-use-instead-of-search is provided, and no exclusions are stated. This is minimum viable routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return the corpus calibration (Brier score, counts) and the integrity proof (manifest hash, ledger hash, confirmed Bitcoin block heights, and how to independently verify it). ALSO returns record_versions: the record is append-only, so if a publication cited a count/Brier that no longer matches the live count, that is expected (calls were sealed since) — resolve the paper's exact cited state by record count or hash via record_versions and recompute the immutable frozen snapshot.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish readOnly/idempotent/non-destructive behavior. The description adds meaningful domain context: append-only sealing means counts drift from paper-published values, and it explains the record_versions resolution path. It does not describe return format or pagination, but this is contextual rather than behavioral.
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?
Front-loaded with the two main outputs, but the second half is a long run-on sentence about record_versions and citation reconciliation. The content is useful but could be tightened or split.
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, so the description must convey what is returned, and it does: Brier score, counts, hashes, block heights, verification method. The append-only/record_versions explanation is a valuable completeness addition. Slightly verbose but covers the agent's needs.
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?
Zero parameters, so baseline is 4. Schema coverage is 100% and there is nothing to document; no parameter information is needed.
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?
States a clear compound purpose: returns corpus calibration (Brier score, counts) and integrity proof (manifest hash, ledger hash, Bitcoin block heights, verification steps). Distinguishable from siblings like get_map or get_corpus_insights, though the sibling 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?
No explicit when-to-use guidance or alternatives. The mention of record_versions as a resolution path for stale citations implies usage context, but there is no comparison with sibling integrity or calibration tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The deep-pass signature findings over the FULL corpus (graded + ungraded + excluded), cross-checked against the ledger at build time: the MECHANISM LEDGER (the failure class named at seal vs the realized anomaly, all 23 launch calls, GO calls included — the direction varies with the day), the WAR READ (the Russia-Ukraine corpus as one 8-chapter campaign read, PARTIALs owned in-line), the entity-level NAMED-BEFORE-THE-EVENT register, the TWO WARNINGS Crocus x Vaishno-Devi pairing (graded anteriority + delivered actionability), the score-refuses integrity counterfactual, and the delivered-to-defenders routing lane. Caveats ship in the same object — quote them with the findings.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and a closed world, so the safety profile is covered. The description adds two pieces of real behavioral context beyond that: the findings are cross-checked against the ledger at build time (i.e., a snapshot, not live), and caveats ship in the same object and should be quoted with the findings. It still says nothing about size, cost, or staleness cadence.
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?
One long run-on sentence dense with capitalized in-house terminology. It is front-loaded with the corpus scope, which is good, but the enumeration of bundled sections reads as a jargon pile rather than a structured list, and several items would be clearer as separate sentences or bullets.
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 usefully compensates by enumerating what the returned object contains and by flagging that caveats travel with the findings. Nothing about the return shape is left wholly unstated, though the individual section names remain undefined.
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 takes zero parameters, so there is no parameter semantics for the description to carry. Baseline of 4 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 identifies a specific resource — the deep-pass signature findings over the full corpus, cross-checked against the ledger at build time — and enumerates the sections it bundles (mechanism ledger, war read, named-before-the-event register, warnings, counterfactual, routing lane). However, it is a noun-phrase content dump without a clear action verb, and it never distinguishes itself from closely related siblings such as get_calibration_and_integrity, get_information_yield, or search_sealed_forecasts, so an agent must infer the boundary.
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?
There is no when-to-use guidance, no when-not-to-use, and no named alternative among the twelve siblings whose scopes overlap. The description only says what is inside, leaving the agent to guess at selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return JYOTINT's data-handling, PROVENANCE & governance posture — the answer to 'is this source safe to read / cite / ingest?'. Chain-of-custody is foregrounded: every record is SHA-256-sealed + Bitcoin-anchored before the event and independently recomputable (the provenance the proposed GSA AI data-safeguarding rule treats as first-class). Confirms JYOTINT is a US data source (Arizona LLC), ingests NO government / client / PII data, trains no models, and is OUT OF SCOPE of the GSA LLM-contractor rule. Descriptive disclosure, not a certification. Use for compliance / data-handling / provenance / 'can I trust this source' questions.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, non-destructive), so the description is not obligated to restate that. It does add non-obvious expectations: the output is 'descriptive disclosure, not a certification,' and it is explicitly out of scope of the GSA LLM-contractor rule — useful framing for interpreting the response.
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?
Front-loaded with the core purpose in the first clause, followed by qualifying detail. It runs four dense sentences with regulatory jargon and ALL-CAPS emphasis, which is heavier than needed, but each sentence carries distinct content (purpose, provenance mechanism, scope claims, usage triggers) rather than 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?
With no output schema, the description carries the burden of conveying what comes back, and it does — provenance chain-of-custody details, US-source status, no PII ingest, no model training, regulatory scope. An agent knows what this call yields. Minor gap: it does not state the response form (structured doc vs. prose).
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 takes zero parameters (empty object schema, 100% coverage), so the baseline of 4 applies. The description adds no parameter guidance, but none is needed for a no-arg posture lookup.
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?
States a specific verb ('Return') and a specific resource ('JYOTINT's data-handling, PROVENANCE & governance posture'), then frames it as the answer to a concrete question ('is this source safe to read / cite / ingest?'). No sibling tool in the list covers governance/compliance posture, so the definition is self-differentiating.
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?
Ends with an explicit trigger list: 'Use for compliance / data-handling / provenance / can I trust this source questions.' This gives a clear when-to-use context, though it names no alternative tool and gives no when-not-to-use exclusion (e.g. versus get_calibration_and_integrity or search_sealed_forecasts).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Information Yield (IY) — how much a confirmed call should move a skeptic's belief, in BITS of surprise-if-true (log2 of the published 1-in-N prior, capped at 1-in-a-million; earned = surprise × verdict-credit). A base rate / consensus-follower scores ZERO bits by construction — the metric on which the 'a base rate ties the Brier' objection inverts. Returns the corpus summary (LIVE median bits/call + %earned — read the numbers from the response, never from this description), the launch/intel/combined domain split, and the count. Pass an optional id for one call's bits.
| Name | Required | Description | Default |
|---|---|---|---|
| id | No | Optional advisory id (e.g. 'LA-022') for one call's IY. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, non-destructive), so the bar is lower; the description still adds real context by enumerating the return payload and warning the agent to read numbers from the response rather than the description. It discloses no rate limits or freshness caveats beyond that, 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 purpose is front-loaded, but a large share of the text is conceptual/marketing framing ('how much a confirmed call should move a skeptic's belief', 'the metric on which the base rate ties the Brier objection inverts') rather than task guidance. The parenthetical formula and polemic are dense and only partially earn their place.
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 describe the return value — and it does, naming the summary components, the domain split, and the count. Combined with the optional-id behavior, an agent has enough to call and interpret the tool, though the interpretation of each number is left implicit.
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 single id parameter is already documented, so the baseline is 3. The description adds the meaningful behavioral detail that supplying the id switches output to that one call's bits, which is slightly better than nothing, but it offers no format constraints beyond the schema's own example.
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 resource and what it returns: a corpus summary (median bits/call, %earned), a launch/intel/combined domain split, and a count, plus a per-call mode when an id is passed. It's a clear metric tool. It does not, however, distinguish itself from metric-adjacent siblings like get_calibration_and_integrity or get_luck_test, so it stops short of a 5.
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 implies the two usage modes ('Pass an optional id for one call's bits' vs. the default corpus summary), so an agent can infer how to invoke it. But there is no explicit when-to-use/when-not guidance and no routing to alternative siblings for related metric questions, leaving the selection decision to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The corpus-level 'could this record be luck?' significance test, computed AGAINST the record: EVERY graded call clustered into independent events (correlated calls share one event; live counts ship in the response), strict scoring (one NEAR fails the whole event), luck-prior floored at a coin flip per event. Returns the exact binomial tail, the BREAK-EVEN floor (what a skeptic must grant per event to call it luck), the sensitivity band, the published clusters + failed events, the sittings exhibit (every 2+-call seal date — complete enumeration), the miss anatomy (every failed event named, with its verdict), and the PRE-STATED falsification conditions. Caveats ship in the same object — quote them with the numbers. Measures improbability-of-luck, never calibration skill (the aggregate Brier's base-rate tie stays disclosed).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), and the description adds substantial context beyond that: clustering rules, strict one-NEAR-fails scoring, the luck-prior floor, and the fact that caveats ship in the same response object and must be quoted with the numbers. It omits any note on cost, latency, or invocation constraints, keeping it short of 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 purpose is front-loaded, which is good, but the body is a single sprawling run-on paragraph packing in break-even floors, sensitivity bands, sittings exhibits, and miss anatomy with heavy capitalization and coined jargon. Every clause does carry content, so it is not filler, but the structure makes it hard to parse quickly.
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 zero parameters and no output schema, the description carries the full burden of explaining returns, and it does so thoroughly — binomial tail, break-even floor, sensitivity band, clusters, failed events, sittings exhibit, falsification conditions, and shipped caveats. It is nearly complete for a no-arg analytical tool, missing only invocation-level details like auth or rate limits.
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 takes zero parameters, so there is no parameter semantics to document and the baseline of 4 applies. The description correctly avoids inventing parameters and instead spends its budget on output semantics.
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?
Names a specific verb and resource — the corpus-level 'could this record be luck?' significance test computed against the record — and explicitly distinguishes it from calibration measurement, which routes agents away from the get_calibration_and_integrity sibling. However, the dense jargon-heavy framing buries the plain 'what it does' statement, so it is clear but not instantly scannable.
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 closing clause 'Measures improbability-of-luck, never calibration skill' implicitly tells the agent to use get_calibration_and_integrity for calibration, which is a useful routing hint. But there is no explicit when-to-use guidance, no prerequisites, and no statement of when this tool is the wrong choice beyond that one negative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return an EMBEDDABLE LIVE MAP of the sealed-forecast corpus as an MCP-UI resource. Clients that can render UI resources (mcp-ui) should display it inline — it is the actual interactive JYOTINT theater map (sealed forecasts plotted by region; each pin carries its verbatim claim, grade, sealed probability, and a click-through to the full sealed record so the user can verify and score it themselves). Use this when a user asks to see, visualize, or explore JYOTINT's forecasts on a map.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover safety (readOnly, idempotent, non-destructive, closed-world), so the description correctly spends its words on what annotations cannot express: the result is an MCP-UI resource that requires a UI-capable client to render inline, and it discloses the pin payload (verbatim claim, grade, sealed probability, click-through to the full sealed record). It stops short of stating fallback behavior for non-UI clients.
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?
Three sentences, front-loaded with the return value before the rendering caveat and the use trigger. The heavy parenthetical and capitalized 'EMBEDDABLE LIVE MAP' / 'JYOTINT theater map' add some marketing bulk, but every sentence still carries information an agent needs.
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 and no parameters, the description must explain the return value, and it does — resource type, renderability requirement, and pin contents. Missing only edge behavior for clients that cannot render mcp-ui resources, which is a minor gap for this tool.
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 takes zero parameters, so the schema carries no semantics to compensate for; baseline for a no-parameter tool is 4. The description adds nothing parameter-related, but nothing is needed.
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?
Starts with a specific verb and resource ('Return an EMBEDDABLE LIVE MAP of the sealed-forecast corpus') and clarifies the delivery form (MCP-UI resource), which cleanly separates it from data-returning siblings like search_sealed_forecasts or list_open_calls. An agent can tell what this produces without opening anything else.
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?
Ends with an explicit trigger: 'Use this when a user asks to see, visualize, or explore JYOTINT's forecasts on a map.' That is a clear use condition, but it does not name or exclude alternatives (e.g., when to prefer search_sealed_forecasts or the raw record view instead).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The grade-it-yourself kit: inputs to recompute the record's Brier (calibration), named-mechanism specificity, AND Information Yield under YOUR OWN verdicts — plus the one-step stress-test recipes (harsh-verdicts, externally-adjudicated-only, estimative-worst-case, …). Each call carries its verbatim claim/outcome, the operator's p + verdict to override, and the surprise_bits / 1-in-N inputs. A base rate scores 0 on specificity and 0 bits on IY. Pass an optional id for one call's row; omit for the recipes + usage + count.
| Name | Required | Description | Default |
|---|---|---|---|
| id | No | Optional advisory id for one call's regrade row. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the bar is lower, and the description adds real operational context: what inputs accompany each call, the base-rate scoring rule (0 specificity, 0 IY bits), and how output shape changes with/without id. What is missing is any note on authorization prerequisites or output size for the recipe set.
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 content is compact for how much it covers, but it is one run-on block saturated with em dashes, capitalized jargon, and an ellipsis list that obscures the priority order. The most decision-relevant fact for an agent (id vs no-id behavior) is buried at the very end rather than front-loaded.
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 one-parameter read tool with no output schema, the description does the needed work: it lists the returned artifacts, the stress-test recipes, and the alternate mode when id is omitted. Only minor gaps remain, such as how large the recipe payload is or what the verdict-override input format looks like.
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 there is only one optional string param, so the baseline is already 3. The description adds meaning beyond the schema by explaining that omitting id yields the recipes plus usage and count, i.e. it clarifies the semantic consequence of the parameter rather than just restating it.
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?
Names a concrete deliverable (a 'grade-it-yourself kit') and enumerates exactly what it returns: Brier/calibration inputs, specificity, Information Yield under the caller's own verdicts, plus stress-test recipes. It implicitly differentiates from siblings get_calibration_and_integrity and get_information_yield via the 'YOUR OWN verdicts' override framing, though it never names those siblings explicitly. Heavy domain jargon makes the purpose slower to grasp than it needs to be.
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?
Gives clear parameter-branching guidance ('Pass an optional id for one call's row; omit for the recipes + usage + count'), which tells the agent how the two invocation modes differ. However, it never states when to reach for this tool instead of get_calibration_and_integrity or get_information_yield, and the 'under YOUR OWN verdicts' distinction is left for the agent to infer.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The 'before-the-event' indications-and-warning / after-action timeline for a named event, by advisory id (e.g. 'LA-022') or slug (e.g. 'new-glenn-ng3', 'crocus'). A neutral chronology: the official/authoritative source named FIRST, then the dated, hash-anchored JYOTINT sealed call as one independently-verifiable entry, with what it does and does not establish. Use for 'what dated public warnings preceded [event]'. Omit id to list every available timeline.
| Name | Required | Description | Default |
|---|---|---|---|
| id | No | Advisory id or timeline slug. Omit to list all. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, openWorldHint=false, destructiveHint=false. The description adds useful behavioral context beyond annotations: it describes the structure of the timeline (official source first, then sealed call), the neutrality stance, and that it lists all timelined when id is omitted. It doesn't describe pagination or output format, but with annotations covering safety profile, this is above average.
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, dense sentence with nested clauses and parenthetical examples. It is not front-loaded; the core function ('timeline for a named event') is buried after a stylized preamble. It could be split into clearer sentences, reducing cognitive load.
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 it's a read-only, single-parameter tool with full schema coverage and no output schema, the description covers what it returns (chronology with official source and sealed call) and how to use it. It lacks explicit output structure details, but enough for an agent to 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?
Schema description coverage is 100% and the description clarifies that omitting id lists all, which maps to the schema 'Omit to list all'. It adds little beyond the schema, but baseline 3 is appropriate when schema fully documents the 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+resource ('timeline for a named event') and gives concrete id examples ('LA-022', 'new-glenn-ng3', 'crocus'), which is clear. However, it's verbose and stylized ('before-the-event' indications-and-warning / after-action timeline) and doesn't explicitly differentiate from siblings like get_advisory, which also seems event-related. The core purpose is understandable but not sharply distinguished.
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 gives a clear use case ('Use for what dated public warnings preceded [event]') and tells the agent to omit id to list all. This is concrete guidance, but it doesn't explicitly name an alternative tool or say when NOT to use this (e.g., versus get_advisory). Mild gap, but usage context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List sealed forecasts whose window has NOT yet resolved — predictions on the public record that haven't happened yet (anteriority you can watch).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered without description help. The description adds the semantic constraint that only unresolved windows are returned, but says nothing about ordering, pagination, result count, or how 'sealed' resolution is determined. Modest added value against an already-complete annotation set.
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 leads with the action and the scope. The parenthetical 'predictions on the public record that haven't happened yet' largely restates the preceding clause, and '(anteriority you can watch)' is atmospheric rather than informative, so it is efficient but not maximally tight.
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 parameters, no output schema, and full annotation coverage, the description supplies the core semantics of what set is returned. It stops short of describing return shape, ordering, or how many entries to expect, which an agent listing results would reasonably want, but nothing critical for 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?
The tool takes zero parameters, so there is no parameter semantics for the description to carry; the baseline for a no-parameter tool is 4. The description correctly introduces no phantom inputs or filtering options that would need documenting.
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 gives a specific verb+resource pair: 'List sealed forecasts whose window has NOT yet resolved', and the scoping clause (unresolved window) implicitly differentiates it from the sibling search_sealed_forecasts. However, it never names or contrasts with that sibling, so an agent must infer the boundary. Clear but not sibling-differentiated by explicit reference.
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 by the filter definition — you call this when you want unresolved/public-record forecasts rather than resolved ones — but there is no explicit 'use this instead of X when Y', no exclusions, and no mention of when the sibling search_sealed_forecasts is preferable. Implied context only.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
SEMANTIC + ASSOCIATIVE search over the public sealed record and the published site corpus — the JYOTINT public brain (a neural associative memory: frozen deep encoder → Hopfield pattern completion → spreading activation over typed synapses → k-winners-take-all). Finds calls by MEANING, not keywords ('upper-stage anomalies' finds the calls that describe one without those words) and returns the RELATED subgraph, not just isolated hits. Retrieval-only and non-generative: every result is VERBATIM sealed/published text with public provenance (source URL, SHA-256 seal hash, frozen grade) plus an explainable why/activation path and Hopfield convergence info. Prefer this over search_sealed_forecasts for fuzzy/conceptual queries; the REST twin is GET /brain?q=…
| Name | Required | Description | Default |
|---|---|---|---|
| k | No | Max results, 1–12 (default 6). | |
| query | Yes | Natural-language query (e.g. 'what did the record say before the Crocus attack', 'upper stage anomaly calls'). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), and the description goes well beyond them: retrieval-only and non-generative, every result is verbatim sealed/published text, provenance fields (source URL, SHA-256 seal hash, frozen grade), plus explainable activation path and Hopfield convergence info. This is rich behavioral context not present in the structured fields.
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?
Front-loaded with purpose and the sibling contrast, and every clause is relevant (mechanism, examples, provenance, REST twin). It is dense and long, with heavy parenthetical mechanism detail, but not padded with 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?
The description explains what comes back (verbatim text with provenance, why/activation path, convergence), compensating for the absent output schema, and the annotations cover safety. For a 2-param read tool it is largely complete, though the lengthy mechanism explanation is more than an agent strictly needs to call 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% (both query and k documented in-schema), so the baseline is 3. The description adds flavor about query semantics via examples, but adds no syntax, format, or constraint detail beyond what the schema already provides.
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?
States a specific verb+resource: semantic/associative search over the sealed record and published corpus, with the retrieval mechanism spelled out. It explicitly names the sibling it is not (search_sealed_forecasts) and characterizes its output (related subgraph, not isolated hits), so an agent can distinguish it without opening either schema.
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?
Gives an explicit alternative and the condition that selects it: 'Prefer this over search_sealed_forecasts for fuzzy/conceptual queries.' It also provides a concrete query example ('upper-stage anomalies' finds calls describing one without those words), making the when-to-use boundary unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the JYOTINT sealed-forecast corpus (Bitcoin-anchored, dated-before-the-event predictions) by free text across id, title, and the verbatim sealed claim. Returns matching records with their grade, sealed probability, seal date, source artifact, and SHA-256 seal hash. For fuzzy or conceptual queries, use neural_search (finds calls by MEANING; REST twin GET /brain?q=…).
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max results (default 10). | |
| query | Yes | Free-text query (e.g. 'Crocus', 'NISAR', 'Brazil election', 'recession'). | |
| graded_only | No | Restrict to graded (Brier) records. Default false. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds value beyond that by enumerating the returned fields (grade, sealed probability, seal date, source artifact, SHA-256 seal hash) and pointing to the REST twin, which is useful since no output schema exists. It stops short of describing pagination or ordering behavior.
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 tight sentences: the first front-loads what and where it searches, the second handles output shape and the alternative tool. No filler or restatement of the name.
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 compensates by naming the return fields, and the search surface plus the neural_search escape hatch cover the decision an agent must make. Nothing essential to calling it correctly 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?
Schema description coverage is 100%, so limit, query, and graded_only are already documented in the schema. The description adds only a light gloss on what the free-text query matches against, which is helpful but not meaningfully beyond the structured fields — the 3 baseline 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?
States a specific verb (Search) and resource (JYOTINT sealed-forecast corpus), and explicitly scopes the search surface to id, title, and the verbatim sealed claim. It also names the sibling it is not suited for (neural_search), so an agent can distinguish it without opening any schema.
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 an explicit when-not rule: 'For fuzzy or conceptual queries, use neural_search.' That routes the agent to the correct alternative and states the condition that selects it, with no inference required.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
neural_searchask_the_recordget_advisoryget_calibration_and_integrityget_corpus_insightsget_governanceget_information_yieldget_luck_testget_mapget_regrade_kitget_warning_timelinelist_open_callssearch_sealed_forecastsSealed prediction-market verdicts, graded in public across Polymarket and Kalshi. No auth required.
Cited Bitcoin coordination record search (~783k). Lightning. MCP. Not prices/chain analytics.
Deterministic crypto futures, on-chain risk, and prediction-market math. 32 tools. Not AI estimates.
Forecast future events and scan prediction-market edges.
Add one secure layer between your agents and this server.
