Santiment

Metrics and Assets Discovery

metrics_and_assets_discovery_tool

Read-only

Catalog lookup: which metrics and which crypto assets (slugs) Santiment supports, and whether a given metric exists for a given asset. Returns names and metadata only — it never returns metric values or timeseries.

When to use

Resolve a name before any data call: turn "Ethereum" into the slug ethereum, or "active addresses" into the metric daily_active_addresses.
Check availability before calling fetch_metric_data_tool, assets_by_metric_tool or show_chart, so a bad slug/metric does not waste a data call.
Recover from a "metric/slug not supported" error from any other tool.

When not to use

Actual metric values over time — use fetch_metric_data_tool.
Ranking, filtering or screening assets by a metric value — use assets_by_metric_tool.
Rendering a chart — use show_chart.
Trending words/stories or insights — use combined_trends_tool or insight_discovery_tool. Those data sets are not in this catalog.

Parameters

Both parameters are optional and the four combinations do four different things:

Arguments	Returns
`{}`	Every supported metric and every supported asset
`{"slug": ...}`	All metrics available for that one asset
`{"metric": ...}`	All assets that support that one metric
`{"slug":..., "metric":...}`	Whether that exact pair is available (validation)

slug — lowercase, hyphen-separated asset id: "bitcoin", "ethereum", "avalanche". Not a ticker: use "bitcoin", not "BTC". One slug per call; lists are not accepted.
metric — lowercase snake_case metric id: "price_usd", "marketcap_usd", "daily_active_addresses". One metric per call.

Examples:

{}
{"slug": "ethereum"}
{"metric": "price_usd"}
{"slug": "bitcoin", "metric": "daily_active_addresses"}

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.
Results are cached server-side, so the catalog can lag a newly listed asset by a few minutes.
Large responses (notably {}, which covers ~500 assets) are truncated to stay under the client token limit. When that happens the response carries "truncated": true plus "truncation_notice", and the counts are adjusted to what was actually returned — pass slug or metric to get a complete answer instead of a truncated one.

Response

Always a JSON object. Its shape depends on the arguments.

{} — full catalog:

{
  "metrics": [{"name": "price_usd", "description": "...", "unit": "USD",
               "supports_many_slugs": true, "min_interval": "1m",
               "default_aggregation": "last",
               "documentation_urls": [{"url": "..."}]}],
  "assets": [{"name": "Bitcoin", "slug": "bitcoin", "ticker": "BTC"}],
  "metrics_count": 120, "assets_count": 500, "description": "..."
}

{"slug": ...} — {"slug", "metrics" (same metric objects as above), "metrics_count", "description"}.

{"metric": ...} — {"metric", "assets" (same asset objects as above), "assets_count", "description"}.

{"slug": ..., "metric": ...} — on success {"slug", "metric": <metric object>, "available": true, "description"}.

Unsupported input is reported inside a successful response, not as a tool error: an unknown slug yields {"error": "...", "available_assets": [...]}, an unknown metric yields {"error": "...", "available_metrics": [...]}. There is no "available": false — read error. Error messages include a fuzzy suggestion for near-miss metric names (price_uds -> price_usd), so retry with the suggested name.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`slug`	No	Santiment slug of one crypto asset: lowercase, hyphen-separated, e.g. 'bitcoin', 'ethereum', 'avalanche'. Not a ticker - use 'bitcoin', not 'BTC'. One slug per call; lists are not accepted. Alone: returns all metrics available for this asset. With `metric`: checks only whether that metric exists for this asset. Omit both to list the whole catalog.
`metric`	No	Santiment id of one metric: lowercase snake_case, e.g. 'price_usd', 'marketcap_usd', 'daily_active_addresses'. One metric per call; lists are not accepted. Alone: returns all assets that support this metric. With `slug`: checks only whether this metric exists for that asset. Omit both to list the whole catalog.

TDQS

A4.8/5.0

Behavior5/5

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

The description richly discloses behaviors beyond annotations: read-only confirmation, auth/API key requirements, server-side caching with lag, response truncation for large payloads (with 'truncated': true and counts adjusted), and error handling via a successful response with an 'error' field plus fuzzy suggestions. This goes far beyond the readOnlyHint/destructiveHint annotations.

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?

The description is long but well-structured with clear headers (When to use, When not to use, Parameters, Behavior, Response) and a table for combinations. Every section contributes essential information for a tool with four distinct modes. It is not overly verbose given the complexity, though a couple of examples could be trimmed without loss.

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?

With no output schema, the description fully explains return shapes for all four argument combinations, including the full catalog JSON, per-slug/metric results, and error responses. It also covers truncation, caching, rate limits, and auth. No critical aspect of behavior or return format is left undocumented.

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

Parameters4/5

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

The input schema already covers 100% of parameter semantics with examples and combination behavior. The description adds value with a four-row table showing the exact output for each argument combination, plus concrete examples and clarification that lists are not accepted. It reinforces but does not significantly extend the schema's detailed parameter descriptions, earning slightly above baseline.

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 opens with a precise, resource-specific statement: 'Catalog lookup: which metrics and which crypto assets (slugs) Santiment supports, and whether a given metric exists for a given asset.' It explicitly says it returns names and metadata only, never metric values or timeseries, which immediately distinguishes it from data-fetching siblings like fetch_metric_data_tool and assets_by_metric_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?

Dedicated 'When to use' and 'When not to use' sections provide explicit guidance. They name alternatives directly: use fetch_metric_data_tool for values, assets_by_metric_tool for screening, show_chart for charts, and combined_trends_tool/insight_discovery_tool for trends. It also covers error-recovery use cases, such as resolving 'metric/slug not supported' errors.

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?