feat: add optional market sentiment tool

[alexander-schneider]

Summary

• add an optional market_sentiment tool for structured US-stock sentiment snapshots and trending names
• expose the same capability through the MCP server
• wire the tool into the existing sentiment-focused swarm presets as an optional fast path

Why

Vibe-Trading already has strong social/sentiment swarm presets, but today they rely on broad web reading and manual synthesis. This patch adds a structured market-sentiment input that is useful when available, while remaining fully optional.

Design

• no change to the default data-provider or backtest paths
• no requests are made unless ADANOS_API_KEY is configured
• when the key is missing, the tool returns status=not_configured so agents can fall back to existing web research flows
• the new tool supports snapshot and trending modes across Reddit, X, finance news, and Polymarket

Validation

• python3 -m pytest tests/ -q
• cd agent && python3 -m py_compile cli.py api_server.py mcp_server.py src/agent/loop.py src/tools/__init__.py src/tools/market_sentiment_tool.py
• git diff --check

[warren618]

Thanks for the contribution — the code quality is solid and the graceful degradation pattern is well done.

We'd love to include structured sentiment as a capability, but we'd prefer a provider-agnostic architecture rather than binding to a specific vendor. Specifically:

1. Abstract sentiment provider interface — define a base class (e.g. BaseSentimentProvider) with snapshot() and trending() methods, so the community can plug in different backends (Adanos, StockTwits, custom APIs, etc.)
2. Adanos as one implementation — your current code becomes AdanosSentimentProvider, registered via config
3. Don't modify existing swarm presets — create new variants (e.g. sentiment_intelligence_team_enhanced.yaml) or let the tool work transparently when available
4. Keep context.py system prompt unchanged — the tool registration in __init__.py is sufficient for the agent to discover it

This way the sentiment capability is extensible and vendor-neutral, which aligns better with the project's multi-source philosophy (same pattern as our 5 data source providers with auto-fallback).

Happy to discuss the interface design if you'd like to iterate on this!

[alexander-schneider]

Thanks, this makes sense.

I agree with the provider-agnostic direction.

My plan would be to:

1. introduce a base sentiment provider interface with snapshot() and trending()
2. move the current implementation behind an AdanosSentimentProvider
3. avoid modifying the existing swarm presets directly
4. remove the context.py prompt change and keep discovery at the tool layer

That would keep the public sentiment capability vendor-neutral while still allowing Adanos as one optional backend via config.

If that matches what you have in mind, I’m happy to rework this PR in that direction.

[warren618]

Thanks for the clean implementation and willingness to iterate.

After reviewing further, I think the current sentiment coverage (skills + swarm presets + web_search + read_url) is sufficient for now. Adding a dedicated provider layer makes more sense when there are multiple backends to justify the abstraction.

Closing for now — if users report gaps in sentiment analysis, happy to revisit with a multi-provider design. Appreciate the contribution!