Инфраструктура для торговых AI-агентов и их людей
которая позволяет экономить токены, получая при этом самую качественную информацию о текущем новостном фоне. За счёт анализа большого количества открытых источников, Polymarket, X и Truth.
Продвинутая формула скоринга, система нарративов и аудит качества источников вместе помогают не пропускать фейки. И легко принимать решения на основе информации, которая уже проанализирована, отобрана и отсортирована. Процесс сбора информации и процесс анализа разложены по полочкам, описаны и понятны — и собраны из открытых источников, так что, на всякий случай, всё это очень легко проверить.
Для человека на сайте — удобный UX, где сразу видно, какие нарративы тянут цену и в каком направлении. Он предоставляет историю в блокчейне, что даёт очень высокую надёжность. Единственный инструмент, позволяющий увидеть движение — сентимент за последний день, за последние несколько дней, за последнюю неделю, что также помогает принимать более взвешенные решения в торговле.
Хотите подробностей? Как ИИ читает новости и строит индекс — About, на восьми языках: EN · RU · DE · FR · ES · PT · PL · NL
Python 3.9+. Без зависимостей — только стандартная библиотека, так что не нужно разрешать конфликты версий и нечего обновлять.
~/Library/Application Support/Claude/claude_desktop_config.json (macOS) или
%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 — та же структура, что и в блоке Claude Desktop выше.
После этого перезапустите клиент и спросите его: «какой сейчас новостной сентимент по биткоину?»
Это один файл без импортов за пределами стандартной библиотеки, так что достаточно клонировать:
git clone https://github.com/IliaKostroma/positive-search-mcp.git
python3 positive-search-mcp/ps_mcp.py --selftestЗатем укажите command как python3, а в args — абсолютный путь к ps_mcp.py.
Или установите его в своё окружение:
pip install git+https://github.com/IliaKostroma/positive-search-mcp
positive-search-mcp --selftest--selftest запускает рукопожатие и каждый инструмент против живого сайта и печатает строку
pass/fail для каждого — стоит запустить один раз, прежде чем доверять ему.
Related MCP server: news-sentiment-mcp
Инструмент | На какой вопрос отвечает |
| Начните здесь. Текущее значение — число, состояние, время замера и срок действия, из чего оно состоит (новости + X + Polymarket), изменение за 1ч/24ч/7д, готовая строка для цитирования — и три самых весомых нарратива, так что один вызов отвечает и на «что», и на «почему» |
| Полный набор историй, каждая со своим сентиментом, |
| Семь дней, ежедневно по умолчанию (close/avg/min/max за день) — достаточно, чтобы отличить обычное значение от выброса; |
| Доказательства — каждый заголовок, вошедший в значение, со своим скоринговым баллом, возрастом, издателем и ссылкой на оригинал |
| Все три значения сразу, отсортированные от самого бычьего к самому медвежьему, каждое со своим временем замера |
Дешёвый путь: compare_assets для выбора актива → get_sentiment для значения и
главных нарративов → get_narratives только если нужна полная картина → get_sources только для
проверки конкретного заголовка → get_history только для проверки, не является ли сегодняшний день необычным.
Активы: BTC, GOLD, OIL. Работают неточные написания — bitcoin, XAU, crude oil. Всё
остальное возвращает явную ошибку с перечнем того, что поддерживается, и никогда не подменяет значение.
О весах. Масса нарратива (mass) публикуется; вес отдельной статьи — нет. Вес одной
статьи — это одно суждение модели и он меняется между запусками, тогда как масса нарратива агрегирует множество
статей и стабильна — поэтому вес публикуется там, где он устойчив. Входные данные проверяемы,
опубликованное значение защищено от подделки, а постатейная взвешенность отсюда невоспроизводима.
Мы предпочитаем сказать об этом прямо, чем создавать иное впечатление.
Каждое значение несёт собственное время замера. Три актива оцениваются в своих собственных часовых запусках, поэтому их значения несут три разных временных метки. Цитируйте число с указанием времени рядом — значение сентимента без момента замера становится неверным уже через час.
Число — это сохранённый факт, а не пересчёт на лету. Оно вычисляется один раз, когда происходит запуск, из компонентов, захваченных в этом же запуске. Перечитайте этот запуск завтра — и получите то же число до последней цифры.
Каждый источник снабжён ссылкой. Индекс настолько хорош, насколько хороши прочитанные им источники,
поэтому прочитанное публично: get_sources возвращает каждый заголовок с его собственным баллом и ссылкой на оригинал.
Прошлые значения нельзя молча переписать. Каждый запуск входит в хеш-цепочку sha256, чья
вершина ежедневно закрепляется в блокчейне Bitcoin через OpenTimestamps. Отпечатки и их
доказательства публикуются на https://positivesearch.app/proofs/ и проверяются независимо
от этого сайта и его владельца (ots verify).
Честные ограничения, заявленные заранее. Он измеряет тональность новостного освещения. Это не цена, не прогноз цены и не финансовая рекомендация. Мы не рекомендуем использовать его как единственный источник — используйте его наряду с техническим, фундаментальным и другим анализом, как один из нескольких инструментов.
+1 — сильно бычье освещение, −1 — сильно медвежье, 0 — сбалансированно, а не тишина —
бычье и медвежье давление измеряются отдельно, поэтому значение около нуля обычно означает два сильных
нарратива, тянущих в противоположные стороны. get_narratives позволяет различить эти два случая.
«Бычий» означает работает в пользу цены, а не хорошие новости. Плохие новости для индустрии часто бычьи для её цены.
Всё здесь также доступно через обычный HTTP, без ключа:
Машинная точка входа: https://positivesearch.app/.well-known/agents-gate.json
Методология и ограничения: https://positivesearch.app/llms.txt
Нужен другой инструмент (ETH, SOL, валютная пара, индекс)? Движок не привязан ни к какому активу — hi@positivesearch.app.
Лицензия MIT для этого клиента. Сами значения публикуются под 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.
Crypto news, perps, market pulse, price history and token checks for AI agents. USDC per call.
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.
