A
licenseA
qualityA
maintenanceA Model Context Protocol (MCP) server that allows AI agents to generate smart contracts using OpenZeppelin Contracts libraries.
33
132 npm
294
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 with GitHub, an HTTP challenge, or a DNS record. Claimed connector authors can inspect health checks, view analytics, and manage their listing.
- Status
- Healthy
- Uptime
- 99.9% over 41 days
- Last Tested
- Transport
- Streamable HTTP · MCP 2025-11-25
- URL
TDQS
A4.3/5.0
Scored across 8 tools
Disambiguation5/5
Each tool targets a distinct contract type (account, custom, ERC1155, ERC20, ERC721, governor, RWA, stablecoin), and descriptions clearly differentiate between them, even for the ERC20-based variants.
Naming Consistency5/5
All tool names follow the identical 'solidity-<type>' pattern, providing a predictable and consistent naming scheme across the entire server.
Tool Count5/5
With 8 tools covering the main Solidity contract categories plus a custom option, the count is well-scoped for a contract generator and avoids unnecessary bloat.
Completeness4/5
The toolset covers major contract types, but it lacks support for upgradeable contracts (proxies) and some common OpenZeppelin features like ERC4626 vaults. The 'solidity-custom' tool can partially compensate for these gaps.
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.
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. |
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.
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. |
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.
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 | |
| 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.
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. | |
| 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. | |
| 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 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. | |
| 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 provided, the description carries the behavioral disclosure burden. It clearly states that the tool returns source code in a Markdown code block and does not write to disk, which are important side-effect details for an agent. It omits deeper information about edge cases or errors, but the core behavior is transparent.
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 concise sentences that front-load purpose and immediately state return format and side-effect behavior. Every sentence earns its place with no filler.
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 highly parameterized tool with 18 inputs and no output schema, the description is minimal but does cover the key return value and side-effect profile. It does not compensate for the absence of annotations or explain how the generator fits among sibling Solidity/Cairo/stylus tools, leaving the context incomplete.
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 rich per-parameter descriptions already carry most of the semantic weight. The tool description itself adds little about parameters beyond 'per the ERC-20 standard', so it meets the baseline but does not go further.
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 says 'Make a fungible token per the ERC-20 standard', which is a clear verb plus resource, and the title/name make the Solidity context obvious. However, it does not explicitly distinguish itself from siblings such as solidity-stablecoin, solidity-rwa, or cairo-erc20.
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 guidance about when to use this tool versus the many sibling generators. The description does not state alternatives, exclusions, or prerequisites, so an agent must infer usage from the tool name alone.
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.
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". | |
| 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.
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 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. 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. | |
| 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. | |
| 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 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. | |
| 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?
Given the absence of annotations, the description carries the full burden and does a good job: it states the tool does not write to disk and returns source code in a Markdown block. The experimental, unaudited nature of some features is disclosed multiple times in the schema, and while the description mentions it, the specifics about which features are experimental are only in the schema. The description is honest that some features are experimental and subject to change, providing critical behavioral context.
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 minimal and to the point, consisting of only three sentences that efficiently convey the core purpose and critical experimental caveat while front-loading the main value proposition.
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 highly complex tool with 19 parameters and nested objects, the description is quite minimal. The schema and parameter descriptions are rich, but the description does not explain the overall workflow or the contract's architecture, nor does it provide an overview of what the generated code looks like. No output schema exists to fill in gaps, so the description could have been more complete about the tool's overall behavior, making its output a contract source file.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% description coverage, so the baseline is 3, but the description adds zero information about how parameters shape the generated contract. With 19 parameters, the description's silence on how the schema parameters configure the output and the impact of those choices is a miss. The description also doesn't clarify the meaning of higher-level interactions like votes and crossChainBridging or the tradeoffs, though the schema itself is thorough.
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 clearly states the tool makes an ERC-20 real-world asset token, though the term 'real-world asset token' is a bit unusual and could benefit from more specificity. The description differentiates it as experimental and clarifies the output is source code in a Markdown block, which helps distinguish it from sibling tools like solidity-erc20 by focusing on the real-world asset aspect.
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 usage when the user wants to create an ERC-20 RWA token, but does not explicitly explain when to choose this over siblings like solidity-erc20. No alternative tools are named, and the differences are left implied. The experimental warning provides some context for when caution is needed, but it is minimal.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
solidity-stablecoinSolidity StablecoinAInspect
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. | |
| 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. | |
| 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 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. | |
| 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. It explicitly states that the tool returns generated source code as a Markdown code block and does not write to disk, which are crucial behavioral details. It also warns that the tool is experimental. Minor gaps remain around error conditions or output characteristics.
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 highly concise and front-loaded, stating purpose and major caveat in the first sentence, then returning behavior in a compact second paragraph. Every sentence earns its place with no redundancy.
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?
Given the tool's complexity (19 parameters, nested objects, no output schema), the description is adequate but sparse. It covers output format and non-persistence, and the schema covers parameters, but it omits an overview of how stablecoin-specific options relate to the tool's purpose and how this tool compares to sibling ERC-20 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 tool description itself adds no parameter-level meaning; it relies entirely on the schema for parameter semantics.
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 clearly states the tool's function: generating a stablecoin token using the ERC-20 standard. However, it does not differentiate from sibling tools like solidity-erc20 or solidity-custom, missing the top score.
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 guidance is provided on when to use this tool versus alternatives such as solidity-erc20 or solidity-rwa. Prerequisites, exclusions, and trade-offs are not mentioned; the experimental warning is a caveat, not usage direction.
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.
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.-
- AlicenseAqualityCmaintenanceAn 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
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd
Glama MCP Gateway
Add one secure layer between your agents and this server.