Bitcoin-anchored sealed-forecast record: search, grades, calibration, luck test. Read-only, no key.
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Average 4/5 across 13 of 13 tools scored. Lowest: 2.2/5.
Most tools have clearly distinct purposes (fetch one forecast vs. list open calls vs. search), but neural_search and search_sealed_forecasts both retrieve from the same corpus, and ask_the_record overlaps slightly with neural_search for site-copy questions. Descriptions mitigate ambiguity, but a few boundaries require careful reading.
The dominant pattern is get_<noun> (get_advisory, get_map, get_luck_test), with list_open_calls, search_sealed_forecasts, ask_the_record, and neural_search as deviations. All names are lowercase snake_case and readable, but the verb prefixes are not perfectly uniform.
With 13 tools, the server is well-scoped for a specialized sealed-forecast corpus. Each tool addresses a distinct analytical or retrieval need, and the count fits comfortably in the ideal range without feeling bloated or thin.
The tool surface covers the full lifecycle of interacting with the corpus: search, retrieve, list, inspect stats, verify integrity, regrade, visualize, and ask questions. The append-only nature means no update/delete tools are needed, so the set is complete for its stated purpose.
ask_the_recordAInspectAsk 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?
No annotations are provided, so the description fully discloses behavioral traits: it returns verbatim passages (never generated/paraphrased), cites source pages, and reports lack of matches truthfully. It does not cover authorization or rate limits, but for a read-only tool, this is sufficient.
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 paragraph that packs essential information: purpose, behavior, usage guidance, and fallback behavior. It is front-loaded with the core action and adds necessary details without excessive verbosity. Minor redundancy exists but does not detract significantly.
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 no output schema, the description adequately explains the return format (verbatim passages with source citations) and fallback behavior. It covers the tool's scope and limitations, making it complete for a retrieval Q&A tool without needing an output schema.
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 'limit' have descriptions). The description adds minimal extra meaning beyond the schema: it reinforces that 'query' is natural language and 'limit' defaults to 3 with max 6. The baseline of 3 is appropriate given full schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies the tool's purpose: answering questions about JYOTINT by retrieving verbatim passages from the operator's published site copy. It distinguishes itself from sibling tools by emphasizing that outputs are never generated or paraphrased, preventing hallucination.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use the tool ('Prefer this for any 'what does JYOTINT say about X' / 'why' / 'how does it work' question'), including behavior when no match is found. It does not explicitly mention alternatives or when-not-to-use, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_advisoryAInspectFetch 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?
With no annotations, the description transparently discloses that the tool returns a full record including verbatim claim, grade, outcome, sources, and seal hash. It does not mention error handling or rate limits, but such omissions are minor for a simple fetch operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences efficiently convey the action, parameter, and return content. The first sentence front-loads the purpose, and the second lists return fields without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple one-parameter input and no output schema, the description fully compensates by detailing return fields. It provides sufficient information for an agent to understand the tool's inputs and outputs without missing context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already describes the 'id' parameter, but the description adds meaningful context by providing example formats and explaining that the id refers to a 'sealed forecast'. This additional semantic information improves parameter understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Fetch' and the resource 'one sealed forecast', with specific id format examples (e.g., 'IA-RU-008'). This distinctively identifies the tool's purpose versus siblings like search_sealed_forecasts or get_map.
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 guidance on when to use this tool versus alternatives. For instance, it doesn't mention that if you don't have an advisory id, you should use search_sealed_forecasts first. The description implies usage only when an id is available.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_calibration_and_integrityAInspectReturn 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?
With no annotations provided, the description fully discloses behavioral traits: the record is append-only, values change over time, and how to independently verify using hashes and Bitcoin block heights. This level of transparency is exceptional and compensates for the lack of 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 description is two sentences, front-loading the primary return values and then explaining the append-only behavior and record_versions utility. It is efficient but the second sentence is dense and could be slightly tighter. Still, it 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?
Given no output schema, the description lists all return components (calibration, integrity proof, record_versions) and explains how to interpret record_versions for resolving state discrepancies. This is comprehensive for the tool's purpose and complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, and schema coverage is 100% (vacuously). Per the guidelines, a baseline of 4 is appropriate. The description adds no param info, which is unnecessary since there are none.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies that the tool returns corpus calibration, integrity proof, and record_versions, detailing the exact components (Brier score, manifest hash, ledger hash, etc.). This distinguishes it from sibling tools like 'get_corpus_insights' or 'get_advisory' by focusing on calibration and verifiable proofs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains that record_versions resolves discrepancies when cited states no longer match live data, guiding the user on when to use the tool to get current state and verify past states. It does not explicitly list when not to use or alternatives, but the context is clear enough for an AI agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_corpus_insightsCInspectThe 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?
No annotations are provided, and the description does not disclose behavioral traits such as read-only, destructive nature, or access requirements. The cryptic language adds confusion rather than clarity.
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, poorly structured run-on sentence filled with jargon. It is not concise and does not front-load key information, making 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?
Given the lack of output schema and annotations, the description fails to explain the return format, usage context, or how an agent should interpret the results. It is completely inadequate for an AI agent to use effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so schema coverage is trivially 100%. With no parameters to describe, the baseline score of 4 is appropriate; the description does not detract from this dimension.
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 is a dense list of internal concepts (e.g., 'mechanism ledger', 'war read') without a clear verb-resource statement. It does not specify what action the tool performs or what the output is, leaving the purpose vague.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus siblings like 'ask_the_record' or 'get_advisory'. The description fails to provide context for appropriate invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_governanceAInspectReturn 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?
With no annotations, the description transparently discloses behavioral traits: chain-of-custody details, SHA-256 sealing, Bitcoin anchoring, confirmation of no government/PII data ingestion, and out of scope of GSA rule. Also notes it's descriptive, not a certification.
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 main purpose. Each sentence adds value, though slightly verbose. Could be trimmed without losing meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 0 parameters and no output schema, the description fully covers what the tool does and returns. Complete enough for an agent to understand.
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 and 100% schema coverage. The description adds no parameter info, but baseline is 4 since schema covers and no parameters require explanation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns JYOTINT's data-handling, provenance, and governance posture, answering 'is this source safe to read/cite/ingest?'. It distinguishes from siblings by focusing on trust and compliance.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states 'Use for compliance / data-handling / provenance / 'can I trust this source' questions', providing clear guidance. Lacks explicit when-not-to-use but context with siblings suffices.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_information_yieldBInspectInformation 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 (median ≈6.8 bits/call + %earned), 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?
No annotations provided, and the description does not explicitly state that the tool is read-only or disclose other behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is overly verbose with a lengthy definition of IY that could be shortened, making it less concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple input (one optional parameter) and lack of output schema, the description adequately describes what is returned, including specifics about corpus summary and domain splits.
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 description adds context to the optional 'id' parameter beyond the schema, explaining it retrieves bits for a single call.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states what the tool returns (corpus summary and optionally one call's bits), effectively conveying the purpose despite some verbose definition.
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 guidance on when to use this tool versus alternatives like get_corpus_insights or get_advisory.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_luck_testAInspectThe corpus-level 'could this record be luck?' significance test, computed AGAINST the record: 92 graded calls clustered into 68 independent events (correlated calls share one event), 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, 23/23), the miss anatomy (all 4 misses electoral, never a miss at >=0.90), 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?
With no annotations, the description fully discloses behavior: computation method (92 calls, 68 events), scoring strictness, luck-prior floor, exact return fields, caveats. It is exceptionally detailed about what the tool does and returns.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense and verbose, using many technical terms. It could be more concise by grouping related details or using bullet points. However, it starts with a clear main purpose sentence.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no parameters and no output schema, the description covers all necessary context: what is computed, what is returned, and even notes caveats. It leaves no ambiguity about the tool's functionality.
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?
Input schema has zero parameters, so baseline is 4. The description adds meaningful context about the computation but does not need to explain parameters as there are none.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource (corpus-level record) and action (significance test for luck). It uses specific language like 'binomial tail' and 'break-even floor' but does not explicitly differentiate from sibling tools like get_advisory or get_calibration.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives (e.g., ask_the_record, get_calibration_and_integrity). The description explains what it does but leaves the agent to infer the appropriate context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_mapAInspectReturn 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?
No annotations are provided, so the description carries the full burden. It explains the map is interactive, with pins containing claim, grade, probability, and a click-through. It implies a read-only, non-destructive action, and provides rich detail about the resource's 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?
The description is concise and front-loaded: it opens with the key action and resource type ('Return an EMBEDDABLE LIVE MAP'), then explains content and use case. Every sentence is necessary and no waste.
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?
Despite no output schema and zero parameters, the description fully explains the tool's return value (a live map resource), its contents (pin details), and when to use it. It is complete for a resource-returning 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 input schema has zero parameters, and schema coverage is trivially 100%. Per guidelines, 0 parameters yields a baseline of 4. The description does not need to add parameter information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns an embeddable live map of the sealed-forecast corpus as an MCP-UI resource, specifying it is interactive with pins. This distinguishes it from sibling tools, none of which provide map visualization.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use this when a user asks to see, visualize, or explore JYOTINT's forecasts on a map.' It does not provide when-not or alternative tools, but given no sibling map tool, the guidance is clear and sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_regrade_kitAInspectThe 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?
No annotations present, but the description details what each call returns (claim/outcome, p, verdict, surprise_bits, 1-in-N) and mentions base rate behavior. It does not cover authorization or side effects, but as a read-only 'kit', this is sufficient.
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 detailed but slightly verbose with multiple clauses. It front-loads the purpose and efficiently packs information, though a more structured list could improve readability.
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 no output schema and the tool's complexity, the description covers the input behavior, what each call carries, and base rate outcomes. It lacks details on output format but is reasonably complete for practical use.
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 description adds significant context to the single parameter 'id', explaining that omitting it yields recipes/usage/count while including it gives a specific call's row. This goes beyond the schema's minimal description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool provides inputs to recompute Brier, specificity, and Information Yield under custom verdicts, including stress-test recipes. It distinguishes from sibling tools like get_calibration_and_integrity which likely provide default calculations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives guidance on using the optional 'id' parameter (pass for one call's row, omit for recipes/usage/count). However, it does not explicitly compare to alternatives or state when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_warning_timelineAInspectThe '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?
Discloses that the timeline is neutral, with official source first, then JYOTINT sealed call, and mentions what it does and does not establish. Since no annotations exist, this is good transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is informative without being overly long, but could be slightly more concise. It front-loads the main purpose and then adds necessary details.
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?
Despite no output schema, the description explains the response structure (official source first, then hash-anchored call) and includes what entries do and don't establish. This is sufficient for a simple single-parameter 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?
Schema coverage is 100%, so baseline is 3. The description adds examples ('LA-022', 'new-glenn-ng3') and clarifies the id parameter accepts advisory id or slug, adding value beyond the schema description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves a 'before-the-event' or after-action timeline for a named event, using advisory id or slug. It uses specific verbs and resource, distinguishing it from siblings like get_advisory which provides the advisory text itself.
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 explicit usage: 'Use for what dated public warnings preceded [event]. Omit id to list every available timeline.' It gives context but doesn't explicitly state when not to use or mention alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_open_callsBInspectList 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?
With no annotations, the description carries full burden for behavioral traits. It describes what is listed (sealed forecasts not yet resolved) but fails to disclose factors like authentication, pagination, or result format. The poetic phrasing adds no actionable behavioral insight.
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 sentence, which is concise. However, it includes a somewhat verbose parenthetical explanation ('anteriority you can watch') that could be simplified. It front-loads the key action and resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (no parameters, no output schema, no annotations), the description provides a basic understanding of the result set. However, it omits important context like whether results are paginated, how to interpret 'window has NOT yet resolved', and whether there are any access restrictions. It is minimally adequate but has gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema coverage is trivially 100%. The description does not need to add meaning beyond the schema since there are no parameters to document. The baseline score of 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool lists sealed forecasts whose window hasn't resolved, using specific terms like 'sealed forecasts' and 'window has NOT yet resolved'. It effectively conveys the core purpose, though it doesn't explicitly differentiate from the sibling tool 'search_sealed_forecasts'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives, nor are there any prerequisites or exclusions mentioned. The description assumes the agent will infer the usage context without explicit direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
neural_searchAInspectSEMANTIC + 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?
With no annotations provided, the description carries the full burden. It discloses retrieval-only and non-generative behavior, verbatim result provenance (source URL, SHA-256 seal hash, frozen grade), explainable activation path, and Hopfield convergence information, offering substantial behavioral context beyond basic functionality.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the main purpose and is structured logically, but it includes some technical details (e.g., Hopfield stages) that are informative yet slightly verbose. Overall it earns its place with meaningful content, though it could be tightened.
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?
Despite lacking an output schema, the description fully explains what the tool returns: a related subgraph, verbatim text with provenance, activation path, and Hopfield convergence info. It also mentions the REST twin, making it complete for an agent to understand expected outputs and usage context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema describes both parameters (query and k) with examples and constraints, achieving 100% coverage. The description does not add extra parameter semantics beyond what the schema already provides, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'SEMANTIC + ASSOCIATIVE search over the public sealed record and the published site corpus' and explains the mechanism, clearly distinguishing it from sibling tools by indicating a preference over search_sealed_forecasts for fuzzy/conceptual queries.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidance by stating 'Prefer this over search_sealed_forecasts for fuzzy/conceptual queries' and explains that it finds by meaning rather than keywords, implying when not to use it (exact keyword queries).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_sealed_forecastsAInspectSearch 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It discloses what fields are searched, what data is returned (grade, sealed probability, seal date, source artifact, hash), and adds context about the corpus being Bitcoin-anchored and dated-before-the-event. It stops short of explicitly stating the operation is read-only or noting any side effects, but the read-only nature is strongly implied by 'search' and 'returns'.
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, zero fluff. It front-loads the primary action, then lists return fields, then gives an alternative with clear reasoning. Every sentence 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?
Given there is no output schema, the description compensates by listing the key return fields. It also provides necessary context about the corpus and points to an alternative tool. It does not mention pagination or default limit behavior, but the schema covers 'limit' and the tool's simplicity makes this acceptable. Overall, it is complete enough for a search 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 input schema has 100% coverage for all parameters, so the baseline is 3. The description adds extra value beyond the schema by specifying which fields the query searches (id, title, verbatim claim), giving semantic meaning to the query parameter. No additional info for 'limit' or 'graded_only', but the schema already describes those.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches a specific corpus (JYOTINT sealed-forecast) by free text across specific fields (id, title, verbatim claim). It also distinguishes itself from neural_search by contrasting exact text search with fuzzy/conceptual search, fully clarifying its purpose.
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 directs users to neural_search for fuzzy or conceptual queries, providing a clear alternative and the criterion for choosing between the two. This tells the user when to use this tool and when not to, making it highly actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!