A
licenseA
qualityB
maintenanceA Model Context Protocol (MCP) server that allows AI agents to generate smart contracts using OpenZeppelin Contracts libraries.
33
123 npm
295
AGPL 3.0
OpenZeppelin Solidity Contracts
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.
If you are the author of this connector, you can claim ownership by verifying the domain or GitHub account it belongs to. Claimed connector authors can inspect health checks, view analytics, and manage their listing.
- Status
- Healthy
- Uptime
- 100.0% over 81 days
- Last Tested
- Transport
- Streamable HTTP · MCP 2025-11-25
- URL
- ChatGPT
- –
- Claude
- –
TDQS
A4/5.0
Scored across 8 tools
Disambiguation5/5
Each tool targets a distinct contract standard or category (ERC-20, ERC-721, ERC-1155, account, governor, custom, RWA, stablecoin). The descriptions clarify the differences even for ERC-20-based variants like stablecoin and RWA. No two tools are likely to be confused for the same purpose.
Naming Consistency5/5
All tool names use a consistent 'solidity-' prefix followed by a concise descriptor (e.g., solidity-erc20, solidity-governor). There is no mixing of naming conventions or verb styles.
Tool Count5/5
Eight tools is well-scoped for a Solidity contract generation server. Each tool represents a distinct contract archetype and earns its place without redundancy.
Completeness4/5
The surface covers the most common ERC standards (20, 721, 1155), account abstraction, governance, and several specialized ERC-20 variants. Minor gaps exist for less common standards like ERC-4626 or upgradeable proxy patterns, but the core domain is well covered.
Available Tools
8 toolssolidity-accountSolidity AccountAInspect
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.
| 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. |
TDQS
A4/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of disclosure. It does reveal that the tool returns source code in a Markdown code block and does not write to disk, which is useful behavioral information. However, it does not mention any other nuances such as error handling or parameter-driven behavior changes, resulting in a moderate level of transparency.
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, focused sentences. It is front-loaded with the purpose, followed by the return format and a key side effect, with no filler or redundancy.
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?
For a tool with 9 parameters and no output schema, the description is brief but covers the essential aspects: what it creates, the format of the result, and that it does not write to disk. Given the rich schema descriptions, the tool is adequately contextualized for correct invocation.
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 coverage is 100% and every property has a detailed description (e.g., signer enum options, upgradeable types, ERC-721/1155 holders). The description itself adds no parameter-level meaning, but the schema compensates fully, so the baseline score of 3 is appropriate.
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 begins with 'Make an account contract that follows the ERC-4337 standard,' which clearly states the action and resource. It also specifies the output format (Markdown code block) and the side effect (does not write to disk), distinguishing it from sibling contract generators by scope and behavior.
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 clearly frames the tool as for generating an ERC-4337 compliant account contract, implying when it should be used. However, it does not explicitly name alternative tools or state exclusions, so it falls short of an explicit when/when-not guide.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
solidity-customSolidity CustomAInspect
Make a custom smart contract.
Returns the source code of the generated contract, formatted in a Markdown code block. Does not write to disk.
| 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. |
TDQS
A4/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description carries the full burden. It transparently discloses that the tool returns source code in a Markdown code block and does not write to disk, which is key behavioral information for a code-generation tool.
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 two short sentences, front-loading the core purpose and immediately adding return format and side-effect information. Every sentence earns its place without redundancy.
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?
The description provides the essential context: purpose, output format, and no disk writes. Given the detailed input schema, this is mostly complete, though it could be slightly richer about how parameters shape the generated contract.
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?
The input schema covers all parameters (100%) with detailed descriptions for name, info, access, pausable, and upgradeable. The description itself adds no parameter-specific detail, so the baseline score of 3 is appropriate.
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 custom smart contract.' It also specifies the output (source code in a Markdown code block), and the word 'custom' distinguishes it from sibling tools like solidity-erc20 or solidity-erc721.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or alternative guidance is provided. The word 'custom' implies it is for bespoke contracts rather than standard templates, but there are no clear conditions, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
solidity-erc1155Solidity ERC1155AInspect
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.
| 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 | |
| crossChainBridging | No | Whether to embed an ERC-7786 based bridge directly in the token contract, making it natively crosschain. Crosschain transfers with registered counterparts burn the tokens on the source chain and mint them on the destination chain. | |
| crossChainLinkAllowOverride | No | Whether to allow replacing a crosschain link that has already been registered. Only used if crossChainBridging is set to "erc7786native". |
TDQS
A3.7/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It explicitly states that the tool returns source code formatted as a Markdown code block and does not write to disk, which are key behavioral and side-effect guarantees for a code generation tool.
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?
Two concise sentences: the first states the purpose and the second states the output format plus the key side-effect limitation. Every sentence earns its place with no redundancy or filler.
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?
For a 12-parameter generator with no output schema and no annotations, the description adequately covers what is returned and that nothing is written to disk, while the schema covers all parameter semantics. It is nearly complete, though explicitly naming Solidity in the description would improve standalone clarity.
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%, and the schema already provides detailed field-level explanations for all 12 parameters. The description adds no parameter-specific detail, so the baseline score for schema-covered parameters applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Make') and a clear resource ('a non-fungible token per the ERC-1155 standard'), and clarifies that it returns generated source code. It distinguishes from unrelated generator tools, but it does not explicitly name Solidity or contrast with the Cairo/Stylus ERC-1155 siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no when-to-use guidance or mention of alternatives. The description only states what the tool generates; it does not help the agent decide between this and sibling tools such as solidity-erc721, stylus-erc1155, or cairo-erc1155 beyond relying on the tool name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
solidity-erc20Solidity ERC20AInspect
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.
| 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. | |
| decimals | No | The number of decimals used to represent token amounts. Defaults to 18. | |
| 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. | |
| chainlinkAce | No | Chainlink ACE (Automated Compliance Engine) adds token policy enforcement through a separately deployed and configured policy engine (integration guide: https://docs.openzeppelin.com/chainlink-ccip-ace; Chainlink docs: https://docs.chain.link/ace). Defaults to false (disabled). Requires ownable or roles access; combining ACE with CCIP requires roles. This integration does not support ACE together with managed access, Callback (ERC-1363), Flash Minting, a nonzero premint, or bridge modes other than CCIP. Configure policies and register the token with the engine before use; this does not establish legal compliance. Enabling ACE makes the generated contract use BUSL-1.1, overriding info.license. Review the ACE license (https://github.com/smartcontractkit/chainlink-ace/blob/v1.2.0/LICENSE) and additional use grants (https://github.com/smartcontractkit/chainlink-ace/blob/v1.2.0/chainlink-ace-License-grants) before production use. | |
| 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 crosschain transfers. Options are custom bridges on any chain, Chainlink CCIP with a separately configured BurnMintTokenPool (integration guide: https://docs.openzeppelin.com/chainlink-ccip-ace; Chainlink docs: https://docs.chain.link/ccip), to embed an ERC-7786 based bridge directly in the token contract, or to use the SuperchainERC20 standard with the predeployed SuperchainTokenBridge. CCIP requires role-based access control, granting the configured pool MINTER_ROLE on each supported chain, and BURNER_ROLE when Burnable is disabled. With Burnable enabled, any holder can burn their own tokens, including the pool, and burnFrom requires an allowance. 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. | |
| crossChainLinkAllowOverride | No | Whether to allow replacing a crosschain link that has already been registered. Only used if crossChainBridging is set to "erc7786native". |
TDQS
A3.6/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are supplied, so the description carries full behavioral burden, and it does disclose the two most important traits: the tool returns source code (not a deployed artifact) formatted as a Markdown code block, and it does not write to disk. These side-effect and output statements are non-obvious and genuinely useful. It is silent on param interdependencies, though the schema itself covers those.
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?
Two short sentences with zero filler, front-loading purpose before the output and side-effect disclosures. Every sentence earns its place.
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?
For a 19-parameter code generator with no output schema, the description usefully explains the return value (Markdown code block of source) and confirms no disk write, which is what an agent most needs. The remaining gap is the absence of any routing guidance among the many sibling generators.
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 description adds no parameter-level meaning beyond what the schema already documents in detail (including the chainlinkAce and crossChainBridging caveats), so it neither helps nor hurts.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Make a fungible token per the ERC-20 standard') that an agent can sharply distinguish from erc721/erc1155 siblings. It does not differentiate itself from near-neighbors like solidity-stablecoin or stylus-erc20, but the ERC-20 reference is specific enough to anchor selection.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no when-to-use or when-not-to-use guidance. With siblings like solidity-stablecoin, solidity-rwa, cairo-erc20, and stylus-erc20, the agent is left to infer which generator applies; the description never names an alternative or a selecting condition.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
solidity-erc721Solidity ERC721AInspect
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.
| 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". | |
| crossChainBridging | No | Whether to embed an ERC-7786 based bridge directly in the token contract, making it natively crosschain. Crosschain transfers with registered counterparts burn the token on the source chain and mint it on the destination chain. If also using incremental token ids, mint only on a single chain and link counterparts without minting, otherwise colliding ids can strand bridged tokens. | |
| crossChainLinkAllowOverride | No | Whether to allow replacing a crosschain link that has already been registered. Only used if crossChainBridging is set to "erc7786native". |
TDQS
A4.1/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description carries the behavioral disclosure burden. It explicitly states the output is source code formatted as a Markdown code block and that it does not write to disk, which is valuable side-effect information beyond what the schema could convey.
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 two short sentences: the first states the core purpose and the second covers the output format and key side-effect. Every sentence earns its place and there is no filler or restatement of the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a code-generation tool with a well-described 16-parameter schema but no output schema, the description adequately covers the return value and side effects. It explains what the agent will receive, how it is formatted, and that nothing is persisted, which is sufficient for agent judgment.
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?
The schema already provides descriptions for 100% of the 16 parameters, so the tool description does not need to repeat them. The description adds no specific parameter-level guidance, but the schema itself is sufficient, so the baseline score of 3 applies.
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 generates a non-fungible token according to the ERC-721 standard, and it clarifies that the result is source code rather than a deployed asset. This is specific enough to distinguish it from the many ERC-20, ERC-1155, Cairo, and Stylus siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool should be used when ERC-721 contract source is needed, but it does not explicitly say when to use it versus alternatives like solidity-erc1155, cairo-erc721, or solidity-custom. There is no when-not-to-use guidance or mention of sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
solidity-governorSolidity GovernorAInspect
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.
| 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 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.
solidity-rwaSolidity RWAAInspect
Make a real-world asset token that uses the ERC-20 standard. This contract type does not support upgradeability. 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.
| 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. | |
| decimals | No | The number of decimals used to represent token amounts. Defaults to 18. | |
| 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. | |
| upgradeable | No | Upgradeability is not available for Stablecoin or RWA. | |
| chainlinkAce | No | Chainlink ACE (Automated Compliance Engine) adds token policy enforcement through a separately deployed and configured policy engine (integration guide: https://docs.openzeppelin.com/chainlink-ccip-ace; Chainlink docs: https://docs.chain.link/ace). Defaults to false (disabled). Requires ownable or roles access; combining ACE with CCIP requires roles. This integration does not support ACE together with managed access, Callback (ERC-1363), Flash Minting, a nonzero premint, or bridge modes other than CCIP. Configure policies and register the token with the engine before use; this does not establish legal compliance. Enabling ACE makes the generated contract use BUSL-1.1, overriding info.license. Review the ACE license (https://github.com/smartcontractkit/chainlink-ace/blob/v1.2.0/LICENSE) and additional use grants (https://github.com/smartcontractkit/chainlink-ace/blob/v1.2.0/chainlink-ace-License-grants) before production use. | |
| 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 crosschain transfers. Options are custom bridges on any chain, Chainlink CCIP with a separately configured BurnMintTokenPool (integration guide: https://docs.openzeppelin.com/chainlink-ccip-ace; Chainlink docs: https://docs.chain.link/ccip), to embed an ERC-7786 based bridge directly in the token contract, or to use the SuperchainERC20 standard with the predeployed SuperchainTokenBridge. CCIP requires role-based access control, granting the configured pool MINTER_ROLE on each supported chain, and BURNER_ROLE when Burnable is disabled. With Burnable enabled, any holder can burn their own tokens, including the pool, and burnFrom requires an allowance. 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. | |
| crossChainLinkAllowOverride | No | Whether to allow replacing a crosschain link that has already been registered. Only used if crossChainBridging is set to "erc7786native". |
TDQS
A3.5/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 and does a reasonable job: it discloses the return shape ('source code of the generated contract, formatted in a Markdown code block'), the side-effect boundary ('Does not write to disk'), a structural limitation (non-upgradeable), and a stability warning (experimental, partially unaudited, subject to change). It does not add anything about generation constraints or required configuration, but the core behavioral profile is covered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences that are front-loaded with the core purpose, followed by the upgradeability limitation and stability caveat, then the return/output behavior. No filler or repetition, though the experimental warning could be folded more tightly into the constraint sentence.
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?
For a 21-parameter code generator there is no output schema, but the description explicitly states what is returned (Markdown code block) and that nothing is written to disk, which is exactly the information an agent needs about the result. Parameter semantics are fully carried by the schema, so the main remaining gap is the absence of selection guidance against siblings.
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% across all 21 parameters, including rich enum and constraint documentation (access modes, ACE compatibility limits, bridging options), so the schema does the heavy lifting. The description adds no parameter-level meaning beyond what is already documented, which is the expected baseline when coverage is complete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: 'Make a real-world asset token that uses the ERC-20 standard.' An agent can tell it produces an RWA token contract rather than a generic ERC-20. However, it never distinguishes itself from the sibling solidity-erc20 or solidity-stablecoin, both of which also emit ERC-20-based contracts, leaving the selection basis implicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit when-to-use guidance or named alternative. The note 'This contract type does not support upgradeability' is a capability constraint that implies a filtering condition, but the description never says which sibling to reach for instead when upgradeability or other features are required. Usage is left entirely to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
solidity-stablecoinSolidity StablecoinBInspect
Make a stablecoin token that uses the ERC-20 standard. This contract type does not support upgradeability. 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.
| 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. | |
| decimals | No | The number of decimals used to represent token amounts. Defaults to 18. | |
| 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. | |
| upgradeable | No | Upgradeability is not available for Stablecoin or RWA. | |
| chainlinkAce | No | Chainlink ACE (Automated Compliance Engine) adds token policy enforcement through a separately deployed and configured policy engine (integration guide: https://docs.openzeppelin.com/chainlink-ccip-ace; Chainlink docs: https://docs.chain.link/ace). Defaults to false (disabled). Requires ownable or roles access; combining ACE with CCIP requires roles. This integration does not support ACE together with managed access, Callback (ERC-1363), Flash Minting, a nonzero premint, or bridge modes other than CCIP. Configure policies and register the token with the engine before use; this does not establish legal compliance. Enabling ACE makes the generated contract use BUSL-1.1, overriding info.license. Review the ACE license (https://github.com/smartcontractkit/chainlink-ace/blob/v1.2.0/LICENSE) and additional use grants (https://github.com/smartcontractkit/chainlink-ace/blob/v1.2.0/chainlink-ace-License-grants) before production use. | |
| 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 crosschain transfers. Options are custom bridges on any chain, Chainlink CCIP with a separately configured BurnMintTokenPool (integration guide: https://docs.openzeppelin.com/chainlink-ccip-ace; Chainlink docs: https://docs.chain.link/ccip), to embed an ERC-7786 based bridge directly in the token contract, or to use the SuperchainERC20 standard with the predeployed SuperchainTokenBridge. CCIP requires role-based access control, granting the configured pool MINTER_ROLE on each supported chain, and BURNER_ROLE when Burnable is disabled. With Burnable enabled, any holder can burn their own tokens, including the pool, and burnFrom requires an allowance. 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. | |
| crossChainLinkAllowOverride | No | Whether to allow replacing a crosschain link that has already been registered. Only used if crossChainBridging is set to "erc7786native". |
TDQS
B3.4/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 and does a decent job: it discloses the output form (source code in a Markdown code block), the absence of a side effect ('Does not write to disk'), the lack of upgradeability, and an experimental/un-audited caveat. It omits any mention of auth requirements or generation limits, which keeps it from a 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Four short sentences, front-loaded with the purpose and the most consequential constraints (no upgradeability, experimental). No filler; each sentence adds a distinct fact. Slightly clipped phrasing ('Experimental, some features...') costs a point.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 21-parameter, nested-schema generator with no annotations, the description covers output behavior and a couple of caveats but says nothing about the major feature surfaces (ACE, cross-chain bridging, access control, restrictions) that dominate the parameter set. Adequate but thin given the complexity.
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% across 21 parameters, so the schema already documents every field in detail. The description adds no parameter-level meaning beyond what the schema provides, which lands at the baseline 3 for high-coverage schemas.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Make a stablecoin token that uses the ERC-20 standard'), which is clear enough to distinguish from generic code-gen siblings. However, it never explicitly contrasts itself with solidity-erc20, so an agent must infer why a stablecoin variant exists over the plain ERC-20 tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No when-to-use guidance, no conditions for choosing this over solidity-erc20 or other token siblings. The only constraint conveyed is a negative one (no upgradeability). It implies context through 'stablecoin' but never states prerequisites or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
3 tool updates
- Changed
solidity-erc204 fields changed- added
Input schema / properties / chainlinkAceAdded value: +{ + "description": "Chainlink ACE (Automated Compliance Engine) adds token policy enforcement through a separately deployed and configured policy engine (integration guide: https://docs.openzeppelin.com/chainlink-ccip-ace; Chainlink docs: https://docs.chain.link/ace). Defaults to false (disabled). Requires ownable or roles access; combining ACE with CCIP requires roles. This integration does not support ACE together with managed access, Callback (ERC-1363), Flash Minting, a nonzero premint, or bridge modes other than CCIP. Configure policies and register the token with the engine before use; this does not establish legal compliance. Enabling ACE makes the generated contract use BUSL-1.1, overriding info.license. Review the ACE license (https://github.com/smartcontractkit/chainlink-ace/blob/v1.2.0/LICENSE) and additional use grants (https://github.com/smartcontractkit/chainlink-ace/blob/v1.2.0/chainlink-ace-License-grants) before production use.", + "type": "boolean" +} - changed
Input schema / properties / crossChainBridging / anyOfPrevious value: -[ - { - "anyOf": [ - { - "const": "custom", - "type": "string" - }, - { - "const": "erc7786native", - "type": "string" - } - ] - }, - { - "const": "superchain", - "type": "string" - } -]New value: +[ + { + "anyOf": [ + { + "anyOf": [ + { + "const": "custom", + "type": "string" + }, + { + "const": "chainlink-ccip", + "type": "string" + } + ] + }, + { + "const": "erc7786native", + "type": "string" + } + ] + }, + { + "const": "superchain", + "type": "string" + } +] - changed
Input schema / properties / crossChainBridging / descriptionPrevious value: -"Whether to allow authorized bridge contracts to mint and burn tokens for crosschain transfers. Options are to use custom bridges on any chain, to embed an ERC-7786 based bridge directly in the token contract, or to use 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."New value: +"Whether to allow authorized bridge contracts to mint and burn tokens for crosschain transfers. Options are custom bridges on any chain, Chainlink CCIP with a separately configured BurnMintTokenPool (integration guide: https://docs.openzeppelin.com/chainlink-ccip-ace; Chainlink docs: https://docs.chain.link/ccip), to embed an ERC-7786 based bridge directly in the token contract, or to use the SuperchainERC20 standard with the predeployed SuperchainTokenBridge. CCIP requires role-based access control, granting the configured pool MINTER_ROLE on each supported chain, and BURNER_ROLE when Burnable is disabled. With Burnable enabled, any holder can burn their own tokens, including the pool, and burnFrom requires an allowance. 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." - changed
Input schema / properties / info / properties / license / descriptionPrevious value: -"The license used by the contract, default is \"MIT\""New value: +"The license used by the contract, default is \"MIT\". Ignored when chainlinkAce is enabled: contracts generated with ACE always use BUSL-1.1."
- Changed
solidity-rwa5 fields changed- added
Input schema / properties / chainlinkAceAdded value: +{ + "description": "Chainlink ACE (Automated Compliance Engine) adds token policy enforcement through a separately deployed and configured policy engine (integration guide: https://docs.openzeppelin.com/chainlink-ccip-ace; Chainlink docs: https://docs.chain.link/ace). Defaults to false (disabled). Requires ownable or roles access; combining ACE with CCIP requires roles. This integration does not support ACE together with managed access, Callback (ERC-1363), Flash Minting, a nonzero premint, or bridge modes other than CCIP. Configure policies and register the token with the engine before use; this does not establish legal compliance. Enabling ACE makes the generated contract use BUSL-1.1, overriding info.license. Review the ACE license (https://github.com/smartcontractkit/chainlink-ace/blob/v1.2.0/LICENSE) and additional use grants (https://github.com/smartcontractkit/chainlink-ace/blob/v1.2.0/chainlink-ace-License-grants) before production use.", + "type": "boolean" +} - changed
Input schema / properties / crossChainBridging / anyOfPrevious value: -[ - { - "anyOf": [ - { - "const": "custom", - "type": "string" - }, - { - "const": "erc7786native", - "type": "string" - } - ] - }, - { - "const": "superchain", - "type": "string" - } -]New value: +[ + { + "anyOf": [ + { + "anyOf": [ + { + "const": "custom", + "type": "string" + }, + { + "const": "chainlink-ccip", + "type": "string" + } + ] + }, + { + "const": "erc7786native", + "type": "string" + } + ] + }, + { + "const": "superchain", + "type": "string" + } +] - changed
Input schema / properties / crossChainBridging / descriptionPrevious value: -"Whether to allow authorized bridge contracts to mint and burn tokens for crosschain transfers. Options are to use custom bridges on any chain, to embed an ERC-7786 based bridge directly in the token contract, or to use 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."New value: +"Whether to allow authorized bridge contracts to mint and burn tokens for crosschain transfers. Options are custom bridges on any chain, Chainlink CCIP with a separately configured BurnMintTokenPool (integration guide: https://docs.openzeppelin.com/chainlink-ccip-ace; Chainlink docs: https://docs.chain.link/ccip), to embed an ERC-7786 based bridge directly in the token contract, or to use the SuperchainERC20 standard with the predeployed SuperchainTokenBridge. CCIP requires role-based access control, granting the configured pool MINTER_ROLE on each supported chain, and BURNER_ROLE when Burnable is disabled. With Burnable enabled, any holder can burn their own tokens, including the pool, and burnFrom requires an allowance. 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." - changed
Input schema / properties / info / properties / license / descriptionPrevious value: -"The license used by the contract, default is \"MIT\""New value: +"The license used by the contract, default is \"MIT\". Ignored when chainlinkAce is enabled: contracts generated with ACE always use BUSL-1.1." - added
Input schema / properties / upgradeableAdded value: +{ + "const": false, + "description": "Upgradeability is not available for Stablecoin or RWA.", + "type": "boolean" +}
- Changed
solidity-stablecoin5 fields changed- added
Input schema / properties / chainlinkAceAdded value: +{ + "description": "Chainlink ACE (Automated Compliance Engine) adds token policy enforcement through a separately deployed and configured policy engine (integration guide: https://docs.openzeppelin.com/chainlink-ccip-ace; Chainlink docs: https://docs.chain.link/ace). Defaults to false (disabled). Requires ownable or roles access; combining ACE with CCIP requires roles. This integration does not support ACE together with managed access, Callback (ERC-1363), Flash Minting, a nonzero premint, or bridge modes other than CCIP. Configure policies and register the token with the engine before use; this does not establish legal compliance. Enabling ACE makes the generated contract use BUSL-1.1, overriding info.license. Review the ACE license (https://github.com/smartcontractkit/chainlink-ace/blob/v1.2.0/LICENSE) and additional use grants (https://github.com/smartcontractkit/chainlink-ace/blob/v1.2.0/chainlink-ace-License-grants) before production use.", + "type": "boolean" +} - changed
Input schema / properties / crossChainBridging / anyOfPrevious value: -[ - { - "anyOf": [ - { - "const": "custom", - "type": "string" - }, - { - "const": "erc7786native", - "type": "string" - } - ] - }, - { - "const": "superchain", - "type": "string" - } -]New value: +[ + { + "anyOf": [ + { + "anyOf": [ + { + "const": "custom", + "type": "string" + }, + { + "const": "chainlink-ccip", + "type": "string" + } + ] + }, + { + "const": "erc7786native", + "type": "string" + } + ] + }, + { + "const": "superchain", + "type": "string" + } +] - changed
Input schema / properties / crossChainBridging / descriptionPrevious value: -"Whether to allow authorized bridge contracts to mint and burn tokens for crosschain transfers. Options are to use custom bridges on any chain, to embed an ERC-7786 based bridge directly in the token contract, or to use 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."New value: +"Whether to allow authorized bridge contracts to mint and burn tokens for crosschain transfers. Options are custom bridges on any chain, Chainlink CCIP with a separately configured BurnMintTokenPool (integration guide: https://docs.openzeppelin.com/chainlink-ccip-ace; Chainlink docs: https://docs.chain.link/ccip), to embed an ERC-7786 based bridge directly in the token contract, or to use the SuperchainERC20 standard with the predeployed SuperchainTokenBridge. CCIP requires role-based access control, granting the configured pool MINTER_ROLE on each supported chain, and BURNER_ROLE when Burnable is disabled. With Burnable enabled, any holder can burn their own tokens, including the pool, and burnFrom requires an allowance. 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." - changed
Input schema / properties / info / properties / license / descriptionPrevious value: -"The license used by the contract, default is \"MIT\""New value: +"The license used by the contract, default is \"MIT\". Ignored when chainlinkAce is enabled: contracts generated with ACE always use BUSL-1.1." - added
Input schema / properties / upgradeableAdded value: +{ + "const": false, + "description": "Upgradeability is not available for Stablecoin or RWA.", + "type": "boolean" +}
5 tool updates
- Changed
solidity-erc11551 field changed- changed
Input schema / properties / crossChainBridging / descriptionPrevious value: -"Whether to embed an ERC-7786 based bridge directly in the token contract, making it natively crosschain. Cross-chain transfers with registered counterparts burn the tokens on the source chain and mint them on the destination chain."New value: +"Whether to embed an ERC-7786 based bridge directly in the token contract, making it natively crosschain. Crosschain transfers with registered counterparts burn the tokens on the source chain and mint them on the destination chain."
- Changed
solidity-erc201 field changed- changed
Input schema / properties / crossChainBridging / descriptionPrevious value: -"Whether to allow authorized bridge contracts to mint and burn tokens for cross-chain transfers. Options are to use custom bridges on any chain, to embed an ERC-7786 based bridge directly in the token contract, or to use 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."New value: +"Whether to allow authorized bridge contracts to mint and burn tokens for crosschain transfers. Options are to use custom bridges on any chain, to embed an ERC-7786 based bridge directly in the token contract, or to use 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."
- Changed
solidity-erc7211 field changed- changed
Input schema / properties / crossChainBridging / descriptionPrevious value: -"Whether to embed an ERC-7786 based bridge directly in the token contract, making it natively crosschain. Cross-chain transfers with registered counterparts burn the token on the source chain and mint it on the destination chain. If also using incremental token ids, mint only on a single chain and link counterparts without minting, otherwise colliding ids can strand bridged tokens."New value: +"Whether to embed an ERC-7786 based bridge directly in the token contract, making it natively crosschain. Crosschain transfers with registered counterparts burn the token on the source chain and mint it on the destination chain. If also using incremental token ids, mint only on a single chain and link counterparts without minting, otherwise colliding ids can strand bridged tokens."
- Changed
solidity-rwa1 field changed- changed
Input schema / properties / crossChainBridging / descriptionPrevious value: -"Whether to allow authorized bridge contracts to mint and burn tokens for cross-chain transfers. Options are to use custom bridges on any chain, to embed an ERC-7786 based bridge directly in the token contract, or to use 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."New value: +"Whether to allow authorized bridge contracts to mint and burn tokens for crosschain transfers. Options are to use custom bridges on any chain, to embed an ERC-7786 based bridge directly in the token contract, or to use 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."
- Changed
solidity-stablecoin1 field changed- changed
Input schema / properties / crossChainBridging / descriptionPrevious value: -"Whether to allow authorized bridge contracts to mint and burn tokens for cross-chain transfers. Options are to use custom bridges on any chain, to embed an ERC-7786 based bridge directly in the token contract, or to use 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."New value: +"Whether to allow authorized bridge contracts to mint and burn tokens for crosschain transfers. Options are to use custom bridges on any chain, to embed an ERC-7786 based bridge directly in the token contract, or to use 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."
3 tool updates
- Changed
solidity-erc11552 fields changed- added
Input schema / properties / crossChainBridgingAdded value: +{ + "const": "erc7786native", + "description": "Whether to embed an ERC-7786 based bridge directly in the token contract, making it natively crosschain. Cross-chain transfers with registered counterparts burn the tokens on the source chain and mint them on the destination chain.", + "type": "string" +} - added
Input schema / properties / crossChainLinkAllowOverrideAdded value: +{ + "description": "Whether to allow replacing a crosschain link that has already been registered. Only used if crossChainBridging is set to \"erc7786native\".", + "type": "boolean" +}
- Changed
solidity-erc7212 fields changed- added
Input schema / properties / crossChainBridgingAdded value: +{ + "const": "erc7786native", + "description": "Whether to embed an ERC-7786 based bridge directly in the token contract, making it natively crosschain. Cross-chain transfers with registered counterparts burn the token on the source chain and mint it on the destination chain. If also using incremental token ids, mint only on a single chain and link counterparts without minting, otherwise colliding ids can strand bridged tokens.", + "type": "string" +} - added
Input schema / properties / crossChainLinkAllowOverrideAdded value: +{ + "description": "Whether to allow replacing a crosschain link that has already been registered. Only used if crossChainBridging is set to \"erc7786native\".", + "type": "boolean" +}
- Changed
solidity-governor1 field changed- added
Input schema / properties / crossChainExecutionAdded 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" +}
4 tool updates
- Changed
solidity-erc201 field changed- added
Input schema / properties / decimalsAdded value: +{ + "description": "The number of decimals used to represent token amounts. Defaults to 18.", + "type": "string" +}
- Changed
solidity-governor1 field changed- changed
Input schema / properties / blockTime / descriptionPrevious value: -"The block time of the chain, default is 12"New value: +"The block time of the chain in seconds, default is 12"
- Changed
solidity-rwa1 field changed- added
Input schema / properties / decimalsAdded value: +{ + "description": "The number of decimals used to represent token amounts. Defaults to 18.", + "type": "string" +}
- Changed
solidity-stablecoin1 field changed- added
Input schema / properties / decimalsAdded value: +{ + "description": "The number of decimals used to represent token amounts. Defaults to 18.", + "type": "string" +}
3 tool updates
- Changed
solidity-erc203 fields changed- changed
Input schema / properties / crossChainBridging / anyOfPrevious value: -[ - { - "const": "custom", - "type": "string" - }, - { - "const": "superchain", - "type": "string" - } -]New value: +[ + { + "anyOf": [ + { + "const": "custom", + "type": "string" + }, + { + "const": "erc7786native", + "type": "string" + } + ] + }, + { + "const": "superchain", + "type": "string" + } +] - changed
Input schema / properties / crossChainBridging / descriptionPrevious value: -"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."New value: +"Whether to allow authorized bridge contracts to mint and burn tokens for cross-chain transfers. Options are to use custom bridges on any chain, to embed an ERC-7786 based bridge directly in the token contract, or to use 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." - added
Input schema / properties / crossChainLinkAllowOverrideAdded value: +{ + "description": "Whether to allow replacing a crosschain link that has already been registered. Only used if crossChainBridging is set to \"erc7786native\".", + "type": "boolean" +}
- Changed
solidity-rwa3 fields changed- changed
Input schema / properties / crossChainBridging / anyOfPrevious value: -[ - { - "const": "custom", - "type": "string" - }, - { - "const": "superchain", - "type": "string" - } -]New value: +[ + { + "anyOf": [ + { + "const": "custom", + "type": "string" + }, + { + "const": "erc7786native", + "type": "string" + } + ] + }, + { + "const": "superchain", + "type": "string" + } +] - changed
Input schema / properties / crossChainBridging / descriptionPrevious value: -"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."New value: +"Whether to allow authorized bridge contracts to mint and burn tokens for cross-chain transfers. Options are to use custom bridges on any chain, to embed an ERC-7786 based bridge directly in the token contract, or to use 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." - added
Input schema / properties / crossChainLinkAllowOverrideAdded value: +{ + "description": "Whether to allow replacing a crosschain link that has already been registered. Only used if crossChainBridging is set to \"erc7786native\".", + "type": "boolean" +}
- Changed
solidity-stablecoin3 fields changed- changed
Input schema / properties / crossChainBridging / anyOfPrevious value: -[ - { - "const": "custom", - "type": "string" - }, - { - "const": "superchain", - "type": "string" - } -]New value: +[ + { + "anyOf": [ + { + "const": "custom", + "type": "string" + }, + { + "const": "erc7786native", + "type": "string" + } + ] + }, + { + "const": "superchain", + "type": "string" + } +] - changed
Input schema / properties / crossChainBridging / descriptionPrevious value: -"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."New value: +"Whether to allow authorized bridge contracts to mint and burn tokens for cross-chain transfers. Options are to use custom bridges on any chain, to embed an ERC-7786 based bridge directly in the token contract, or to use 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." - added
Input schema / properties / crossChainLinkAllowOverrideAdded value: +{ + "description": "Whether to allow replacing a crosschain link that has already been registered. Only used if crossChainBridging is set to \"erc7786native\".", + "type": "boolean" +}
8 tool updates
- First observed
solidity-account - First observed
solidity-custom - First observed
solidity-erc1155 - First observed
solidity-erc20 - First observed
solidity-erc721 - First observed
solidity-governor - First observed
solidity-rwa - First observed
solidity-stablecoin
Related MCP Connectors
The OpenZeppelin Stylus Contracts MCP server generates secure smart contracts for the Arbitrum Stylus environment using OpenZeppelin templates, including ERC-20, ERC-721, and ERC-1155 standards. It automatically validates generated code against OpenZeppelin's security and style rules, enforcing best practices for imports, modifiers, naming conventions, and security checks to prevent common vulnerabilities. The server integrates with AI development tools like Cursor, Claude, Gemini, Windsurf, and VS Code to enable AI-assisted, production-ready smart contract development.
The OpenZeppelin Cairo Contracts MCP server generates secure smart contracts in the Cairo language for Starknet environments based on OpenZeppelin templates. It brings OpenZeppelin's proven security and style rules directly into AI-driven development workflows to create safe, production-ready contracts. Key capabilities include providing templates for ERC-20, ERC-721, ERC-1155, Multisig, Governor, and Vesting contracts.
The OpenZeppelin Stellar Contracts MCP server generates secure smart contracts for the Stellar blockchain based on OpenZeppelin templates. It integrates with AI assistants to automatically enforce OpenZeppelin's security best practices, style rules, and standards at every prompt, enabling developers to create production-ready Fungible Token, Non-Fungible Token, and Stablecoin contracts through AI-driven workflows.
MCP server for secureFlows: token-free URL builders and integration-linting tools for AI agents.
Related MCP Servers
- FlicenseNot gradedqualityDmaintenanceAn MCP server that statically audits Solidity smart contracts for common vulnerabilities like reentrancy and access control, enabling developers to identify and fix security issues via natural language.-
- AlicenseAqualityDmaintenanceAn MCP server that gives autonomous coding agents deterministic, schema-validated tools for EVM smart contract development — security scanning, gas profiling, compiler diagnostics, and transaction simulation.91MIT
- AlicenseNot gradedqualityDmaintenanceEnables users to generate and retrieve secure, audited smart contract templates from OpenZeppelin including ERC20, ERC721, ERC1155 tokens, access control, governance, and finance contracts through natural language prompts.MIT
Try in Browser
Claude Code, inside the Godot 4 editorFlockbay puts an AI agent in the real Godot 4 editor: it writes GDScript, runs your game and fixes what breaks. Free, or bring your own Claude Code or Codex.flockbay.comAd
Glama MCP Gateway
Add one secure layer between your agents and this server.