What a BSC pool costs to trade, free; grid levels and break-even spacing paid, free with 1M $BOBAI.
Scored across 2 tools
The two tools overlap substantially: bsc_pool_scan is described as the 'free half' that measures depth, price impact, and transfer tax, while grid_plan costs a full grid cycle from the same pool data and adds break-even spacing. The free/paid split is explained, but an agent still has to reason about whether the free scan already answers its question before paying for grid_plan.
Both names are snake_case and readable, but they follow different structures: bsc_pool_scan uses a scope_prefix + noun + verb, while grid_plan is a bare noun + noun with no verb. The inconsistent bsc_ prefix and the noun-vs-verb ending make the pattern only partially predictable.
Two tools is thin even for a narrow grid-trading niche; the surface covers scan and plan but nothing else. It is defensible for a tightly scoped paid-analysis service, but feels borderline minimal.
For the stated purpose of costing and planning a grid on a BSC pool, the scan-then-plan lifecycle is covered, including transfer tax, price impact, and break-even spacing. Gaps exist around pool/token discovery and any post-plan monitoring or execution, but those may be out of scope.
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 adds what a grid cycle costs on this pool and the spacing that breaks even. Free for 1,000 scans per caller and UTC day; past that a day pass carries on (POST https://agent.brainonbnb.com/scan-pass, 0.50 USD1 or half that in $BOBAI), sent as HTTP header X-Scan-Pass.
| 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 cover the safety profile (readOnly, openWorld, non-destructive), so the bar is lower, and the description goes beyond them with a concrete quota (1,000 scans per caller per UTC day), the payment endpoint, price, and the required X-Scan-Pass header. That is genuine operational context an agent cannot see in the schema. It stops short of describing error or failure behavior when the quota is exhausted or the pass is missing.
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?
The rate-limit and pricing detail is useful and specific, but the 'free half / paid half' marketing framing occupies the front of the text and delays the actual description of outputs. Several words are spent selling the paid tier rather than helping invocation. It is not bloated, but the structure is narrative rather than action-first.
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 carries the burden of explaining returns, and it does list the three measured quantities, plus quota and payment mechanics. The only meaningful gap is what happens at or past the quota boundary and how a missing or invalid pass is surfaced. For a single-parameter read tool, that is close to complete.
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 parameter with 100% schema description coverage, so the schema already explains that it is a BEP-20 token address. The description reinforces the scope ('any BSC token's pool') but adds no format, validation, or edge-case detail beyond that baseline. Baseline 3 is appropriate when the schema carries the semantics.
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 the concrete measurements returned for any BSC token pool — depth, price impact at sizes, and transfer tax measured from executed trades — which tells an agent what the resource and payload are. It also implicitly separates itself from the sibling by describing 'the paid half' as adding grid-cycle cost and break-even spacing. The framing as 'the free half' rather than a clean verb+resource statement keeps it 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?
Usage is only implied: the 'free half' vs 'paid half' framing suggests this tool for raw pool economics and grid_plan for cycle/break-even analysis, but the sibling is never named and no explicit when-to-use/when-not-to-use rule is given. The rate limit is stated operationally rather than as a selection guideline. An agent can infer the split but must do work the description could have done.
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, or nothing for a wallet holding 1,000,000 $BOBAI (holder pass over x402: a signature, no transaction — terms in the reply)): 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?
Beyond the read-only/open-world annotations, the description discloses the paid access model, holder-pass alternative, x402 signature/no-transaction path, and the core returned terms. The payment flow is slightly ambiguous, but the description adds substantial behavioral context that annotations alone do not provide.
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?
The description is dense and front-loads payment mechanics before the tool's core function. Nested parentheticals about USD1, $BOBAI, holder passes, x402, and ERC-8183 escrow make the opening hard to parse, even though some of that information is relevant.
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 still names the important returned components: grid levels, round-trip cost, swap fee, price impact, transfer tax, and break-even spacing. It also covers the paid-access model, which is important for an open-world tool, though the payment flow could be clearer.
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 only one parameter, `task`, and the schema already documents it at 100% coverage as 'What you want, with the address in it.' The description reinforces the BNB Chain pool context but adds no extra syntax or formatting guidance for the parameter.
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 makes clear that the tool produces a grid trading plan for a BNB Chain pool, including round-trip cost, swap fee, price impact, transfer tax, and break-even spacing. It does not explicitly distinguish itself from the sibling tool bsc_pool_scan, but the resource and computation are otherwise identifiable.
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 by phrases like 'Grid levels for any BNB Chain pool' and 'Calling this tool returns the terms.' The description does not state when an agent should choose this over bsc_pool_scan, nor does it give explicit exclusions or prerequisites beyond payment terms.
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_scan1 field changedInput schema / examplesAdded value: +[
+ {
+ "address": "0x0e09fabb73bd3ade0a17ecc321fd13a19e81ce82"
+ }
+]bsc_pool_scangrid_planPancakeSwap V3 fee tiers of a BSC token, free; tier and range plan paid, or free holding 1M $BOBAI.
PancakeSwap best route, free; a rebalance priced on real pools paid, or free holding 1M $BOBAI.
PancakeSwap V3 range check for any position, free; re-centre plan paid, or free holding 1M $BOBAI.
Venus health factor of any BNB Chain account, free; liquidation stress paid, free holding 1M $BOBAI.
Add one secure layer between your agents and this server.