The Market Pulse MCP server gives Claude access to live financial market data across crypto and forex — no API keys required.
Get Cryptocurrency Price (get_price): Look up the current price of any supported cryptocurrency by name or ticker (e.g., Bitcoin, ETH, SOL, Dogecoin).
Get Top Cryptocurrencies (get_top_cryptos): Retrieve the top 1–25 cryptocurrencies ranked by market cap, including prices and 24-hour price changes (default: 10).
Get Forex Exchange Rate (get_forex_rate): Fetch the current exchange rate between any two fiat currencies (e.g., USD to EUR, GBP to JPY).
Get Fear & Greed Index (get_fear_greed_index): Check the Crypto Fear & Greed Index score (0–100) and its 7-day trend to gauge market sentiment, from Extreme Fear to Extreme Greed.
Get Market Summary (get_market_summary): Get a full market snapshot in one call — top 5 cryptos, major forex rates, and the Fear & Greed Index — ideal for a quick daily briefing.
Provides real-time price data and market information for Bitcoin.
Provides real-time price data and market information for Cardano.
Provides real-time price data and market information for Chainlink.
Provides real-time price data and market information for Dogecoin.
Provides real-time price data and market information for Ethereum.
Provides real-time price data and market information for Litecoin.
Provides real-time price data and market information for Polkadot.
Provides real-time price data and market information for Polygon.
Provides real-time price data and market information for Solana.
Provides real-time price data and market information for XRP.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Market Pulse MCP what's the current price of Bitcoin?"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
An MCP server that gives Claude live market data instead of guessing or searching the web. Crypto, stocks, forex, indices, sentiment — real numbers from real APIs.
You: "how's the market doing?"📊 MARKET SUMMARY
═══════════════════
🪙 Top Cryptos:
Bitcoin (BTC): $78,004.00 🔴 -0.24%
Ethereum (ETH): $2,489.00 🟢 +1.12%
BNB (BNB): $598.00 🟢 +0.87%
Solana (SOL): $148.30 🔴 -2.31%
XRP (XRP): $0.52 🟢 +0.45%
📈 Indices:
S&P 500: 5,842.01 🟢 +0.62%
NASDAQ: 18,847.28 🟢 +0.89%
Dow Jones: 42,654.74 🔴 -0.12%
💱 Forex (USD base):
USD/EUR: 0.9234
USD/GBP: 0.7891
USD/JPY: 154.23
😰 Fear & Greed: 38/100 (Fear)No web searches. No hallucinated data. Just live numbers.
Related MCP server: Yahoo Finance MCP Server
Tool | Does what | |
🪙 |
| Price of any crypto — BTC, ETH, SOL, DOGE, and 10+ more |
📊 |
| Top N ranked by market cap |
📈 |
| NEW — Any stock or ETF: AAPL, NVDA, TSLA, MSFT, SPY, QQQ... |
🏛️ |
| NEW — S&P 500, NASDAQ, Dow Jones, Russell 2000, VIX |
🔥 |
| NEW — Top 7 trending coins on CoinGecko right now |
💱 |
| Exchange rate between any two currencies |
😱 |
| Fear & Greed Index + 7-day trend |
📋 |
| Everything above in one call |
1. Clone and install:
git clone https://github.com/decksaga/market-pulse-mcp.git
cd market-pulse-mcp
npm install2. Add to your Claude config:
{
"mcpServers": {
"market-pulse": {
"command": "node",
"args": ["/path/to/market-pulse-mcp/dist/server.js"]
}
}
}3. Restart Claude. Ask it anything about the market.
Already compiled. No build step.
Source | What it provides |
Crypto prices, market caps, trending, 24h volume | |
Stocks, ETFs, market indices | |
150+ fiat currency pairs | |
Crypto Fear & Greed Index |
market-pulse-mcp/
├── src/
│ ├── server.ts # Tool definitions (8 tools)
│ └── apis.ts # CoinGecko, Yahoo Finance, ExchangeRate, Alternative.me
├── dist/ # Ready to run
├── package.json
└── tsconfig.jsonMIT — do whatever you want with it.
Made by @decksaga
Get the Crypto Fear & Greed Index. Values: 0-25 = Extreme Fear, 25-50 = Fear, 50-75 = Greed, 75-100 = Extreme Greed.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must fully disclose behavior. It only defines the index interpretation but does not explain the output format, caching behavior, or whether any side effects occur. This is insufficient for an agent to understand the response structure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with only two sentences. The first sentence delivers the core purpose, and the second provides the value interpretation. No wordiness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with no parameters and no output schema, the description is somewhat incomplete. It explains the index values but does not specify the output format (e.g., a number or object with fields). An agent would need to infer the return structure from the name alone.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and 100% schema description coverage, so the description does not need to add parameter details. The baseline is 4, and no additional parameter context is required.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves the Crypto Fear & Greed Index, a specific resource. The value ranges distinguish it from sibling tools that deal with forex rates, market summaries, prices, and top cryptos.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use the tool versus alternatives is provided. However, the distinct purpose and sibling names imply its usage context is for sentiment analysis, not for price or market data.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the current exchange rate between two currencies (forex). Examples: USD to EUR, GBP to JPY.
| Name | Required | Description | Default |
|---|---|---|---|
| from | Yes | Base currency code (e.g. 'USD', 'EUR', 'GBP') | |
| to | Yes | Target currency code (e.g. 'EUR', 'JPY', 'CHF') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and description fails to disclose behavioral traits like data source, update frequency, trading hours, or response format. Only states it gets a rate, leaving significant unknowns.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence efficiently conveys purpose and examples; no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with 2 parameters and no output schema, the description is nearly complete. However, given no annotations, a note on real-time nature or refresh cadence would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema provides full description for both parameters (currency codes). Description adds examples adding context, but does not go beyond schema. 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.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states verb 'Get', resource 'current exchange rate between two currencies', and provides concrete examples (USD to EUR, GBP to JPY). Distinguishes from siblings like get_price (likely for single asset).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description implies use for forex rates with examples, but no explicit guidance on when to use versus alternatives (e.g., get_price for non-forex), no mention of limitations or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a complete market overview: top 5 cryptos, major forex rates, and the Fear & Greed Index. Great for a quick daily briefing.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavior. It states the tool returns a market overview but does not mention read-only nature, authentication requirements, rate limits, or whether it aggregates from other endpoints. The behavioral profile is partially transparent but lacks important details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no wasted words. The first sentence states function, the second adds a use case. It is front-loaded and to the point.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Although the tool has no parameters and no output schema, the description does not clarify the return format or structure. It mentions components but not how they are presented (e.g., JSON object). For a tool used as a daily briefing, more detail on output would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters, so the description does not need to add parameter semantics. Schema coverage is 100% (trivially). Baseline expectation is met excellently.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns a market overview including top 5 cryptos, major forex rates, and Fear & Greed Index. It distinguishes itself from sibling tools (get_fear_greed_index, get_forex_rate, get_top_cryptos) by being a composite, making purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions 'Great for a quick daily briefing,' providing a clear use case. It implies this tool is for broad overviews rather than detailed data, but does not explicitly state when to avoid it or mention alternatives. Given sibling tool names, the context is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the current price of a cryptocurrency. Supports: bitcoin, ethereum, solana, cardano, ripple, dogecoin, bnb, litecoin, avalanche, polkadot, chainlink, polygon, and more.
| Name | Required | Description | Default |
|---|---|---|---|
| symbol | Yes | Crypto name or ticker (e.g. 'bitcoin', 'btc', 'ethereum', 'sol') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description does not disclose any behavioral traits such as data freshness, rate limits, or response format.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise: a single sentence that covers purpose and supported assets, with no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the description is simple and the tool appears straightforward, the lack of output schema or mention of return format leaves some ambiguity for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a clear description for 'symbol'. The description adds value by listing specific supported cryptocurrencies, which aids in parameter selection.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it gets the current price of a cryptocurrency, lists many supported coins, and distinguishes from sibling tools like get_fear_greed_index and get_forex_rate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or when-not-to-use instructions, but the purpose is clear enough to infer usage for crypto price retrieval.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the top cryptocurrencies by market cap with prices and 24h changes.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Number of cryptos to return (1-25, default 10) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only mentions what is returned (prices and 24h changes) but omits any side effects, authentication requirements, rate limits, or data freshness. For a read-only tool, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. Every word serves the purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (1 parameter, no output schema), the description covers the basic functionality. However, it lacks behavioral context such as rate limits or data freshness, which would be helpful for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the description does not add meaning beyond what the schema already provides (the 'limit' parameter is fully documented). Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get the top cryptocurrencies by market cap with prices and 24h changes,' using a specific verb and resource. It naturally distinguishes from sibling tools like 'get_price' which likely focuses on a single crypto, and 'get_market_summary' which is broader.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for retrieving top cryptos by market cap but does not explicitly state when to use it over alternatives or provide any exclusion criteria. Sibling tools exist but no differentiation guidance is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v1.0.0get_fear_greed_indexget_forex_rateget_market_summaryget_priceget_top_cryptosEach tool has a clearly distinct purpose: fear/greed index, forex rate, market summary, specific crypto price, and top cryptos. The summary tool combines others but does not create ambiguity.
All tools follow a consistent 'get_' prefix followed by a descriptive noun phrase (e.g., get_fear_greed_index, get_top_cryptos). No style mixing.
With 5 tools, the set is well-scoped for a market data server focused on crypto and forex. Each tool adds unique value without redundancy.
The set covers core market data needs: sentiment, prices, top movers, and forex rates. Minor gaps exist (e.g., historical data, news), but the surface is sufficient for typical queries.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Live & historical FX rates and currency conversion for AI agents. No API keys.
Live & historical FX rates and currency conversion for AI agents. No API keys.
Global stock research, ML forecasts, valuation signals, screeners & portfolio tracking in Claude
Loan & mortgage calculator, compound interest, ROI, crypto prices, FX conversion for AI agents.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/decksaga/market-pulse-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
