blockchain_fees_tezos

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

With no annotations provided, the description carries the full behavioral burden, and it does disclose real cost context: per-action credit costs plus the caveat that they are indicative and that actual credits appear in response headers. That is genuinely useful and non-obvious. It stops short of describing side effects, auth requirements, rate limits, or error behavior, which for a 4-action estimator leaves a meaningful gap.

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 definition is front-loaded with the purpose, then a clean action list, then the credit block. It is appropriately sized, though the credit section repeats the identical value '52' four times and could be collapsed to a single line, which is minor redundancy rather than bloat.

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 9-parameter tool with no output schema and no annotations, the description covers action selection well but says nothing about the shape of the returned fee estimate, the network requirement (mainnet vs shadownet), or failure modes. It is adequate for invocation but not fully complete given the absence of a structured output contract.

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%, so the schema already explains every parameter, including conditional requirements and the tokenId string-format trap. The description contributes no additional parameter semantics beyond mapping actions to purposes, which is the expected baseline when the schema does the heavy lifting.

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 names a concrete resource (Tezos fees) and enumerates four specific actions covering XTZ, FA1.2 and FA2 transfers, so the agent knows exactly what operations are available. The chain-specific scope is unmistakable and cleanly distinguishes it from siblings like blockchain_fees_evm and blockchain_fees_solana.

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?

Each action is paired with a plain-language purpose (e.g. 'get-fee-recommendations: get current minimal fee/cost rates from the mempool'), which effectively routes the agent to the right action for the transfer type at hand. However, there is no explicit when-not-to-use guidance and no cross-reference to the sibling chain tools, so the guidance is clear but not exhaustive.

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