Bitcoin-anchored sealed-forecast record: search, grades, calibration, luck test. Read-only, no key.
Scored across 13 tools
Most tools target distinct operations: individual record lookup, open-call listing, keyword vs neural search, map, governance, timeline, and site-record Q&A. The main overlap is among the analytical/verification tools (calibration/integrity, corpus insights, information yield, luck test, regrade kit), but their descriptions provide enough discriminating cues for most agent queries.
Nine of thirteen tools use a predictable get_* pattern, and list_open_calls and search_sealed_forecasts follow a clear verb_noun style. The deviations—neural_search (adjective_noun) and ask_the_record (imperative phrase)—are readable but keep the naming from being fully uniform.
Thirteen tools is well-scoped for a read-only forecast corpus with retrieval, search, calibration, provenance, governance, visualization, and regrade needs. Each tool appears to earn its place rather than bloating the surface.
The server covers the full read-only lifecycle: discovery (list/search/neural/map), retrieval (advisory, warning timeline), verification (calibration/integrity, seal hashes), interpretation (insights, information yield, luck test, regrade kit), and governance. No create/update/delete is expected for a sealed public record, and no obvious dead ends are apparent.
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. | |
| sensitivity | No | Recall/precision posture (default balanced). high_recall: miss nothing, accept noise — a planner inside a live window. high_precision: only hits that clear the similarity floor, the rest reported under `withheld` — an office quoting the record outward. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish read-only, idempotent, non-destructive, closed-world behavior. The description adds meaningful value beyond that: sources are cited per passage, and on no-match it reports that rather than inventing, plus an instruction to quote and attribute. It says little about latency or corpus scope limits, but the behavior story is largely 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 purpose is front-loaded and the no-hallucination guarantee is stated early, but the middle is padded with promotional framing ('This is the operator answering in his own words') and a long enumerative list (method, doctrine, the five pillars...) that adds little selectability signal.
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 cover returns — and it does: verbatim passages, per-passage source citations, withheld/no-match behavior. Combined with the annotation-covered safety profile, an agent has enough to call this correctly, though corpus boundaries remain fuzzy.
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 sensitivity enum is documented in the schema itself, so the schema carries parameter meaning. The description adds no syntax or default guidance beyond what the schema already provides, so the 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?
States a specific verb+resource: ask a natural-language question about JYOTINT and get back verbatim source passages, with an explicit contrast to generated/paraphrased content. However it never names the sibling it most resembles (neural_search, get_corpus_insights), so differentiation from siblings is left 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?
Gives clear triggering context ('what does JYOTINT say about X' / 'why' / 'how does it work') and the word 'prefer' signals it should be chosen over something else. It stops short of naming the alternatives or stating when-not to use it.
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'). | |
| sensitivity | No | Recall/precision posture (default balanced). high_recall: miss nothing, accept noise — a planner inside a live window. high_precision: only hits that clear the similarity floor, the rest reported under `withheld` — an office quoting the record outward. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only/idempotent/non-destructive safety, but the description adds substantial behavioral detail: retrieval-only and non-generative, verbatim text with public provenance, explainable activation paths, and convergence info. It does not contradict the annotations.
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 and routing guidance are front-loaded and the description is well-structured despite being dense. The parenthetical neural mechanism is somewhat elaborate, but it supports behavioral transparency rather than being pure 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 complex retrieval tool with no output schema, the description explains what results contain (verbatim text, provenance, activation path, convergence), how it differs from siblings, and what safety profile the annotations already guarantee. Nothing essential for correct selection or 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?
Schema description coverage is 100%, so the schema already documents query, k, and sensitivity including enum meanings. The description does not add meaningfully beyond the schema for any parameter, making the baseline 3 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?
States a specific search verb and scope: semantic/associative search over the public sealed record and published site corpus. It distinguishes itself explicitly from search_sealed_forecasts and explains the meaning-based retrieval behavior with a concrete example.
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?
Names the alternative search_sealed_forecasts and gives the condition that selects this tool: fuzzy/conceptual queries. It also provides the REST twin endpoint and enough context about sensitivity postures to guide invocation.
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. | |
| sensitivity | No | Recall/precision posture (default balanced). high_recall: miss nothing, accept noise — a planner inside a live window. high_precision: only hits that clear the similarity floor, the rest reported under `withheld` — an office quoting the record outward. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint/idempotent/non-destructive, so the bar is low, and the description adds real substance beyond them: the returned fields (grade, sealed probability, seal date, source artifact, SHA-256 seal hash) and the `withheld` behavior under high_precision sensitivity. Minor gap: no note on pagination or result ordering.
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, each earning its place, with the core purpose front-loaded and the alternative route at the end. The parenthetical about the REST twin is slightly extra but still informative.
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, but the description compensates by listing the key return fields. Combined with explicit alternative routing and annotation-covered safety, an agent has nearly everything needed; only pagination/ordering behavior is unstated.
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 baseline is 3, but the description adds meaning the schema does not: which fields the `query` actually matches against (id, title, verbatim claim). That scope detail is genuinely useful for forming a query.
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 (the JYOTINT sealed-forecast corpus) plus the exact fields scanned (id, title, verbatim sealed claim), and it names the sibling it is not (neural_search for meaning-based lookups). An agent can distinguish it from neural_search 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?
Explicitly routes fuzzy/conceptual queries to neural_search and even names its REST twin (GET /brain?q=…), while this tool handles free-text literal matching. The when-to-use-this-vs-alternative decision is fully stated.
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.
ask_the_record1 field changedInput schema / properties / sensitivityAdded value: +{
+ "description": "Recall/precision posture (default balanced). high_recall: miss nothing, accept noise — a planner inside a live window. high_precision: only hits that clear the similarity floor, the rest reported under `withheld` — an office quoting the record outward.",
+ "enum": [
+ "high_recall",
+ "balanced",
+ "high_precision"
+ ],
+ "type": "string"
+}neural_search1 field changedInput schema / properties / sensitivityAdded value: +{
+ "description": "Recall/precision posture (default balanced). high_recall: miss nothing, accept noise — a planner inside a live window. high_precision: only hits that clear the similarity floor, the rest reported under `withheld` — an office quoting the record outward.",
+ "enum": [
+ "high_recall",
+ "balanced",
+ "high_precision"
+ ],
+ "type": "string"
+}search_sealed_forecasts1 field changedInput schema / properties / sensitivityAdded value: +{
+ "description": "Recall/precision posture (default balanced). high_recall: miss nothing, accept noise — a planner inside a live window. high_precision: only hits that clear the similarity floor, the rest reported under `withheld` — an office quoting the record outward.",
+ "enum": [
+ "high_recall",
+ "balanced",
+ "high_precision"
+ ],
+ "type": "string"
+}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.
Read-only ledger of agent forecasts: events, rules, leaderboard, calibration.
Score, seal and prove any AI decision, timestamped into Bitcoin - checkable by anyone.
Signed, Bitcoin-anchored observations of AI training-data disclosure; verifies silence proofs, seals
Add one secure layer between your agents and this server.
