bykaranteli-mcp

Server Quality Checklist

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

Latest release: v0.5.0
Disambiguation5/5
Every tool targets a distinct data type or metric: sentiment, liquidity, ETF flows, funding rates, arbitrage, pressure, movers, signals, performance, leaderboard, COT, options, premium, toxicity, flow, and slippage. Overlapping concepts like funding heatmap vs. arbitrage are clearly separated by exchange vs. single-exchange scope, and tools cross-reference each other to route to the right call.
Naming Consistency5/5
All tools follow the consistent 'get_' + snake_case noun pattern (e.g., get_etf_flows, get_options_snapshot). Names are descriptive and predictable, with no mixing of verb styles or casing. The pattern makes it easy to infer what each tool does from its name alone.
Tool Count4/5
With 16 tools, this is slightly over the typical 3-15 well-scoped range, but the count is justified by the server's broad derivatives and market-flow domain. Each tool covers a distinct analytical area, and none feels redundant or superfluous.
Completeness5/5
The server provides comprehensive coverage for its apparent purpose of crypto derivatives and flow analytics: current sentiment, funding, liquidations, options, signals, and performance. There are no dead ends—each tool offers a complete view of its metric, and historical data is available where relevant. The only possible gap is raw price data, but that falls outside the stated derivatives/flow focus.
Average 4.5/5 across 16 of 16 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 15 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

Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint and openWorldHint. The description adds that results are one row per finalized US trading day, denominated in USD, and covers about 14 months of history, providing a clear picture of data granularity and temporal range.
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 sentences, front-loaded with usage instruction, followed by a compact description of output fields and data history. No redundant phrases.
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?
The description fully explains the output structure (row per day/asset, fields), which compensates for the lack of an output schema. It also covers history length and data currency, making it sufficient for the tool's simple interface.
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 schema already provides 100% parameter descriptions (days and asset). The description does not add additional parameter-level detail, so it meets the baseline but does not exceed it.
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 direct instruction ('Call this when the user asks about Bitcoin or Ethereum ETF flows') and enumerates specific metrics (daily net inflows/outflows, cumulative flow, total net assets) and example ETFs (IBIT, FBTC, ETHA). This clearly distinguishes it from sibling tools focused on different market 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?
The description explicitly states when to invoke ('when the user asks about Bitcoin or Ethereum ETF flows') and outlines the range of queries it satisfies. It does not mention alternatives, but no sibling tool covers ETF flows, making the use case unambiguous within the toolset.
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?
Annotations already declare readOnlyHint and openWorldHint, which sets the safety baseline. The description adds value by specifying the data source ('live verified track record'), the market type ('Binance USDT-M perp'), and the timeframe windows (30/90/180 days), giving the agent crucial context beyond the annotations.
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 sentences, front-loaded with the invocation trigger. Every clause provides useful information: when to call, what to return, data source, and scope. No fluff or redundancy.
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?
For a two-parameter tool with thorough schema descriptions and read-only annotations, the description is complete. It covers output metrics, recent closed signals, the trading venue, and the lookback window. Since there is no output schema, the description adequately explains return value semantics.
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% with descriptive parameter details (e.g., symbol format and window_days allowed values/default). The description adds no new parameter-level information beyond what the schema provides; it merely restates the window options and coin scope. Thus 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?
The description clearly states the tool's purpose: reporting per-symbol signal performance (win rate, profit factor, net PnL, best/worst trade) and recent closed signals for a specific coin. It distinguishes from siblings by emphasizing 'specific coin' and 'one Binance USDT-M perp', contrasting with tools like get_recent_signals.
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?
Explicitly provides when-to-use guidance ('Call this when the user asks how signals performed on a specific coin...'). It gives clear context and even a second use case (recent closed signals). However, it does not explicitly name alternative tools or state when not to use, 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?
The description defines the VPIN scale (0=balanced, 1=fully one-sided) and adds interpretive context ('Elevated readings historically precede volatility'), which goes beyond the readOnlyHint annotation. It honestly caveats that VPIN says nothing about direction, improving the agent's understanding of the tool's limitations. The annotation and description are consistent; no contradiction.
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, each with a distinct purpose: trigger condition, output description, and interpretive caveat. It is front-loaded with a clear 'Call this when' opening and contains no filler or redundant information.
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 zero-parameter read-only tool without an output schema, the description is complete enough: it names all key return values, defines the metric's meaning, and provides a historical interpretation. It stops short of exact formatting, but that's acceptable given the simple output structure and the read-only annotation.
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 baseline for parameter semantics is high. The description doesn't need to explain input syntax but instead clarifies the output fields (VPIN, percentile, danger threshold, 24h average), adding meaningful value beyond the empty 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 clearly states the tool's purpose with specific trigger phrases ('when the user asks whether informed or toxic order flow is building, about VPIN, or whether market makers are under pressure') and names the exact assets (BTC, ETH, SOL perps). It distinguishes itself from sibling tools by focusing on toxicity/VPIN, a unique metric not covered by the listed siblings.
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 explicit when-to-use guidance with concrete user intents ('when the user asks...'). It also gives a when-not signal by stating 'VPIN says nothing about direction,' which helps avoid misuse. While it doesn't name alternative sibling tools, its scope is explicit and the sibling list makes alternatives evident.
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?
Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds valuable context beyond annotations by describing the snapshot nature ('Daily snapshot'), asset coverage (Bitcoin/Ethereum), and the exact analytical components returned (top strikes, put/call ratio, dealer hedging map, ATM IV by expiry).
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 two sentences: the first is an action-oriented trigger list, and the second enumerates the content of the snapshot. Every word earns its place; no filler or repetition of schema information.
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?
Without an output schema, the description clearly outlines the main return components (strikes, put/call ratio, hedging map, ATM IV by expiry). It could be slightly more explicit about the time period or update frequency, but the 'daily snapshot' label provides adequate context for a zero-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, and the schema coverage is 100%, so there is no parameter burden for the description to address. The description accurately conveys that the tool is a fixed-scope snapshot without requiring user input, satisfying the baseline for parameterless tools.
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 the tool returns a daily snapshot of listed crypto options with specific content: top strikes, put/call ratio, dealer hedging map, and ATM IV by expiry. The trigger phrases 'options walls', 'gamma exposure', 'DVOL', and 'IV term structure' precisely define the scope and distinguish it from the sibling get_options_flow (which likely focuses on individual flow events).
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 starts with 'Call this when the user asks...', giving explicit usage triggers and listing covered topics. It does not explicitly state when not to use it or mention alternative tools, but the trigger list is specific enough to guide selection in most cases.
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?
The description discloses the scoring methodology (funding rate, 1h/4h/24h OI deltas, basis) and output fields (direction, regime label), which goes beyond the readOnlyHint=true and openWorldHint=true annotations. This doesn't contradict the annotations (which indicate a safe, read-only, open-world operation) and adds useful behavioral context about how the score is computed.
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 exactly two sentences, with the use case front-loaded first, the alternative tool second, and the output composition in the same first sentence. Every phrase contributes to understanding when and how to use the tool, with no filler or repetition.
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?
Given the tool has no output schema, the description does well to explain the nature of the result (composite 0-100 score, direction, regime label). It also mentions symbol filtering and ranking. While it doesn't spell out default limits or pagination, those are covered in the parameter schema, so the description is complete enough for a straightforward read-only query tool.
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 clear descriptions for both parameters (limit and symbol), so the description adds no extra semantic detail. However, it does implicitly reference the 'symbol' parameter ('specific coins') and the 'limit' parameter ('top-10 ranking'), reinforcing their usage. Since schema coverage is 100%, the baseline 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 clearly states the tool's purpose: it returns crowded/over-leveraged coins or a derivatives-stress score for specific coins. It also describes the output components (0-100 composite score, direction, regime label), making the tool's function unambiguous. It distinguishes itself from the sibling get_top_movers by naming that tool as an alternative for a different use case.
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?
The description explicitly states when to use this tool: 'when the user asks which coins are crowded or over-leveraged, or asks for the pressure/derivatives-stress score of specific coins.' It also gives an explicit exclusion: for a quick top-10 ranking, 'use get_top_movers instead.' This is clear, actionable guidance for an AI agent to select between tools.
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?
Annotations already indicate readOnlyHint=true, so safety is covered. The description adds valuable context beyond annotations: rankings are based on live closed signals only (no backtests) and are net of fees. This helps the agent interpret results correctly. It doesn't cover pagination or return format, but the core behavioral 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with a clear usage trigger, and every sentence adds value: the first defines the use case and metrics, the second clarifies the data source and fee treatment. No fluff or redundancy.
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?
With no output schema, the description carries the burden of explaining return values. It lists the specific metrics (win rate, profit factor, drawdown, Sharpe) and states the computation basis. It does not specify the ranking sort order or output structure, but for a parameterless tool this is largely complete.
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 is empty with 100% coverage vacuously. Per the baseline for 0 params, a score of 4 is appropriate. The description does not need to add parameter semantics since none exist.
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 the tool provides a strategy leaderboard with specific performance metrics (win rate, profit factor, drawdown, Sharpe). The verb 'Call this when the user asks which trading strategies are performing best' gives a specific use case, and the focus on strategy performance distinguishes it from sibling tools like market indices or liquidations.
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 explicitly states when to use the tool ('Call this when the user asks which trading strategies are performing best'), and clarifies what the rankings include. It does not mention explicit alternatives or when-not-to-use, but the trigger condition is clear and actionable.
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?
The annotations declare readOnlyHint and openWorldHint, but the description adds that the tool returns four top-10 lists in one call, which is a key behavioral aspect not covered by annotations. This helps the agent set expectations about output structure without needing an output schema.
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 sentences, front-loaded with usage trigger, and a clear list of content categories. Every word earns its place; no fluff or repetition.
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?
Given the tool has no parameters and no output schema, the description reasonably covers return structure (four top-10 lists) and the domains it spans. It could specify more detail (e.g., exact field names or time period) but is adequate for a zero-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 and 100% schema description coverage, so there are no parameters needing explanation. Per the rubric, 0 parameters warrants a baseline score of 4.
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 the tool's purpose: it returns top movers in crypto derivatives across four dimensions (OI spikes, extreme funding, widest basis, highest stress). It distinguishes itself from siblings like get_funding_heatmap or get_pressure_scores by aggregating multiple top-10 lists into a single call.
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 opening phrase 'Call this when the user asks...' explicitly lists the exact query types for which this tool is appropriate. It does not explicitly mention alternatives or when not to use it, but the context makes it clear this is the go-to tool for broad 'what is moving' questions.
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?
Annotations already mark it read-only and open-world. The description adds useful context about the output fields (funding rate, OI change, price change) and explains the funding interpretation (longs pay shorts), going beyond the annotation hints.
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?
Three concise sentences, front-loaded with the primary use case, then an exception, then return details. Every sentence earns its place with no redundancy.
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?
Despite no output schema, the description fully covers what the tool returns (per-symbol funding rate, 24h OI change, 24h price change) and the interpretation, making it self-sufficient for a simple optional-parameter tool.
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 schema already documents the single optional 'symbol' parameter with filtering and default behavior (omit to get all 30 rows). The description confirms this but adds little beyond schema coverage, so 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?
The description clearly states the tool returns funding rates for the top-30 Binance perp universe or a single coin, with a specific verb ('Call this... Returns') and distinguishes it from sibling get_top_movers.
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 specifies when to call (user asks for full table or one coin's funding rate) and provides an alternative (get_top_movers for top-10 extremes), making the decision clear.
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?
Beyond the readOnlyHint annotation, the description discloses the data source (ByKaranteli's own Binance, Bybit, and OKX stream collectors), that values are a floor (not estimates), the row granularity (one row per finalized UTC day, symbol, exchange), and the history start date (2026-07-30). This is rich behavioral context that annotations do not provide.
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: the first gives usage trigger and output; the second explains data source and caveats; the third defines row granularity and history. It is front-loaded, concise, and every sentence adds value.
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?
For a simple read-only tool with two optional parameters and no output schema, the description explains the output shape (daily long/short totals per symbol/exchange), data source, caveat (floor), and history start. No critical context is missing.
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 description coverage is 100% for both parameters (days and symbol) with clear descriptions. The tool description does not add additional meaning beyond the schema, so 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?
The description clearly states the tool returns daily long and short liquidation totals in USD per symbol and exchange, specifically for crypto futures. It uses a specific verb ('returns') and resource ('liquidation totals'), and is easily distinguished from sibling tools like get_market_indices or get_funding_heatmap.
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 opens with explicit when-to-use guidance: 'Call this when the user asks how much was liquidated... or for liquidation history.' It does not explicitly mention when-not-to-use or name alternative tools, but given the distinct sibling tools, the context is clear.
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?
Annotations already declare readOnlyHint and openWorldHint, and the description adds useful context: the refresh interval ('about every 30 minutes') and the specific data components returned. It does not contradict annotations and adds value beyond the structured metadata.
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 two sentences, front-loaded with the invocation trigger, and lists all relevant metrics in a compact, readable manner. Every sentence provides essential information without redundancy.
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?
For a tool with no parameters and no output schema, the description fully covers when to use it, what data it returns, and the data freshness behavior. It is complete for a zero-parameter data retrieval 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 baseline is 4. The description appropriately explains what data is returned without needing to explain parameter usage, and the schema already confirms no parameters exist.
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 explicitly states the tool returns overall crypto market sentiment and macro state indicators, listing specific metrics (Fear & Greed index, Bitcoin dominance, total market cap, Retail Euphoria composite). This clearly distinguishes it from sibling tools that focus on liquidations, ETF flows, or funding rates.
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 begins with 'Call this when the user asks about overall crypto market sentiment or macro state,' providing explicit guidance on when to invoke the tool. It does not explicitly mention when not to use it or name alternatives, but the contextual scope is clear.
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?
Annotations already declare readOnlyHint and openWorldHint, and the description adds useful context: the 24-hour premium comparison, block-trade share, 48-hour largest prints, and a 15-minute update cadence. This goes beyond the annotations by explaining data scope and freshness.
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 two sentences long, front-loaded with use cases, and every clause adds value. It efficiently communicates what the tool returns and how often it updates without redundancy.
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 the zero-parameter tool with no output schema, the description adequately lists the returned data types (call vs put premium, block-trade share, largest prints with strikes/premium/IV) and update frequency. It is complete for the tool's simplicity.
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 takes zero parameters, so the description does not need to explain parameter semantics. The baseline for no parameters is 4, and the description provides sufficient content detail without any param ambiguity.
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 'Call this when' and clearly identifies the resource: options flow, including block trades and premium. It distinguishes itself from siblings by focusing on big player activity and premium flow rather than market indices, liquidations, or funding 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?
The description provides clear context for when to use the tool: when users ask about big options players, block trades, or call vs put premium dominance. It does not explicitly name alternatives or exclusions, but the use cases are specific enough to guide selection.
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?
Annotations already declare read-only and open-world hints. The description adds meaning beyond this: positive premium equals US buying pressure, history since 2017, and the specific metrics returned. No contradictions and no hidden behaviors.
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?
Three sentences, front-loaded with the call trigger, and every clause is informative. No filler or redundancy; it efficiently packs purpose, output details, and interpretation.
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 zero parameters and no output schema, the description fully compensates by enumerating the output fields and time horizons. It provides enough context for an agent to invoke the tool and interpret results, even fitting in historical depth and semantic meaning.
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 schema baseline is 4. The description goes beyond by explaining the semantics of the returned data (premium percent, buy pressure), which is valuable even though parameters are absent.
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 identifies the tool as a Coinbase Premium indicator for US buying/selling pressure and cash-and-carry yields. It specifies exactly what it returns (daily premium, 7-day average, streak, 30 days, carry yields) and distinguishes it from siblings like funding or pressure tools.
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?
Explicitly states when to call: when the user asks about US investor buying/selling, Coinbase Premium, or cash-and-carry basis trade. It does not mention exclusions or alternatives, but the context is clear enough to avoid mis-selection among siblings.
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?
Beyond the readOnly and openWorld annotations, the description adds valuable context: data comes from 'official CFTC data updated every Friday,' and it warns that 'a large share of hedge fund shorts is the market-neutral basis trade, so the weekly change carries more signal than the level.' This is non-obvious behavioral information that helps interpretation.
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 two sentences: one for usage and output, one for an interpretive caveat. Every sentence adds value, and the most important information (when to call) is front-loaded.
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?
For a tool with no parameters and no output schema, the description correctly covers the data source, update frequency, the key data points returned, and a critical interpretation nuance. It is sufficiently complete for an agent to decide when to call and what to expect.
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 (schema is empty), so the parameter description baseline is 4. The description does not need to explain parameters; it focuses on the output instead, which 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 states a clear action: 'Call this when the user asks how hedge funds or institutions are positioned in Bitcoin or Ethereum' and specifies the output: 'Returns net positions in contracts, week-over-week changes, open interest and notable extremes/streaks.' This distinguishes it from sibling tools like ETF flows or liquidations.
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 an explicit when-to-use: 'Call this when the user asks... about the CFTC Commitments of Traders report.' It also explains what the tool returns, but does not mention when not to use it or suggest alternative tools, 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.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true and openWorldHint=true. The description goes further by detailing what the tool computes and returns—best long/short venue per symbol, gross and net annualized APR, with explicit costs (taker fees and weekly rebalance). This adds meaningful behavioral context beyond the annotations.
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 sentences, no wasted words. The first sentence gives the usage trigger; the second covers exchange coverage, symbol count, and output details. Front-loaded and highly scannable for an agent.
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?
The description fully explains what the tool does, which exchanges and symbols are covered, and what the output contains. Given zero parameters and no output schema, this is sufficient for an agent to invoke and interpret results correctly.
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 there is no parameter-specific burden on the description. The description compensates by explaining the output semantics (best venue, net APR) even though no input schema details are needed. This aligns with the baseline for zero-parameter tools.
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 explicit trigger phrasing ('Call this when the user asks about funding arbitrage...') and then specifies the exact function: comparing funding across six exchanges and 12 perps. This clearly differentiates it from siblings like get_funding_heatmap by focusing on arbitrage opportunity discovery rather than general heatmap visualization.
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?
Provides clear when-to-use conditions: funding arbitrage, funding rate differences, or delta-neutral carry trades. It does not name alternative tools for other cases, but the trigger context is explicit and sufficiently bounded for an agent to route accurately.
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?
Even with readOnlyHint=true, the description adds significant context: results are net of fees, slippage, and funding, every signal has a SHA-256 receipt, and only live signals are included. This goes beyond the basic read-only annotation and helps the agent understand data provenance and content.
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 two sentences, front-loaded with the call-to-action and followed by concise important constraints. Every sentence adds value: the first defines the content, the second adds quality and authenticity details. No fluff.
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?
With no parameters and no output schema, the description fully covers what the agent needs to know: the trigger context, the result types (TP1, SL, TIMEOUT), net bps, 24h summary, and verification via receipt. It distinguishes live signals from backtests, making the tool's purpose complete.
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 has zero parameters, which gives a baseline of 4. The description reinforces that calling is a simple auto-trigger with no configuration, though it doesn't explicitly state 'no parameters'. It does explain what will be returned, which is useful.
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 what the tool does: it returns recent closed LONG/SHORT signals with verified outcomes (TP1, SL or TIMEOUT), including net basis-point results and a 24h summary. This is specific and distinct from sibling tools, which focus on market data rather than signal engine performance.
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 an explicit trigger: 'Call this when the user asks how the ByKaranteli signal engine is doing today, or wants recent closed LONG/SHORT signals...' It also excludes backtests ('live signals only, never backtests'). However, it does not explicitly compare to alternative tools, though none appear closely related.
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?
Beyond the readOnlyHint and openWorldHint annotations, the description adds meaningful behavioral details: it covers both sides, uses the full visible order book, explicitly excludes fees, and explains that null means the book cannot absorb that size. This gives the agent a clear picture of edge cases and output interpretation.
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 two front-loaded sentences with no filler. It leads with when to call the tool, then packs scope, content, and edge-case semantics into a compact, highly readable format.
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?
With no output schema, the description fully explains what is returned (cost ladders, basis points, sizes, both sides, 8 perpetuals) and how to interpret null values. This is complete enough for an agent to invoke the tool and understand the result without needing further documentation.
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 schema already conveys there is nothing to configure. The description adds useful context about the size range covered ($10K to $5M), aligning with the '0 params = baseline 4' guidance.
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 the tool's function: it returns live cost ladders in basis points for market order sizes from $10K to $5M across 8 perpetuals. It also distinguishes this from sibling tools by specifying use cases like slippage, book thickness, and thinnest market.
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 gives explicit invocation guidance ('Call this when the user asks...') and lists three relevant user intents. However, it does not explicitly mention when not to use it or name alternative sibling tools, so it falls just 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.

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:

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

Score Badge

Copy to your README.md:

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

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/bykarantelicom/bykaranteli-mcp'

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