JYOTINT Sealed Forecasts
Server Details
Bitcoin-anchored sealed-forecast record: search, grades, calibration, luck test. Read-only, no key.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
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.
Tool Definition Quality
Average 3.9/5 across 12 of 12 tools scored. Lowest: 2.3/5.
Each tool has a clearly distinct purpose: ask_the_record for Q&A on site copy, get_advisory for individual forecast, get_calibration_and_integrity for scoring/verification, get_corpus_insights for deep analysis, get_governance for compliance, get_information_yield for bits metric, get_luck_test for statistical test, get_map for visualization, get_regrade_kit for recomputation, get_warning_timeline for chronology, list_open_calls for unresolved forecasts, and search_sealed_forecasts for text search. No significant overlap.
Nine tools use the 'get_' prefix (get_advisory, get_calibration_and_integrity, etc.), but three use other verbs: ask_the_record, list_open_calls, and search_sealed_forecasts. While not fully uniform, the names are still clear and follow a predictable pattern for their action type. Minor deviation prevents a 5.
With 12 tools, the server is well-scoped for its purpose. It covers individual forecast retrieval, corpus analysis, statistical tests, compliance, visualization, and search. No tool feels redundant or missing; the count is appropriate for the specialized domain.
The tool surface is comprehensive for a read-only forecast archive. It includes search, list, retrieval, integrity verification, statistical analysis, governance, map visualization, and a Q&A tool. There are no obvious gaps; core workflows (finding, verifying, understanding forecasts) are fully supported.
Available Tools
12 toolsask_the_recordAInspect
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. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully bears the burden of behavioral disclosure. It states the tool never generates, paraphrases, or hallucinates; returns verbatim passages with source citations; and says so if no match exists. This is thorough and honest.
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 four sentences long, front-loaded with the core purpose and key traits. It is efficient but could be slightly more concise; 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?
No output schema is provided, but the description explains the return format (verbatim passages with source citations) and behavior (no hallucination, says if no match). Given the tool's complexity (free-text query, retrieval), the description is fully adequate.
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 parameters described in schema), so baseline is 3. The description adds context that the query should be in natural language and the limit defaults to 3, max 6. This adds some value but does not significantly extend beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool answers questions about JYOTINT/Vijay Jyotish by returning verbatim passages from the operator's site, distinguishing it from generated or paraphrased responses. It specifies the resource and action.
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 this tool: 'for any 'what does JYOTINT say about X' / 'why' / 'how does it work' question.' It also explains behavior when no match is found. However, it does not explicitly mention when not to use or list alternatives among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_advisoryAInspect
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. |
Tool Definition Quality
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 states the tool returns data (a read operation), but does not disclose potential side effects, error handling, or authentication needs. The description is adequate for a simple fetch tool.
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 that conveys purpose, parameter format, and return content without waste. Every phrase adds value.
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 one parameter and no output schema, the description covers purpose, parameter format examples, and return fields. It is mostly complete, though it lacks mention of error handling for non-existent IDs.
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 describes 'id' as 'Advisory id.' The description adds concrete examples ('IA-RU-008', 'LA-011', 'IA-MKT-002'), which clarifies the expected format 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 uses a specific verb ('Fetch') and resource ('sealed forecast by its id'), provides example IDs, and lists specific return fields. This clearly distinguishes it from sibling tools like 'search_sealed_forecasts' which returns multiple records.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when you have a specific advisory ID, but does not explicitly state when to use this tool over alternatives like 'search_sealed_forecasts'. No when-not or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_calibration_and_integrityAInspect
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).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, description carries full burden. It indicates a read operation ("return") but does not explicitly state it is non-destructive or side-effect-free. Lists return components but no behavioral traits like rate limits or required permissions.
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?
Single sentence, front-loaded with purpose, and every phrase adds value. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters and no output schema, description adequately covers output components. Could be slightly more detailed about the verification instructions format, but overall sufficient for a simple getter.
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?
No parameters exist, so schema coverage is 100% trivially. Description adds full meaning by explaining what the return contains, fulfilling the role of parameter semantics by describing the tool's output.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it returns corpus calibration and integrity proof, listing specific components (Brier score, counts, hashes, Bitcoin block heights, verification instructions). This differentiates it from sibling tools like get_corpus_insights or get_governance.
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. Does not specify prerequisites, exclusions, or context where this tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_corpus_insightsCInspect
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 | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must convey behavioral traits. It mentions caveats but lacks details on side effects, authentication needs, data freshness, or performance implications. The mention of 'Caveats ship in the same object' hints at transparency but is insufficient.
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 run-on sentence listing many items in an unstructured manner. It is not front-loaded and is difficult to parse, lacking conciseness.
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 complexity of the tool (multiple insight types) and lack of output schema, the description fails to comprehensively explain the return format. The list of items is ambiguous and incomplete for an agent to understand the full output.
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?
No parameters exist in the input schema, and schema description coverage is 100% (trivially). Baseline for zero parameters is 4, and 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 attempts to define the tool's output as 'deep-pass signature findings' over the full corpus, but the phrasing is overly technical and vague. It does not clearly state a specific verb and resource, nor does it distinguish from similar sibling tools like get_calibration_and_integrity or get_advisory.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description only lists contents without any contextual direction for usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_governanceAInspect
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 | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully covers behavioral traits: stateless read operation, disclosure (not certification), data source details (US, no PII), and provenance mechanisms (SHA-256, Bitcoin-anchored). It doesn't explicitly state no side effects, but it's implied. Minor gap: no mention of response format.
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 efficiently front-loaded with the main purpose, but the subsequent technical details (chain-of-custody, SHA-256) are dense. Every sentence adds value, though slight condensation 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, the description thoroughly explains what is returned (governance posture details). It covers key aspects: compliance, provenance, data sourcing, and scope. However, it doesn't address potential overlaps with sibling tools like get_advisory.
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?
There are zero parameters with 100% schema coverage, so the baseline is 4. The description adds no extra parameter info because none 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?
The description clearly states the tool returns JYOTINT's data-handling, provenance, and governance posture, answering 'is this source safe?'. It uses a specific verb and resource, and the detailed content distinguishes it from sibling tools like get_calibration_and_integrity by focusing on governance rather than 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?
The description explicitly recommends use for compliance, data-handling, provenance, and trust questions. However, it does not specify when not to use this tool or suggest alternatives if the user needs, say, a certification instead of a disclosure.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_information_yieldAInspect
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 (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. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses that the tool returns a corpus summary with median, %earned, domain split, and count, and optionally a call's bits. However, it does not mention safety (read-only), authorization needs, or side effects, leaving behavioral traits partially transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single long sentence containing a dense technical definition of Information Yield, followed by a brief listing of return components. While not overly long, it could be more front-loaded with the action and return structure, reducing the conceptual 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?
No output schema exists, so description must explain return values. It does so by listing median bits, %earned, domain split, and count. Given the tool's complexity (custom metric), this is largely complete, though exact structural details (e.g., keys, types) are omitted.
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?
Only one optional parameter 'id' with schema description 'Optional advisory id (e.g. 'LA-022') for one call's IY.' The tool description adds value by clarifying that passing an id retrieves 'one call's bits', which goes beyond the schema's generic description. Schema coverage is 100%, so baseline is 3; description adds meaning, hence 4.
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 corpus summary of Information Yield metrics and optionally a single call's bits. It uses specific verb 'get' and resource 'information yield', and distinctly stands out from sibling tools which deal with other metrics like calibration, map, governance, etc.
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. Sibling tools exist but the description does not differentiate usage contexts or provide when-not criteria. The user is left to infer from the tool's purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_luck_testAInspect
The 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 | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description provides comprehensive behavioral details: exact binomial tail, break-even floor, sensitivity band, clusters, miss anatomy, falsification conditions, and caveats. It also clarifies what the tool measures (improbability-of-luck, not calibration skill).
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, dense paragraph that could benefit from structuring (e.g., bullet points). While information-dense, it is not concise; every sentence adds value but the length reduces 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 the complex mathematical nature and absence of an output schema, the description covers all return components. However, it could be more approachable with clearer organization.
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 the description need not explain them. It adds context about the data used (92 graded calls, etc.), which is helpful but not required. Baseline 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 clearly states the tool performs a corpus-level luck significance test, listing specific computations and outputs. It distinguishes from sibling tools like get_calibration_and_integrity by focusing solely on luck hypothesis testing.
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. The description implies its use for luck testing but lacks direct comparisons or exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_mapAInspect
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 | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It explains the tool returns a live interactive map resource, implying a read-only operation with no side effects. It further details what the map displays (pins, claims, grades, etc.), providing sufficient behavioral context for an agent.
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 that front-loads the key action and then details the content. It is informative but somewhat long; could be slightly more concise, but the structure is effective.
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 parameters and a simple output (an MCP-UI resource), the description is comprehensive. It explains what the map shows, when to use it, and notes that clip-through allows verification. No output schema exists, but the return value is described adequately.
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 no parameters and schema coverage is 100%. With zero parameters, the baseline is 4. The description adds meaning by explaining the returned resource type and content, but there is no parameter info 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?
The description clearly states the tool returns an embeddable live map of the sealed-forecast corpus as an MCP-UI resource. It specifies the verb 'Return', the resource type, and the content (interactive map with pins, claims, grades, etc.). Among sibling tools, none are about maps, so it is well-differentiated.
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: 'Use this when a user asks to see, visualize, or explore JYOTINT's forecasts on a map.' This clearly indicates use cases. It does not explicitly mention when not to use it, but the context is sufficient given no alternative map tools exist.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_regrade_kitAInspect
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. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses that the kit includes verbatim claim/outcome, operator's p+verdict override, surprise_bits/1-in-N inputs, and explains base rate behavior (scores 0). It also mentions stress-test recipes. Missing auth or error details, but still informative.
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 includes many details, which is informative but could be more concise. It front-loads the core purpose ('The grade-it-yourself kit') but then lists components without clear structuring. Some sentences could be combined or removed.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (recomputations, recipes), no output schema, and only one optional parameter, the description covers key aspects: what it returns, base rate handling, and parameter behavior. It lacks error handling or return format but is sufficient for basic usage.
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% with 1 optional parameter. The description adds meaning beyond the schema by explaining the 'id' parameter is for a single call's row and describing behavior when omitted (returns recipes, usage, count). This helps the agent understand the parameter's effect.
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 user's verdicts, plus stress-test recipes. It specifies verb+resource ('grade-it-yourself kit') and distinguishes from siblings like get_calibration_and_integrity and get_information_yield by emphasizing user-supplied verdicts and recipes.
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 includes usage guidance: 'Pass an optional id for one call's row; omit for the recipes + usage + count.' However, it does not explicitly state when to use this tool vs alternatives like get_calibration_and_integrity, leaving 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.
get_warning_timelineAInspect
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. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully carries the burden. It details the neutral chronology, the official/authoritative source named first, the hash-anchored JYOTINT sealed call, and what it does and does not establish. This goes well beyond minimal disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, each earning its place. It is front-loaded with the core purpose, then details output structure, and ends with usage instructions. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given a single optional parameter, no output schema, and no annotations, the description is remarkably complete. It explains the input, output structure conceptually, and the nature of the timeline. Nothing essential 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?
Only one parameter 'id' with 100% schema coverage. The description adds context that id can be an advisory id or slug, and omitting it lists all. The schema already provides a description, so the added value is marginal but helpful.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it provides a 'before-the-event' indications-and-warning / after-action timeline for a named event by advisory id or slug. It specifies the verb 'get' and resource 'warning_timeline', distinguishing it from siblings like 'get_advisory'.
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 for 'what dated public warnings preceded [event]'.' and notes 'Omit id to list every available timeline.' It implies when to use via the single optional parameter, but does not explicitly mention when not to use or provide alternative sibling names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_open_callsBInspect
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 | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It fails to disclose behavioral traits such as output format, ordering, pagination, or any rate limits. The term 'anteriority' is jargon and adds little 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 sentence that quickly conveys the core purpose. However, the parenthetical 'anteriority you can watch' is somewhat verbose and might confuse rather than clarify.
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 absence of annotations and output schema, the description should provide more context about what the returned list contains (e.g., IDs, titles, dates). It does not clarify what 'sealed forecasts' are or how the list is structured.
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?
There are no parameters (0 params, baseline 4). The description does not need to add parameter information, and it does not contradict 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 explicitly states the tool lists sealed forecasts with unresolved windows. The verb 'List' and specific resource 'sealed forecasts whose window has NOT yet resolved' clearly differentiate it from sibling tools like 'search_sealed_forecasts' which allow filtering.
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 does not provide any guidance on when to use this tool versus alternatives. It does not mention when not to use it or suggest other tools for different needs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_sealed_forecastsAInspect
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.
| 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. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations, so description carries full burden. It describes search scope and return fields but does not disclose ordering, pagination, or potential performance implications. Adequate but not comprehensive.
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, front-loaded with key information about corpus and search scope. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, description reasonably covers search behavior and return values. Lacks details on sorting or result handling, but sufficient for a straightforward 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?
Schema coverage is 100%, so baseline is 3. Description adds value by specifying that the query searches across id, title, and claim, and lists return fields, which clarifies parameter intent beyond schema descriptions.
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?
Clearly states it searches the JYOTINT sealed-forecast corpus by free text across specific fields (id, title, claim). Distinguishes from sibling tools, which are not search-oriented.
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/when-not usage guidance or alternatives mentioned. Implied by tool name and description that it is for searching forecasts, but lacks explicit context for when to prefer this over siblings.
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.
Discussions
No comments yet. Be the first to start the discussion!