OpenZeppelin Contracts MCP Server

Official

Overview Schema Source Related Servers Discussions Admin

Solidity Governor

solidity-governor

Generate DAO governance contract source code with customizable voting, quorum, timelock, and upgradeability settings. Output as Markdown for review.

Instructions

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.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv1.0.4Aug 1, 2026

addedInput schema / properties / crossChainExecution

Added value: +{
+  "description": "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.",
+  "type": "boolean"
+}

Changed1 schema field changedv1.0.1May 21, 2026

changedInput schema / properties / blockTime / description

Previous value: -"The block time of the chain, default is 12"New value: +"The block time of the chain in seconds, default is 12"

Changed15 schema fields changedv1.0.0Jan 3, 2026

removedInput schema / additionalProperties
```
Removed value: -false
```

addedInput schema / properties / clockMode / anyOf

Added value: +[
+  {
+    "const": "blocknumber",
+    "type": "string"
+  },
+  {
+    "const": "timestamp",
+    "type": "string"
+  }
+]

removedInput schema / properties / clockMode / enum

Removed value: -[
-  "blocknumber",
-  "timestamp"
-]

removedInput schema / properties / clockMode / type
```
Removed value: -"string"
```
removedInput schema / properties / info / additionalProperties
```
Removed value: -false
```

addedInput schema / properties / quorumMode / anyOf

Added value: +[
+  {
+    "const": "percent",
+    "type": "string"
+  },
+  {
+    "const": "absolute",
+    "type": "string"
+  }
+]

removedInput schema / properties / quorumMode / enum
```
Removed value: -[
-  "percent",
-  "absolute"
-]
```
removedInput schema / properties / quorumMode / type
```
Removed value: -"string"
```

changedInput schema / properties / timelock / anyOf

Previous value: -[
-  {
-    "enum": [
-      false,
-      "openzeppelin"
-    ],
-    "type": [
-      "boolean",
-      "string"
-    ]
-  },
-  {
-    "const": "compound",
-    "type": "string"
-  }
-]New value: +[
+  {
+    "anyOf": [
+      {
+        "const": false,
+        "type": "boolean"
+      },
+      {
+        "const": "openzeppelin",
+        "type": "string"
+      }
+    ]
+  },
+  {
+    "const": "compound",
+    "type": "string"
+  }
+]

addedInput schema / properties / upgradeable / anyOf

Added value: +[
+  {
+    "const": "transparent",
+    "type": "string"
+  },
+  {
+    "const": "uups",
+    "type": "string"
+  }
+]

removedInput schema / properties / upgradeable / enum
```
Removed value: -[
-  "transparent",
-  "uups"
-]
```
removedInput schema / properties / upgradeable / type
```
Removed value: -"string"
```

addedInput schema / properties / votes / anyOf

Added value: +[
+  {
+    "const": "erc20votes",
+    "type": "string"
+  },
+  {
+    "const": "erc721votes",
+    "type": "string"
+  }
+]

removedInput schema / properties / votes / enum

Removed value: -[
-  "erc20votes",
-  "erc721votes"
-]

removedInput schema / properties / votes / type
```
Removed value: -"string"
```

First observedAug 15, 2025

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.

Solidity Governor

Instructions

Input Schema

Schema Changelog

TDQS

Other Tools