bobai

pancakeswap_best_route

Read-only

For an agent about to swap on PancakeSwap, and for the two questions it has to answer before signing. FIRST: which of the up-to-five pools the pair lives in actually returns the most AT THIS SIZE, quoted by the venue itself rather than ranked by depth - the deepest pool is regularly not the cheapest one for the trade being made. SECOND: what comes back if the proceeds are sold straight back on the same route, with the transfer tax (measured from executed trades, or simulated on chain when there was no trade to measure: transfer_tax.source says which) applied to the amounts carried between the legs, because the tax is taken outside the pool where no quoter can see it. Returns the best route, what every other route would have cost, the round trip with and without the tax, and the slippage this size really needs. It is not a safety certificate and does not use the word: it cannot see an owner who has not acted yet, and it says so.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "address": "<address>"
    },
    "name": "pancakeswap_best_route"
  }
}

Input Schema

Name	Required	Description	Default
`usd`	No	Trade size in dollars, optional - defaults to 250
`address`	Yes	A BSC token address, or a PancakeSwap pool address to pin the pair

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedNov 11, 2026
- addedInput schema / properties / address / examples
```
Added value: +[
+  "0x0E09FaBB73Bd3Ade0a17ECC321fD13a19e81cE82"
+]
```
AddedSep 1, 2026

TDQS

A4/5.0

Behavior5/5

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

Annotations only declare readOnlyHint=true; the description goes well beyond by explaining the quote source (venue itself, not depth ranking), how the transfer tax is obtained (measured from executed trades or simulated on chain, surfaced in transfer_tax.source), where the tax sits relative to the pool, and that the response includes competing routes' costs, both round-trip variants, and required slippage. It also states a hard limitation ('cannot see an owner who has not acted yet'), which is exactly the kind of caveat an agent needs before trusting the result.

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 context sentence is front-loaded and the FIRST/SECOND structure aids scanning, but the prose is roughly 200 words for a two-parameter tool and includes rhetorical asides ('does not use the word', 'the deepest pool is regularly not the cheapest one'). Those lines carry some signal but cost more space than the information warrants.

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?

With no output schema, the description has to enumerate returns, and it does: best route, every other route's cost, round trip with and without tax, and needed slippage. It even names a response field (transfer_tax.source). The remaining gap is response shape or units, which an agent must discover at call time.

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 both parameters are already documented, and the description adds only the framing that results are size-dependent ('AT THIS SIZE', 'the slippage this size really needs') without restating usd defaults or the pool-address pinning option. Baseline 3 applies when the schema carries the parameter detail.

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 names a specific verb+resource: it returns the best PancakeSwap route among the up-to-five pools a pair lives in, quoted by the venue at the requested size, plus the round-trip cost with transfer tax. That is concrete and distinguishable from quoting-by-depth or a generic price feed. It stops short of naming a sibling tool, so an agent must infer the boundary from phrasing alone.

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?

Opens with the exact decision context ('For an agent about to swap... the two questions it has to answer before signing'), which tells the agent when to call it, and explicitly excludes a neighboring concern by saying it is not a safety certificate. There is no explicit pointer to an alternative tool for that excluded concern, so routing is implied rather than stated.

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

All bobai tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?