This MCP server provides real-time AI news-sentiment readings for Bitcoin, Gold, and Oil to help trading agents and humans gauge market news tone.
get_sentiment – Get the current −1..+1 sentiment score, measurement time/expiry, 1h/24h/7d changes, composition (news + X + Polymarket), citation line, and top 3 narratives.
get_narratives – Retrieve the full set of stories behind the sentiment, each with its own sentiment, mass, cross-source agreement, and example headlines.
get_history – View 7 days of sentiment history, daily or hourly granularity, to compare today's reading against recent trends.
get_sources – See every headline that went into the current reading, with individual scores, age, publisher, and links to original articles for verification.
compare_assets – Compare all three asset readings (BTC, GOLD, OIL) at once, ranked most bullish first.
Provides Bitcoin (BTC) sentiment analysis, including current sentiment scores, supporting narratives, hourly history, source evidence, and comparison with other assets.
Click on "Deploy 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., "@positive-search-mcp what's the news sentiment on bitcoin right now?"
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.
Infrastructure for trading AI agents and their humans
which allows saving tokens while getting the highest-quality information about the current news background. Through the analysis of a large number of open sources, Polymarket, X and Truth.
An advanced scoring formula, a system of narratives and a source-quality audit together help not to let fakes through. And to easily make decisions based on information that is already analyzed, selected and sorted. The process of collecting the information and the process of analysis are laid out, described and easy to understand — and assembled from open sources, so, just in case, all of it is very easy to verify.
For the human on the site — a convenient UX where you immediately see which narratives pull the price and in which direction. It provides history in the blockchain, which gives very high reliability. The only tool to see the movement — sentiment over the last day, over the last few days, over the last week, which also helps to make better decisions in trading.
Want the details? How the AI reads the news and builds the index — About, in eight languages: EN · RU · DE · FR · ES · PT · PL · NL
Python 3.9+. No dependencies — standard library only, so there is no version conflict to resolve and nothing to keep updated.
~/Library/Application Support/Claude/claude_desktop_config.json (macOS) or
%APPDATA%\Claude\claude_desktop_config.json (Windows):
{
"mcpServers": {
"positive-search": {
"command": "uvx",
"args": [
"--from", "git+https://github.com/IliaKostroma/positive-search-mcp",
"positive-search-mcp"
]
}
}
}claude mcp add positive-search -- uvx --from git+https://github.com/IliaKostroma/positive-search-mcp positive-search-mcp~/.cursor/mcp.json — same shape as the Claude Desktop block above.
Restart the client afterwards, then ask it "what's the news sentiment on bitcoin right now?"
It is one file with no imports beyond the standard library, so a clone is enough:
git clone https://github.com/IliaKostroma/positive-search-mcp.git
python3 positive-search-mcp/ps_mcp.py --selftestThen point command at python3 and args at the absolute path to ps_mcp.py.
Or install it into your environment:
pip install git+https://github.com/IliaKostroma/positive-search-mcp
positive-search-mcp --selftest--selftest runs the handshake and every tool against the live site and prints a pass/fail
line for each — worth running once before you trust it.
Related MCP server: news-sentiment-mcp
Tool | What it answers |
| Start here. The current reading — number, state, measurement time and expiry, what it is made of (news + X + Polymarket), 1h/24h/7d change, a ready citation line — and the three heaviest narratives, so one call answers both what and why |
| The full set of stories, each with its sentiment, |
| Seven days, daily by default (close/avg/min/max per day) — enough to tell a normal reading from an outlier; |
| The evidence — every headline that went into the reading, with its own score, age, publisher and a link to the original |
| All three readings at once, ranked most bullish first, each with its own measurement time |
The cheap path: compare_assets to pick an asset → get_sentiment for the reading and the
top narratives → get_narratives only if you want the whole picture → get_sources only to
verify a specific headline → get_history only to check whether today is unusual.
Assets: BTC, GOLD, OIL. Loose spellings work — bitcoin, XAU, crude oil. Anything
else returns an explicit error naming what is covered, never a substitute reading.
On weights. Narrative mass is published; per-article weight is not. A single article's
weight is one model judgement and moves between runs, while narrative mass aggregates many
articles and is stable — so weight is published where it holds still. Inputs are auditable,
the published reading is tamper-evident, and the per-article weighting is not reproducible
from here. We would rather say that than imply otherwise.
Every reading carries its own measurement time. The three assets are scored on their own hourly runs, so their readings carry three different timestamps. Quote a number with the time next to it — a sentiment value without its moment is wrong the hour after.
The number is a stored fact, not a live recomputation. It is computed once, when the run happens, from the components captured in that same run. Re-read that run tomorrow and you get the same number to the last digit.
Every source is linked. The index is only as good as what it read, so what it read is
public: get_sources returns each headline with its own score and a link to the original.
Past readings cannot be silently rewritten. Every run enters a sha256 hash chain whose
head is anchored daily in the Bitcoin blockchain via OpenTimestamps. The fingerprints and
their proofs are published at https://positivesearch.app/proofs/ and verify independently
of this site and its owner (ots verify).
Honest limits, stated up front. It measures the tone of news coverage. It is not price, not a price forecast, and not financial advice. We do not recommend using it as your only input — use it alongside technical, fundamental and other analysis, as one instrument among several.
+1 strongly bullish coverage, −1 strongly bearish, 0 balanced, not silent — bull
and bear pressure are measured separately, so a reading near zero usually means two strong
narratives pulling against each other. get_narratives tells the two cases apart.
"Bullish" means works in favour of the price, not good news. Bad news for an industry is often bullish for its price.
Everything here is also plain HTTP, no key required:
Machine entry point: https://positivesearch.app/.well-known/agents-gate.json
Methodology and limits: https://positivesearch.app/llms.txt
Need another instrument (ETH, SOL, an FX pair, an index)? The engine is not tied to any asset — hi@positivesearch.app.
MIT licence for this client. The readings themselves are published under CC BY 4.0.
All three readings (Bitcoin, Gold, Oil) in one call, ranked most bullish first, each with its own measurement time. Use when asked where the news mood is best or worst, or to pick an asset before going deeper with get_sentiment — three separate calls for the same picture is the most common waste.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that the tool returns all three readings in one call, ranks them by bullishness, and includes measurement times. It does not mention side effects, but as a read-only operation, this is adequate. It lacks details on return format or error handling, but the core behavior is transparent.
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?
Two sentences with no wasted words. The primary information is front-loaded (what it does and rankings), followed by usage context and a caution against redundancy. Each sentence earns its place.
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?
The description covers the essential aspects: purpose, usage, and key behavioral details. It does not provide a detailed return structure (no output schema given), but it does mention ranking and measurement time. For a parameterless tool, this is reasonably complete; however, a brief note on the exact output shape would make it fully complete.
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, so the base score is 4. The description does not need to explain parameters because there are none; the input schema is empty and covers 100% of the (non-existent) parameters. No additional semantic information 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 states a specific verb ('compare'), resource (Bitcoin, Gold, Oil readings), and output ('ranked most bullish first'), clearly distinguishing it from sibling tools like get_sentiment and get_history. It is not tautological and adds unique functionality.
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?
It explicitly tells when to use the tool ('when asked where the news mood is best or worst, or to pick an asset before going deeper with get_sentiment') and when not to (by suggesting using get_sentiment for deeper analysis). It also warns against the wasteful alternative of three separate calls, providing clear guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Sentiment over the last seven days — reach for this only to tell a normal reading from an outlier, since today's number often only means something next to yesterday's. Daily by default: one point per day with close/avg/min/max, which answers that question at about a sixth of the payload. Pass granularity 'hourly' for every run only when the shape inside a day matters. Seven days is the full public window.
| Name | Required | Description | Default |
|---|---|---|---|
| asset | No | BTC, GOLD or OIL | |
| granularity | No | daily (default, ~8 points) or hourly (~170 points, ~6x the payload) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does so well. It discloses the return structure (close/avg/min/max for daily), defaults, payload size comparison, the full public window, and even interpretive guidance about how today's number relates to yesterday's. This is comprehensive transparency for a read-only operation.
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, front-loaded with the purpose. Every clause carries weight: purpose, usage condition, default behavior, payload ratio, and window limit. There is no redundancy or filler, making it highly efficient.
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 tool with two optional parameters, the description covers purpose, usage, and behavior thoroughly. However, it does not specify what happens when the 'asset' parameter is omitted, since the schema has no required fields. This leaves a potential ambiguity about whether a default asset exists, which is a minor gap in an otherwise complete description.
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 schema already covers both parameters, including payload counts for granularity. The description adds meaning by explaining that daily returns close/avg/min/max and clarifies that hourly is only for intraday shape, which goes beyond the schema's static definitions. It enriches the granularity parameter but does not add much for the asset parameter.
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 provides sentiment over the last seven days, specifying both the resource and the time window. It does not explicitly name sibling tools, but the historical scope is distinct enough from likely alternatives like current sentiment. The purpose is specific and actionable, though it could benefit from a direct contrast with a sibling.
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 explicitly says to use this only to distinguish normal readings from outliers, and provides clear conditions for hourly granularity ('only when the shape inside a day matters'). It also mentions the seven-day window limit and the payload trade-off, giving the agent precise when-to-use and when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The full set of stories behind the number — this is where most of the value is. Recurring narratives the hour's coverage groups into, each with its own sentiment, mass (its weight in the reading), cross-source agreement and example headlines with links. Use it to answer WHY sentiment is where it is, and to tell a quiet market (index near zero, no strong narratives) from a contested one (strong narratives pulling opposite ways). get_sentiment already returns the top three — call this when you want the whole picture or the headlines.
| Name | Required | Description | Default |
|---|---|---|---|
| asset | No | BTC, GOLD or OIL | |
| limit | No | how many narratives, 1-20 (default 8) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full weight. It discloses the output structure (each narrative has sentiment, mass, agreement, headlines) and the semantic difference from get_sentiment. It does not mention error conditions or side effects, but for a read-only data retrieval tool that is acceptable. The description provides context beyond the schema by explaining the 'mass' and 'agreement' concepts.
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 longer than necessary but well-structured: it opens with a value statement, lists the key fields, and then provides usage guidance. It is front-loaded with the most important info (full set vs top three) and ends with a clear alternative. A bit verbose but not wasteful.
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 no output schema, the description explains the return format (narratives with sentiment, mass, agreement, headlines). It also explains the use cases and how to differentiate from get_sentiment. It does not mention what happens if asset is omitted, but that is a minor gap given the schema marks both fields optional. The description is sufficient for an agent to understand what it will get and when to call it.
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% (both asset and limit have descriptions in the schema). The description adds no new meaning about the parameters themselves—it only references the returned data. The schema already covers the default for limit ('default 8') and asset values. Baseline of 3 is appropriate since the schema does the heavy lifting.
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 resource ('narratives') and the action (retrieve the full set), and distinguishes it from get_sentiment which only returns the top three. It names the returned fields (sentiment, mass, agreement, headlines) which makes the tool's purpose concrete and differentiated from siblings like get_history and get_sources.
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?
Explicitly explains when to use this over get_sentiment: 'get_sentiment already returns the top three — call this when you want the whole picture or the headlines.' Also provides use cases (answer WHY sentiment is where it is, distinguish quiet vs contested markets). This is clear routing guidance with an explicit alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
START HERE. Current AI news-sentiment reading for Bitcoin, Gold or crude Oil on a −1..+1 scale, rebuilt every hour from that hour's news coverage — plus the three heaviest narratives behind it, so one call answers both what the mood is and why. Also returns the measurement time and expiry, what the number is made of (news + X chatter + Polymarket odds), 1h/24h/7d changes, and a ready-to-use citation line. Covers BTC, GOLD and OIL only; any other asset returns an explicit error rather than a substitute. It measures the tone of coverage, not price, and does not forecast price.
| Name | Required | Description | Default |
|---|---|---|---|
| asset | No | BTC, GOLD or OIL (bitcoin/gold/oil also work) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility and excels: it discloses hourly rebuilds, the three heaviest narratives, measurement time/expiry, composition (news + X chatter + Polymarket odds), 1h/24h/7d changes, a citation line, and explicit error behavior for out-of-scope assets. This gives the agent complete behavioral understanding.
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 dense but efficient, front-loading the core purpose with 'START HERE' and then stacking related details in a logical order. Every sentence adds information, and the structure guides the reader from the primary output to secondary details to scope. Slightly long but justified given the breadth.
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?
With no output schema, the description must explain what the call returns — and it does thoroughly: scale, narratives, time/expiry, composition, changes, citation line, and error behavior. It also clarifies non-price tone. Nothing critical is missing for an agent to correctly invoke and interpret the result.
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 schema already documents the asset parameter with aliases, and coverage is 100%, so the baseline is 3. The description adds value by explicitly limiting accepted values to BTC/GOLD/OIL and stating that any other asset returns an error rather than a substitute, which is not in the schema. This goes beyond the schema's simple listing.
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 states a specific verb (get sentiment), a precise resource (news-sentiment for Bitcoin, Gold, Oil), and a clear scale (−1..+1). It also differentiates from siblings by explicitly limiting coverage to three assets and noting what it does not do (price forecasting), making it unmistakable which tool to pick.
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?
It opens with 'START HERE', signaling it as the entry point. It explicitly restricts to BTC/GOLD/OIL and warns that other assets return an error. It clarifies it measures tone, not price, and does not forecast, giving context on when not to use it. It does not name sibling tools explicitly, but the guidance is otherwise clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The evidence — reach for it to VERIFY, not to explain. Every headline that went into the current reading, each with its own score, age, publisher and a link to the original article. Use it to check a specific claim or to find the primary reporting behind a move; for the explanation itself, narratives are cheaper and clearer. Per-article weight is deliberately not published — weight is published where it is stable, as narrative mass.
| Name | Required | Description | Default |
|---|---|---|---|
| asset | No | BTC, GOLD or OIL | |
| limit | No | how many articles, 1-60 (default 15) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses a key behavioral trait: 'Per-article weight is deliberately not published' — a limitation the agent should know. It also implies a read-only nature via 'VERIFY,' but does not explicitly state it is non-destructive. There is no contradiction with annotations (none provided). The disclosure of what is omitted adds transparency beyond a bare function statement.
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 front-loaded with the core purpose ('The evidence — reach for it to VERIFY, not to explain.') and is concise overall. It contains useful usage guidance and a limitation note, each earning its place. Slightly stylized but not verbose.
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 list-retrieval tool with two optional parameters, the description covers purpose, output content (score, age, publisher, link), usage, and a notable omission (weight). It lacks explicit pagination details but these are minor for this tool. Given no output schema, this is sufficiently complete for an agent to call it correctly.
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%: both 'asset' and 'limit' have descriptions ('BTC, GOLD or OIL' and 'how many articles, 1-60 (default 15)'). The description adds no extra parameter-specific meaning, 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?
The description clearly states the tool's function: it returns the list of headlines that formed the current reading, each with score, age, publisher, and a link. It uses a specific verb ('reach for it to VERIFY') and resource ('evidence'). It also distinguishes itself from get_narratives by positioning sources as verification vs. explanation, which helps differentiate it from siblings.
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?
Explicitly tells the agent when to use this tool: 'to check a specific claim or to find the primary reporting behind a move.' It also tells when not to use it: 'for the explanation itself, narratives are cheaper and clearer,' directly routing to a sibling. This is clear use-versus-alternative guidance.
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.
v1.0.0compare_assetsget_historyget_narrativesget_sentimentget_sourcesScored across 5 tools
Each tool targets a clearly distinct aspect: current sentiment, historical data, narrative details, source headlines, and cross-asset comparison. No two tools overlap in purpose, and descriptions explicitly differentiate when to use each, such as get_sentiment for the current reading vs. get_narratives for full stories.
All tool names follow a consistent verb_noun pattern in snake_case: get_sentiment, get_history, get_narratives, get_sources, and compare_assets. The first four use 'get_' and the last uses 'compare_', which is still a verb_noun pattern, maintaining a predictable and uniform style.
Five tools is well-scoped for this sentiment analysis server covering three assets. Each tool adds meaningful functionality without redundancy, and the count fits comfortably within the ideal 3-15 range for a focused API.
The tool surface covers all major aspects of sentiment analysis: current reading, historical trends, narrative breakdown, source evidence, and multi-asset comparison. Given the stated domain (news-sentiment for BTC, GOLD, OIL), there are no obvious gaps—the descriptions even mention users can follow up with more granular calls as needed.
Real-time curated crypto news for AI agents with sentiment, recaps, and search.
Real-time digital asset narrative intelligence from 1,000+ curated media sources.
Real-time financial news for AI agents: search by ticker and source, with sentiment and entities.
Crypto market signals, technical indicators, and sentiment analysis for AI agents.
