create_erc20_token

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

With no annotations, the description must carry the burden of behavioral disclosure. It only says 'Create a new ERC20 token' and omits critical details: what occurs on-chain (deployment?), whether gas fees are incurred, what is returned (contract address?), and any side effects or irreversible actions. The private key security note in the schema provides some transparency, but the overall description does not.

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 a single, concise sentence with no filler. However, while brevity is a strength, it sacrifices necessary context for a tool that performs an on-chain mutation. The front-loaded verb and object are clear, but the description could afford a second sentence clarifying outcomes without losing conciseness.

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 4 parameters, no output schema, and no annotations, the description is too sparse. It doesn't explain what the tool returns (e.g., contract address), the fact that it deploys a token contract, how the network parameter affects deployment, or the irreversible/payable nature of the action. This is a substantive gap for an operationally heavy 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?

The schema descriptions cover 100% of parameters, including a security note for privateKey and a default/scope for network. The description itself adds no parameter-specific meaning, so it doesn't exceed the schema's value. Baseline 3 is appropriate since the schema handles the semantics thoroughly.

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 clearly states the action ('Create') and the resource ('a new ERC20 token'), which distinguishes it from token transfer, burn, and approval tools in the sibling list. However, it doesn't explicitly differentiate from generic deployment tools like deploy_contract, which could also create a token, so there's minor ambiguity.

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?

No guidance is provided on when to use this tool versus alternatives like deploy_contract or deploy_proxy. The description doesn't mention prerequisites (e.g., funding for gas), supported networks, or scenarios where this tool is preferred over creating a token manually.

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