Estimate the exact cost of a token operation before anything is built. Returns the platform fee (quoted per service-chain pair) plus the estimated network fee (rent + base + priority), as decimal strings in the chain's currency.
| Name | Required | Description | Default |
|---|---|---|---|
| request | Yes | The operation intent — same shape the browser flow sends (chain, then service, then the service's fields). |
Changes observed during successful MCP inspections.
Input schema / properties / request / properties / options / descriptionPrevious value: -"Service options, keyed by service. spl-token and token-2022 (optional, may be omitted): transferTaxBps, transferTaxMaxFee, permanentDelegate, freezeAuthority. authority-tools (REQUIRED): revokeMint, revokeFreeze, revokeUpdate as booleans — all three must be present, at least one true; optional revokePermanentDelegate, revokeTransferFee, revokeWithheldWithdraw, revokeTransferHook, revokePause. airdrop (REQUIRED): recipients, a list of {address, amount} with amount as a decimal string in whole tokens, the same unit as supply — the mint's decimals are applied at prepare time. update-metadata (REQUIRED, at least one): name, symbol, metadataUri."New value: +"Service options, keyed by service. spl-token and token-2022 (optional, may be omitted): transferTaxBps, transferTaxMaxFee, permanentDelegate, freezeAuthority. authority-tools (REQUIRED): revokeMint, revokeFreeze, revokeUpdate as booleans — all three must be present, at least one true; optional revokePermanentDelegate, revokeTransferFee, revokeWithheldWithdraw, revokeTransferHook, revokePause. airdrop (REQUIRED): recipients, a list of {address, amount} — at most 20 recipients per transaction — with amount as a decimal string in whole tokens, the same unit as supply; the mint's decimals are applied at prepare time. update-metadata (REQUIRED, at least one): name, symbol, metadataUri."Input schema / properties / request / properties / token / properties / supply / descriptionPrevious value: -"Total supply as a decimal string in base units, e.g. \"1000000000\" for 1B tokens."New value: +"Total supply in whole tokens as a decimal string, e.g. \"1000000000\" for 1B tokens — the mint's decimals are applied at prepare time."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 discloses the output (platform and network fees as decimal strings) and implies a non-mutating operation via 'before anything is built', but it does not explicitly state read-only semantics, authentication requirements, or other side effects. This is a moderate gap given the lack of annotation support.
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 redundant wording. The output format and timing are stated upfront, making it easy to parse quickly.
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?
Given the complex nested request schema, the description is minimal but the schema covers all parameter details. The description does explain the return format, which is necessary since there is no output schema. It is adequate for an agent to understand the tool's purpose and output, though it could offer a brief hint about the request structure.
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?
The description adds no parameter-specific guidance; it relies entirely on the input schema, which has 100% coverage. Since the schema fully documents the request structure, the baseline of 3 applies. The description's mention of 'per service-chain pair' refers to output, not input parameters.
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 uses the specific verb 'estimate' and identifies the resource as 'cost of a token operation'. It clearly distinguishes itself from siblings (build_request, submit_transaction) by focusing on cost estimation before any building occurs.
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 phrase 'before anything is built' clearly indicates when to use this tool, implying it should precede build_request and submit_transaction. However, it does not explicitly name alternatives or exclusion conditions, so it falls short of the highest bar.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.