What a BSC pool really costs to trade, free; grid levels with their break-even spacing, paid.
Scored across 2 tools
The two tools are clearly delineated: bsc_pool_scan is a free diagnostic/scanning tool for pool costs, while grid_plan is the paid planning tool that builds on that data. There is no overlap in purpose and the boundary between free and paid is explicit.
Both names follow a consistent snake_case noun_verb pattern (bsc_pool_scan, grid_plan). While not identical verb_noun, they share a clear, predictable structural convention.
With only 2 tools, the surface is thin for a grid-trading domain; the server appears to be a focused free-entry-point/paid-upsell pair, which is borderline but not unreasonable for a niche agent service.
The surface covers scanning and planning but has no execution, monitoring, grid adjustment, or cancellation operations. For a grid-trading server, the lifecycle is severely incomplete, leaving agents with dead ends after planning.
Grid trading, the free half: what a trade in any BSC token’s pool really costs — depth, price impact at sizes, and the transfer tax measured from executed trades. The paid half lays the grid and its break-even spacing.
| Name | Required | Description | Default |
|---|---|---|---|
| address | Yes | A BEP-20 token address on BNB Chain (0x…) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description usefully adds that transfer tax is 'measured from executed trades' (a data-source disclosure) and enumerates the returned metrics, which matters because there is no output schema. It stops short of stating responsiveness, refresh/freshness, or limits on which tokens are scannable.
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 with no egregious padding, but the lead-in 'Grid trading, the free half' is scene-setting jargon that delays the actual purpose, and the closing clause about the paid half is largely about the sibling rather than this tool. Front-loading is weak; the concrete deliverables appear only mid-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?
With no output schema, the description does carry the burden of naming return values, which it does (depth, price impact, transfer tax). However, for a single-address scanner it omits what is scanned (a specific pool? all pools for the token?), how 'sizes' are chosen given no size parameter, and any freshness caveat — leaving meaningful gaps for an agent deciding whether the output will answer its question.
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?
There is a single required parameter and schema coverage is 100%, with the schema itself specifying 'A BEP-20 token address on BNB Chain (0x…)'. The description adds no syntax, format, or constraint detail beyond that, so the baseline 3 is appropriate. Notably, the mention of 'price impact at sizes' implies size configuration that no parameter exposes, which adds mild ambiguity instead of clarity.
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 conveys what the tool returns — pool depth, price impact at sizes, and transfer tax measured from executed trades — but does so through marketing-flavored framing ('Grid trading, the free half') rather than an explicit verb+resource statement. An agent can eventually infer 'analyze a BSC token pool's trading costs' but has to decode the metaphor first, so this lands at minimum-viable rather than clear.
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 only implied through the contrast with the sibling: this is the 'free half' (cost analysis) while grid_plan is the 'paid half' that lays the grid. There is no explicit 'call this before/after grid_plan' or any condition stating when the cost scan is warranted versus skipping it, so the routing must be inferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Grid trading plan, costed against the real pool, the paid half (0.10 USD1, or half that in $BOBAI): Grid levels for any BNB Chain pool with the round-trip cost of a cycle measured from the pool itself — swap fee, price impact at your fill size, and the transfer tax read from executed trades rather than a label. States the break-even spacing, which is the number that decides whether the grid can work at all. Calling this tool returns the terms; the answer is sold over x402 at https://agent.brainonbnb.com/answer?service=grid_plan (or hired through the ERC-8183 escrow for 0.10 $U).
| Name | Required | Description | Default |
|---|---|---|---|
| task | No | What you want, with the address in it |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, so safety is covered. The description does add genuinely useful behavior beyond that – it discloses the tool is paid (x402, ERC-8183 escrow) with specific prices – but the price statement is internally inconsistent ('0.10 USD1, or half that in $BOBAI' vs '0.10 $U'), and it never clarifies whether the returned payload is the answer or just terms.
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?
A single run-on block that repeats the payment arrangement twice with conflicting figures and spends most of its length on sales framing rather than the tool's behavior. The one decisive concept, break-even spacing, is buried mid-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?
With no output schema, the description must carry the return-value burden, and it partially does by naming the computed fields (grid levels, swap fee, price impact, transfer tax, break-even spacing). However it leaves the critical ambiguity of what the caller actually receives versus what must be purchased unresolved, which matters for a paid tool.
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 100% (the single 'task' parameter is documented as 'What you want, with the address in it'), so the baseline is 3. The description adds no extra meaning, format, or examples for the task string.
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 middle of the text does state a concrete deliverable – grid levels for a BNB Chain pool plus round-trip cycle cost (swap fee, price impact, transfer tax) and break-even spacing – so it is more than a tautology. But it is wrapped in pricing/marketing phrasing and never resolves whether the call returns the plan itself or merely 'the terms,' nor distinguishes it from sibling bsc_pool_scan.
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?
There is no when-to-use guidance: nothing says when this beats bsc_pool_scan, what inputs are needed beyond 'the address,' or what prerequisites exist. The only routing information concerns payment channels, not tool selection.
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.
bsc_pool_scangrid_planPancakeSwap best route on BNB Chain, free; a portfolio rebalance priced against real pools, paid.
PancakeSwap V3 fee tiers for a BSC token, free; which tier and range to place liquidity in, paid.
PancakeSwap V3 range check for any position or wallet, free; the re-centre plan is paid. BNB Chain.
R_net LP risk evaluator for DeFAI agents. IL + Breakeven Corridor O(1). L402 Lightning paywall.
Add one secure layer between your agents and this server.