Skip to main content
Glama

Santiment

by io.github.santiment
OverviewDiscussionsAdmin

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
NameRequiredDescriptionDefault
time_periodNoLookback 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'.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / time_period / description
      Previous value: -"Time period for insights (e.g., '7d', '30d', '90d').\nThis parameter defines the range of insights to fetch - from <time_period> time\nago up until now.\n\nDefaults to 30d.\n"New value: +"Lookback window as <integer><unit>, unit one of s, m, h, d, w, y\n(e.g. '12h', '7d', '30d', '90d', '1y'). Insights published in\n`now - time_period` .. `now` are returned. Absolute dates and future\nranges are not supported. Defaults to '30d'.\n"
  2. First observed

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 toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources