TRON Governor

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

With no annotations provided, the description carries the full behavioral burden. It explicitly discloses that the tool generates source code, returns it in a Markdown code block, and does not write to disk — key safety-relevant behavior. It does not disclose whether the generated contract is audited, whether it includes tests, or whether it may have chain-specific limitations, but the critical no-write behavior is clearly stated.

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 filler. The key output/behavior detail (returns Markdown, does not write to disk) is front-loaded in the second sentence. It is appropriately concise for a tool with a rich schema.

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?

Despite 17 parameters and nested objects, the schema is thorough and self-contained: defaults, conditional fields, and enum constraints are documented. The description covers the essential behavioral contract (code generation, return format, no disk write). Missing context includes what the generated code actually contains or whether cross-chain execution requires extra deployment steps, but the schema covers the key decision points and the output is source code, not a complex API response.

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 baseline is 3. The description does not add parameter-level semantics beyond the schema, but the schema itself thoroughly documents each parameter with defaults and conditional relationships (e.g., decimals default differs by voting type, quorumPercent applies only when quorumMode equals percent). The description's high-level purpose helps the agent infer how parameters combine, but it doesn't add any extra meaning beyond the schema.

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 a specific verb ('Make a contract to implement governance'), a specific resource ('for a DAO, targeting the TRON Virtual Machine'), and explicitly says it returns generated source code without writing to disk. This clearly distinguishes it from sibling tools like solidity-governor or cairo-governor by naming the TRON Virtual Machine target.

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 description does not explicitly say when to use this tool versus alternatives. However, the tool name (tron-governor), the target 'TRON Virtual Machine', and sibling list of other chain-specific generators imply it is the choice for TRON governance contracts. No explicit exclusions or alternative routing are provided, leaving usage inference largely to the agent.

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