Skip to main content
Glama
Sign In
traivo-mcp

traivo-mcp

Official
by traivoxyz
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

On-chain crypto tokens

get_onchain_tokens
Read-onlyIdempotent

Retrieve Ethereum tokens with a real Uniswap V3 route against USDC, including route, fee tier, and on-chain USD price when available.

Instructions

Tokens with a real Uniswap V3 route against USDC on Ethereum mainnet (ETH plus tokens Traivo discovered on-chain), with the on-chain USD price when a quote is available. via is the route (direct USDC pool, or USDC → WETH → token); fee is the pool fee tier in hundredths of a bip. Discovered tokens are not reviewed by Traivo — check liquidity with get_trade_quote before sizing up.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "get_onchain_tokens"
  }
}

Input Schema

NameRequiredDescriptionDefault
limitNoMax rows to return (default 100, max 500).
symbolNoOnly this symbol.
priced_onlyNoDrop tokens with no current on-chain price (default false).

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A3.7/5.0
Behavior4/5

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

Annotations already declare readOnly/idempotent/non-destructive, so the safety profile is covered. The description adds genuinely new context beyond that: discovered tokens are not reviewed by Traivo, prices exist only 'when a quote is available', and the meaning of `via` and `fee` in the result. This trust caveat is exactly the kind of behavioral detail annotations cannot convey.

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?

Three sentences, each doing work: scope, result field semantics, then a risk caveat with a next step. It is slightly dense in the opening sentence with nested parentheticals, but there is no filler and the key scoping constraint leads.

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

Completeness4/5

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

There is no output schema, so the description usefully explains the returned route and fee fields and flags that some tokens may lack a price. Combined with annotations, an agent has enough to call this correctly; only the relationship to the other listing tools is unaddressed.

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 limit, symbol, and priced_only are fully documented in the schema. The description adds no input-parameter meaning; its explanatory effort goes to output fields (`via`, `fee`). Baseline 3 is appropriate when the schema carries parameter semantics.

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

Purpose4/5

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

The first sentence states a specific scope: tokens with a real Uniswap V3 route against USDC on Ethereum mainnet, plus the on-chain USD price when a quote exists. The parenthetical contrast ('ETH plus tokens Traivo discovered on-chain') and the field explanations make the resource concrete. It stops short of naming how it differs from the sibling listing tool get_crypto_markets, so a 4 rather than a 5.

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

Usage Guidelines3/5

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

There is one explicit routing instruction: check liquidity with get_trade_quote before sizing up, which correctly points to a sibling. However, no guidance is given on when to choose this over get_crypto_markets or get_stock_board, and the trade-off between using symbol/limit/priced_only filters is left to inference. Usage is implied by the description rather than fully framed.

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

Deploy Server

Other Tools