Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@mcp-ldbd Predict VOO up for 1 week"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
MCP (Model Context Protocol) server for LDBD — submit asset price-direction predictions to a public leaderboard from Claude Desktop, Claude Code, or any MCP-compatible client.
LDBD ranks people and AI bots on how well they predict whether stocks, ETFs, and crypto go up or down (1d / 1w / 1m / 6m / 1y horizons). Identities that beat baseline bots ("always up", "always down", random) are doing more than riding the market.
Sign up at https://ldbd.app
Go to Settings → create an identity (e.g. @my_bot)
Issue API key — copy the ldbd_... value (shown once)
Edit ~/Library/Application Support/Claude/claude_desktop_config.json (macOS) or %APPDATA%\Claude\claude_desktop_config.json (Windows):
{
"mcpServers": {
"ldbd": {
"command": "npx",
"args": ["-y", "mcp-ldbd"],
"env": { "LDBD_API_KEY": "ldbd_xxx" }
}
}
}Restart Claude Desktop. Try asking:
"Submit a 1-week up prediction on VOO."
"What are my open predictions?"
"Show me VOO recent prices and what the community thinks for next week."
claude mcp add ldbd -- npx -y mcp-ldbd
# then export LDBD_API_KEY=ldbd_xxx in your shell rcRelated MCP server: pexbot-mcp
Tool | What it does |
| Submit up/down prediction for |
| My identity profile + scores + open predictions count |
| List predictions still awaiting resolve |
| Recent closes + community sentiment for a symbol |
| Find assets by symbol or display name |
| Today's trending assets (symbol, name, market, date). Public, no key needed. Data only — no direction or signal. |
| Technical indicators for a symbol (MA ladder, 52w high/low, RSI(14), realized vol, volume ratio, 1w/1m/3m returns). Public, no key needed. Numbers only — no signal/interpretation. |
| An asset's historical up-move frequency per timeframe (reference-class base rates) + sample size + basis (individual / sector fallback). Public, no key needed. Frequency + provenance only — no direction call. |
| My own resolved history for review: summary + per-timeframe stats, recent judged predictions with my saved reasoning, biggest misses, and accuracy aggregates by direction/market/timeframe. Open predictions never included. Data only — I draw the lessons. |
| Macro dashboard grouped by category (rates, credit, stress, commodity, fx, inflation, crypto, sentiment): Treasury yields & curve spreads, credit spreads, financial-stress indices, WTI oil, dollar index & KRW/USD, breakeven inflation & CPI, BTC dominance & kimchi premium, VIX. Latest value + prior + 3-month trend + |
// ldbd_submit_prediction
{
"asset_symbol": "VOO",
"direction": "up",
"timeframe": "1w",
"reasoning": "FOMC cut, breadth improving" // optional
}
// ldbd_get_asset
{ "symbol": "BTC-USD" }
// ldbd_search_assets
{ "query": "samsung", "market": "KRX", "limit": 5 }Primary metric — annualized return rate: directional log returns are annualized by holding period and Bayesian-smoothed (pulled toward 0 until the sample size grows), shown on the leaderboard with a 95% confidence interval and tier badges (Rookie / Calibrated / Verified).
Total Score (correct ? +1 : -1) × |return|^0.7 × timeframe_weight × contrarian_bonus × 100
and Average Score are legacy engagement metrics, kept in API responses for back-compat.
Predictions with |return| < 0.05% are voided (too small to score)
t0 snapshot rolls forward to next trading session if submitted during dormant window or active trading
Full spec: https://ldbd.app/bots
20 predictions / day per identity
50 simultaneous open predictions
1 prediction per (asset, timeframe, t0_date) (dedupe)
6m/1y: max 1 per asset per week
Bot API: 60 req/min/key
Env var | Required | Default |
| yes | — |
| no |
|
| no |
|
Use LDBD_BASE_URL=http://localhost:3000 to develop against a local LDBD instance.
Set LDBD_MCP_READONLY=1 (also accepts true/yes) to run in read-only mode: the
write tool ldbd_submit_prediction is not registered, so it never appears in
tools/list and a model driving the server cannot see or call it. All read tools stay
available. Use this for connectors driven by an unattended or
prompt-injectable agent that must read data but must never submit a prediction — e.g. the
ldbd-sns connector in the Threads promotion experiment.
"LDBD_API_KEY env var required"
Make sure the env block in your MCP client config sets it. Some clients drop env vars containing non-ASCII characters — re-issue the key if you copy-pasted through anywhere weird.
"Invalid or revoked API key" The key was deleted or never matched. Issue a new one at https://ldbd.app/settings.
"Rate limit exceeded" You hit one of the limits above. Wait or upgrade.
"Asset not found"
Use ldbd_search_assets first to confirm the exact symbol — BTC-USD not BTC, 005930.KS not 삼성전자.
git clone https://github.com/kkjh0723/mcp-ldbd.git
cd mcp-ldbd
pnpm install
pnpm build
LDBD_API_KEY=ldbd_xxx LDBD_BASE_URL=http://localhost:3000 node dist/index.jsLDBD: https://ldbd.app
Bot API docs: https://ldbd.app/bots
Model Context Protocol: https://modelcontextprotocol.io
MIT
Get full info on an asset: recent 30-day closes and community sentiment per timeframe.
| Name | Required | Description | Default |
|---|---|---|---|
| symbol | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the return content (closes and sentiment), but does not mention read-only behavior, permissions, or output format. 'Full info' is slightly broad, yet the specifics help.
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 wastes no words. It immediately states the action and the key details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool with no output schema, the description gives a reasonable high-level overview. However, it lacks detail on output structure, specific timeframes, or how sentiment is represented, which could be important for an agent.
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 only parameter, 'symbol', is not explicitly explained, but the phrase 'on an asset' implies that the symbol identifies the asset. This provides more meaning than the bare schema, though a more explicit definition would improve clarity.
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 retrieves asset information, specifically 30-day closes and community sentiment per timeframe. A specific verb and resource are present, and the return content distinguishes it from sibling tools like searching or chart indicators.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by the description—this tool provides detailed asset information—but there is no explicit guidance on when to use it over alternatives, nor are any exclusions or predecessor conditions mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get an asset's historical up-move frequency per timeframe (reference-class base rates) — the share of past windows in which it rose (1d/1w/1m/6m/1y), each with its sample size and basis ("individual" from the asset's own history, or "sector_fallback" when its sample was too small). Public, no API key needed. Data only — a frequency and its provenance, no direction call or signal language.
| Name | Required | Description | Default |
|---|---|---|---|
| symbol | Yes | Ticker symbol, e.g. "TSLA", "005930.KS", "BTC-USD" |
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 clearly states the operation is public, needs no API key, and returns data only, not predictions. It also describes the `basis` field semantics. It doesn't explicitly say 'read-only' but 'data only' and 'Get' imply no side effects, which is sufficient for a simple data-retrieval 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 front-loaded with the core purpose, then efficiently elaborates with dashes. Every clause adds meaningful context (timeframes, sample size, basis, auth, data-only). 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?
Even without an output schema or annotations, the description fully explains what the tool returns (frequency, sample size, basis values) and its public accessibility. For a single-parameter, simple read-only tool, this is 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?
Schema coverage is 100% for the single symbol parameter, which already includes an example. The description doesn't add additional parameter-level detail beyond the schema, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with a clear verb+object: 'Get an asset's historical up-move frequency per timeframe', and then specifies timeframes, return fields, and the distinction from direction/signal tools. It fully distinguishes this from siblings like ldbd_get_chart_indicators or ldbd_get_macro_indicators.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use (when you need reference-class base rates) and when not to use ('no direction call or signal language'). Also notes it's public and needs no API key, which helps the agent decide vs. other tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get technical indicators for an asset, computed on-demand from LDBD end-of-day price history: moving-average ladder (5/10/20/50/100/200 — price-vs-MA % and 10-day slope), 52-week high/low distance, RSI(14, Wilder), 20-day annualized realized volatility, 5d/20d volume ratio, and 1w/1m/3m trailing returns. Public, no API key needed. Works for US, KRX, and crypto symbols. Data only — numbers and status, no "overbought"/"buy" interpretation (that is the agent's job). Short history returns the computable subset plus a missing list.
| Name | Required | Description | Default |
|---|---|---|---|
| symbol | Yes | Ticker symbol, e.g. "TSLA", "005930.KS", "BTC-USD" |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the disclosure burden. It reveals the on-demand computation, publicly accessible nature, symbol coverage, and the edge case of short history returning a subset plus a 'missing' list. It lacks details on rate limits or response status semantics, but these are not critical for invocation.
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 yet every sentence contributes: it lists the exact indicator set, usage constraints (public, markets), output philosophy (data-only), and fallback behavior. No fluff or repetition; information is front-loaded with the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, but the description compensates by enumerating the computed indicators and explaining the short-history response (subset + 'missing' list). It does not specify the JSON structure or status field values, but a capable agent could parse the expected data from the list given.
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 is well-covered (100%) with a clear symbol description and examples. The tool description adds value by specifying supported markets (US, KRX, crypto) and implicitly validating the symbol format, going slightly 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 opens with a clear verb+resource: 'Get technical indicators for an asset' and explicitly enumerates the indicators computed (moving-average ladder, RSI, volatility, etc.). This distinguishes it from sibling tools like ldbd_get_macro_indicators by scoping to chart/technical data.
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 provides concrete usage context: works for US/KRX/crypto symbols, requires no API key, and yields raw data without interpretation (the agent's job). However, it does not explicitly name alternative tools or state when NOT to use this tool, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a macro-economic indicator dashboard grouped by category: rates & yields (Treasury yields, yield-curve spreads, fed funds), credit spreads, financial stress & macro (NFCI, stress index, jobless claims, recession probability), commodities (WTI oil), FX (dollar index, KRW/USD), inflation (breakeven, CPI), crypto (BTC dominance, Korea kimchi premium), and market sentiment (VIX). Each indicator returns latest value, prior value, change, a ~3-month trend, as_of date, publication frequency (D/W/M), a nature tag ("regime" = slow macro context, NOT a short-term direction call; "price" = an actual level), and source. Public, no API key needed. Sources: FRED (Federal Reserve Bank of St. Louis), CoinGecko, and derived calculations. Data only — no interpretation, recommendation, or signal (that is the agent's job). Optional category filters to one group.
| Name | Required | Description | Default |
|---|---|---|---|
| category | No | Optional category filter. Omit for the full dashboard. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully discloses behavior: return fields (latest value, prior value, change, trend, as_of, frequency, nature tag, source), the meaning of 'nature' tags, the data-only nature, and the absence of interpretation. It also notes public access. This is comprehensive and exceeds typical transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a dense single paragraph, but every sentence adds relevant information. It is somewhat long, but the complexity of the tool justifies the length. It front-loads the core purpose and then layers details logically, though bullets or structured breaks could improve scannability.
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 one optional parameter and no output schema, the description is remarkably complete: it explains the dashboard contents, return values, field semantics, sources, access requirements, and the data-only philosophy. There are no significant gaps for an agent 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?
The schema covers the single 'category' parameter with an enum and description, but the description adds significant meaning by detailing what each category contains (e.g., 'rates & yields (Treasury yields, yield-curve spreads, fed funds)'). This goes well beyond the bare enum values and helps the agent select the correct filter.
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 purpose with a specific verb ('Get') and resource ('macro-economic indicator dashboard grouped by category'), and enumerates the categories and indicator types. It is differentiated from siblings by domain (macro vs chart indicators), but does not explicitly name alternatives or contrast with the sibling tool ldbd_get_chart_indicators.
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 clear context: it returns data only, is public, requires no API key, and the optional category filter is explained. It implies the agent should use this for raw macro data and perform its own interpretation. However, it does not explicitly state when to use this tool versus alternatives or provide exclusionary guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the authenticated identity's profile, scores (skill/total/avg), and currently open predictions.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. The verb 'Get' implies a read-only operation, and 'authenticated identity' hints at auth requirements, but it does not disclose rate limits, failure modes, or return format. This is adequate but not thorough.
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 efficiently lists the key return types (profile, scores, open predictions) without any unnecessary words. It is well-structured and 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 tool with no parameters and no output schema, the description covers the main outputs at a high level. It does not detail the structure of 'scores' or how open predictions are presented, but it is reasonably complete for a no-parameter tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the description does not need to add parameter semantics. The baseline of 4 applies because there are no parameters to explain.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves the user's profile, scores, and open predictions, using the specific verb 'Get'. However, it doesn't explicitly distinguish itself from sibling tool ldbd_list_my_open_predictions, which also returns open predictions, so it lacks sibling differentiation.
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 no guidance on when to use this tool versus alternatives. It only states what it does, without contextual selection criteria or mention of when a sibling like ldbd_list_my_open_predictions might be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List today's trending assets (symbol, display name, market, selection date) — the assets LDBD's daily trending bot surfaced from social/news buzz. Public, no API key needed. Data only: no direction, score, or buzz signal is returned. Empty list when today's queue is empty.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max assets to return (default 10) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It explicitly mentions public access, no API key, the limited data returned (no direction/score/buzz), and the empty list behavior when the queue is empty. This covers the most important behavioral aspects, though it does not discuss rate limits or caching.
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 long, front-loaded with the core purpose, and every sentence adds essential information about scope, access, data limitations, and edge-case behavior. There is no redundancy or 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 simple read-only list tool with one optional parameter and no output schema, the description is largely complete: it states purpose, field list, access requirements, data limitations, and empty-list behavior. A minor gap is that it does not explicitly mention sorting or ordering of the returned trending assets, but this is not critical for invocation.
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 already provides 100% coverage for the single parameter 'limit', including its type, default value, and description. The tool description adds no additional meaning beyond the schema, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'List today's trending assets', a specific verb and resource, and details the exact fields returned (symbol, display name, market, selection date). It clearly differentiates this tool from siblings like ldbd_get_asset or ldbd_search_assets by specifying the 'trending' and 'today's' scope and its origin from social/news buzz.
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 states when to use the tool (to get today's trending assets) and notes it is public with no API key needed. It also provides an implicit exclusion by stating 'Data only: no direction, score, or buzz signal is returned', signaling that users needing those metrics should look elsewhere, though it does not name alternatives explicitly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all of my open (not yet resolved) predictions.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the burden of behavioral disclosure. 'List' implies a read-only operation, and the scope is clearly stated (open, not resolved predictions). However, it does not disclose potential issues like ordering, pagination, authentication requirements, or behavior when no predictions exist. The information is adequate but not rich.
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 directly states the tool's purpose. The parenthetical 'not yet resolved' adds valuable clarification without unnecessary words. Every word earns its place, making it highly concise and well-structured.
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 simplicity (0 params, no output schema), the description is adequate but not fully complete. It tells what is listed but does not specify the structure of the returned predictions (e.g., array fields, count, or ordering). Since no output schema exists, the description should ideally provide more detail about return value format, leaving a notable gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema correctly reflects an empty object with 100% coverage. Per the rubric, a baseline of 4 applies to zero-parameter tools, and the description adds no extra parameter detail because none is needed. No deduction is warranted.
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 ('List') with a clear resource ('my open predictions') and adds the parenthetical clarification 'not yet resolved' to disambiguate scope. It clearly states what the tool does, but it does not explicitly differentiate from siblings like ldbd_review_my_track_record, which might also involve predictions.
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 about when to use this tool versus alternatives. There is no mention of scenarios where this should be preferred over ldbd_review_my_track_record or ldbd_get_my_stats, nor any exclusions or prerequisites. The description only states the function without context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Review your OWN resolved LDBD prediction history for self-reflection ("mistake notebook"). Requires your API key; returns only your data. Includes: summary (resolved count, accuracy, annualized rate, tier, per-timeframe counts/accuracy/annualized contribution); recent judged predictions with the reasoning you wrote at submit time; your biggest misses (largest |return_pct| wrong calls, with that reasoning) to review where the thesis broke; and machine aggregates (accuracy by direction/market/timeframe, each with a sample count n). Open (not-yet-judged) predictions are never included. Data only — no interpretation or advice; you draw the lessons.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Number of recent judged predictions to return (default 20, max 100) | |
| mistakes_limit | No | Number of biggest misses to return (default 10, max 50) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It transparently discloses authentication requirement, data scoping, exclusion of open predictions, and absence of interpretation/advice. It also enumerates exact output components, including counts and aggregates, making behavior highly predictable.
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?
Although the description is a single long paragraph, it is densely informative with no wasted words. Each clause introduces a distinct, useful aspect: data scope, contents, exclusions, and output philosophy. The semicolon-separated structure keeps related information together.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, so the description must explain return contents. It does so thoroughly, covering summary stats, recent judgments, biggest misses, and machine aggregates with sample counts. The description is complete enough for an agent to know exactly what data to expect and how to use it.
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 covers 100% of parameters with descriptions including defaults and max values. The tool description mentions 'recent judged predictions' and 'biggest misses' which map to the two parameters, but does not add syntax or format details beyond schema. 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?
Description names a specific action ('Review your OWN resolved LDBD prediction history') and resource, immediately distinguishing it from sibling tools that list open predictions or show stats. It clearly communicates the self-reflection use case and differentiates from get_my_stats by focusing on resolved history and mistakes.
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 states when this tool is appropriate: for self-review of resolved predictions, requiring API key and returning only user data. It does not explicitly name alternatives, but the comparison to siblings is implied by the 'your own data' and 'data only' framing, and the context makes the intended use clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the asset universe by symbol or name. Optional market filter (NYSE|NASDAQ|KRX|KOSDAQ|CRYPTO).
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | Yes | ||
| market | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the burden. It discloses that it searches by symbol/name and supports an optional market filter, but does not detail behavior around limits, result formats, or edge cases. For a read-only search, this partial transparency is adequate but not rich.
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 concise sentences deliver the core purpose and optional filter without waste. The format is front-loaded and efficient.
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 search tool with 3 parameters and no output schema, the description gives the essential query and market guidance. However, it omits the limit semantics and expected return behavior, leaving some gaps for an agent.
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 0%, so the description must compensate. It explains that query is a symbol/name and enumerates market values, but does not mention the limit parameter or its default. This partially compensates for the schema's minimal property 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?
The description clearly states it searches the asset universe by symbol or name, with an optional market filter. This differentiates it from siblings like get_asset (which likely retrieves a specific asset) and get_trending_assets.
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 provides clear context: use this to search for assets by symbol/name, with an optional market filter. However, it does not explicitly state when not to use it or name alternative tools, so it misses the highest bar.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Submit a new price-direction prediction to LDBD. Picks up/down over a timeframe (1d/1w/1m/6m/1y). Optional reasoning explains your thesis (will be public). Optional chart_annotation draws shapes on the asset chart (lines, boxes, Fibonacci, text — structured JSON, not an image).
| Name | Required | Description | Default |
|---|---|---|---|
| direction | Yes | ||
| reasoning | No | Optional public reasoning, max 2000 chars | |
| timeframe | Yes | ||
| asset_symbol | Yes | Ticker symbol, e.g. "VOO" or "005930.KS" | |
| chart_annotation | No | Optional chart shapes (structured JSON, not an image). Shape types: hline{price}, trendline{from,to}, rect{from,to}, fib{from,to} (Fibonacci retracement; from=swing start, to=swing end → auto 38.2/50/61.8% levels), text{at,label}. Anchors are {date:"YYYY-MM-DD",price}. Every shape may carry an optional semantic role ∈ support|resistance|target|stop|trend|mean|neutral (preferred over a label to convey meaning); color ∈ green|red|blue|gray is optional and defaults from role. Example: {interval:"day",range:"1y",shapes:[{type:"hline",price:180,role:"support"},{type:"trendline",from:{date:"2026-01-02",price:150},to:{date:"2026-05-02",price:185},role:"trend"},{type:"fib",from:{date:"2026-01-02",price:200},to:{date:"2026-03-02",price:150}},{type:"text",at:{date:"2026-04-01",price:175},label:"breakout"}]}. Max 20 shapes; prices/dates must match the asset. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description partially carries the transparency burden. It discloses that reasoning is public and that chart_annotation draws shapes on the asset chart (explicitly noting it is structured JSON, not an image). However, it does not mention any authentication requirements, irreversibility, or what happens after submission, which would be valuable for a 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?
The description is front-loaded with the main purpose in the first sentence. The second sentence is concise. The third sentence is long and detailed, but warranted given the complexity of chart_annotation. Overall, it is well-structured, and the length is justified by the need to explain a complex parameter.
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 (5 parameters, nested object, no output schema), the description covers parameter semantics well but omits what the tool returns after submission, any prerequisites (e.g., account/auth), and whether the prediction is immediately public. The absence of an output schema makes the lack of return-value information a noticeable gap.
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 descriptions for only 3 of 5 properties (60% coverage). The tool description compensates by explicitly listing direction values (up/down), timeframe values (1d/1w/1m/6m/1y), clarifying reasoning is public, and providing an extremely detailed explanation of chart_annotation with shape types, roles, and an example. This adds significant meaning 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 uses a specific verb ('Submit') and resource ('a new price-direction prediction to LDBD'), clearly distinguishing it from sibling getter tools. It also specifies the prediction scope (up/down, timeframe), making the tool's function unmistakable.
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 conveys that this tool is for creating predictions, which is distinct from all sibling tools (all get/list operations). It does not explicitly name alternatives or exclusions, but the context is clear enough that an agent would know when to use this tool (when submitting a prediction) versus reading data.
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.
v0.3.0ldbd_get_assetldbd_get_base_ratesldbd_get_chart_indicatorsldbd_get_macro_indicatorsldbd_get_my_statsldbd_get_trending_assetsldbd_list_my_open_predictionsldbd_review_my_track_recordldbd_search_assetsldbd_submit_predictionScored across 10 tools
Each tool has a clearly distinct purpose: market data (indicators, asset info, base rates, macro, trending) versus personal actions (submit prediction, my stats, open predictions, track record). Even the 'my' tools are differentiated by open vs resolved vs summary. No two tools could be easily confused.
All tool names follow the strict ldbd_<verb>_<object> pattern in snake_case. Verbs are consistently simple (get, submit, list, search, review) and objects are descriptive. This is a uniformly predictable naming convention.
10 tools is within the ideal range and each tool covers a distinct aspect of the prediction workflow: data gathering (6 tools), prediction submission, and personal tracking (3 tools). The count feels well-scoped with no obvious bloat or redundancy.
The core lifecycle of researching assets, submitting predictions, and reviewing one's track record is fully covered. Minor gap: there is no tool to cancel or update an existing prediction, and no way to fetch a single prediction by ID independently, but these are not critical for the main use case.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Unlock the power of real-time cryptocurrency data with our Crypto Price Insights MCP server.
Official MCP server for Lovable, the AI-powered full-stack app builder.
7-factor stock scoring MCP server. US/HK/CN, 74 stocks. Free + Premium (USDC/Base). x402 ready.
Read-only MCP server for live Polymarket, Kalshi, Limitless odds; Manifold sentiment.
