Allows Hermes agents to access the same narrative intelligence tools via MCP configuration, enabling them to retrieve market narratives and clean feeds.
Narrative & signal intelligence for AI agents — crypto, AI, and macro. A dumb-but-trustworthy pipe: it delivers curated narrative & signal, not raw data, and it fails safe — when it has no coverage it says so, rather than inventing. Built for machines, not human eyes.
API + MCP: https://api.signaldaemon.com
Self-serve key: POST /v1/request-key (no signup)
This repo is the front door — quickstart, client configs, and the interface contract. The pipeline itself (sources, scoring, curation) is not open source.
It is | It is not |
Cross-source narrative convergence + capital-vs-narrative divergence | A price/market-data API (use CoinGecko etc. for that) |
Coverage across ~14 crypto/AI/macro domains | A raw news firehose |
Fails safe — "no coverage" over hallucination | A database you query for facts |
For agents (API/MCP), token-cost-agnostic, quality-first | A human-facing dashboard |
Related MCP server: fathom-fyi
# 1 · self-serve a demo key (no signup)
KEY=$(curl -s -X POST https://api.signaldaemon.com/v1/request-key | jq -r .key)
# 2 · the day's ranked narratives + derived signals (cached, instant)
curl -s https://api.signaldaemon.com/v1/narratives \
-H "x-api-key: $KEY" -d '{"limit":8}'
# 3 · clean narrative feed for a topic
curl -s https://api.signaldaemon.com/v1/feed \
-H "x-api-key: $KEY" -d '{"query":"restaking","limit":8}'Remote MCP over Streamable HTTP, authenticated with the x-api-key header.
# Claude Code
claude mcp add --transport http signaldaemon \
https://api.signaldaemon.com/mcp --header "x-api-key: <KEY>"# Hermes Agent — ~/.hermes/config.yaml
mcp_servers:
signaldaemon:
url: "https://api.signaldaemon.com/mcp"
headers: { x-api-key: "<KEY>" }More clients (Cursor, Cline) in examples/mcp-configs.md.
Tools: get_market_narratives(limit) · get_clean_feed(query, category, limit) ·
vet_trade(symbol, side) — all annotated readOnlyHint. vet_trade is the
pre-trade gate: hand it a candidate trade and it returns a narrative-layer stance
(support/caution/contradict/no_signal) with reason + confidence — it vets,
it does not recommend.
For clients that don't support remote MCP, this repo ships a thin stdio
bridge (mcp_server.py) exposing the same three tools over
the hosted API. It holds no methodology — just a client.
pip install mcp
export SIGNALDAEMON_API_KEY=cns_... # https://signaldaemon.com/console
python mcp_server.pyOr with Docker:
docker build -t signaldaemon-mcp . && \
docker run -i -e SIGNALDAEMON_API_KEY=cns_... signaldaemon-mcpThe bridge starts and answers introspection (tools/list) without a key;
tool calls require one.
Endpoints and response-field contract (incl. the divergence schema) in
API.md. Field names are stable.
Examples and docs in this repo: MIT (see LICENSE). The signaldaemon service and pipeline are proprietary.
Return a curated, de-noised, source-attributed feed of articles for a query topic. Reports coverage honestly ("thin" rather than padding).
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | ||
| category | No | ||
| limit | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds behavioral context beyond annotations: it curates, de-noises, attributes sources, and reports honestly (thin coverage). This complements the readOnlyHint and openWorldHint annotations. No contradiction.
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 purpose and followed by a key behavioral note. Every word adds value. No redundancy.
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 three parameters, no output schema, and no parameter explanations, the description leaves gaps. It fails to specify expected values for category, limit constraints, or return format. Incomplete for an AI agent to invoke confidently.
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 0%, and the description does not explain any of the three parameters (query, category, limit). The schema provides structure but no semantics; the description should compensate but does not.
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 curated, de-noised, source-attributed feed for a query topic. The verb 'return' and resource 'feed' are specific, and the mention of honest coverage distinguishes it from siblings like get_market_narratives.
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 honesty in reporting ('thin rather than padding'), which hints at when to use this tool, but does not explicitly state when to use or not use it versus the sibling tool get_market_narratives. No alternative or exclusion is mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return top crypto market narratives with strength, momentum, and price divergence signals. Includes a market_snapshot (regime, market_7d, fear_greed) that every divergence reading is relative to.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint and openWorldHint. The description adds value by detailing the output components (narratives with strength, momentum, divergence, and market_snapshot) and notes that divergence readings are relative to the snapshot. However, it does not clarify data recency or how results change over time.
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 main purpose, and contains no extraneous information. It is concise and well-structured.
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 one optional parameter and no output schema, the description adequately explains the return value. It could be more complete by explaining how to interpret strength/momentum scales or the effect of the limit parameter.
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 description does not mention the only parameter 'limit' at all. With 0% schema description coverage, the description should compensate but fails to explain the parameter's purpose, default, or usage.
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 it returns 'top crypto market narratives with strength, momentum, and price divergence signals' and includes a 'market_snapshot'. This is specific and distinguishes from the sibling tool 'get_clean_feed', which likely serves a different purpose.
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 usage for fetching market narratives and signals, but does not explicitly state when to use this tool versus the sibling 'get_clean_feed' or provide any conditions or exclusions.
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_clean_feedget_market_narrativesThe two tools serve clearly different purposes: one for curated article feeds on a query topic, the other for crypto market narratives with divergence signals. No overlap.
Both tools use consistent snake_case and verb_noun pattern (get_clean_feed, get_market_narratives), maintaining naming uniformity.
With only two tools, the server feels thin for a 'signal daemon' scope, but it may be intentionally focused. The count is borderline acceptable.
The tool set covers only two specific signal types (feed and market narratives) and lacks broader operations like historical analysis or asset-specific signals, leaving significant gaps for a comprehensive signal daemon.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Prediction markets, on-chain flows, ETF flows, equities and macro intelligence for AI agents.
Pre-reasoned Bitcoin & macro financial briefings for AI agents. Trend signals, regimes, 17 contexts.
Crypto market intelligence: social sentiment, on-chain, trending narratives & analyst insights.
Signed BTC and macro market intelligence for autonomous research, risk, and trading agents.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/bevanding/signaldaemon'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
