Funding-mcp

Official

by namixai

Overview Schema Related Servers Score Discussions

JavaScript

Remote

Server Quality Checklist

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

Latest release: v0.4.1
Disambiguation5/5
Each tool targets a distinct aspect of perpetual funding market data: arbitrage screening, history, signal, spread, open interest, volume, orderbook, etc. Even closely related tools like funding_arb and funding_signal have clear differences in scope and detail.
Naming Consistency5/5
All tool names follow a consistent lowercase_snake_case pattern, primarily noun_noun (e.g., funding_arb, volume_24h) or adjective_noun (e.g., open_interest). The naming is predictable and descriptive, with no mixed conventions.
Tool Count5/5
With 12 tools, the server offers a well-scoped set that covers the core domain without being overwhelming or too sparse. Each tool earns its place by addressing a specific data need.
Completeness5/5
The tool surface covers key areas of perpetual funding analysis: funding rates (history, spread, signal, screen), open interest, volume, orderbook slippage, oracle risk, and RWA coverage. There are no obvious gaps for the intended use case of market data retrieval and analysis.
Average 3.6/5 across 12 of 12 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 6 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.
This repository includes a glama.json configuration file.
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

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, yet the only behavioral disclosure is the cost note 'PAID ~$0.001 via x402.' It omits whether the operation is read-only, idempotent, or any rate limits. The cost detail adds value but leaves major behavioral aspects unaddressed.
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 extremely concise: two sentences. The first sentence states purpose, the second adds cost. No wasted words, front-loads the core function.
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 no output schema and no annotations, the description covers the core functionality and cost but lacks details on return format, pagination, common errors, or use cases. For a simple two-parameter tool, it is minimally adequate but could be more 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 description coverage is 100%, with both 'venue' and 'ticker' having clear examples. The description adds no extra meaning beyond 'Venue, e.g. binance' and 'Ticker, e.g. BTC', so baseline 3 is appropriate.
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 'Current open interest for a ticker on a venue' which specifies the verb (get), resource (open interest), and scope (current). It distinguishes from siblings like oi_delta which likely tracks changes. However, it doesn't explicitly state it fetches a single snapshot, and the term 'current' could be clearer.
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 on when to use this tool versus alternatives like oi_delta or funding_arb. The description provides no context for selecting this tool over siblings, nor any prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/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 discloses a cost (~$0.001 via x402), which is a key behavioral trait, but does not mention other aspects like mutability (likely read-only), rate limits, or authentication requirements. The output behavior is not described.
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, each earning its place: first defines purpose, second discloses cost. No redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description should fully explain the tool's behavior. However, 'coverage' is ambiguous (list of assets? prices? details?). The return value is not described, making it incomplete for an agent to use correctly.
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?
With 100% schema description coverage, the baseline is 3. The tool description does not add any additional meaning to the single parameter 'asset_class' beyond what the enum and schema description 'Filter by RWA class' already provide.
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 provides coverage data for Hyperliquid HIP-3 RWA perpetual assets, listing specific asset classes and noting that common aggregators do not cover these. The verb 'coverage' and resource specification are clear, and it distinguishes from sibling tools focused on funding, volume, etc.
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?
The description implies use when needing data on non-standard RWA perpetuals, but does not explicitly state when not to use it or provide alternatives. The sibling tools are in different domains, so context is sufficient but not explicit.
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?
The description discloses that the tool is a paid call costing $0.001 via x402, which is a key behavioral trait beyond the schema. However, it does not mention whether the operation is read-only, what happens if the ticker or venue is invalid, or any rate limits. With no annotations, this partial disclosure is adequate but not comprehensive.
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 with no wasted words. The purpose is front-loaded, and the cost is appended efficiently. Every sentence serves a purpose.
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 two-parameter tool with no output schema, the description explains what it does but omits what the response looks like (e.g., return type, structure). This might force the agent to guess or rely on error handling. The cost note is useful context.
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 simple descriptions ('Venue', 'Ticker'). The description adds no extra meaning beyond restating 'for a ticker on a venue'. The agent receives no hints about format, examples, or allowed values, so the description adds minimal value over the schema.
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 that the tool provides the 24-hour perpetual volume for a specific ticker on a specific venue. The verb 'get' is implied, and the resource and scope are well-defined. It differentiates from siblings like funding_arb and volume_anomalies by focusing on raw volume, but it does not explicitly contrast them.
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 does not provide any guidance on when to use this tool versus alternatives like open_interest or funding_screener. There is no mention of prerequisites, limitations, or typical use cases, leaving the agent to infer usage from the name alone.
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?
Without annotations, the description carries the burden of behavioral disclosure. It mentions a cost ('PAID ~$0.001 via x402'), which is a notable trait. However, it does not disclose whether the tool is read-only, any side effects, or required permissions. The cost adds value but leaves gaps.
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 states the core function, the second adds cost context. Front-loaded and efficient.
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's simplicity (one param, no output schema), the description is fairly complete. It explains what the tool returns (spread across venues, min/max, basis) and the cost. It could be more specific about output format, but overall it provides sufficient context 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 schema has 100% description coverage for the single parameter 'symbol' (described as 'Ticker, e.g. BTC'). The tool description adds no additional meaning beyond that. Baseline of 3 is appropriate.
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 provides the 'current funding-rate spread for one symbol across all venues (min/max venue, basis)', which is specific. However, it lacks an explicit verb like 'get' or 'retrieve', making it slightly less direct. It distinguishes from siblings like funding_history (history) and funding_screener (screener) but not explicitly from funding_arb.
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 gives no guidance on when to use this tool versus alternatives. It does not mention when to use funding_spread instead of funding_arb or other related tools. No exclusions or prerequisites are provided.
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?
The description discloses the tool is paid (cost ~$0.003) but does not cover other behavioral traits like data freshness, return format, or error conditions. With no annotations, the description partially carries the burden but is lacking depth.
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 one sentence plus cost, front-loaded with key information. No fluff, though the cost could be presented separately for clarity.
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 no output schema and simple parameters, the description covers the main purpose but lacks detail on output format (e.g., numeric value, percentage) and whether it's absolute or relative change.
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%, so baseline is 3. The description adds the 'lookback window' context but does not enhance parameter meaning beyond what the schema already provides (e.g., '1-168, default 24').
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 computes open-interest change over a lookback window for a specific ticker and venue, distinguishing it from sibling tools like plain `open_interest` or `funding_*` tools.
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 on when to use this tool vs alternatives, nor any when-not-to-use information. It merely describes what it does without contextual usage advice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It only discloses the cost ($0.005 via x402) but does not mention if the tool is read-only, rate limits, or any other behavioral traits beyond being a paid operation.
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-loading the purpose and succinctly adding cost info. Every word earns its place with no redundancy or fluff.
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 has no output schema and no annotations, the description explains the use case and cost but lacks details on return format or behavior (e.g., whether data is aggregated per venue or per time bucket). It is adequate but not comprehensive.
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 provides 100% coverage for all four parameters with clear descriptions. The description adds minimal extra meaning (e.g., 'across venues' is implied by schema), so the schema already handles param semantics adequately.
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 that the tool provides historical funding rates for a symbol across venues, specifically for backtesting and analysis. This distinct purpose differentiates it from siblings like funding_arb (arbitrage) or funding_screener (screening).
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?
The description indicates usage for backtesting/analysis, implying it is for historical data. However, it does not explicitly exclude real-time use or provide guidance on when to prefer this over sibling tools like funding_signal or funding_spread.
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 full burden. It discloses that the tool is a 'preview' (read-only) and 'no wallet required,' which implies low risk. However, it does not describe rate limits, data freshness, or whether the output is real-time or delayed, which is acceptable for a preview tool but leaves some uncertainty.
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, efficient sentence that conveys the tool's purpose and key differentiators (free, no wallet, multiple exchanges). No unnecessary words, and front-loaded with the core action.
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's simplicity (one optional param, read-only preview), the description is mostly complete. It covers purpose, scope (20+ exchanges), and requirements (none). Missing details about output format or return structure are acceptable since no output schema exists and the tool is a simple data feed.
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 the single optional parameter 'symbol' with an example. The tool description does not add additional parameter details, but the schema already provides clear meaning. Baseline 3 is appropriate as the description neither adds nor detracts from parameter understanding.
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 preview of current cross-venue perpetual funding rates across 20+ exchanges, with specific examples. The verb 'preview' and resource 'funding rates' are precise, and it implicitly differentiates from siblings like funding_arb or funding_history by focusing on a broad overview.
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 on when to use this tool versus alternatives like funding_arb, funding_history, or funding_spread. The description mentions it's free and requires no wallet, but does not specify contexts where this tool is preferred or when to use the optional symbol filter.
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 provided, so description carries full burden. It adds cost information (~$0.003 via x402) but does not disclose other behavioral traits like rate limits or authentication.
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: first states core function, second mentions cost. No wasted words, front-loaded with key 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?
For a simple list tool with well-described parameters and no output schema, the description adequately explains output (tickers with anomalies). Slightly incomplete on return format details.
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 clear parameter descriptions. The tool description adds no additional parameter meaning beyond the schema, so 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?
Description clearly states it identifies tickers with anomalous volume spikes for flow detection, distinguishing it from sibling tools like volume_24h and funding_arb.
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 explicit when-to-use or when-not-to-use guidance; only 'flow detection' implies a use case but no alternatives or exclusions are provided.
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 full burden. It discloses the cost (~$0.001) and hints at the output (basis-risk map) but does not state whether the tool is read-only, requires authentication, or has side effects.
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 with no wasted words. The purpose is front-loaded, and the cost note is a separate sentence. Ideal conciseness for a zero-parameter tool.
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 no parameters, no annotations, and no output schema, the description should fully set expectations. It explains the purpose but does not describe the output format or structure, leaving the agent somewhat uncertain about the return value.
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 0 parameters and 100% schema coverage, giving a baseline of 4. The description does not add parameter info but that is not needed since there are none.
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 the tool provides oracle-family grouping across venues to create a basis-risk map. This is specific and distinct from sibling tools like funding_arb, oi_delta, etc., which focus on funding or order book data.
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 does not provide guidance on when to use this tool versus alternatives. It mentions a cost but no context on scenarios or prerequisites, leaving the agent to infer usage from the purpose alone.
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?
The description discloses that the tool costs $0.005 via x402, which is relevant behavioral context. However, it does not mention failure modes, rate limits, or data freshness. With no annotations, it carries the burden but adds only one behavioral trait.
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 concise (two sentences) and front-loaded with purpose. The second sentence adds essential payment info. No wasted words, though could be slightly more 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?
For a simple tool with two parameters and no output schema, the description adequately explains what it does and its cost. However, it lacks description of the return format or error handling, leaving some gaps.
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?
Schema coverage is 100%, and the description adds value by explaining that the tool finds the cheapest venue for a given size. This goes beyond the schema's basic parameter descriptions, clarifying output context.
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 computes multi-venue execution cost/slippage for a given ticker and trade size, and identifies where the ticker is cheapest to execute. This distinguishes it from sibling tools like funding_arb or volume_24h, which deal with different financial metrics.
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?
The description implies usage when needing execution cost across venues and mentions payment via x402, but does not explicitly state when to use this tool over alternatives or provide exclusions. Agents must infer context from sibling tool names.
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 full burden. It discloses the tool computes facts (not profit forecast), is decision-ready, and includes pricing. However, it omits details on authorization, rate limits, or data freshness, though it covers the core behavioral traits well.
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 single dense sentence that front-loads the key concept and efficienty lists outputs and pricing. Each element is valuable, but the high density could be slightly improved with structured formatting. Score 4 for being concise yet informative.
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 adequately explains the output structure (net fees, break-even, max notional, liquidity flag) and distinguishes from siblings. It lacks explicit details on authentication or limits, but overall covers essential aspects for a signal 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?
Schema coverage is 100% so baseline is 3. The description does not add extra meaning to the parameters (min_diff, limit) beyond their schema definitions. It focuses on outputs, not parameter 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 provides 'DECISION-READY funding-arb SIGNAL' and explicitly distinguishes it as the 'sell-the-outcome upgrade over funding_arb'. It lists specific outputs (e.g., net of fees, break-even periods, max notional, liquidity flag) making the purpose unambiguous and differentiating from siblings.
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?
The description implies use for funding arbitrage signal decisions and calls it an 'upgrade over funding_arb', but does not explicitly state when to use this tool versus others like funding_history or funding_screener, nor provide exclusions or context for alternatives.
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 bears full responsibility. It discloses the tool is a naive scan that ignores fees, latency, and execution timing, and that it costs ~$0.003 via x402. This transparency about limitations and cost is strong, though no mention of data freshness or recurrence.
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 core purpose and key limitations. Every sentence adds value; no redundant or filler content.
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's complexity (cross-exchange arbitrage across 20 venues) and lack of output schema, the description covers the main purpose, limitations, and payment. It could be enhanced by briefly noting the output format (e.g., a table of ranked pairs with spreads), but overall sufficient.
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 descriptions for both parameters (min_diff and limit). The description does not add new information beyond the schema; it reuses the concept of 'funding-rate diff' but not specifically min_diff. Baseline 3 is appropriate as schema already covers meaning.
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 clearly states it identifies cross-exchange funding-rate arbitrage candidates, ranking long/short venue pairs by funding spread across 20+ venues. The verb 'arbitrage' and resource 'funding-rate' are specific, and the tool is distinguished from siblings like funding_screener or funding_spread by focusing on arbitrage candidates.
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 context for when to use the tool: 'Naive scan — excludes fees/latency/execution timing' implies it is for preliminary screening, not final execution. It also mentions payment via x402. No explicit alternatives or when-not-to-use, but the limitations guide appropriate usage.
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:

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

Score Badge

Copy to your README.md:

[![funding-mcp MCP server](https://glama.ai/mcp/servers/namixai/funding-mcp/badges/score.svg)](https://glama.ai/mcp/servers/namixai/funding-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/namixai/funding-mcp'

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