usenami-mcp

Name: usenami-mcp
Author: namixai

Official

by namixai

Overview Schema Related Servers Score Discussions

JavaScript

Local

@usenami/mcp-server

MCP server giving AI agents (Claude Desktop, Cursor, MCP-aware clients) direct access to Usenami — a multi-venue perpetual futures funding rate & real-world-asset spread API built for arb-aware agents.

Bazaar listing: https://agentic.market/services/api-usenami-io
API base: https://api.usenami.io
Paid via x402 USDC on Base mainnet (Coinbase CDP Facilitator)

Tools

Free (no wallet required)

Tool	Description
`usenami_venues_list`	Catalog of perpetual futures venues Usenami tracks (CEX + DEX, incl. Hyperliquid HIP-3 sub-venues).
`usenami_venues_health`	Last-update timestamps + freshness status per venue. Use to verify currency before a paid call.

Paid ($0.001 USDC each, requires `X402_PRIVATE_KEY`)

Tool	Description
`usenami_funding_current`	Per-venue funding rates across 30+ exchanges. Optional `symbol` filter (`BTC-PERP`, `ETH-PERP`, …).
`usenami_perp_funding_spread`	Cross-venue funding-rate spread snapshot for a base ticker. Returns long-side / short-side venues + spread in bps.
`usenami_perp_oracle_families`	Oracle price-source family classification. Identify venues that share a price source (no genuine arbitrage edge between same-family pairs).
`usenami_rwa_perp_coverage`	RWA perpetual coverage on Hyperliquid HIP-3 DEXes. 6 sub-venues × ~139 tickers across stocks / metals / forex / commodities / indices / pre-IPO synthetics. Optional `asset_class` filter.

Related MCP server: hyperd-mcp

Setup — Claude Desktop

Add to ~/Library/Application Support/Claude/claude_desktop_config.json (macOS) or %APPDATA%\Claude\claude_desktop_config.json (Windows):

{
  "mcpServers": {
    "usenami": {
      "command": "npx",
      "args": ["-y", "@usenami/mcp-server"],
      "env": {
        "X402_PRIVATE_KEY": "0xYOUR_PRIVATE_KEY"
      }
    }
  }
}

Restart Claude Desktop. The 6 tools appear in the tool drawer.

X402_PRIVATE_KEY is optional — the 2 free tools work without it. Paid tools return a clear error if the env is missing.

Setup — Cursor

In Cursor settings → MCP, add the same JSON block as above. Cursor invokes the server via stdio.

Wallet preparation

X402_PRIVATE_KEY must be an EVM private key of a wallet holding USDC on Base mainnet:

USDC contract: 0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913
Network: Base mainnet (chain id 8453)
Suggested minimum: 0.05 USDC (~50 paid calls of headroom)
No ETH needed — the Coinbase CDP Facilitator covers gas via EIP-3009 meta-transactions.

Pricing is $0.001 USDC per paid call. Settlement is on-chain, irrevocable, no subscription.

Local development

npm install
npm run build
node dist/index.js   # talks JSON-RPC over stdio — use MCP Inspector to drive it

For dev (no build step):

npm run dev

To test a paid tool manually:

X402_PRIVATE_KEY=0x... npm run dev
# Then in another terminal use @modelcontextprotocol/inspector

What you get back — response shapes

All paid responses are JSON. Examples:

usenami_funding_current → { symbol: "BTC-PERP" | null, rates: [{ source_id, venue, symbol, rate, updated_at }, ...] }

usenami_perp_funding_spread → { ticker, venues_count, spread: { ticker, long_venue, long_rate, short_venue, short_rate, spread_bps, updated_at } | null }

usenami_perp_oracle_families → { families: [{ family, method, venues }, ...], total_venues }

usenami_rwa_perp_coverage → { items: [{ ticker, venue, asset_class, funding_rate, updated_at }, ...], tickers_count, venues_count }

Architecture

Transport: stdio (Claude Desktop, Cursor, MCP Inspector). Streamable HTTP remote planned for v0.2.
Payment: x402-fetch wraps fetch — intercepts 402 responses, signs EIP-3009 authorization with the local wallet, retries with the X-Payment header. Wallet PK never leaves the local process.
Custody: zero — there is no MCP-side wallet. The customer brings their own PK.

Differentiation vs CoinGecko / CMC

Usenami is perp-first: funding rates and venue spreads are the primary product, not an afterthought. The two unique offers:

Oracle family disclosure — explicit basis-risk awareness. Cross-venue strategies between same-family venues (cex_aggregated, pyth_stork, etc.) carry no real edge; Usenami exposes this directly.
RWA on HIP-3 — 139 RWA tickers (stocks, metals, forex, commodities, pre-IPO) on Hyperliquid HIP-3 sub-venues. CoinGecko/CMC have no comparable surface.

License

MIT

Available Tools

6 tools

usenami_funding_currentCurrent Funding Rates (per venue)A

Read-onlyIdempotent

Returns current funding rates per venue for a given perp symbol, or all symbols if symbol is omitted. Covers 30+ CEX + DEX venues. Cost: $0.001 USDC per call (x402 on Base mainnet).

ParametersJSON Schema

Name	Required	Description	Default
`symbol`	No	Optional perp symbol filter (e.g. 'BTC-PERP', 'ETH-PERP'). Omit for all symbols across all venues.

TDQS

A4/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already indicate read-only, non-destructive, idempotent behavior. Description adds useful context: covers 30+ venues and cost per call, enhancing transparency without 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?

Three concise sentences: purpose, coverage, cost. Every sentence adds value, front-loaded with primary 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?

Adequate for a simple read-only data retrieval tool with a single optional parameter and no output schema. Could mention return format, but not critical given clarity.

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?

Input schema has 100% coverage with clear description of the optional symbol parameter. Description merely reiterates this, adding no new 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 uses specific verb 'Returns' and resource 'current funding rates per venue'. Clearly distinguishes from sibling tools like usenami_perp_funding_spread by focusing on current rates.

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?

Provides context for when to use (specific symbol or all symbols) and cost guidance, but does not explicitly state when not to use or compare with alternative sibling tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

usenami_perp_funding_spreadCross-Venue Funding Spread for a TickerA

Read-onlyIdempotent

Returns the cross-venue funding-rate spread snapshot for a base ticker. Identifies the long-side (lowest rate) and short-side (highest rate) venues and reports the spread in basis points — the directional edge for a funding-rate arbitrage. Cost: $0.001 USDC per call.

ParametersJSON Schema

Name	Required	Description	Default
`ticker`	Yes	Base ticker (e.g. 'BTC', 'ETH'). Required.

TDQS

A4/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, openWorldHint=true, so the tool's safety profile is clear. The description adds the cost ($0.001 USDC per call) and states it returns a snapshot with specific components (spread in basis points). It does not contradict annotations, and provides valuable additional behavioral context beyond what annotations cover.

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 plus a cost note. It immediately states the main function, then details the output components. Every sentence adds value with no redundancy. Front-loaded with the core purpose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple snapshot tool with one parameter and no output schema, the description covers purpose, output components, cost, and usage context (arbitrage). Minor gaps include lack of error handling for invalid tickers or network issues, but these are not critical given the tool's simplicity and the schema's validation. Overall, it provides sufficient context for an agent to use it 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?

The only parameter 'ticker' is fully covered in the input schema with a description, pattern, and example. The description does not add any further meaning about the parameter beyond what the schema provides. Schema coverage is 100%, 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 uses specific verbs ('Returns the cross-venue funding-rate spread snapshot') and identifies the resource (base ticker). It clearly explains that it identifies long-side and short-side venues and reports the spread in basis points, which distinguishes it from siblings like usenami_funding_current (which likely returns a single venue's rate). The arbitrage context further clarifies its unique role.

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 for funding-rate arbitrage by mentioning 'directional edge', but it does not explicitly state when to use this tool vs. alternatives (e.g., usenami_funding_current). There are no 'when-not-to-use' statements or comparisons to sibling tools. The usage context is implied but not formally guided.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

usenami_perp_oracle_familiesOracle Price-Source Family MapA

Read-onlyIdempotent

Returns the oracle family classification for 30+ perp venues — useful for basis-risk awareness in cross-venue strategies. Venues sharing a price source (e.g. 'cex_aggregated', 'pyth_stork') tend to move together and offer no genuine arbitrage edge. Cost: $0.001 USDC.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.5/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true and idempotentHint=true. The description adds value by specifying the scope (30+ venues) and cost ($0.001 USDC), which is behavioral information beyond the annotations. No contradictions.

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, each purposeful: first states the action, second provides usage context, third mentions cost. No fluff, front-loaded with key information.

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 tool's simplicity (zero parameters, no output schema), the description fully covers what the tool does, why it's useful, and the cost. It is sufficient for an agent to decide whether to invoke it.

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?

Input schema has no parameters (0 params), so baseline is 4. The description does not need to explain parameters, and it adds meaning by indicating what the output will be used for, though parameter-specific semantics are not applicable.

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 the tool returns oracle family classification for 30+ perp venues, which is a specific verb+resource. It distinguishes itself from sibling tools (funding, spread, coverage, health, list) by focusing on price source families.

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?

Description provides context for usage: useful for basis-risk awareness in cross-venue strategies and highlights that venues sharing price sources offer no genuine arbitrage edge. It implicitly guides when to use this tool (when assessing arbitrage opportunities) but does not explicitly name exclusion criteria or alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

usenami_rwa_perp_coverageRWA Perpetual Coverage (HIP-3 DEXes)A

Read-onlyIdempotent

Returns real-world asset perpetual coverage on Hyperliquid HIP-3 DEXes (6 sub-venues: cash, flx, km, vntl, xyz, hyna). Asset classes: stocks, metals, forex, commodities, indices, pre-IPO synthetics. Optionally filter by asset_class. Cost: $0.001 USDC per call.

ParametersJSON Schema

Name	Required	Description	Default
`asset_class`	No	Optional asset class filter. Case-insensitive. Omit to return all classes.

TDQS

A4.1/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already cover read-only and idempotent nature. Description adds cost and venue details, but doesn't disclose response format or potential rate limits. Adequate addition beyond 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 conveying all key info: purpose, scope, filter, and cost. No fluff, front-loaded with the main action.

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 query tool with one optional parameter and no output schema, the description covers the return subject, scope, asset classes, filter, and cost. Complete for the tool's complexity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema covers 100% of the single parameter with enum and case-insensitive description. Description merely restates the optional filter, adding no new semantic value.

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?

Clearly states the tool returns RWA perpetual coverage on specific DEXes, lists sub-venues and asset classes, distinguishing it from sibling tools that deal with funding, venues, etc.

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?

Implies usage when needing coverage data for RWA perps on HIP-3 DEXes, with filter options. No explicit when-not-to-use or alternative comparisons, but context is clear.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

usenami_venues_healthGet Venue Health SnapshotA

Read-onlyIdempotent

Returns last-update timestamps and freshness status for each tracked venue. Use this to verify that data is current before paying for a snapshot. Free endpoint, no payment required.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.5/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true and idempotentHint=true. The description adds value by specifying what the tool returns (timestamps and freshness status) and confirming it's free, providing useful 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?

The description is two concise sentences, front-loaded with purpose and usage context. Every sentence adds value 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 simple parameterless tool with comprehensive annotations, the description fully covers purpose, usage guidance, and output description (timestamps and freshness status). It is complete for the tool's complexity.

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, and schema coverage is 100%. The description does not need to add parameter info; baseline for 0 parameters is 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 explicitly states 'Returns last-update timestamps and freshness status for each tracked venue', providing a specific verb and resource. It also distinguishes from siblings like usenami_funding_current by focusing on venue freshness, making the tool's unique purpose clear.

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 says 'Use this to verify that data is current before paying for a snapshot', giving clear guidance on when to use. It also mentions 'Free endpoint, no payment required', implying cost context but lacks explicit when-not or alternative tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

usenami_venues_listList Supported VenuesA

Read-onlyIdempotent

Returns the catalog of perpetual futures venues Usenami tracks. Includes CEX (Binance, Bybit, OKX, etc.) and DEX (Hyperliquid, dYdX, HIP-3 sub-venues for RWA, etc.). Free endpoint, no payment required.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.3/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already indicate readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds context that it is a free endpoint with no payment required, and lists the types of venues tracked. No contradictions.

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 zero redundancy. The first sentence states the core purpose, the second provides examples and a note about cost. Front-loaded and efficient.

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 parameterless list endpoint with no output schema, the description sufficiently explains what the tool returns. It gives enough detail (types of venues, examples) for an agent to understand the response. No missing information.

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?

There are no parameters (schema has no properties). The description adds meaning by explaining the content of the catalog (CEX, DEX, etc.), which is valuable beyond the empty schema. Baseline 4 for 0 params.

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 returning a catalog of perpetual futures venues, listing specific examples (CEX like Binance, Bybit; DEX like Hyperliquid, dYdX). It distinguishes from sibling tools, which deal with funding, spread, 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 usage for obtaining the list of supported venues, but does not provide explicit when/not-to-use guidance or compare with sibling tools. Context from sibling names suggests differentiation, but the description itself lacks direct usage instructions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

6 tool updatesv0.1.0May 28, 2026
- First observedusenami_funding_current
- First observedusenami_perp_funding_spread
- First observedusenami_perp_oracle_families
- First observedusenami_rwa_perp_coverage
- First observedusenami_venues_health
- First observedusenami_venues_list

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.4/5.0

Disambiguation5/5

Each tool addresses a distinct aspect of perpetual futures data: funding rates, cross-venue spreads, oracle families, RWA coverage, venue health, and venue catalog. No two tools overlap in functionality.

Naming Consistency5/5

All tools use the 'usenami_' prefix followed by descriptive snake_case nouns. The naming pattern is uniform and predictable, aiding agent selection.

Tool Count5/5

With six tools, the surface is neither sparse nor bloated. Each tool earns its place, covering data retrieval, analysis, and metadata without unnecessary duplication.

Completeness5/5

The set covers core data (funding rates, spreads, oracle info), specialized coverage (RWA perps), and operational utilities (venue health and list). No obvious gaps for the domain of perpetual futures data queries.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Polyform A
org.polyform
Pay-per-call data APIs for AI agents. USDC on Base via x402. 33 tools, no signup.
Cryptocurrency AI & Machine Learning
671
Agent Newsstand C
com.agentnewsstand
Market data and web intelligence for AI agents, paid per call in USDC on Base via x402.
Finance Search RAG Systems
161
CryptoPulse Data API A
ai.saascloud
Pay-per-call crypto market intelligence for AI agents. USDC on Base via x402.
Cryptocurrency Web3 & Decentralized Tech Finance
111
US Economic, SEC EDGAR & On-Chain Data (x402)A
net.agentfund
21 paid tools: US macro data, SEC EDGAR filings, on-chain EVM reads. Settled in USDC on Base.
Finance Blockchain Open Data
211

Related MCP Servers

cerebrus-pulse-mcp
Finance Blockchain Cryptocurrency
0xsl1m
A
license
A
quality
C
maintenance
Real-time crypto intelligence for AI agents. Technical analysis, liquidation heatmaps, sentiment, and funding rates for 50+ Hyperliquid perpetuals via x402 micropayments.
Updated 8 days ago (2026-08-28 20:54 UTC)
15
1
MIT
hyperd-mcpofficial
Blockchain Cryptocurrency Web3 & Decentralized Tech
hyperd-ai
A
license
A
quality
C
maintenance
Pre-trade DeFi intelligence for AI agents. 20 paid x402 endpoints, USDC on Base.
Updated 3 months ago (2026-06-09 22:01 UTC)
23
58
1
MIT
Funding-mcpofficial
Cryptocurrency Blockchain Finance
namixai
A
license
A
quality
B
maintenance
Real-time perp market-data for AI trading agents — funding rates, funding-arb signals, open interest, volume, orderbook depth/slippage and oracle families across 25 venues, plus HIP-3 RWA coverage (tokenized stocks, metals, oil) that mainstream aggregators lack. x402-native pay-per-call (USDC on Base): one free funding screener tool + 11 paid tools with auto-pay.
Updated 19 days ago (2026-08-18 13:19 UTC)
12
21
2
MIT
Perpetual Funding Rates API
Finance Cryptocurrency
Br0ski777
A
license
Not graded
quality
B
maintenance
Live perpetual funding rates across Binance, Bybit, OKX with open interest and predicted next rate, pay-per-call via x402 micropayments (USDC on Base).
Updated 3 days ago (2026-09-02 19:56 UTC)
MIT

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/usenami-mcp'

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

@usenami/mcp-server

Tools

Free (no wallet required)

Paid ($0.001 USDC each, requires X402_PRIVATE_KEY)

Setup — Claude Desktop

Setup — Cursor

Wallet preparation

Local development

What you get back — response shapes

Architecture

Differentiation vs CoinGecko / CMC

License

Available Tools

Tool Schema Changelog

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

hyperd-mcpofficial

Funding-mcpofficial

Latest Blog Posts

MCP directory API

Paid ($0.001 USDC each, requires `X402_PRIVATE_KEY`)