OpenZeppelin Solidity Contracts

Solidity Governor

solidity-governor

Make a contract to implement governance, such as for a DAO.

Returns the source code of the generated contract, formatted in a Markdown code block. Does not write to disk.

Input Schema

TableJSON Schema

Name	Required	Description
`info`	No	Metadata about the contract and author
`name`	Yes	The name of the contract
`delay`	Yes	The delay since proposal is created until voting starts, default is "1 day"
`votes`	No	The type of voting to use
`period`	Yes	The length of period during which people can cast their vote, default is "1 week"
`storage`	No	Enable storage of proposal details and enumerability of proposals
`decimals`	No	The number of decimals to use for the contract, default is 18 for ERC20Votes and 0 for ERC721Votes (because it does not apply to ERC721Votes)
`settings`	No	Allow governance to update voting settings (delay, period, proposal threshold)
`timelock`	No	The type of timelock to use
`blockTime`	No	The block time of the chain in seconds, default is 12
`clockMode`	No	The clock mode used by the voting token. For Governor, this must be chosen to match what the ERC20 or ERC721 voting token uses.
`quorumMode`	No	The type of quorum mode to use
`upgradeable`	No	Whether the smart contract is upgradeable. Transparent uses more complex proxy with higher overhead, requires less changes in your contract. Can also be used with beacons. UUPS uses simpler proxy with less overhead, requires including extra code in your contract. Allows flexibility for authorizing upgrades.
`quorumPercent`	No	The percent required, in cases of quorumMode equals percent
`quorumAbsolute`	No	The absolute quorum required, in cases of quorumMode equals absolute
`proposalThreshold`	No	Minimum number of votes an account must have to create a proposal, default is 0.
`crossChainExecution`	No	Whether passed proposals can relay execution to other chains through ERC-7786 gateways. Requires a CrosschainRemoteExecutor contract, controlled by this governor, deployed on each target chain. The gateway and executor are chosen per proposal as arguments to the relayCrosschain function.

TDQS

A4.2/5.0

Behavior4/5

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

With no annotations, the description carries the full burden for behavioral disclosure. It explicitly states the tool returns source code in a Markdown code block and does not write to disk, which are critical side-effect and output behaviors. This gives the agent a clear understanding of the tool's non-mutating, generation-only nature, although it doesn't detail potential errors or dependencies.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is three short sentences, each earning its place: the first establishes purpose, the second specifies the return format, and the third clarifies a key side-effect (does not write to disk). It is front-loaded with the core purpose and contains no filler or irrelevant information.

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?

Despite the tool's complexity (17 parameters, nested objects, no output schema), the description covers the essential aspects: purpose, output format, and side-effect behavior. The schema handles parameter details, so the description need not repeat them. It could have added more about the generated contract's structure or usage examples, but it is sufficiently complete for an agent to select and invoke the tool correctly.

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 description coverage is 100%, so the baseline is 3. The tool description itself adds no parameter details, but the input schema already provides comprehensive descriptions for all 17 parameters. The description does not need to compensate, and no value is added beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's function: 'Make a contract to implement governance, such as for a DAO.' It identifies the specific resource (governance contract) and the action (generate). The phrase 'such as for a DAO' and the return format ('Returns the source code...') distinguish it from sibling contract generators like solidity-erc20 or solidity-account.

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?

The description provides clear context: use this tool when you need to generate a governance/DAO contract. It implies the use case without explicitly naming alternatives, but the purpose is specific enough that an agent can infer when to choose it over sibling contract generators. No exclusions are given, but the context is unambiguous.

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

All OpenZeppelin Solidity Contracts tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.3/5.0

Disambiguation5/5

Each tool targets a distinct contract type (account, custom, ERC1155, ERC20, ERC721, governor, RWA, stablecoin), and descriptions clearly differentiate between them, even for the ERC20-based variants.

Naming Consistency5/5

All tool names follow the identical 'solidity-<type>' pattern, providing a predictable and consistent naming scheme across the entire server.

Tool Count5/5

With 8 tools covering the main Solidity contract categories plus a custom option, the count is well-scoped for a contract generator and avoids unnecessary bloat.

Completeness4/5

The toolset covers major contract types, but it lacks support for upgradeable contracts (proxies) and some common OpenZeppelin features like ERC4626 vaults. The 'solidity-custom' tool can partially compensate for these gaps.

Resources

Need Help?