Skip to main content
Glama
coinpaprika

DexPaprika (CoinPaprika)

Official

getCapabilities

Read-onlyIdempotent

Retrieve the server onboarding guide with supported workflows, network slug synonyms, recommended call sequences, and common pitfalls. Use this at session start or when asked how to use the API.

Instructions

Get the static agent onboarding guide for this server: supported workflows, network name synonyms (mapping words like 'eth' to the canonical slug 'ethereum'), recommended call sequences, and common pitfalls. Read-only and keyless. Read it once at the start of a session before your first query, or when asked 'how do I use this API?', 'what order should I call things in?', or 'which slug maps to eth?'. This returns onboarding docs, not live market data; for the actual list of network slugs use getNetworks, and for coverage totals use getStats. Takes no parameters beyond a short rationale.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
rationaleYesREQUIRED. 1-2 sentence rationale for this call (e.g. "User asked for X; calling Y to fetch Z"). Logged for MCP improvement, never shown to end users. No PII or secrets. See the server `instructions` field for the full convention and worked examples.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
statsYes
serverYes
workflowsYesNamed tool sequences for common agent tasks.
agent_skillsYes
documentationYes
common_pitfallsYesKnown edge cases agents should be aware of.
network_synonymsYesCanonical network id -> common alternates an agent might try.
Behavior4/5

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, destructiveHint. The description adds key context: 'Read-only and keyless' and explains rationale logging, which enhances transparency without contradiction.

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?

The description is six concise sentences, front-loaded with the core purpose, each sentence adding value. No wasted words, excellent structure.

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 tool with simple input and annotations covering safety, the description fully addresses when, what, and how, making it contextually complete for an agent to use correctly.

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?

With 100% schema description coverage, the parameter 'rationale' is fully documented in the schema. The description adds no new semantics beyond stating it takes one parameter, so baseline score of 3 is appropriate.

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 specifies 'Get the static agent onboarding guide' with a clear verb and resource, lists contents (workflows, synonyms, sequences, pitfalls), and explicitly distinguishes from sibling tools getNetworks and getStats, fulfilling the highest bar for purpose clarity.

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: 'Read it once at the start of a session... or when asked...' and when not to: 'not live market data', with clear alternatives for related tasks (getNetworks, getStats), meeting the top score.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/coinpaprika/dexpaprika-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server