Skip to main content
Glama
Circuit-LLM

circuit-mcp

Official
by Circuit-LLM
OverviewSchemaRelated ServersScoreDiscussions
JavaScript
Remote

circuit-mcp

Give any AI agent Circuit's real-time Solana data and agent-swarm intelligence as tools — auto-paid per call in CIRC over x402. No API keys, no signup. Add it to Claude Desktop, Claude Code, or any agent runtime with one line.

Node.js Version MCP x402 License

Website · Data API · Circuit SDK · Telegram · X / Twitter

Beta software. circuit-mcp is under active development — expect breaking changes, incomplete features, and rough edges. Paid tools spend real CIRC per call; start with the free tools (or a small spend cap) until you're comfortable with how it behaves.

What it does

A thin Model Context Protocol server over @circuit-llm/data. It exposes Circuit's real-time Solana data as tools any MCP client can call — and auto-pays for them per call in CIRC over x402. Free tools return data directly; paid tools are auto-paid from your wallet, bounded per call and per session. No API keys, no accounts.

The differentiator is the swarm_* tools: live signals, consensus, leaderboard, holdings, and a crowd-sourced rug blacklist from Circuit's running trading-agent fleet — data no generic price API has.

29 data tools (14 free) + dllm_chat (decentralized LLM inference) + pay_settle, 3 guided prompts, and 5 free ambient resources. Every tool is read-only.

Related MCP server: @portalsprotocol/mcp-server

Quick Start

Add it to any MCP client (Claude Desktop, Claude Code, an agent runtime):

// claude_desktop_config.json → "mcpServers"
{ "circuit": { "command": "npx", "args": ["-y", "@circuit-llm/mcp"],
    "env": { "CIRCUIT_WALLET": "<base58 secret funded with CIRC>" } } }   // omit → free tools only

Then ask your agent "what's the swarm's consensus on this mint?" or "audit this token for rug risk." The paid tools settle on Solana in ~400ms behind the scenes. Without CIRCUIT_WALLET, the free tools still work — and paid tools return an x402 quote you can pay from your own wallet and complete with pay_settle (see pass-through).

Tools

Free — price & market data

Tool

What

circuit_quote

live price list for every tool (call this first)

token_price

aggregated USD price (Jupiter + DexScreener + CoinGecko)

live_prices

sub-second batch prices (≤20 mints) from the gRPC indexer

sol_price

current SOL/USD oracle price

token_candles

OHLCV candlesticks (1m/5m/1h/1d) from the on-chain feed

scan

on-chain dip-reversal scanner

slippage_buy / slippage_sell

pre-trade price-impact estimate

x402_accepted_tokens

tokens accepted to pay Circuit's x402 endpoints (universal adapter)

Free — swarm intelligence ⭐ (the differentiator)

Tool

What

swarm_leaderboard ⭐

agents ranked by reputation — whose signals to trust

swarm_holdings ⭐

what the fleet is holding right now (live smart-money positioning)

swarm_blacklist ⭐

crowd-sourced rug/scam avoid-list with reasons

swarm_blacklist_check ⭐

fast single-token "is this flagged?" check

swarm_stats ⭐

live fleet activity + signal volume

Paid (auto-paid in CIRC via x402)

Tool

Cost

What

swarm_feed ⭐

~$0.002

live buy/sell/rug signals from the swarm

swarm_consensus ⭐

~$0.002

reputation-weighted swarm view on one token

swarm_insights ⭐

~$0.002

aggregated patterns the swarm is seeing

token_security

~$0.003

rug-risk audit — authorities, LP lock, risk flags

token_overview

~$0.003

price + metadata + security + pools in one call

token_info

~$0.005

metadata + market data (supply, mcap, FDV, liquidity)

token_holders

~$0.005

holder count + top-5/10/20 concentration

token_top_traders

~$0.005

top traders by volume (Birdeye) — wallet, whale tags, buy/sell, USD volume

trending

~$0.002

trending tokens across sources

new_tokens

~$0.002

freshly launched tokens (discovery feed)

wallet_pnl

~$0.01

realized/unrealized P&L for any wallet

wallet_analytics

~$0.01

behavioral profile — win rate, hold times, sizing

market_regime

~$0.002

risk-on/risk-off macro read

market_sentiment

~$0.002

fear/greed gauge

market_overview

~$0.002

broad market snapshot + top movers

nft_market

~$0.002

global NFT market snapshot — collections, listings, bid coverage, arb count, median floor

nft_floors

~$0.003

all Tensor collection floors + listing counts, sortable

nft_collection

~$0.003

one collection: floor, cheapest listings, top bid, royalty, net spread

nft_arb

~$0.005

mark-to-market NFT arb — floor ≤ best bid, ranked by net spread

nft_asset

~$0.002

inspect one NFT by mint (listed?, price, floor, sellable-into-bid)

nft_bids

~$0.003

full standing collection-bid depth (highest first)

nft_search

~$0.002

resolve a collection by name → on-chain address + floor

nft_sales

~$0.003

recent listing activity (velocity read, not confirmed sales)

wallet_nfts

~$0.005

a wallet's NFTs + floor mark-to-market total

Prices are live from circuit_quote (/api/quote); a few paid endpoints are intermittently ungated (free).

Paid — decentralized inference

Tool

Cost

What

dllm_chat

~$0.03

chat completion from Circuit's decentralized LLM (Qwen2.5-72B) over x402

dllm_chat pays per call in CIRC — the same x402 rail as the data tools, not model credits. Pass prompt (single turn, optional system) or full OpenAI-style messages. The result includes a backend field: mesh = the decentralized DLLM, openrouter-fallback = a hosted fallback model served while the mesh is offline (so a paid call never dead-ends). Point it elsewhere with CIRCUIT_INFERENCE_URL (default https://inference.circuitllm.xyz).

Settlement — pay_settle: when the server has no wallet, a paid tool returns an x402 quote instead of paying. Pay it on Solana yourself (CIRC to the recipient, or any registered token to its collector), then call pay_settle with the same { tool, args } and your transaction signature to get the data. With a funded CIRCUIT_WALLET, paid tools auto-pay and you never need this.

Prompts

Guided workflows that chain the right tools for a single intent:

Prompt

Args

What it does

rug_check

mint

blacklist + security + holders + consensus → SAFE / CAUTION / AVOID

ape_check

mint, solAmount?

consensus + security + slippage + regime → GO / NO-GO

swarm_pulse

—

stats + holdings + leaderboard + fresh buy signals → what the fleet is doing

Resources

Free, read-only ambient context a client can pull without a tool call: circuit://quote, circuit://swarm/leaderboard, circuit://swarm/holdings, circuit://swarm/blacklist, circuit://x402/accepted-tokens.

Configuration

All configuration is via environment variables.

Variable

Default

Purpose

CIRCUIT_WALLET

—

base58 secret key that funds micropayments (omit → free tools only)

CIRCUIT_MCP_MAX_SPEND_CIRC

1000

per-call CIRC spend cap

CIRCUIT_MCP_MAX_TOTAL_CIRC

50000

per-process CIRC cap — the runaway-spend guard; paid tools stop once reached

CIRCUIT_MCP_TIMEOUT_MS

120000

outer per-tool-call backstop (a genuinely stuck call returns a clean error)

CIRCUIT_TREASURY

—

if set, only ever pay this address (recipient allow-list — recommended)

CIRCUIT_DATA_URL

https://api.circuitllm.xyz

override the data API base

CIRCUIT_INFERENCE_URL

https://inference.circuitllm.xyz

override the DLLM inference gateway base (dllm_chat)

CIRCUIT_RPC_URL

public RPC

Solana RPC used to send payments — set your own; the public default rate-limits

CIRCUIT_PAYMENT_MINT

—

pay in a registered token instead of CIRC (see Paying in another token)

CIRCUIT_MCP_MAX_PAYTOKEN

—

required with CIRCUIT_PAYMENT_MINT: per-call ceiling in the token's own base units (fail-closed)

CIRCUIT_MCP_MAX_TOTAL_PAYTOKEN

—

optional cumulative foreign-token ceiling (base units) — the drain guard

Paying in another token

Circuit's Universal x402 Adapter lets any registered token pay Circuit's x402 endpoints — the token is swapped to CIRC on the back end. To have this server pay for tools in a registered token instead of CIRC, set CIRCUIT_PAYMENT_MINT to that mint (call x402_accepted_tokens to see what's registered) and CIRCUIT_MCP_MAX_PAYTOKEN to a per-call ceiling in the token's base units. The ceiling is mandatory — without it the server fails closed and keeps paying CIRC. Any endpoint that doesn't accept the token also falls back to CIRC automatically. Requires a funded CIRCUIT_WALLET that holds the token.

Safety

  • Spend is bounded two ways — CIRCUIT_MCP_MAX_SPEND_CIRC per call and CIRCUIT_MCP_MAX_TOTAL_CIRC per process (the drain guard against a looping agent). Set CIRCUIT_TREASURY to pin the payee so a hostile endpoint can't redirect funds.

  • Read-only — every tool is a data fetch; none move funds beyond the micropayment.

  • No bypass — this package always pays per call; the internal-key bypass is a Circuit-hosted concern, never a user knob (see docs/HOSTING.md).

  • Protocol-safe — all logs go to stderr; stdout is reserved for the MCP channel.

How it works

Each paid tool call hits the Circuit Data API: a free endpoint returns data; a paid one answers 402 Payment Required with a CIRC quote. @circuit-llm/data pays the quote from your wallet on Solana and retries — the spend caps and CIRCUIT_TREASURY allow-list bound where and how much.

Pass-through (no wallet). Without CIRCUIT_WALLET, the server doesn't pay — it returns that 402 quote to the caller. You pay it yourself and finish with pay_settle; the data API verifies the signature on-chain (single-use, ≤5 min), so the server never holds funds. This is how a wallet-free hosted endpoint (like mcp.circuitllm.xyz) lets each caller pay per call in their own token. For a Circuit-fronted hosted deployment, see docs/HOSTING.md.

Develop

git clone https://github.com/Circuit-LLM/MCP && cd MCP
npm install
npm run smoke    # spawn the server via a real MCP client, list tools, exercise the free tools (no spend)
npm start        # run the server over stdio

Built on @circuit-llm/data + @circuit-llm/wallet + the MCP TypeScript SDK.

Part of the Circuit Stack

  • circuit-mcp — this repo, Circuit data + swarm intel as x402-paid MCP tools

  • circuit-sdk — the TypeScript SDK (x402 · data · wallet · agent · inference)

  • circuit-data-api — the x402-gated Solana data aggregator these tools serve

  • circuit-agent — the autonomous trading agent behind swarm_feed

  • circuitllm.xyz — website and data terminal

License

MIT — see LICENSE.

Available Tools

10 tools
circuit_quoteCircuit price listA

FREE. List every Circuit data tool with its live cost in USD and CIRC. Call this first to see what each paid tool costs.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

A4.2/5.0
Behavior3/5

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

Description highlights 'FREE' and 'live cost' but lacks details on authentication, rate limits, or data freshness. No annotations exist, so description carries full burden but only partially covers it.

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?

Two-sentence description that is front-loaded with 'FREE.' and no extraneous words. Every sentence earns its place.

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?

Given no parameters, output schema, or annotations, description explains purpose and usage well. Missing output structure details, but for a simple list tool it is reasonably complete.

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?

No parameters; schema coverage is 100%. Description adds meaning by explaining output: list of tools with costs. For zero-param tools, baseline is 4, and description meets it.

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?

Description uses specific verb 'List' and resource 'Circuit data tools with costs'. It explicitly states the tool lists costs in USD and CIRC, distinguishing it from siblings like 'live_prices' which likely provide token prices.

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

Usage Guidelines4/5

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

Explicitly says 'Call this first to see what each paid tool costs', providing clear guidance on when to use it. Does not explicitly discuss when not to use or alternatives, but the directive is strong.

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

live_pricesLive batch pricesA

FREE. Sub-second batch prices for up to 20 mints straight from the Circuit gRPC indexer (Redis reads).

ParametersJSON Schema
NameRequiredDescriptionDefault
mintsYesSPL token mint addresses (max 20)

TDQS

A3.8/5.0
Behavior3/5

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

No annotations are provided, so the description must disclose behavioral traits. It reveals that the tool is free, fast, and reads from Redis, but lacks details on rate limits, error handling, data freshness, or idempotency. The description adds some context but is not fully transparent.

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 a single, efficient sentence that front-loads key attributes ('FREE', 'sub-second') and clearly states the tool's purpose. No waste or redundancy.

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?

For a simple batch price tool with one parameter and no output schema, the description covers the data source, speed, and batch limit. It lacks output format details and error behavior, but is largely complete given the tool's simplicity.

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?

The input schema has 100% description coverage for the only parameter ('mints'), including maxItems=20. The description echoes the batch limit but does not add any new semantic meaning beyond the schema. 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?

The description clearly states the tool's function: retrieving sub-second batch prices for up to 20 mints. It specifies the data source (Circuit gRPC indexer via Redis) and distinguishes itself from sibling tools that likely handle single tokens or different operations.

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?

The description implies usage for fast batch price queries, mentioning 'FREE' and 'sub-second'. However, it does not explicitly state when to prefer this tool over alternatives like 'token_price' or 'circuit_quote', nor does it provide exclusion criteria.

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

scanDip-reversal scanC

FREE. The Circuit on-chain dip-reversal scanner: freshly scored candidates from the live gRPC feed.

ParametersJSON Schema
NameRequiredDescriptionDefault
limitNomax candidates (default 20)
minLiquidityNomin USD liquidity filter

TDQS

C2.9/5.0
Behavior2/5

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

With no annotations, the description must fully disclose behavior. It mentions 'live gRPC feed' but does not clarify read-only nature, rate limits, required permissions, or any side effects. The behavior beyond scanning is opaque.

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 a single sentence with no wasted words. It front-loads the free aspect and immediately states the tool's function. It is concise and to the point.

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

Completeness2/5

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

The tool lacks an output schema, so the description should explain what candidates are returned (e.g., token symbols, scores). It does not mention the output format, pagination, or how results are ordered, leaving context incomplete.

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 coverage is 100%, so the input schema already documents both parameters well. The description adds no additional meaning or usage hints beyond what the schema provides, meeting the baseline of 3.

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 description clearly states it is a 'dip-reversal scanner' providing 'freshly scored candidates', which defines its purpose. It distinguishes from siblings like circuit_quote (quotes) and trending (trending tokens) through the specific term 'dip-reversal'.

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

Usage Guidelines2/5

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

No guidance is provided on when to use this tool versus alternatives. The description lacks context about prerequisites, complementary tools, or situations where this tool is appropriate or not.

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

swarm_consensusSwarm consensus on a tokenC

~$0.002 in CIRC. The swarm's reputation-weighted view on ONE token: bullish / bearish / rug_alert with confidence.

ParametersJSON Schema
NameRequiredDescriptionDefault
mintYesSPL token mint address

TDQS

C2.9/5.0
Behavior2/5

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

With no annotations, the description carries the full burden. It mentions cost (~$0.002) but does not disclose other behavioral traits such as rate limits, error handling, or whether it is read-only.

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?

Single sentence, no wasted words. Cost is upfront, which may be slightly misplaced but does not detract significantly from clarity.

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

Completeness3/5

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

For a simple tool with one parameter and no output schema, the description explains the output categories. However, it lacks details on the response structure or what happens on error.

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 coverage is 100%, so baseline is 3. The description adds minimal extra meaning by stating 'ONE token', but does not elaborate on the parameter format beyond what the schema provides.

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 description clearly states it provides a reputation-weighted view (bullish/bearish/rug_alert) with confidence. It specifies 'ONE token', which differentiates from siblings like swarm_feed. However, the verb is implied rather than explicit.

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

Usage Guidelines2/5

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

No guidance on when to use this tool versus alternatives like token_overview or swarm_feed. It does not mention exclusions or prerequisites.

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

swarm_feedSwarm signal feedC

~$0.002 in CIRC. Live buy/sell/rug signals published by the Circuit trading-agent swarm — signal data unique to Circuit.

ParametersJSON Schema
NameRequiredDescriptionDefault
typeNo
limitNo
minReputationNoonly signals from agents above this reputation

TDQS

C2.9/5.0
Behavior2/5

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

With no annotations, the description must disclose behavioral traits. It reveals a cost (~$0.002 in CIRC) but omits whether the operation is read-only, any rate limits, pagination details, or response characteristics. This leaves critical safety and behavior unclear.

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 a single, front-loaded sentence that conveys cost, signal types, source, and uniqueness. No wasted words; every part earns its place.

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

Completeness2/5

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

Given 3 parameters, no output schema, and no annotations, the description lacks essential context. It does not explain return format, how the 'limit' parameter affects results, whether signals are historical or real-time, or how to interpret the data. Incomplete for an agent to use effectively.

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 coverage is only 33% (minReputation has a description). The description adds context by listing signal types (buy/sell/rug) which correspond to the 'type' enum, but provides no additional meaning for 'limit' or 'minReputation' beyond the schema. It partially compensates for low coverage but not fully.

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 description states the tool provides live buy/sell/rug signals from the Circuit trading-agent swarm, clearly identifying the resource and action. It also differentiates from siblings by noting the data is unique to Circuit, but it does not explicitly state the verb (e.g., 'fetch' or 'list') or that it returns a feed.

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

Usage Guidelines2/5

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

No explicit guidance on when to use this tool versus alternatives like swarm_consensus. The phrase 'unique to Circuit' implies exclusivity but lacks a clear directive or when-not-to-use scenarios. No prerequisites or exclusions are mentioned.

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

token_holdersHolder concentrationC

~$0.005 in CIRC. Holder count + top-5/10/20 supply concentration (a key rug/whale signal).

ParametersJSON Schema
NameRequiredDescriptionDefault
mintYes

TDQS

C2.4/5.0
Behavior2/5

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

No annotations are provided, so the description carries the full burden. It discloses the cost ('~$0.005 in CIRC') which is a behavioral trait, but lacks information on mutability, side effects, or response format. More detail is needed for a complete picture.

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

Conciseness3/5

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

The description is very short, which is good for conciseness, but the structure is suboptimal: the cost note ('~$0.005 in CIRC.') appears first and may confuse, while the actual output details follow. It could be reordered for clarity.

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

Completeness2/5

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

Given the tool is simple (1 parameter, no output schema), the description is incomplete: it does not explain how to interpret the concentration values, the format of the output, or what 'CIRC' refers to. This leaves gaps for an AI agent attempting to use the tool correctly.

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

Parameters1/5

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

With 0% schema description coverage and no explanation of the 'mint' parameter in the description, the agent gains no additional meaning beyond the raw schema. The description fails to clarify what 'mint' represents (likely a token address), leaving the parameter ambiguous.

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 description clearly states the tool provides holder count and top-5/10/20 supply concentration, which is a specific verb+resource. However, it does not explicitly say 'returns' or distinguish from sibling tools that might also provide holder data.

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

Usage Guidelines2/5

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

The description mentions it's a 'key rug/whale signal' implying use for risk assessment, but gives no explicit guidance on when to use this tool vs alternatives like token_overview or token_security, and no when-not-to-use advice.

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

token_overviewOne-shot token overviewA

Price + metadata + security audit + active pools in a single call (replaces four). Priced per /api/quote (~$0.003 in CIRC; often free).

ParametersJSON Schema
NameRequiredDescriptionDefault
mintYes

TDQS

A3.5/5.0
Behavior3/5

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

With no annotations, the description carries full burden. It mentions cost and aggregation of four data types, but does not disclose behavior on invalid mint, rate limits, or internal API calls. Adds some value but lacks depth.

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?

Two concise sentences with no redundancy. Front-loaded with main function, but could be slightly more structured (e.g., listing included data).

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

Completeness3/5

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

Given one parameter and no output schema, the description outlines the tool's purpose but omits output structure (e.g., what fields 'metadata' covers) and error handling. Adequate but not complete for an agent.

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

Parameters2/5

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

Schema coverage is 0%, and description does not explain the single parameter 'mint' (e.g., token mint address). For a tool aggregating multiple data sources, failing to clarify the parameter reduces usability.

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 provides 'Price + metadata + security audit + active pools in a single call,' specifying the verb (gives overview) and resource (token). It distinguishes itself from siblings by noting it 'replaces four' other calls.

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?

The description implies usage when consolidating multiple lookups, but does not explicitly state when to use vs. alternatives like 'circuit_quote' or 'token_security.' The pricing note helps, but guidance is implicit.

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

token_priceToken priceA

FREE. Aggregated USD price for a Solana token (Jupiter + DexScreener + CoinGecko, with on-chain price-feed fallback).

ParametersJSON Schema
NameRequiredDescriptionDefault
mintYesSPL token mint address

TDQS

A4/5.0
Behavior4/5

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

No annotations provided, so description must disclose behavior. It states it is 'FREE' (cost implications) and uses aggregated sources with fallback. However, it does not mention failure modes (e.g., what if token not found) or rate limits.

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?

Single sentence with front-loaded 'FREE' and clear purpose. Under 20 words, zero redundancy. Every word adds value.

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?

Given the tool's simplicity (1 param, no output schema, no annotations), the description is mostly complete. It covers data sources and cost. However, it omits return format (e.g., 'returns a float USD price') and error handling details.

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% (single param 'mint' with description 'SPL token mint address'). The tool description adds minimal extra meaning ('Solana token' aligns with mint address). Baseline 3 as schema does the heavy lifting.

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 purpose: 'Aggregated USD price for a Solana token' with specific data sources listed (Jupiter, DexScreener, CoinGecko, on-chain fallback). This distinguishes it from siblings like 'live_prices' which might provide multiple token prices or different sources.

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?

The description implies usage for getting a single token's price but does not explicitly state when to use this tool over alternatives (e.g., 'live_prices' or 'circuit_quote'). No guidance on prerequisites or exclusions.

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

token_securityToken security auditA

~$0.003 in CIRC. Rug-risk audit: authority analysis, LP lock %, creator balance, and full risk flags by category.

ParametersJSON Schema
NameRequiredDescriptionDefault
mintYes

TDQS

A3.5/5.0
Behavior3/5

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

No annotations exist, so description bears full burden. It mentions a cost (~$0.003 in CIRC) and lists analysis categories but does not disclose if the tool is read-only, output format, or any side effects.

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?

Single sentence with no waste, though cost information is secondary. Purpose is front-loaded. Could be slightly improved by removing extraneous detail.

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

Completeness3/5

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

Provides enough context for the tool's purpose but lacks output format details or prerequisites. Adequate for a simple 1-param tool but not comprehensive.

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

Parameters2/5

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

The schema has 1 parameter (mint) with 0% description coverage, and the description does not explain that 'mint' is the token mint address, forcing the agent to infer.

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 performs a 'Rug-risk audit' with specific analyses (authority analysis, LP lock %, creator balance, risk flags), distinguishing it from sibling tools like token_overview or token_price.

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?

The description implies usage for security auditing but provides no explicit when-to-use or when-not-to-use guidance, nor does it reference alternatives among sibling tools.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. 10 tool updatesv0.1.0
    • First observedcircuit_quote
    • First observedlive_prices
    • First observedscan
    • First observedswarm_consensus
    • First observedswarm_feed
    • First observedtoken_holders
    • First observedtoken_overview
    • First observedtoken_price
    • First observedtoken_security
    • First observedtrending
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

B3.4/5.0
Disambiguation5/5

Each tool has a clearly distinct purpose, from listing costs to providing token prices, holders, security audits, and trading signals. There is no overlap between tools; even the swarm-related tools (consensus and feed) target different outputs.

Naming Consistency4/5

Tool names mostly follow a descriptive noun or compound noun pattern in snake_case (e.g., circuit_quote, live_prices, token_holders). A few single-word names like 'scan' and 'trending' are minor deviations but still clear and consistent in style.

Tool Count5/5

With 10 tools, the set is well-scoped for a crypto data and signal server. Each tool provides distinct functionality without being overwhelming or sparse.

Completeness4/5

The tools cover essential operations for token analysis and trading signals: price, security, holders, trending, and swarm signals. Minor gaps exist, such as lack of historical data or direct trading capabilities, but the core domain is well covered.

Maintenance

ActivityMaintained
ResponsivenessNo issues

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Related MCP Servers

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/Circuit-LLM/MCP'

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