Santiment

Fetch Metric Data

fetch_metric_data_tool

Read-only

Fetch metric timeseries for one metric and one or many slugs, or for a text search term.

Defaults: last 30 days (time_period="30d"), interval="1d".

Pass text instead of slugs to get a social metric for any word or phrase (e.g. how often "sold" was mentioned), not just for an asset.

Use this when the assets are already known and the values over time matter. For the opposite direction — "which assets satisfy X" / "top N by X", one aggregated value per asset across the whole universe — use assets_by_metric_tool. To confirm a metric exists for a slug first, use metrics_and_assets_discovery_tool; to draw the result, use show_chart.

Input Schema

TableJSON Schema

Name	Required	Description
`text`	No	Pass either `slugs` or `text`, not both. A search term (word or phrase, e.g. "sold" or "etf approval") to compute the metric for, instead of an asset. Supported only by social metrics such as social_volume_total and social_dominance_total. For text, social dominance is the share of all social documents that match the term.
`slugs`	No	Pass either `slugs` or `text`, not both. List of slug identifiers (e.g., ["bitcoin"], ["bitcoin", "ethereum"], etc.). Accepts at most 10 slugs at a time. Only metrics that have `supports_many_slugs: true` can accept more than one slug. Check the `supports_many_slugs` field in the metrics_and_assets_discovery_tool response before passing multiple slugs. Financial and on-chain metrics generally support multiple slugs; social, sentiment, and derivatives metrics generally do not. The tool returns data for one metric and one or many slugs.
`metric`	Yes	Metric name to fetch (e.g., 'price_usd'). IMPORTANT: Before fetching data, verify metric names by calling the metrics_and_assets_discovery_tool first. Only metrics listed there are supported. Do not guess or infer metric names — they may differ from what you expect.
`interval`	No	The interval between two data points in the timeseries data (e.g., '5m', '1h', '1d'). The format is: <number><suffix>, where: - <number> is an integer - <suffix> is one of: - m (minutes) - h (hours) - d (days) - w (weeks) - y (years) For example, 5m means that the data returned will have a 5 minute interval between two data points. Each metric has predefined `min_interval`. It describes the lowest possible interval for which data is available. If the metric has `min_interval=1d` it means that Santiment has one data point per day for that metric. For these metrics `interval="5m"` won't work as 5 minutes is less than 1 day.
`time_period`	No	How far back in time to fetch the data for (e.g., '7d', '30d', '90d'). This parameter defines the range of metric data to fetch - from <time_period> time ago up until now. Defaults to 30d.

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedOct 2, 2026

changedInput schema / properties / slugs / description

Previous value: -"List of slug identifiers (e.g., [\"bitcoin\"], [\"bitcoin\", \"ethereum\"], etc.).\n\nAccepts at most 10 slugs at a time.\n\nOnly metrics that have `supports_many_slugs: true` can accept more than one slug.\nCheck the `supports_many_slugs` field in the metrics_and_assets_discovery_tool response\nbefore passing multiple slugs. Financial and on-chain metrics generally support multiple\nslugs; social, sentiment, and derivatives metrics generally do not.\n\nThe tool returns data for one metric and one or many slugs.\n"New value: +"Pass either `slugs` or `text`, not both.\n\nList of slug identifiers (e.g., [\"bitcoin\"], [\"bitcoin\", \"ethereum\"], etc.).\n\nAccepts at most 10 slugs at a time.\n\nOnly metrics that have `supports_many_slugs: true` can accept more than one slug.\nCheck the `supports_many_slugs` field in the metrics_and_assets_discovery_tool response\nbefore passing multiple slugs. Financial and on-chain metrics generally support multiple\nslugs; social, sentiment, and derivatives metrics generally do not.\n\nThe tool returns data for one metric and one or many slugs.\n"

addedInput schema / properties / text

Added value: +{
+  "description": "Pass either `slugs` or `text`, not both.\n\nA search term (word or phrase, e.g. \"sold\" or \"etf approval\") to compute\nthe metric for, instead of an asset. Supported only by social metrics such\nas social_volume_total and social_dominance_total. For text, social\ndominance is the share of all social documents that match the term.\n",
+  "type": "string"
+}

changedInput schema / required

Previous value: -[
-  "metric",
-  "slugs"
-]New value: +[
+  "metric"
+]

First observedAug 13, 2026

TDQS

A4.2/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=true, destructiveHint=false, openWorldHint=false, so the safety profile is covered. The description adds the text-vs-slugs alternative behavior and social-metric scoping, but says nothing about return shape or pagination, which is modest added value on top of structured fields.

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

Conciseness4/5

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

Defaults are front-loaded in the first two lines, followed by the text-mode note and then the routing guidance. The concrete examples ('sold', 'etf approval') earn their space, though the routing block is slightly long.

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?

For a read-only timeseries fetch with no output schema, annotations cover safety and the description covers defaults, input-mode choice, constraints, and where to validate metric names. Nothing essential to correct invocation is missing.

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

Parameters3/5

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

Schema description coverage is 100%, so the meaning of slugs, text, interval and time_period is already documented in the schema, including the 'slugs or text, not both' constraint. The description's defaults restatement (30d/1d) and text semantics are marginal additions, so baseline 3 applies.

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?

Starts with a specific verb and resource ('Fetch metric timeseries for one metric and one or many slugs, or for a text search term') and names the exact tradeoff versus siblings. An agent can distinguish it from assets_by_metric_tool directly from the text.

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?

Explicitly states when to use it ('when the assets are already known and the values over time matter') and the condition that routes to the alternative ('which assets satisfy X / top N by X ... use assets_by_metric_tool'). It also names metrics_and_assets_discovery_tool for pre-validation and show_chart for rendering.

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

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

Need Help?