mcp-ldbd

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.3.0
Disambiguation5/5
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.
Naming Consistency5/5
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.
Tool Count5/5
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.
Completeness4/5
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.
Average 4.1/5 across 10 of 10 tools scored. Lowest: 3.4/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 4 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior3/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters4/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose4/5
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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior3/5
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.
Conciseness4/5
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.
Completeness3/5
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.
Parameters5/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.
Behavior5/5
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.
Conciseness4/5
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.
Completeness5/5
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.
Parameters5/5
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.
Purpose4/5
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.
Usage Guidelines4/5
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.
Behavior5/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![mcp-ldbd MCP server](https://glama.ai/mcp/servers/kkjh0723/mcp-ldbd/badges/card.svg)](https://glama.ai/mcp/servers/kkjh0723/mcp-ldbd)

Score Badge

Copy to your README.md:

[![mcp-ldbd MCP server](https://glama.ai/mcp/servers/kkjh0723/mcp-ldbd/badges/score.svg)](https://glama.ai/mcp/servers/kkjh0723/mcp-ldbd)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/kkjh0723/mcp-ldbd'

If you have feedback or need assistance with the MCP directory API, please join our Discord server