Read what BitPredict members call Up or Down on each coin, plus the Daily Call and crowd record.
Scored across 4 tools
Each tool targets a distinct slice: crowd_call is a per-coin member split, crowd_record is aggregate member performance, daily_call is the featured coin of the day, and make_call is the only action tool (returns a link). The main soft spot is overlap between crowd_call and daily_call, since both surface an Up vs Down split, though the coin scope and framing differ enough that descriptions resolve it.
All four names are snake_case, short, and noun-terminated, giving a predictable shape. make_call is the only verb-first name, but that deviation usefully signals it is the sole action tool rather than a data read.
Four tools is lean but each covers a distinct need (coin sentiment, member track record, daily pick, action handoff). Nothing appears redundant, and the narrow prediction-call domain does not obviously demand more surface.
The surface covers the core loop: see the daily question, check crowd sentiment, verify member credibility, and get a link to act. The main gap is that a user cannot check their own existing or past calls in-chat, but the link-out to BitPredict makes that a workable omission.
What BitPredict members called on a coin over the last 30 days: the Up vs Down split and how many calls it rests on. Members only, never the house AI agents. Says so when fewer than 5 member calls exist.
| Name | Required | Description | Default |
|---|---|---|---|
| symbol | Yes | Coin ticker such as BTC, ETH or SOL. A coin name such as "Bitcoin" also works. |
| Name | Required | Description |
|---|---|---|
| url | Yes | |
| name | Yes | |
| upPct | Yes | Share of member calls that were Up, 0 to 100. |
| symbol | Yes | |
| window | Yes | Time window the counts cover. |
| downPct | Yes | Share of member calls that were Down, 0 to 100. |
| minCalls | Yes | |
| enoughCalls | Yes | False when there are too few member calls to show a split. |
| memberCalls | Yes | Calls by BitPredict members on this coin in the window. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish read-only, idempotent, non-destructive, closed-world behavior, so the safety profile is covered. The description adds genuinely new behavioral context: a hard 30-day lookback, exclusion of house AI agents from the aggregate, and a suppression rule below 5 member calls with an explicit signal. It does not address refresh cadence or how the split is weighted, but the substantive traits are disclosed.
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 the payload ('Up vs Down split and how many calls it rests on') before the scope qualifiers. Every clause contributes: window, population, edge case. No restatement of the title or the schema.
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 an output schema present, the description need not explain the return shape, and it correctly focuses on scope, population, window, and the low-sample edge case. What remains unstated is minor: timezone/boundary of the 30-day window and what counts as a member call. For a one-parameter read tool this is close to complete.
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 is a single required parameter and the schema description coverage is 100%, with the schema itself documenting ticker-or-name acceptance and length bounds. The description adds no parameter-level detail beyond that, but it does implicitly define the resolution scope of the symbol (calls on that coin, not that coin's price). Baseline 3 applies when the schema carries the parameter 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 names a specific resource and measurement: the aggregated Up/Down split of member calls on a given coin over a fixed 30-day window, plus the sample size behind it. It also scopes the population ('Members only, never the house AI agents'), which separates it from agent-authored call tools. It never names a sibling (crowd_record, daily_call, make_call) explicitly, so differentiation is inferred rather than stated.
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 30-day window and members-only scope imply when this tool is appropriate, and the 'fewer than 5 calls' note signals when results will be suppressed. However, there is no explicit guidance on choosing this over daily_call (presumably per-day detail) or crowd_record, and no statement of prerequisites. Usage is inferable but not prescribed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
How BitPredict members did on recently settled calls: hit rate over the last 30 and 7 days, plus a pointer to the public hash chain that proves the results. Members only.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| window | Yes | |
| proofUrl | Yes | |
| proofDate | Yes | |
| settled7d | Yes | |
| minSettled | Yes | |
| settled30d | Yes | Settled calls by members in the last 30 days. |
| hitRate7dPct | Yes | |
| enoughSettled | Yes | |
| hitRate30dPct | Yes | Share of those calls that were right, 0 to 100. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, non-destructive, and closed-world, so the safety profile is fully covered. The description adds useful context beyond that — the two rolling windows (30 and 7 days) and the link to a public hash chain proving results — but omits how the windows are computed, refresh cadence, and whether the sample is only settled calls (affecting denominators).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence with the substance first (hit rate, windows) followed by the provenance pointer and the access caveat. It is tight and free of filler, though the 'Members only' caveat would read better as its own short sentence than as a trailing fragment.
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?
An output schema exists, so return-value explanation is not required, and with no parameters the calling mechanics are trivial. What the description still leaves open — authentication prerequisites and the settlement-window definition — is minor but relevant to an agent deciding whether it can call this at all.
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?
With zero parameters the baseline is 4; the description correctly signals that the tool takes no inputs and returns time-windowed aggregates rather than anything caller-specified. No additional param meaning is needed or offered, and none is possible.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific resource and metric: aggregate hit rate for BitPredict members over 7- and 30-day windows, plus a hash-chain provenance pointer. It hints at sibling differentiation through the 'recently settled calls' framing and 'members' audience, but never names crowd_call, daily_call, or make_call to contrast the aggregate view with an individual or daily call.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is only implied: 'recently settled calls' and 'Members only' suggest reading performance after outcomes are known and that some membership/authentication context is required. There is no explicit when-to-use statement, no exclusion of alternatives, and no guidance on choosing this over the similarly named crowd_call or daily_call siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Today's BitPredict Daily Call: the coin of the day, its opening price, the question, and the members' Up vs Down split so far.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| url | No | |
| name | No | |
| open | Yes | |
| upPct | No | |
| symbol | No | |
| downPct | No | |
| closesAt | No | |
| minCalls | No | |
| dayNumber | No | |
| lastPrice | No | |
| openPrice | No | |
| roundDate | No | |
| yesterday | No | |
| eventLabel | No | |
| memberCalls | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is fully covered without description help. The description adds useful context about what data the call contains, but says nothing about freshness, whether a call may be absent before the day starts, or failure behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence with zero filler that front-loads the resource and then lists its contents in priority order. 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?
With no parameters, rich annotations, and an output schema that documents return values, the definition covers what an agent needs to select and invoke it. The only omission is edge-case behavior (e.g., no call published yet), which is minor for a zero-argument read.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so there is nothing for the description to disambiguate and the baseline of 4 applies. The description correctly does not invent any input options.
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 resource (today's BitPredict Daily Call) and enumerates its contents: coin of the day, opening price, question, and Up vs Down split. The word 'Today's' implicitly scopes it against time-based siblings, but it is a noun-phrase summary of return data rather than an explicit verb, and it never names the sibling it differs from (e.g., crowd_call).
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 guidance on when to call this versus crowd_call, crowd_record, or make_call. An agent must infer that this is the read path for today's call and that make_call is the write path, which is a reasonable guess but not stated anywhere.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Places nothing. Returns a link the person opens in BitPredict to lock in a 24h Up or Down call on a coin (a free account is created if they have none). Use it when the person wants to make that call.
| Name | Required | Description | Default |
|---|---|---|---|
| symbol | Yes | Coin ticker such as BTC, ETH or SOL. A coin name such as "Bitcoin" also works. | |
| horizon | No | Time frame. Only 24h is available. | |
| direction | Yes | Whether the coin finishes the 24 hours higher (up) or lower (down). |
| Name | Required | Description |
|---|---|---|
| url | Yes | Link the person opens to lock the call in. |
| name | Yes | |
| placed | Yes | Always false: nothing is placed until the person opens the link. |
| symbol | Yes | |
| horizon | Yes | |
| direction | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotation set already declares readOnlyHint, idempotentHint and non-destructive, so the safety profile is covered; the description nonetheless earns credit by confirming "Places nothing" and by disclosing an external side effect the annotations cannot express — a free account is created if the person has none. It does not discuss link expiry or reuse, which would have pushed it higher.
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 short sentences with the most important correction ("Places nothing") front-loaded, followed by what is returned and when to use it. Every sentence carries information; the phrasing is slightly clipped but not padded.
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?
An output schema exists, so the description need not document the returned link; it still states what the link is for and the account-creation side effect. For a three-parameter read-only tool that is nearly complete, with only cross-tool disambiguation missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already explains symbol, direction and the 24h-only horizon enum; baseline 3 applies. The description restates the same semantics (24h, Up or Down, coin) without adding format or validation detail 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?
"Returns a link the person opens in BitPredict to lock in a 24h Up or Down call on a coin" names a specific verb (returns a link) and resource (a 24h directional call on a coin), and "Places nothing" preempts the false read that this executes a trade. It does not differentiate itself from the siblings crowd_call, daily_call or crowd_record, so it falls short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
"Use it when the person wants to make that call" gives only an implied when-to-use condition. There is no when-not guidance and no explicit routing between this and the similarly named crowd_call or daily_call siblings, leaving the agent to infer the boundary.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
crowd_callcrowd_recorddaily_callmake_callLive crypto Buy/Sell/Hold readings from prediction markets and options, plus daily trend calls.
Browse prediction markets, check odds, and follow big trades.
Free daily AI crypto research verdicts: graded stance, dimensions, and key levels for 67+ coins.
AI-operated crypto signal scores for 20 Coinbase USDC pairs. $0.001/call via x402.
Add one secure layer between your agents and this server.
