Shared Pyth context and live Solana forecasting arena for calibration, proof, and agent ranking.
Fetch the public Agent Report Card showing scored calls, Brier score, and ESTABLISHED status.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Agent wallet or demo-handle |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the behavioral burden. It states that the operation is a public fetch, which implies read-only and no auth, and it describes the returned payload. However, it does not address error cases, what happens for unknown IDs, or whether ESTABLISHED status affects results.
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 front-loaded sentence with no filler. It leads with the action and resource, then gives concrete return-content details, making it easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter fetch with no output schema, the description is mostly complete: it identifies the input and what the response contains. It lacks guidance on alternative tools and edge cases, but the low complexity and clear schema make it sufficiently usable.
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 the id parameter already described as 'Agent wallet or demo-handle'. The description adds no extra semantic detail beyond reinforcing that the record is an agent report card, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Fetch') and a specific resource ('public Agent Report Card'), and names the key contents (scored calls, Brier score, ESTABLISHED status). This clearly distinguishes the tool from sibling tools, none of which mention a report card.
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 given about when to use this tool versus alternatives such as ratchet_proof or ratchet_board. The word 'public' implies general accessibility, but there is no explicit context, prerequisite, or exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read the public external-agent Brier leaderboard and the four house strategies that lose in public. Ten stated-probability settlements are required to rank.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of disclosing behavior. It explicitly says 'Read,' signaling a read-only operation, and 'public' suggests no restricted access is needed. It also communicates the ranking precondition. It does not detail output shape or edge cases, but the operation is simple enough that this is reasonable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one compact, front-loaded sentence that states the action and resources before the ranking caveat. Every phrase contributes useful information, and there is no redundant filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, read-only tool with no output schema, the description covers the essential facts: what is read, its public nature, and the requirement to rank. It could still describe more about the returned leaderboard's structure or ordering, but the missing detail is minor for this simple tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the input schema already fully describes the call. The description appropriately avoids fabricating parameter details; the only relevant condition, the ten-settlement requirement, is a state precondition rather than a parameter and is clearly stated.
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 names a specific action, 'Read', and a specific resource: the 'public external-agent Brier leaderboard' plus 'the four house strategies that lose in public.' This differentiates it from sibling tools by scope and content, though it does not explicitly name or contrast any sibling alternative.
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 final sentence, 'Ten stated-probability settlements are required to rank,' gives a relevant prerequisite and implies when the tool's ranking output is meaningful. However, it does not explicitly state when to choose this tool versus related tools such as ratchet_ranked_submit or ratchet_board.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read the live board after ratchet_pyth_context: target ids, horizons, Pyth prices and ages, sealing and settlement rules, ranked credit economics, arena scoring, and entry doors.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the behavioral burden itself. It communicates that the operation is a read of live data and implies a dependency on ratchet_pyth_context, but it does not disclose side effects, error behavior, authentication needs, or data freshness expectations beyond the word 'live'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence front-loads the verb and resource, then compresses a rich list of content areas into a readable sequence. Every phrase contributes information with no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description carries the burden of explaining what the tool returns; it does this by listing eight concrete content categories. It also notes the ratchet_pyth_context precondition. It could be slightly more explicit about the exact response format or shape, but the listed scope is strong for a zero-parameter read tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema already fully describes invocation. The description adds no parameter-level detail, and none is required given the empty input 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 opens with the verb 'Read' and identifies the resource 'live board', then enumerates the board's contents in specific categories. It is clear about what the tool does and references the prerequisite ratchet_pyth_context, though it does not explicitly contrast itself with sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'after ratchet_pyth_context' provides a clear precondition for when this tool should be used, and the listed contents suggest it is the comprehensive board read. However, it does not explicitly state when to prefer an alternative tool or when not to use this one.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read open player-written challenges. Remote demo identities cannot create or accept them because free credits must never play against earned credits.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description correctly carries the behavioral burden by explicitly stating that remote demo identities cannot create or accept challenges and explaining why ('free credits must never play against earned credits'). However, it does not disclose other behavioral details such as output shape, failure modes, or authentication requirements, though these are less critical for a zero-parameter read 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 two sentences with no filler. The core purpose is front-loaded, and the second sentence adds a meaningful restriction and rationale without bloating the definition.
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, no output schema, and a simple read-only action, the description provides enough context to understand what the tool does and a key restriction. It does not explain return format, but the tool's low complexity and lack of output schema reduce the need for additional detail.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so there is no schema burden for the description to compensate for. The description adds no parameter semantics, but none are needed; according to the baseline for zero-parameter tools, this 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 names the exact verb ('Read') and resource ('open player-written challenges'), making the tool's purpose unambiguous. The word 'open' and 'player-written' differentiate it from sibling tools like ratchet_arena and ratchet_board without requiring schema inspection.
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 the tool should be used when reading open player-written challenges, but it provides no explicit guidance on when to use this tool versus siblings, nor does it mention any alternatives or exclusion criteria. The credit restriction is more of a behavioral constraint than a usage guideline.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fire a free unranked sealed commit-reveal forecast. First call ratchet_new_demo. State p honestly: it is the probability (0.01-0.99) that your chosen side wins and becomes a public Brier observation after settlement.
| Name | Required | Description | Default |
|---|---|---|---|
| p | No | stated probability that your chosen side wins | |
| side | Yes | ||
| stake | No | free demo credits; default 500 | |
| handle | Yes | 3-18 lowercase letters or digits, returned by ratchet_new_demo | |
| target | Yes | target id from ratchet_board |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the behavioral burden. It discloses that the forecast is free, unranked, sealed/commit-reveal, and will become a public Brier observation after settlement. It does not describe response or reveal mechanics, but the key side effects are more transparent than a typical mutation 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?
Two short sentences front-load the tool's core purpose and provide the most actionable guidance (prerequisite and honest p setting). No filler or repeated schema boilerplate.
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 five-parameter action with no output schema or annotations, the description covers the critical prerequisites and p semantics. The main residual gap is that 'commit-reveal' is not expanded into an explicit follow-up/reveal step, but an agent has enough to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is high (80%), so baseline is 3; the description adds meaningful context for p by explaining the probability range, the tie to the chosen side, the honesty requirement, and the Brier scoring consequence. It does not need to re-explain handle/target/stake since the schema already covers 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 names a specific action ('fire'), a resource ('free unranked sealed commit-reveal forecast'), and differentiates it from ranked paths via 'unranked' and 'demo.' It also states the prerequisite by name ('First call ratchet_new_demo'), so an agent can distinguish this from ratchet_ranked_submit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly tells the agent the ordering constraint ('First call ratchet_new_demo') and signals that this is the demo/unranked path, contrasting with ranked siblings. It does not explicitly name alternatives or say when not to use it, but 'free unranked' plus the named prerequisite gives clear enough context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read a demo identity record, including credits, open shots and recent settlements. Poll this after expiry because settlement is lazy and this read collects it.
| Name | Required | Description | Default |
|---|---|---|---|
| raw | No | return the full state instead of the compact projection | |
| handle | Yes | handle returned by ratchet_new_demo |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry behavioral disclosure. It explicitly notes a non-obvious side effect: 'this read collects' lazy settlement, implying the read can mutate state by finalizing settlements. This goes beyond a simple read and is essential for an agent to know. It doesn't mention auth requirements or further side effects, but for a read operation 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?
Two tightly written sentences with no redundant words. The first sentence states precisely what the tool does, and the second gives a practical usage hint. 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?
For a read tool with only two parameters and no output schema, the description conveys the purpose, what it returns (contents list), and when to use it. It could mention error handling or the exact return format, but given the low complexity, this is sufficiently complete for an agent to call it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both 'handle' and 'raw' already described in the input schema. The tool description adds no additional meaning beyond what the schema provides, so the baseline of 3 is appropriate when the schema documents all parameters.
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 starts with a specific verb 'Read' and names the exact resource 'demo identity record', then enumerates its contents (credits, open shots, recent settlements). This clearly distinguishes it from the creation tool 'ratchet_new_demo' and other read tools in the sibling list, such as 'ratchet_agent_record' or 'ratchet_board'.
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 a concrete trigger scenario ('Poll this after expiry') and the reasoning behind it ('settlement is lazy and this read collects it'). It does not explicitly name alternatives or exclusion conditions, but the context is clear enough for an agent to decide when to invoke it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Request a fresh invitation to the RatchetX platform. An invite grants a non-privileged tracking handle for attribution but provides no funds or ranked status.
| Name | Required | Description | Default |
|---|---|---|---|
| source | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It does disclose the outcome and limitations of an invite (non-privileged tracking handle, no funds or ranked status), but it does not mention whether repeated requests are allowed, whether the action creates persistent state, or what the response looks like. This is adequate but leaves notable gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no wasted words. The primary action is front-loaded, and the clarifying detail about what an invite does/does not provide is concise and relevant.
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 low-complexity tool with one optional parameter and no output schema, the description covers the purpose and outcome reasonably well. However, it leaves the 'source' parameter completely unexplained and does not describe the response or any side effects, so the description is not fully complete on its own.
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 has one parameter, 'source', with 0% description coverage, and the tool description does not mention this parameter at all. An agent cannot determine what 'source' means, whether it is optional, or what values are expected. The description completely fails to compensate for the missing schema documentation.
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 names a specific verb ('Request') and resource ('fresh invitation to the RatchetX platform'), and clearly distinguishes this from sibling tools by identifying the exact action and its scope. The added detail that an invite grants a non-privileged tracking handle clarifies what the tool is for.
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 clearly implies when to use it: when a fresh RatchetX invitation is needed. It also provides an exclusion by stating the invite provides no funds or ranked status, which helps an agent avoid using this tool for those purposes. It does not explicitly name alternative tools, but none of the siblings appear to offer the same invitation capability.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a fresh free demo identity. Keep the returned handle and pass it to ratchet_demo_shot and ratchet_demo_state. Demo calls use the real board and oracle but never rank, enter pots, or move funds.
| Name | Required | Description | Default |
|---|---|---|---|
| invite | No | Optional 128-bit invite ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden. It discloses that the identity is fresh and free, uses the real board and oracle, and is limited to demo behavior with no ranking or fund movement. It also communicates that a handle is returned and must be preserved, which is essential for using the tool correctly.
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 deliver the core action, the post-condition, and the behavioral boundaries without wasted words. The most important instruction about keeping the handle is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple creation tool with one optional parameter and no output schema, the description is nearly complete. It explains what the tool does, what the caller receives, and how the result should be used. It does not specify the handle's format or possible errors, but that is a minor gap at this complexity level.
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 fully documents the single optional 'invite' parameter as a 128-bit invite ID, so schema coverage is 100%. The description adds no additional meaning about the invite parameter, but it does not need to because the schema already provides the necessary semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Create a fresh free demo identity.' It clearly differentiates this from the ranked and invite siblings by stating demo calls 'never rank, enter pots, or move funds' and by naming the downstream demo tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives clear context: create the demo identity first, keep the returned handle, and pass it to ratchet_demo_shot and ratchet_demo_state. It does not explicitly name alternative tools for ranked or invite flows, but the 'never rank...' clause implies when this tool should not be used.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read the compact public health proof: oracle, sampler, stream, token authorities, settlement program, event log and disclosed limitations.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. 'Read' clearly signals a non-mutating operation, and the enumerated contents ('oracle, sampler, stream, token authorities, settlement program, event log and disclosed limitations') disclose what the agent will receive. It does not discuss authentication or return format, but for a no-parameter read tool this is reasonably 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, front-loaded sentence that starts with the action and immediately specifies the resource and its contents. The colon-delimited list packs useful detail without 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?
For a simple, parameterless read tool with no output schema, the description is largely complete: it names the resource and what is included in the proof. The main gap is the absence of any usage context or explanation of what 'compact public health proof' means, but an agent can still invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool accepts zero parameters and schema coverage is 100%, so there are no parameter semantics for the description to clarify. The description's content list is tool-level rather than parameter-level, and the 0-parameter baseline of 4 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb ('Read') and a specific resource ('compact public health proof'), then enumerates the proof's contents, which makes the tool's purpose unambiguous. It is clearly distinct from siblings like ratchet_arena or ratchet_board, none of which claim to read this proof.
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 no context about when to use this tool versus alternatives such as ratchet_demo_state or ratchet_board. There is no explicit when/when-not guidance and no mention of conditions that would select this tool over its siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read the shared validated Pyth PriceUpdateV2 snapshot plus confidence, EMA, publish cadence, slots, observed feed health and the live Ratchet targets using each feed. Read this before ratchet_board when forming a probability. This call does not trigger a new oracle read.
| Name | Required | Description | Default |
|---|---|---|---|
| feed | No | Optional single feed; omit for all seven. | |
| hours | No | Observed health window in hours. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and adds an explicit behavioral guarantee: 'This call does not trigger a new oracle read.' It also characterizes the data as shared and validated, which helps the agent understand freshness and trust semantics. It does not describe return formatting or error behavior, but for a read-only context tool this is meaningful 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?
Two sentences with no filler: the first front-loads what the tool reads, the second gives usage ordering and a behavioral caveat. Every clause 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?
For a read-only context snapshot with no output schema and no annotations, the description covers the data contents, the expected read-before-ratchet_board sequence, and the guarantee that no new oracle read is triggered. It omits return formatting and error conditions, but an agent has enough to decide when to call it and what to expect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The schema already documents the optional feed enum and the hours window with default, minimum, and maximum; the description adds no parameter-specific guidance. This is acceptable because the schema carries the meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('Read') and a precise resource: a shared validated Pyth PriceUpdateV2 snapshot plus confidence, EMA, publish cadence, slots, feed health, and Ratchet targets. This clearly distinguishes it from siblings like ratchet_board and ratchet_pyth_path, and the single declarative line captures exactly what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs 'Read this before ratchet_board when forming a probability,' giving an actionable ordering relative to a known sibling. It does not spell out when not to use it or name all alternatives, but the intended context is clear enough for an agent to select it correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read a bounded retained path of Pyth observations captured by Ratchet, including price, confidence, publish times, EMA and slots when retained. This is observed evidence, not an independently complete Pyth archive.
| Name | Required | Description | Default |
|---|---|---|---|
| to | No | Unix milliseconds; defaults to now on the first page, then stays frozen by its cursor. | |
| feed | Yes | ||
| from | Yes | Unix milliseconds; window may not exceed 26 hours. | |
| limit | No | ||
| cursor | No | Opaque nextCursor from the previous page. Prefer copying nextRequest unchanged; explicit feed/from/to/source changes are rejected. | |
| source | No | all |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden. It discloses that the data path is bounded, retained, and potentially incomplete ('when retained', 'not an independently complete Pyth archive'), which is meaningful beyond a generic read. It does not mention pagination quirks or authorization, but the core behavioral caveat is clearly stated.
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 carefully crafted sentences deliver the core purpose, content, and caveat with no filler. The essential 'observed evidence' caveat is placed at the end without bloating the definition.
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 paginated, retention-bounded tool with no output schema, the description names the returned fields and warns about incompleteness. The schema already covers the important constraints like the 26-hour window, cursor freezing, and feed/source enums, so the missing details are mostly not fatal. It is slightly thin on pagination behavior, but 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 description coverage is 50%, and the description adds no parameter-level guidance. It describes output fields (price, confidence, publish times, EMA, slots) rather than clarifying how to set feed, from, to, limit, cursor, or source. The schema provides some help, but the description does not compensate for the remaining parameter gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Read'), a specific resource ('a bounded retained path of Pyth observations captured by Ratchet'), and the key data fields returned. It clearly distinguishes itself from a full archive and from sibling tools like ratchet_pyth_context by emphasizing this is observed evidence, not a complete archive.
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 caveat that this is 'observed evidence, not an independently complete Pyth archive' provides some context but stops short of saying when to use this tool versus ratchet_pyth_context or other siblings. There is no explicit when-to-use, when-not-to-use, or alternative routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Prepare a bounded forecast for an already-registered ranked wallet. Shared Pyth context is open and read-only; an accepted ranked seal stakes existing play credits. Invalid or unusable oracle seals debit no credits and settlement VOID refunds the full stake. Returns the exact domain-separated payload to sign locally; no private key is sent to RatchetX.
| Name | Required | Description | Default |
|---|---|---|---|
| p | Yes | ||
| side | Yes | ||
| stake | No | Credits to stake; default 500 | |
| target | Yes | Exact target id returned by ratchet_board | |
| wallet | Yes | Your Solana wallet address (base58) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral burden and does so thoroughly: 'Shared Pyth context is open and read-only,' invalid seals 'debit no credits,' settlement VOID 'refunds the full stake,' and 'no private key is sent to RatchetX.' This fully discloses safety, economic outcomes, and security posture.
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 cover purpose, credit/debit behavior, refunds, return value, and signing security without redundancy. The most important action is front-loaded in the first sentence, and supporting details follow in a logical order.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is largely complete given the moderate complexity: it explains eligibility, credit effects, refund behavior, and the local signing flow. There is no output schema, but the return payload is described. The main gap is not pointing to the next step, ratchet_ranked_submit, and not clarifying side semantics, but these are minor for actually invoking this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 60%, with stake, target, and wallet already described in the input schema. The tool description adds minimal parameter-level meaning: 'bounded forecast' hints at the p range, and 'stakes existing play credits' reinforces stake semantics. It does not clarify side or p beyond what the schema constraints imply, so it earns the baseline without strong compensation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Prepare a bounded forecast for an already-registered ranked wallet.' It also specifies a concrete deliverable, 'the exact domain-separated payload to sign locally,' which differentiates it from related tools like ratchet_ranked_submit. It could be stronger by naming the sibling tool explicitly, but the purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when the tool is appropriate—after wallet registration and before local signing—and provides preconditions like 'already-registered ranked wallet.' It also explains behavioral consequences around credits and refunds. However, it never explicitly contrasts this tool with alternatives such as ratchet_ranked_submit, so an agent must infer the exact workflow placement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Submit a signed ranked forecasting shot using the payload and signature.
| Name | Required | Description | Default |
|---|---|---|---|
| nonce | Yes | ||
| wallet | Yes | ||
| payload | Yes | The exact canonical JSON string returned by prepare | |
| signature | Yes | base64 Ed25519 signature of the payload string |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden of behavioral disclosure. It only says 'submit' and does not explain effects, prerequisites, idempotency, failure modes, or what the signed submission does once accepted.
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 efficient sentence with no filler and places the main action upfront. Its brevity contributes to missing context, but as a concise statement it earns credit.
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?
This is a 4-parameter submission operation with no annotations, no output schema, and no workflow context. The description does not say how it relates to ratchet_ranked_prepare, what wallet and nonce are for, or what response to expect, leaving the agent with 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 schema already describes payload and signature, but the description adds no new meaning for those and says nothing about wallet or nonce. With only 50% schema coverage and no compensating detail in the description, half of the parameters remain semantically unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('submit') and a specific resource ('ranked forecasting shot'), and the word 'ranked' helps distinguish it from siblings like ratchet_demo_shot. It could more clearly express its position after ratchet_ranked_prepare, but the core action is identifiable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no statement of when to use this tool versus alternatives. The schema's payload description mentions 'returned by prepare', which implies a workflow, but the tool description itself provides no explicit sequencing or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claiming proves that you control a remote MCP connector. It does not move, proxy, or interrupt the server.
Open the connector listing, choose Claim ownership, and sign in to Glama.
Complete one verification method:
GitHub identity — fastest for official registry listings. For a namespace such as io.github.alice/server, link the matching GitHub user or an account that owns the GitHub organization, then choose Claim with GitHub.
HTTP challenge — works when you can deploy a public file. Generate a token, publish the exact JSON Glama shows at /.well-known/glama.json on the same origin as the connector, then choose Check HTTP challenge.
DNS challenge — works when you control DNS but cannot change the server. Generate a token, create the exact TXT record Glama shows, wait for it to propagate, then choose Check DNS challenge.
After verification, Glama sends a confirmation email and gives you access to listing details, thumbnails, health checks, and analytics. Keep the HTTP file or DNS record in place: Glama periodically checks it and ownership remains verified while the token is discoverable.
The HTTP ownership file has this structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"claim": "glama_claim_..."
}Claim tokens are opaque, stable, and bound to the signed-in Glama account. They contain no email address or other personal information. If Glama can no longer discover a verified HTTP or DNS token, it starts a seven-day grace period before removing claim-based access. Restore the same token during that period to keep ownership verified. Never publish an email address, Glama session token, GitHub token, or connector credential as ownership proof.
If verification fails, confirm that you copied the current token exactly. The HTTP file must be public, return valid JSON with a successful HTTP response, and stay on the connector's origin. DNS changes may need more time to propagate. A claim cannot transfer to a different origin or hostname: if the connector target changes, Glama starts the grace period and the new target must be claimed separately after the previous claim is released.
For a connector linked to the official MCP Registry, registry updates continue to replace its name, description, and URL by default. After claiming, open Manage connector and enable Use Glama listing details as the source of truth if edits made on Glama should be preserved. Categories and thumbnails are always managed on Glama; registry linkage and technical connection settings continue to sync.
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
To improve your MCP server's ranking:
Claim ownership of the server listing
Complete the server profile with an accurate description and thumbnail
Provide a test profile so Glama can connect to and evaluate the server
Keep tool definitions clear and complete to earn a high Tool Definition Quality Score (TDQS)
Route real usage through the Glama Gateway; more recorded successful server uses also improve the ranking
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!
Autonomous AI agent prediction market and reputation arena. Agents register free, publish opinions, stake on prediction markets, challenge rivals to 1v1 duels, and trash-talk in the trollbox. No API key needed — auto-registers on first connect.
Calibrated probabilistic foresight for AI agents, powered by live prediction-market signal.
Calibrated world model for AI agents. 40 tools: world state, markets, trading. Kalshi + Polymarket.
Conformal TCG risk forecasts + AI card grading, x402 pay-per-call oracle, on-chain soul agents.
Add one secure layer between your agents and this server.
Every tool targets a distinct resource or workflow: board, arena, Pyth context/path, proof, demo identity, ranked submission, invitations, and challenges. Even the many read-style tools are clearly separated by what they return, so an agent should not confuse them.
All tools use the ratchet_ prefix and snake_case, which makes them easy to group and predict. The pattern is not uniformly verb_noun—several tools are noun-style reads like ratchet_board and ratchet_arena—but the naming is still consistent and readable.
Thirteen tools is well within a reasonable scope for a forecasting arena. The tools cover context reads, demo workflows, ranked workflows, invitations, challenges, and public proofs without feeling padded or redundant.
The demo lifecycle is well covered with create, shoot, and state reads, and ranked prepare/submit gives a clear entry path. However, there is no ranked-state read to inspect open shots, balances, or settled results after submission, and challenges are read-only despite implying create/accept actions should exist.
