Loading ToolBench
MCP server for Omni.fun — exposes token data, trading info, and bonding curve queries to AI agents
Solid definition foundations across 8 read-only tools with complete input schemas and non-empty descriptions. All tools follow verb_noun naming convention (get_*, simulate_*). Tool descriptions average ~150 chars, meeting baseline. All parameters have type definitions and descriptions. However, several gaps prevent higher scores: (1) Output schemas are completely undocumented, no structured response format visible for any tool, violating pattern:tool and pattern:response-shaper; (2) Missing pagination guidance despite tools like get_trending_tokens likely returning lists; (3) No error handling documentation, tools should guide recovery with actionable messages; (4) Parameter descriptions lack specific constraints (e.g., limit enforcement, address format validation, enum values for chain parameter); (5) No evidence of resource-chaining IDs in responses (e.g., does get_trending_tokens return address for use in get_token?); (6) Tool composition is solid (single responsibility) but discovery flow is unclear (when to use search_tokens vs get_trending_tokens?).
Get an AI agent's profile on Omni.fun by token symbol. Returns the agent's bio, capabilities, token info, curve state, and recent trading activity.
Get the bonding curve state for a token. Returns current price, tokens sold, total raised, progress toward graduation ($69K market cap), and whether the token has graduated to Uniswap V3.
Get step-by-step instructions for buying a token on Omni.fun, including which contracts to interact with on each chain.
Get the list of supported chains for cross-chain trading on Omni.fun. Buys use deBridge DLN (filler-based, instant). Sells use Across or deBridge sell adapters.
Get detailed information about a specific token on Omni.fun by its contract address. Returns price, market cap, bonding curve progress, holder count, and trading volume.
Get the list of trending/active tokens on Omni.fun. Returns token names, symbols, prices, market caps, and bonding curve progress. Use this to discover what tokens are available for trading.
Output schemas completely undocumented. No visible documentation of what fields are returned by any tool (e.g., get_trending_tokens returns structure with 'address, name, symbol, price, marketCap, progress' but this is stated only in description text, not in structured schema). LLMs cannot plan downstream calls without knowing response shape.
Parameter constraints missing. 'limit' in get_trending_tokens states 'max 100' but no minimum is specified, and no constraint declared in schema (should use 'minimum': 1, 'maximum': 100). 'chain' in get_how_to_buy lists valid values in description text ('base, ethereum, arbitrum, ...') instead of as enum in schema. LLMs cannot verify valid values before calling.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 56 | 2026-07-28+ | v2 |
Search for tokens on Omni.fun by name or symbol. Returns matching tokens with their current price and market cap.
Simulate a buy or sell trade to estimate how many tokens you'd receive for a given USDC amount (or vice versa). Does NOT execute a trade. Uses the bonding curve formula: price = basePrice + priceIncrement * tokensSold.
No pagination support documented. Tools returning lists (get_trending_tokens, search_tokens) may return many results, but no limit, offset, page_size, or next_cursor parameters are visible. Default limit=20 is mentioned for get_trending_tokens but not enforced in schema.
No error handling guidance. Tools do not document what errors are possible (e.g., invalid address, token not found, API rate limit) or how to recover. Error descriptions should guide LLMs: 'Token not found. Try search_tokens() to find a valid symbol.' instead of a bare 404.
Tool discovery ambiguity. Both search_tokens and get_trending_tokens return token lists, but the distinction is unclear. When should an agent call search_tokens vs get_trending_tokens? Description should clarify: 'search_tokens finds a specific token by name/symbol; get_trending_tokens discovers what's currently active (discovery-first).'
No resource-chaining IDs documented. If get_trending_tokens returns token data, does it include 'address' so the agent can pass it directly to get_token()? If yes, not stated explicitly in descriptions. Without chaining IDs in responses, agents must make extra lookup calls.
Parameter format constraints missing. 'address' in get_token accepts 'The token contract address (0x...)' but no length, checksum, or regex pattern is enforced. 'symbol' parameters across multiple tools have no length limits or character restrictions specified.