Server Details
The OpenZeppelin Solidity Contracts MCP server integrates OpenZeppelin's security and style rules into AI-driven development workflows, enabling AI assistants to generate safe, correct, and production-ready smart contracts. It automatically validates generated code against OpenZeppelin standards (including imports, modifiers, naming conventions, and security checks) and supports various contract types including ERC-20, ERC-721, ERC-1155, Stablecoins, RWA, Governor, and Account contracts through prompt-driven workflows.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Available Tools
8 toolssolidity-accountTry in Inspector
Make an account contract that follows the ERC-4337 standard.
Returns the source code of the generated contract, formatted in a Markdown code block. Does not write to disk.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| info | No | Metadata about the contract and author | |
| name | Yes | The name of the account contract | |
| signer | No | Defines the signature verification algorithm used by the account to verify user operations. Options: - ECDSA: Standard Ethereum signature validation using secp256k1, validates signatures against a specified owner address - EIP7702: Special ECDSA validation using account's own address as signer, enables EOAs to delegate execution rights - Multisig: ERC-7913 multisignature requiring minimum number of signatures from authorized signers - MultisigWeighted: ERC-7913 weighted multisignature where signers have different voting weights - P256: NIST P-256 curve (secp256r1) validation for integration with Passkeys and HSMs - RSA: RSA PKCS#1 v1.5 signature validation (RFC8017) for PKI systems and HSMs - WebAuthn: Web Authentication (WebAuthn) assertion validation for integration with Passkeys and HSMs on top of P256 | |
| 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. | |
| ERC721Holder | No | Whether to implement the `onERC721Received` function to allow the account to receive ERC721 tokens. | |
| ERC1155Holder | No | Whether to implement the `onERC1155Received` function to allow the account to receive ERC1155 tokens. | |
| ERC7579Modules | No | Whether to implement the ERC-7579 compatibility to enable functionality on the account with modules. | |
| batchedExecution | No | Whether to implement a minimal batching interface for the account to allow multiple operations to be executed in a single transaction following the ERC-7821 standard. | |
| signatureValidation | No | Whether to implement the ERC-1271 standard for validating signatures. This is useful for the account to verify signatures. |
solidity-customTry in Inspector
Make a custom smart contract.
Returns the source code of the generated contract, formatted in a Markdown code block. Does not write to disk.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| info | No | Metadata about the contract and author | |
| name | Yes | The name of the contract | |
| access | No | The type of access control to provision. Ownable is a simple mechanism with a single account authorized for all privileged actions. Roles is a flexible mechanism with a separate role for each privileged action. A role can have many authorized accounts. Managed enables a central contract to define a policy that allows certain callers to access certain functions. | |
| pausable | No | Whether privileged accounts will be able to pause specifically marked functionality. Useful for emergency response. | |
| 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. |
solidity-erc1155Try in Inspector
Make a non-fungible token per the ERC-1155 standard.
Returns the source code of the generated contract, formatted in a Markdown code block. Does not write to disk.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| uri | Yes | The location of the metadata for the token. Clients will replace any instance of {id} in this string with the tokenId. | |
| info | No | Metadata about the contract and author | |
| name | Yes | The name of the contract | |
| access | No | The type of access control to provision. Ownable is a simple mechanism with a single account authorized for all privileged actions. Roles is a flexible mechanism with a separate role for each privileged action. A role can have many authorized accounts. Managed enables a central contract to define a policy that allows certain callers to access certain functions. | |
| supply | No | Whether to keep track of total supply of tokens | |
| burnable | No | Whether token holders will be able to destroy their tokens | |
| mintable | No | Whether privileged accounts will be able to create more supply or emit more tokens | |
| pausable | No | Whether privileged accounts will be able to pause specifically marked functionality. Useful for emergency response. | |
| 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. | |
| updatableUri | No | Whether privileged accounts will be able to set a new URI for all token types |
solidity-erc20Try in Inspector
Make a fungible token per the ERC-20 standard.
Returns the source code of the generated contract, formatted in a Markdown code block. Does not write to disk.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| info | No | Metadata about the contract and author | |
| name | Yes | The name of the contract | |
| votes | No | Whether to keep track of historical balances for voting in on-chain governance. Voting durations can be expressed as block numbers or timestamps. | |
| access | No | The type of access control to provision. Ownable is a simple mechanism with a single account authorized for all privileged actions. Roles is a flexible mechanism with a separate role for each privileged action. A role can have many authorized accounts. Managed enables a central contract to define a policy that allows certain callers to access certain functions. | |
| permit | No | Whether without paying gas, token holders will be able to allow third parties to transfer from their account. | |
| symbol | Yes | The short symbol for the token | |
| premint | No | The number of tokens to premint for the deployer. | |
| burnable | No | Whether token holders will be able to destroy their tokens | |
| callback | No | Whether to include support for code execution after transfers and approvals on recipient contracts in a single transaction. | |
| mintable | No | Whether privileged accounts will be able to create more supply or emit more tokens | |
| pausable | No | Whether privileged accounts will be able to pause specifically marked functionality. Useful for emergency response. | |
| flashmint | No | Whether to include built-in flash loans to allow lending tokens without requiring collateral as long as they're returned in the same transaction. | |
| 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. | |
| premintChainId | No | The chain ID of the network on which to premint tokens. | |
| namespacePrefix | No | The prefix for ERC-7201 namespace identifiers. It should be derived from the project name or a unique naming convention specific to the project. Used only if the contract includes storage variables and upgradeability is enabled. Default is "myProject". | |
| crossChainBridging | No | Whether to allow authorized bridge contracts to mint and burn tokens for cross-chain transfers. Options are to use custom bridges on any chain, or the SuperchainERC20 standard with the predeployed SuperchainTokenBridge. The SuperchainERC20 feature is only available on chains in the Superchain, and requires deploying your contract to the same address on every chain in the Superchain. |
solidity-erc721Try in Inspector
Make a non-fungible token per the ERC-721 standard.
Returns the source code of the generated contract, formatted in a Markdown code block. Does not write to disk.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| info | No | Metadata about the contract and author | |
| name | Yes | The name of the contract | |
| votes | No | Whether to keep track of individual units for voting in on-chain governance. Voting durations can be expressed as block numbers or timestamps (defaulting to block number if not specified). | |
| access | No | The type of access control to provision. Ownable is a simple mechanism with a single account authorized for all privileged actions. Roles is a flexible mechanism with a separate role for each privileged action. A role can have many authorized accounts. Managed enables a central contract to define a policy that allows certain callers to access certain functions. | |
| symbol | Yes | The short symbol for the token | |
| baseUri | No | A base uri for the token | |
| burnable | No | Whether token holders will be able to destroy their tokens | |
| mintable | No | Whether privileged accounts will be able to create more supply or emit more tokens | |
| pausable | No | Whether privileged accounts will be able to pause specifically marked functionality. Useful for emergency response. | |
| enumerable | No | Whether to allow on-chain enumeration of all tokens or those owned by an account. Increases gas cost of transfers. | |
| uriStorage | No | Allows updating token URIs for individual token IDs | |
| incremental | No | Whether new tokens will be automatically assigned an incremental id | |
| 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. | |
| namespacePrefix | No | The prefix for ERC-7201 namespace identifiers. It should be derived from the project name or a unique naming convention specific to the project. Used only if the contract includes storage variables and upgradeability is enabled. Default is "myProject". |
solidity-governorTry in Inspector
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.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| 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, 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. |
solidity-rwaTry in Inspector
Make a real-world asset token that uses the ERC-20 standard. Experimental, some features are not audited and are subject to change.
Returns the source code of the generated contract, formatted in a Markdown code block. Does not write to disk.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| info | No | Metadata about the contract and author | |
| name | Yes | The name of the contract | |
| votes | No | Whether to keep track of historical balances for voting in on-chain governance. Voting durations can be expressed as block numbers or timestamps. | |
| access | No | The type of access control to provision. Ownable is a simple mechanism with a single account authorized for all privileged actions. Roles is a flexible mechanism with a separate role for each privileged action. A role can have many authorized accounts. Managed enables a central contract to define a policy that allows certain callers to access certain functions. | |
| permit | No | Whether without paying gas, token holders will be able to allow third parties to transfer from their account. | |
| symbol | Yes | The short symbol for the token | |
| premint | No | The number of tokens to premint for the deployer. | |
| burnable | No | Whether token holders will be able to destroy their tokens | |
| callback | No | Whether to include support for code execution after transfers and approvals on recipient contracts in a single transaction. | |
| mintable | No | Whether privileged accounts will be able to create more supply or emit more tokens | |
| pausable | No | Whether privileged accounts will be able to pause specifically marked functionality. Useful for emergency response. | |
| flashmint | No | Whether to include built-in flash loans to allow lending tokens without requiring collateral as long as they're returned in the same transaction. | |
| freezable | No | Whether authorized accounts can freeze and unfreeze accounts for regulatory or security purposes. This feature is experimental, not audited and is subject to change. | |
| restrictions | No | Whether to restrict certain users from transferring tokens, either via allowing or blocking them. This feature is experimental, not audited and is subject to change. | |
| premintChainId | No | The chain ID of the network on which to premint tokens. | |
| namespacePrefix | No | The prefix for ERC-7201 namespace identifiers. It should be derived from the project name or a unique naming convention specific to the project. Used only if the contract includes storage variables and upgradeability is enabled. Default is "myProject". | |
| crossChainBridging | No | Whether to allow authorized bridge contracts to mint and burn tokens for cross-chain transfers. Options are to use custom bridges on any chain, or the SuperchainERC20 standard with the predeployed SuperchainTokenBridge. The SuperchainERC20 feature is only available on chains in the Superchain, and requires deploying your contract to the same address on every chain in the Superchain. |
solidity-stablecoinTry in Inspector
Make a stablecoin token that uses the ERC-20 standard. Experimental, some features are not audited and are subject to change.
Returns the source code of the generated contract, formatted in a Markdown code block. Does not write to disk.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| info | No | Metadata about the contract and author | |
| name | Yes | The name of the contract | |
| votes | No | Whether to keep track of historical balances for voting in on-chain governance. Voting durations can be expressed as block numbers or timestamps. | |
| access | No | The type of access control to provision. Ownable is a simple mechanism with a single account authorized for all privileged actions. Roles is a flexible mechanism with a separate role for each privileged action. A role can have many authorized accounts. Managed enables a central contract to define a policy that allows certain callers to access certain functions. | |
| permit | No | Whether without paying gas, token holders will be able to allow third parties to transfer from their account. | |
| symbol | Yes | The short symbol for the token | |
| premint | No | The number of tokens to premint for the deployer. | |
| burnable | No | Whether token holders will be able to destroy their tokens | |
| callback | No | Whether to include support for code execution after transfers and approvals on recipient contracts in a single transaction. | |
| mintable | No | Whether privileged accounts will be able to create more supply or emit more tokens | |
| pausable | No | Whether privileged accounts will be able to pause specifically marked functionality. Useful for emergency response. | |
| flashmint | No | Whether to include built-in flash loans to allow lending tokens without requiring collateral as long as they're returned in the same transaction. | |
| freezable | No | Whether authorized accounts can freeze and unfreeze accounts for regulatory or security purposes. This feature is experimental, not audited and is subject to change. | |
| restrictions | No | Whether to restrict certain users from transferring tokens, either via allowing or blocking them. This feature is experimental, not audited and is subject to change. | |
| premintChainId | No | The chain ID of the network on which to premint tokens. | |
| namespacePrefix | No | The prefix for ERC-7201 namespace identifiers. It should be derived from the project name or a unique naming convention specific to the project. Used only if the contract includes storage variables and upgradeability is enabled. Default is "myProject". | |
| crossChainBridging | No | Whether to allow authorized bridge contracts to mint and burn tokens for cross-chain transfers. Options are to use custom bridges on any chain, or the SuperchainERC20 standard with the predeployed SuperchainTokenBridge. The SuperchainERC20 feature is only available on chains in the Superchain, and requires deploying your contract to the same address on every chain in the Superchain. |
FAQ
How do I claim this server?
To claim this server, publish a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [
{
"email": "your-email@example.com"
}
]
}
The email address must match the email associated with your Glama account. Once verified, the server will appear as claimed by you.
What are the benefits of claiming a server?
- Control your server's listing on Glama, including description and metadata
- Receive usage reports showing how your server is being used
- Get monitoring and health status updates for your server