Santiment

Discover Insights

insight_discovery_tool

Read-only

List Santiment insights (analyst-written crypto articles) published in a lookback window. Returns metadata only — id, title, tags, author, link, published_at, prediction — never the article body.

When to use

The user asks what Santiment analysts have written or published recently.
As step 1 of a two-step read: discover ids here, then pass them to fetch_insights_tool for the full text.

When not to use

Full text of an insight — use fetch_insights_tool (it needs ids, so call this tool first).
What the market is talking about right now — use trending_stories_tool (stories only) or combined_trends_tool (stories + trending words). Insights are human-authored articles, not live social signal.
Numeric metric timeseries for an asset — use fetch_metric_data_tool.
Ranking or screening assets by a metric — use assets_by_metric_tool.

Parameters

time_period (optional, default "30d") — lookback window as <integer><unit>, unit one of s, m, h, d, w, y (e.g. "12h", "7d", "90d", "1y"). The window is always now - time_period .. now; absolute dates and future ranges are not supported. An unparsable value returns an error, not a default.

There is no tag, author, asset or full-text filter — filter the returned list yourself.

Behavior

Read-only: no writes, no state change, nothing destructive.
Requires an authenticated Santiment account (API key or OAuth token); every call counts against the account plan's MCP rate limits.
Returns only published, moderator-approved insights, newest first, hard capped at 100 per call. A wide time_period can hit that cap and silently omit the oldest insights — if total_count is 100, narrow the window and call again.

Response

JSON object:

{
  "insights": [
    {
      "id": 1234,                          // integer, feed to fetch_insights_tool
      "title": "...",
      "tags": ["BTC", "bitcoin"],          // asset tickers/slugs and topics
      "link": "https://app.santiment.net/insights/read/1234",
      "published_at": "2025-01-30T10:00:00Z",
      "author": "username",                // "Anonymous" when unset
      "prediction": "semi_bullish"         // heavy_bullish | semi_bullish |
                                           // semi_bearish | heavy_bearish |
                                           // none | unspecified | null
    }
  ],
  "time_period": "30d",
  "total_count": 1,
  "period_start": "2024-12-31T10:00:00Z",
  "period_end": "2025-01-30T10:00:00Z"
}

An empty insights list with total_count: 0 means nothing was published in the window — a valid result, not an error.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`time_period`	No	Lookback window as <integer><unit>, unit one of s, m, h, d, w, y (e.g. '12h', '7d', '30d', '90d', '1y'). Insights published in `now - time_period` .. `now` are returned. Absolute dates and future ranges are not supported. Defaults to '30d'.

TDQS

A5/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already include readOnlyHint=true and destructiveHint=false. The description further discloses authentication requirements, rate limiting, pagination cap of 100, silent omission behavior, and response validity conditions. This goes far beyond annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

While long, the description uses clear headings and every section serves a distinct purpose: usage, parameters, behavior, and response. It is appropriately sized for the tool's complexity, with no redundant content.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite having no output schema, the description provides a complete response format with field types and semantics, plus edge cases (like empty results). It covers all necessary context for correct invocation and result handling.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% for the single parameter, but the description adds substantial meaning: concrete examples, unit constraints, exact window semantics, no absolute dates, and error behavior. This is a model of enriching schema information.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's function with a specific verb and resource: 'List Santiment insights (analyst-written crypto articles) published in a lookback window. Returns metadata only'. It explicitly distinguishes from siblings by naming alternatives like fetch_insights_tool and trending_stories_tool.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The 'When to use' and 'When not to use' sections provide explicit guidance, including exact scenarios and named alternative tools. This fully covers when to use this tool versus alternatives, making it exemplary.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All Santiment tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.4/5.0

Disambiguation5/5

Each tool has a clearly distinct purpose: screening assets vs fetching timeseries vs catalog discovery vs charting vs insights discovery/fetch vs trending stories vs combined trends. The overlapping trending tools are explicitly differentiated through a superset relationship with usage guidance.

Naming Consistency3/5

All names are snake_case and most end in '_tool', but the pattern is mixed: some start with verbs (fetch_*, show_*) while others are noun phrases (assets_by_metric_tool, combined_trends_tool, insight_discovery_tool). This is readable but not a consistent verb_noun convention.

Tool Count5/5

8 tools is well-scoped for a crypto analytics server, covering discovery, data retrieval, screening, charting, and content access without bloat or thinness. Each tool earns its place in the workflow.

Completeness4/5

The toolset covers the core workflows: catalog discovery, metric timeseries, asset screening, chart rendering, insights list/fetch, and trending data. Minor gaps include no multi-metric timeseries fetch and a limited set of chart overlay options, but agents can work around these.

Resources

Need Help?