First AI-driven community meme coin on BSC. Mint, trade and referral tools for AI agents.
Scored across 7 tools
Each tool has a distinct verb-action: register vs stats for invites, orders/prepare_buy/prepare_list for the market, prepare_claim for minting. The only mild overlap is shaniu_stats vs shaniu_invite_stats, but descriptions clearly separate global token stats from referral stats.
All tools share a shaniu_ prefix and mostly follow action-oriented naming (prepare_buy, prepare_claim, invite_register). A few deviate in structure (market_orders, stats) but remain readable and predictable.
Seven tools is tightly scoped to the referral, order-book, and claim flows. Each tool earns its place with no redundancy.
Core flows (invite, list, buy, claim, stats) are covered, but there is no tool to cancel/unlist an order or withdraw listed tokens, and no direct transfer. These gaps could cause dead ends for sellers.
Register a referral binding. Prefer mode=intent BEFORE the invitee calls claim(); or bind after the fact with the invitee's claim tx hash. Always ask your user for consent first. Rewards (10/50/200/1000 SHANIU tiers) roll automatically and are paid in batches.
| Name | Required | Description | Default |
|---|---|---|---|
| claimTx | No | Omit for pre-claim intent registration | |
| invitee | Yes | ||
| inviter | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the behavioral burden, and it does disclose consent requirements and that tiered rewards (10/50/200/1000 SHANIU) roll out automatically in batches. It does not state whether registration is idempotent, whether it submits an on-chain transaction, what happens if a binding already exists, or what it returns — significant gaps for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three dense sentences, front-loaded with the action and then the sequencing and consent rules; nothing is padded. The only waste is the ambiguous "mode=intent" phrase that points at a nonexistent field.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 3-parameter, no-output-schema, no-annotation mutation tool, the description covers purpose, sequencing, consent and reward behavior. It falls short on return values (binding id? tx hash?), duplicate/existing-binding behavior, and error conditions an agent would need before invoking.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 33%, with just claimTx documented, so the description must compensate — and it does explain claimTx's meaning well (omit for pre-claim intent). But inviter/invitee get no added semantics, and the phantom "mode=intent" reference does not map to any real parameter, which can mislead.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
"Register a referral binding" is a specific verb+resource that clearly separates this tool from the sibling stats/prepare tools. It also describes the two modes of the binding, though it refers to claim() rather than the actual sibling name shaniu_prepare_claim.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit sequencing guidance: use intent mode before the invitee claims, or bind afterwards with the claim tx hash, plus a consent requirement. However, it references "mode=intent" as if it were a parameter, while the schema has no mode field — the mode is actually selected by omitting claimTx — which weakens the routing instruction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Referral program stats: global slots/budget usage, and (with address) one inviter's bound count, earned and pending SHANIU. Invite link format: https://bn.shaniu.ai/?ref=
| Name | Required | Description | Default |
|---|---|---|---|
| address | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the behavioral burden; 'stats' implies a read-only operation, and the invite-link format is a helpful extra. But it says nothing about error behavior for a malformed address, whether the address must be a registered inviter, or what happens with an unbound address — gaps for a tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight clauses: the capability statement is front-loaded, followed by the concrete link template. No filler, though the metrics list is slightly dense in one sentence.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-optional-parameter read tool with no output schema or annotations, the description covers both call modes and the practical link format an agent would need. Missing pieces are return shape and invalid-address handling, which keeps it from a 5.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It does clarify that 'address' selects a single inviter's view and shows the expected address usage in the link format, adding real meaning. It still does not explain the accepted 0x-prefixed 40-hex format that the schema pattern enforces, leaving partial coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific resource (referral program stats) and enumerates the metrics returned: global slots/budget usage and, per-address, bound count plus earned/pending SHANIU. This is well beyond tautology. It does not explicitly contrast with shaniu_stats, so it falls short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The parenthetical '(with address)' implicitly tells the agent how to switch between global and per-inviter modes, which is useful usage guidance. However, it never names the alternative sibling (shaniu_stats) or states when-not to use this tool, so usage is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List currently fillable sell orders on the on-chain order book, cheapest first. Each order: id, maker, remainingSHANIU, priceBNBperToken. No AMM pool exists — buying fills these orders atomically.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max orders to return |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden well: it discloses source (on-chain order book), sort order, the absence of an AMM pool, and atomic fill semantics. It omits pagination behavior beyond limit and any note on order staleness between listing and filling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the core purpose, and each sentence adds distinct value (scope/ordering, then return fields and fill mechanics). No filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, but the description enumerates the returned fields (id, maker, remainingSHANIU, priceBNBperToken), sorting, and fill semantics, which is enough to call it correctly. Minor gap on what happens if no orders exist or how many are typically returned.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only one parameter and the schema already documents it fully (100% coverage), so the baseline is 3. The description adds no extra meaning about limit, such as max/default behavior or how it interacts with ordering.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (List) and resource (fillable sell orders on the on-chain order book), plus the ordering (cheapest first). This is clearly distinguishable from the prepare_* siblings that presumably act on these orders.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The closing sentence about buying filling these orders atomically implicitly routes the agent from listing to the prepare_buy flow. There is clear usage context but no explicit when-not or named alternative (e.g., compared with shaniu_stats).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Prepare an unsigned buy transaction that fills one or more sell orders. Computes exact BNB cost. Single order uses the market contract; multiple orders use the cart contract (buyMany) in one tx.
| Name | Required | Description | Default |
|---|---|---|---|
| fills | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations the description carries the full burden, and it does add real value: the transaction is unsigned (caller must sign/submit), cost is computed exactly in BNB, and multi-fill goes through buyMany in one tx. It omits failure modes (order already filled), whether approval or allowances are needed, whether fills reserve the listing, and the expiry/validity of the unsigned tx.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences, front-loaded with the action, then cost semantics, then the contract-routing rule. No redundant restatement of the name and nothing wasted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a transaction-preparation tool with no annotations and no output schema, the description covers what it does but not what it returns (unsigned tx payload, target address/chain) or what the caller must do next. Adequate to select the tool, thin for correct end-to-end invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% at the top level; only the nested id and amountSHANIU fields carry inline descriptions. The description partially compensates by explaining that fills target sell-order ids and that BNB cost is computed, but it does not state the unit/semantics of amountSHANIU or the 50-item cap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: 'Prepare an unsigned buy transaction that fills one or more sell orders.' It also clarifies routing (market contract vs cart buyMany), which distinguishes this from the prepare_claim/prepare_list siblings. It never explicitly names those siblings, so differentiation is inferred rather than stated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The single-vs-multiple order condition tells an agent which contract path is taken, but that is implementation detail rather than selection guidance. There is no explicit when-to-use, no when-not-to-use, and no pointer to siblings such as prepare_list when the agent only wants to list rather than buy.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Prepare an unsigned claim() (mint) transaction. Caller wallet must hold a Binance Agent ID (.ai); one claim per address; reward is a block-hash lottery (50-150 typical, up to 21,000; last claim sweeps the pool). Returns {to, data, valueWei} to sign with the user's wallet.
| Name | Required | Description | Default |
|---|---|---|---|
| address | Yes | Wallet that will claim (gets the tokens) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does well: it discloses that output is unsigned (not submitted), the exact return shape {to, data, valueWei}, the eligibility gate, the one-claim-per-address rule, and the reward distribution including the last-claim sweep. It omits chain/network identity and failure behavior when the Agent ID requirement is unmet.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Purpose and the return contract are front-loaded in the first and last clauses, with constraints packed into a single parenthetical. No sentence is filler given the density of genuinely useful information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter transaction-builder with no output schema, the description covers the essentials: what is built, prerequisites, limits, and the returned fields so the agent knows what to sign. Only network/chain context and error conditions are absent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with the address parameter fully documented, so the baseline is 3. The description adds only light context by tying the address to the eligibility requirement; it adds no format or semantics beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: 'Prepare an unsigned claim() (mint) transaction,' which is immediately distinguishable from the sibling prepare_buy and prepare_list tools. The mint clarification removes ambiguity about what claim() does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives a clear precondition for use ('Caller wallet must hold a Binance Agent ID (.ai)') and a limit ('one claim per address'), which tells the agent when this call will succeed. It stops short of explicitly naming alternatives or saying when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Prepare unsigned transactions to list SHANIU for sale: (1) approve the market contract, (2) list(amount, priceWei). The tokens stay in the seller's wallet until filled — the market is authorization-based, no custody.
| Name | Required | Description | Default |
|---|---|---|---|
| amountSHANIU | Yes | Total amount to list, e.g. "817" | |
| priceBNBperToken | Yes | BNB price per 1 SHANIU, e.g. "0.0000078" |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full load and does disclose non-obvious behavior: it returns unsigned transactions rather than executing, the tokens never leave the seller's wallet, and the market is authorization-based with no custody. It omits what the returned payload looks like, chain/network assumptions, and whether the approve step is skipped when already approved.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two compact sentences with the action and step sequence front-loaded, followed by the custody clarification. Every clause adds information; nothing is padding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a prepare-only tool with no output schema or annotations, the description covers the action, the two underlying transactions, and the key custody semantics. Remaining gaps (return shape of the unsigned tx array, chain, approval-already-exists case) are minor but real.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and both parameters are documented with examples, so the schema does the heavy lifting. The description adds only the 'list(amount, priceWei)' mapping and per-token price framing, which is marginal value beyond the schema's 'BNB price per 1 SHANIU'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Uses a specific verb+resource: 'Prepare unsigned transactions to list SHANIU for sale', and even enumerates the internal steps (approve, then list(amount, priceWei)). It does not explicitly name a sibling such as shaniu_prepare_buy, but the 'for sale' scoping naturally separates it from buy/claim variants.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The two-step flow (approve the market contract, then list) implies when the tool is invoked, but there is no explicit statement of prerequisites (e.g., must the seller hold SHANIU, is approval needed if already granted) or when to prefer this over shaniu_prepare_buy/prepare_claim. Usage is inferable rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Live SHANIU stats: total supply, claim pool remaining, claim count, current claim fee (wei of BNB, ~0.2 USD via Chainlink oracle), whether claiming is open, and optionally a wallet's balance / claimed status.
| Name | Required | Description | Default |
|---|---|---|---|
| address | No | Optional wallet to check balance and hasClaimed |
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 usefully discloses units and conversion ('wei of BNB, ~0.2 USD via Chainlink oracle'), 'live' freshness, and the conditional output when address is supplied. However, it never states that the call is read-only/no side effects, nor how stale the oracle price may be or what happens on an invalid/unknown address.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One front-loaded sentence with a compact, information-dense enumeration; nothing is padded. It borders on a run-on list, but every clause maps to a real output field.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description does the necessary work of enumerating return fields, which is the key thing an agent needs. Gaps are modest: no error or empty-state behavior and no explicit statement that the operation is non-mutating.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the schema already documents the single optional address param, so the baseline is 3. The description adds only a light gloss ('a wallet's balance / claimed status') and implies the global-only results when omitted; it adds little beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a concrete verb+resource ('Live SHANIU stats') and enumerates exactly what data comes back (supply, claim pool, fee in wei, claim-open flag, optional wallet status). It is clearly the global read-only stats reader among the shaniu_ siblings, though it never names a sibling it overlaps or replaces.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied rather than stated: the field list signals 'call this to check protocol state,' and the optional address signals 'pass a wallet to see its balance/claimed status.' There is no explicit when-to-use, when-not, or pointer to shaniu_invite_stats / shaniu_market_orders for adjacent data.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
shaniu_invite_registershaniu_invite_statsshaniu_market_ordersshaniu_prepare_buyshaniu_prepare_claimshaniu_prepare_listshaniu_statsLaunch Solana coins from your AI. You approve each launch in your wallet and earn creator fees.
Memecoin safety scanner for Solana, BNB and Robinhood Chain with an onchain track record
Prepare pump.fun token launches from your AI agent. You review and sign each one in your own wallet.
AI meme coin concept generator: theme in, coin name, ticker, lore and logo out. Concepts only.
Add one secure layer between your agents and this server.