A
licenseA
qualityA
maintenanceA Model Context Protocol (MCP) server that allows AI agents to generate smart contracts using OpenZeppelin Contracts libraries.
33
56 npm
294
AGPL 3.0
OpenZeppelin Cairo Contracts
Server Details
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.
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 37 days
- Last Tested
- Transport
- Streamable HTTP · MCP 2025-11-25
- URL
TDQS
A3.8/5.0
Scored across 9 tools
Disambiguation4/5
Each tool targets a distinct contract type or standard, but cairo-custom is a generic catch-all that overlaps with cairo-account, and ERC-1155 vs. ERC-6909 both describe multi-token contracts, which could cause some confusion. The descriptions help clarify boundaries in most cases.
Naming Consistency5/5
All tools follow the same predictable pattern: 'cairo-' prefix plus a contract-type identifier in kebab-case. There are no deviations or mixed conventions.
Tool Count5/5
Nine tools is well-scoped for generating common OpenZeppelin Cairo contract templates. Each tool corresponds to a distinct contract category, and none feels redundant.
Completeness3/5
The surface covers core token standards, governance, multisig, vesting, and account abstraction, but it misses common OpenZeppelin modules like access control (Ownable), upgradeability/proxies, and timelocks. These are notable gaps for a server named after the full contracts library.
Available Tools
9 toolscairo-accountCairo AccountAInspect
Make a custom smart contract that represents an account that can be deployed and interacted with other contracts, and can be extended to implement custom logic. An account is a special type of contract that is used to validate and execute transactions.
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 | |
| type | Yes | Type of signature used for signature checking by the Account contract, Starknet account uses the STARK curve, Ethereum-flavored account uses the Secp256k1 curve. | |
| deploy | No | Whether to enables the account to be counterfactually deployed. | |
| macros | No | The macros to use for the contract. | |
| pubkey | No | Whether to enables the account to change its own public key. | |
| declare | No | Whether to enable the account to declare other contract classes. | |
| upgradeable | No | Whether the smart contract is upgradeable. | |
| outsideExecution | No | Whether to allow a protocol to submit transactions on behalf of the account, as long as it has the relevant signatures. |
TDQS
A3.7/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 full burden. It discloses key behavioral traits: it returns source code formatted as a Markdown code block and does not write to disk. It also mentions deployability and extensibility. This goes beyond basic 'generate contract' and provides useful operational details, though it does not cover potential errors or prerequisites.
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?
The description is concise with two short paragraphs. The first sentence states the core purpose, and the second paragraph clarifies the return format and side effects. There is minor redundancy (e.g., 'custom smart contract' and 'account' explanation), but overall it is well-structured and front-loaded without excessive wordiness.
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?
Given the tool's complexity (9 parameters, nested objects, no output schema), the description covers the essential missing pieces: it states the return format (Markdown code block) and non-disk-write behavior. The schema covers parameter meanings. However, it does not address edge cases or limitations, and it lacks explicit differentiation from sibling code generators, leaving some contextual ambiguity. Still, it is reasonably complete for an agent to 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?
The input schema has 100% description coverage for all 9 parameters, so the schema already explains each parameter. The description itself adds no additional parameter-specific semantics beyond what the schema provides. The baseline is 3 because the schema does the heavy lifting and the description does not need to compensate.
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 verb 'Make' and the resource 'a custom smart contract that represents an account'. It distinguishes itself from sibling tools by focusing specifically on account contracts, though it does not explicitly name alternatives like cairo-custom or cairo-multisig. The purpose is specific enough for an agent to understand this generates account contract source code.
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 provides context by explaining that an account is a special type of contract for validating and executing transactions, which implies when this tool is relevant. However, it does not explicitly state when to prefer this over sibling tools such as cairo-multisig or cairo-governor, nor does it mention any exclusions. Usage guidance is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
cairo-customCairo 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 | ||
| macros | No | The macros to use for the contract. | |
| 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. |
TDQS
A3.8/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Even though annotations are absent, the description discloses critical behaviors: it returns source code, formats it as Markdown, and does not write to disk. This transparently signals a side-effect-free generation process. It stops short of mentioning more subtle behaviors (e.g., output length or dependency on network), but is strong for a code generator.
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 exceptionally concise: two sentences convey purpose, return format, and side-effect involvement. Every phrase adds value, with the key information front-loaded.
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 code-generation tool, the description covers the essential behaviors: what it does, what it returns, and what it doesn't do (write to disk). The input schema fully documents parameters, and no output schema is present, so the text appropriately focuses on the generation outcome. It could mention deployment explicitly, but that is reasonably implied by 'returns source code.'
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 high (83%) and includes detailed explanations for nested objects like 'access' and 'macros'. The description adds no parameter-specific context beyond the schema, so the baseline 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') and explicitly notes the output (source code in a Markdown code block). The term 'custom' distinguishes it from the sibling template-based tools, making its unique role clear.
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 explicit guidance is given on when to choose this tool over siblings like cairo-erc20 or cairo-governor. The word 'custom' implies a fallback for non-standard contracts, but the description never states criteria, exclusions, or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
cairo-erc1155Cairo ERC1155BInspect
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 |
|---|---|---|---|
| info | No | Metadata about the contract and author | |
| name | Yes | The name of the contract | |
| access | No | ||
| macros | No | The macros to use for the contract. | |
| supply | No | Whether to keep track of total supply of tokens. | |
| baseUri | Yes | The location of the metadata for the token. Clients will replace any instance of {id} in this string with the tokenId. | |
| 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. | |
| uriStorage | No | Allows updating token URIs for individual token IDs. | |
| royaltyInfo | No | Provides information for how much royalty is owed and to whom, based on a sale price. Follows ERC-2981 standard. | |
| upgradeable | No | Whether the smart contract is upgradeable. | |
| updatableUri | No | Whether privileged accounts will be able to set a new URI for all token types. |
TDQS
B3.2/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry behavioral disclosure. It states the tool returns Markdown-formatted source code and does not write to disk, which are important side-effect facts. However, it doesn't disclose other behaviors like network calls, compilation, or whether it's purely deterministic. For a code-generation tool, the disclosed behavior is adequate but not exhaustive.
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 extremely concise: two short sentences with no filler. It front-loads the core purpose and then states the two most operationally relevant behaviors (output format and no disk write). Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having 13 parameters, nested objects, and no output schema, the description is minimal. It does not explain how to choose this tool over near-identical siblings (e.g., solidity-erc1155 or cairo-erc721), nor does it hint at what a successful response contains beyond a code block. The schema covers parameter details, but the description lacks usage context and integration guidance, making it insufficient for a tool with this 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 92%, so the schema documents most parameters. The description adds no parameter-specific meaning beyond what the schema already provides. It does not explain how the numerous boolean flags interact or what the nested objects control, but the high coverage makes the schema the primary source. Baseline 3 is appropriate.
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 it creates an ERC-1155 non-fungible token and returns source code. The verb 'Make' is specific, and the resource (ERC-1155 standard) is clear. It distinguishes from ERC-20/ERC-721 siblings, though it doesn't explicitly say this is for Cairo (relying on the tool name).
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 like solidity-erc1155 or cairo-erc721. There is no mention of context, prerequisites, or exclusions. The description does not help an agent decide between this and sibling code generators.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
cairo-erc20Cairo 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, with a way to delegate one's voting power to a trusted account. | |
| access | No | ||
| macros | No | The macros to use for the contract. | |
| symbol | Yes | The short symbol for the token | |
| appName | No | Required when votes is enabled, for hashing and signing typed structured data. Name for domain separator implementing SNIP12Metadata trait. Prevents two applications from producing the same hash. | |
| premint | No | The number of tokens to premint for the deployer. | |
| wrapper | No | Whether to include ERC20Wrapper functionality for depositing and withdrawing an underlying token. | |
| burnable | No | Whether token holders will be able to destroy their tokens | |
| decimals | No | The number of decimals to use for the contract. 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 | Configuration object for the ERC20FlashMint extension (ERC-3156 flash loans). The extension is included only when `enabled` is true; the other fields tune the loan limit, fee, and fee destination. | |
| appVersion | No | Required when votes is enabled, for hashing and signing typed structured data. Version for domain separator implementing SNIP12Metadata trait. Prevents two versions of the same application from producing the same hash. | |
| upgradeable | No | Whether the smart contract is upgradeable. |
TDQS
A3.8/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 usefully states that the tool returns source code in a Markdown code block and explicitly notes it does not write to disk, which clarifies side effects and output format. It does not mention every edge behavior, but the key safety-relevant behavior is disclosed.
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 only two sentences and every sentence adds value: the first states the purpose, and the second clarifies output format and side-effect behavior. It is front-loaded with the core purpose and contains no fluff.
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?
Given the tool's complexity, the description covers the essential context: what it generates, how the result is returned, and that it has no filesystem side effect. The extensive input schema covers parameter details, so the description does not need to repeat them. A brief note about language/platform fit could improve completeness, but the tool name supplies that context.
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 94%, so the parameter schemas already carry detailed explanations for most options. The tool description itself adds no parameter-level semantics, which is acceptable but does not go beyond what the schema provides.
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 states a specific action and resource: 'Make a fungible token per the ERC-20 standard.' This clearly differentiates it from non-fungible siblings like cairo-erc721 and cairo-erc1155. However, it does not explicitly distinguish it from other ERC-20 sibling tools in different languages, relying on the tool name for that distinction.
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 usage context is implied: use this tool when an ERC-20 fungible token contract source is needed. There is no explicit guidance about when to prefer cairo-erc20 over solidity-erc20, stylus-erc20, or tron-trc20, nor any stated exclusions or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
cairo-erc6909Cairo ERC6909AInspect
Make a minimal multi-token per the ERC-6909 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 | |
| access | No | ||
| macros | No | The macros to use for the contract. | |
| burnable | No | Whether token holders will be able to destroy their tokens | |
| metadata | No | Whether to include per-token metadata extension providing name, symbol, and decimals per token ID. | |
| 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. | |
| contentUri | No | Whether to include Content URI extension for contract-level and per-token URI metadata. | |
| tokenSupply | No | Whether to keep track of total supply per token ID. | |
| upgradeable | No | Whether the smart contract is upgradeable. |
TDQS
A4/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 full burden of behavioral disclosure. It specifies that the tool returns source code in a Markdown block and does not write to disk, which are essential behaviors. However, it does not mention any potential side effects beyond that, but for a code generator these two are the most critical.
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 with no filler. The purpose is front-loaded, and the behavioral note about output and disk usage adds value 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?
For a tool with 11 parameters and nested objects, the description covers the core purpose, output format, and side-effect avoidance. It does not clarify the interaction between 'minimal' and the optional features, but the schema descriptions cover each parameter adequately. Overall, it is sufficiently complete for an agent to call it 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?
The schema description coverage is 91%, so the parameters are well-documented in the schema itself. The description adds no extra meaning to parameters, only the general notion of 'minimal' which might be ambiguous. Baseline 3 is appropriate given the high coverage.
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 action ('Make a minimal multi-token') and the specific standard (ERC-6909), which distinguishes it from sibling tools like cairo-erc20 and cairo-erc721. It also clarifies that it returns source code, removing any ambiguity about being a generator.
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 for ERC-6909 tokens via the standard name, but it does not explicitly mention when to choose this tool over alternatives or provide exclusions. Since siblings cover other standards, the guidance is only implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
cairo-erc721Cairo 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. | |
| access | No | ||
| macros | No | The macros to use for the contract. | |
| symbol | Yes | The short symbol for the token | |
| appName | No | Required when votes is enabled, for hashing and signing typed structured data. Name for domain separator implementing SNIP12Metadata trait. Prevents two applications from producing the same hash. | |
| baseUri | No | A base uri for the non-fungible token. | |
| wrapper | No | Whether to include ERC721Wrapper functionality for wrapping an underlying ERC721. | |
| 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. | |
| appVersion | No | Required when votes is enabled, for hashing and signing typed structured data. Version for domain separator implementing SNIP12Metadata trait. Prevents two versions of the same application from producing the same hash. | |
| 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. | |
| consecutive | No | Enables gas-efficient batch minting of consecutive token IDs during construction (ERC-2309). The contract owner must call `mint_consecutive` from the constructor to issue the initial batch. Cannot be combined with enumerable. | |
| royaltyInfo | No | Provides information for how much royalty is owed and to whom, based on a sale price. Follows ERC-2981 standard. | |
| upgradeable | No | Whether the smart contract is upgradeable. |
TDQS
A3.6/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 full behavioral burden. It does this well by disclosing the output format ('formatted in a Markdown code block') and explicitly stating 'Does not write to disk,' which clarifies the tool is a non-persistent source-code generator. It does not cover behavior on invalid or conflicting parameters, but the core side-effect profile 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 sentences with no filler: it front-loads the purpose, then states the return format and side-effect behavior. Every sentence adds distinct value.
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 code-generation tool with a rich input schema and no output schema, the description supplies the missing pieces: return format and lack of disk writes. It does not explicitly mention the target chain/language in the description, but the tool name and title cover that context. All functional parameters are already explained in the schema.
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 high (94%), so the input schema already provides strong parameter-level meaning. The description adds no parameter-specific details, which is acceptable under the high-coverage baseline of 3.
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 and resource: 'Make a non-fungible token per the ERC-721 standard,' and clarifies that it returns contract source code. It distinguishes the tool from ERC-20/ERC-1155 siblings by naming the standard, though it does not explicitly state 'Cairo' or reference sibling Solidity/Stylus ERC-721 tools, leaving some differentiation to the tool title/name.
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 alternatives such as solidity-erc721, stylus-erc721, or cairo-erc1155. No conditions, exclusions, or explicit alternative selection hints are provided; usage is only implied by the tool name and the ERC-721 standard mention.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
cairo-governorCairo 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, in readable date time format matching /^(\d+(?:\.\d+)?) +(second|minute|hour|day|week|month|year)s?$/, default is "1 day". | |
| votes | No | The type of voting to use. Either erc20votes, meaning voting power with a votes-enabled ERC20 token. Either erc721votes, meaning voting power with a votes-enabled ERC721 token. Voters can entrust their voting power to a delegate. | |
| macros | No | The macros to use for the contract. | |
| period | Yes | The length of period during which people can cast their vote, in readable date time format matching /^(\d+(?:\.\d+)?) +(second|minute|hour|day|week|month|year)s?$/, default is "1 week". | |
| appName | No | Required when votes is enabled, for hashing and signing typed structured data. Name for domain separator implementing SNIP12Metadata trait. Prevents two applications from producing the same hash. | |
| 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 | Whether to allow governance to update voting settings (delay, period, proposal threshold). | |
| timelock | No | Whether to add a delay to actions taken by the Governor. Gives users time to exit the system if they disagree with governance decisions. If "openzeppelin", Module compatible with OpenZeppelin's TimelockController. | |
| clockMode | No | The clock mode used by the voting token. For now, only timestamp mode where the token uses voting durations expressed as timestamps is supported. For Governor, this must be chosen to match what the ERC20 or ERC721 voting token uses. | |
| appVersion | No | Required when votes is enabled, for hashing and signing typed structured data. Version for domain separator implementing SNIP12Metadata trait. Prevents two versions of the same application from producing the same hash. | |
| quorumMode | No | The type of quorum mode to use, either by percentage or absolute value. | |
| upgradeable | No | Whether the smart contract is upgradeable. | |
| 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. |
TDQS
A4/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 full burden of behavioral disclosure. It transparently states that the tool returns source code formatted as a Markdown code block and explicitly says it does not write to disk. This is valuable context about side effects and output format, though it does not cover every possible behavioral nuance.
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 sentences long, front-loaded with the tool's purpose, and immediately follows with the key output behavior. Every sentence provides necessary information 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?
Given the tool's complexity (17 parameters, nested objects, no output schema), the description covers the essential contextual points: what it generates, the output format, and its non-destructive behavior. The absence of details about parameter interactions is mitigated by the rich schema descriptions. It is slightly lean for such a complex tool but still adequate.
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 schema already fully documents all 17 parameters. The description adds no parameter-specific meaning, which is acceptable given the high schema coverage. The baseline of 3 applies because the schema handles the heavy lifting.
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 a specific action: 'Make a contract to implement governance, such as for a DAO.' It also clarifies the output by noting it returns source code in a Markdown code block. This distinguishes the tool from sibling contract generators like cairo-erc20 or cairo-account by its governance focus.
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 phrase 'such as for a DAO' implies a governance use case, but no explicit comparison with alternatives or exclusions is provided. While the sibling tool names suggest other contract types, the description itself does not state when to prefer this tool over them.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
cairo-multisigCairo MultisigAInspect
Make a multi-signature smart contract, requiring a quorum of registered signers to approve and collectively execute transactions.
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 | |
| macros | No | The macros to use for the contract. | |
| quorum | Yes | The minimal number of confirmations required by the Multisig to approve a transaction. | |
| upgradeable | No | Whether the smart contract is upgradeable. |
TDQS
A4/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description provides crucial behavioral context: it returns source code in a Markdown code block and does not write to disk. This explicitly states the tool's side-effect-free nature, which is valuable for an agent deciding whether to invoke it. It doesn't mention input validation or edge cases, but for a code generator this is sufficient.
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 sentences, no filler, front-loaded with the core purpose. Each sentence adds value: the first states what the tool does, and the second clarifies the output format and side effects. Excellent conciseness.
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 code generation tool with 5 parameters and no output schema, the description provides the essential context: what it does, the output format, and that it doesn't write to disk. The schema covers parameter details, so the description is complete enough without explaining every field.
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?
All 5 parameters are documented in the schema (100% coverage), so the description adds little beyond the schema. The mention of quorum and signers provides some additional context, but the baseline of 3 is appropriate since the schema does the heavy lifting.
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 uses a specific verb ('Make') and resource ('multi-signature smart contract'), clearly distinguishing it from sibling contract generators. It also adds key details like quorum and signers, making the purpose unmistakable.
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 context is clear (generating a multisig contract), but there is no explicit guidance on when to choose this over alternatives like cairo-governor or cairo-custom. It implies usage but lacks when-not or alternative recommendations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
cairo-vestingCairo VestingAInspect
Make a vesting smart contract that manages the gradual release of ERC-20 tokens to a designated beneficiary based on a predefined vesting schedule.
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 | |
| macros | No | The macros to use for the contract. | |
| duration | Yes | The total duration of the vesting period. In readable date time format matching /^(\d+(?:\.\d+)?) +(second|minute|hour|day|week|month|year)s?$/ | |
| schedule | Yes | A vesting schedule implementation, tokens can either be vested gradually following a linear curve or with custom vesting schedule that requires the implementation of the VestingSchedule trait. | |
| startDate | Yes | The timestamp marking the beginning of the vesting period. In HTML input datetime-local format, e.g. "2026-03-15T14:30". | |
| cliffDuration | Yes | The duration of the cliff period. Must be less than or equal to the total duration. In readable date time format matching /^(\d+(?:\.\d+)?) +(second|minute|hour|day|week|month|year)s?$/ |
TDQS
A4/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 full burden. It discloses two important behaviors: the output is rendered as a Markdown code block and it does not write to disk. This goes beyond the basic purpose and gives the agent a clear picture of side-effects and return format, though it does not cover error cases or permission requirements.
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 sentences: the first states the purpose, the second states the output and side-effect. It is front-loaded, concise, and every sentence earns its place with no redundant 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?
The combination of the description and a very detailed input schema provides a solid understanding of the tool. The output format and non-persistence behavior are clearly specified. However, the description mentions a 'designated beneficiary' which is not represented as a parameter in the schema, creating a minor gap about how the beneficiary is configured. Otherwise, it is complete for a code generation tool.
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%, so all parameters are already described in detail (formats, enums, defaults). The description adds no additional parameter-specific meaning, only referencing a 'predefined vesting schedule' without elaborating on the schedule option. Baseline of 3 is appropriate because the schema does the heavy lifting.
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?
Purpose is highly specific: 'Make a vesting smart contract that manages the gradual release of ERC-20 tokens to a designated beneficiary based on a predefined vesting schedule.' This clearly distinguishes it from sibling contract generators (e.g., erc20, erc721) and includes the output format (Markdown source code) and side-effect (no disk write).
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 when to use the tool (when a vesting contract is needed), but it does not explicitly mention alternatives or exclusion criteria. Since sibling tools are all different contract types, the usage is clear by context but not explicitly stated, resulting in an implied rather than explicit guideline.
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.
1 tool update
- Changed
cairo-erc201 field changed- added
Input schema / properties / flashmintAdded value: +{ + "description": "Configuration object for the ERC20FlashMint extension (ERC-3156 flash loans). The extension is included only when `enabled` is true; the other fields tune the loan limit, fee, and fee destination.", + "properties": { + "enabled": { + "description": "Whether to include ERC20FlashMint functionality, allowing flash loans of tokens compliant with ERC-3156.", + "type": "boolean" + }, + "feeDestination": { + "default": "burn", + "description": "Where the flash loan fee is sent. 'burn' sends it to the zero address (effectively burning it). 'fee_receiver' adds a constructor argument that the deployer must populate with a non-zero address; the address is stored on-chain and validated at deploy time.", + "enum": [ + "burn", + "fee_receiver" + ], + "type": "string" + }, + "feeMode": { + "default": "percent", + "description": "Mode for the flash loan fee. 'percent' charges a percentage of the loaned amount (value provided via feePercent). 'custom' emits a TODO stub for the caller to implement.", + "enum": [ + "percent", + "custom" + ], + "type": "string" + }, + "feePercent": { + "default": "0", + "description": "Percentage of the loan amount charged as the flash loan fee. Number between 0 and 100, fractional values supported (e.g. \"0.0013725\"). Used when feeMode is 'percent'. Defaults to 0 (no fee).", + "type": "string" + }, + "maxAmount": { + "default": "max", + "description": "Maximum amount of tokens that can be flash-loaned in a single call. Use the literal string \"max\" to inherit the default (the maximum representable u256 minus the current total supply), or a non-negative number in the token's decimal units to set a custom cap. A value of 0 effectively disables flash loans without removing the extension.", + "type": "string" + } + }, + "required": [ + "enabled" + ], + "type": "object" +}
4 tool updates
- Changed
cairo-erc11552 fields changed- added
Input schema / properties / supplyAdded value: +{ + "description": "Whether to keep track of total supply of tokens.", + "type": "boolean" +} - added
Input schema / properties / uriStorageAdded value: +{ + "description": "Allows updating token URIs for individual token IDs.", + "type": "boolean" +}
- Changed
cairo-erc201 field changed- added
Input schema / properties / wrapperAdded value: +{ + "description": "Whether to include ERC20Wrapper functionality for depositing and withdrawing an underlying token.", + "type": "boolean" +}
- Added
cairo-erc6909 - Changed
cairo-erc7213 fields changed- added
Input schema / properties / consecutiveAdded value: +{ + "description": "Enables gas-efficient batch minting of consecutive token IDs during construction (ERC-2309). The contract owner must call `mint_consecutive` from the constructor to issue the initial batch. Cannot be combined with enumerable.", + "type": "boolean" +} - added
Input schema / properties / uriStorageAdded value: +{ + "description": "Allows updating token URIs for individual token IDs.", + "type": "boolean" +} - added
Input schema / properties / wrapperAdded value: +{ + "description": "Whether to include ERC721Wrapper functionality for wrapping an underlying ERC721.", + "type": "boolean" +}
5 tool updates
- Changed
cairo-custom8 fields changed- added
Input schema / properties / access / properties / darDefaultDelayIncrease / defaultAdded value: +"5 days" - changed
Input schema / properties / access / properties / darDefaultDelayIncrease / descriptionPrevious value: -"The default delay increase in seconds for the default admin role (in case Roles (Default Admin Rules) is used)."New value: +"The default delay increase for the default admin role (in case Roles (Default Admin Rules) is used). Default is \"5 days\"." - added
Input schema / properties / access / properties / darInitialDelay / defaultAdded value: +"1 day" - changed
Input schema / properties / access / properties / darInitialDelay / descriptionPrevious value: -"The initial delay for the default admin role (in case Roles (Default Admin Rules) is used)."New value: +"The initial delay for the default admin role (in case Roles (Default Admin Rules) is used). Default is \"1 day\"." - added
Input schema / properties / access / properties / darMaxTransferDelay / defaultAdded value: +"30 days" - changed
Input schema / properties / access / properties / darMaxTransferDelay / descriptionPrevious value: -"The maximum delay in seconds for a default admin transfer (in case Roles (Default Admin Rules) is used)."New value: +"The maximum delay for a default admin transfer (in case Roles (Default Admin Rules) is used). Default is \"30 days\"." - changed
Input schema / properties / access / requiredPrevious value: -[ - "type", - "darInitialDelay", - "darDefaultDelayIncrease", - "darMaxTransferDelay" -]New value: +[ + "type" +] - changed
Input schema / requiredPrevious value: -[ - "name", - "access" -]New value: +[ + "name" +]
- Changed
cairo-erc11558 fields changed- added
Input schema / properties / access / properties / darDefaultDelayIncrease / defaultAdded value: +"5 days" - changed
Input schema / properties / access / properties / darDefaultDelayIncrease / descriptionPrevious value: -"The default delay increase in seconds for the default admin role (in case Roles (Default Admin Rules) is used)."New value: +"The default delay increase for the default admin role (in case Roles (Default Admin Rules) is used). Default is \"5 days\"." - added
Input schema / properties / access / properties / darInitialDelay / defaultAdded value: +"1 day" - changed
Input schema / properties / access / properties / darInitialDelay / descriptionPrevious value: -"The initial delay for the default admin role (in case Roles (Default Admin Rules) is used)."New value: +"The initial delay for the default admin role (in case Roles (Default Admin Rules) is used). Default is \"1 day\"." - added
Input schema / properties / access / properties / darMaxTransferDelay / defaultAdded value: +"30 days" - changed
Input schema / properties / access / properties / darMaxTransferDelay / descriptionPrevious value: -"The maximum delay in seconds for a default admin transfer (in case Roles (Default Admin Rules) is used)."New value: +"The maximum delay for a default admin transfer (in case Roles (Default Admin Rules) is used). Default is \"30 days\"." - changed
Input schema / properties / access / requiredPrevious value: -[ - "type", - "darInitialDelay", - "darDefaultDelayIncrease", - "darMaxTransferDelay" -]New value: +[ + "type" +] - changed
Input schema / requiredPrevious value: -[ - "name", - "baseUri", - "access" -]New value: +[ + "name", + "baseUri" +]
- Changed
cairo-erc208 fields changed- added
Input schema / properties / access / properties / darDefaultDelayIncrease / defaultAdded value: +"5 days" - changed
Input schema / properties / access / properties / darDefaultDelayIncrease / descriptionPrevious value: -"The default delay increase in seconds for the default admin role (in case Roles (Default Admin Rules) is used)."New value: +"The default delay increase for the default admin role (in case Roles (Default Admin Rules) is used). Default is \"5 days\"." - added
Input schema / properties / access / properties / darInitialDelay / defaultAdded value: +"1 day" - changed
Input schema / properties / access / properties / darInitialDelay / descriptionPrevious value: -"The initial delay for the default admin role (in case Roles (Default Admin Rules) is used)."New value: +"The initial delay for the default admin role (in case Roles (Default Admin Rules) is used). Default is \"1 day\"." - added
Input schema / properties / access / properties / darMaxTransferDelay / defaultAdded value: +"30 days" - changed
Input schema / properties / access / properties / darMaxTransferDelay / descriptionPrevious value: -"The maximum delay in seconds for a default admin transfer (in case Roles (Default Admin Rules) is used)."New value: +"The maximum delay for a default admin transfer (in case Roles (Default Admin Rules) is used). Default is \"30 days\"." - changed
Input schema / properties / access / requiredPrevious value: -[ - "type", - "darInitialDelay", - "darDefaultDelayIncrease", - "darMaxTransferDelay" -]New value: +[ + "type" +] - changed
Input schema / requiredPrevious value: -[ - "name", - "symbol", - "access" -]New value: +[ + "name", + "symbol" +]
- Changed
cairo-erc7218 fields changed- added
Input schema / properties / access / properties / darDefaultDelayIncrease / defaultAdded value: +"5 days" - changed
Input schema / properties / access / properties / darDefaultDelayIncrease / descriptionPrevious value: -"The default delay increase in seconds for the default admin role (in case Roles (Default Admin Rules) is used)."New value: +"The default delay increase for the default admin role (in case Roles (Default Admin Rules) is used). Default is \"5 days\"." - added
Input schema / properties / access / properties / darInitialDelay / defaultAdded value: +"1 day" - changed
Input schema / properties / access / properties / darInitialDelay / descriptionPrevious value: -"The initial delay for the default admin role (in case Roles (Default Admin Rules) is used)."New value: +"The initial delay for the default admin role (in case Roles (Default Admin Rules) is used). Default is \"1 day\"." - added
Input schema / properties / access / properties / darMaxTransferDelay / defaultAdded value: +"30 days" - changed
Input schema / properties / access / properties / darMaxTransferDelay / descriptionPrevious value: -"The maximum delay in seconds for a default admin transfer (in case Roles (Default Admin Rules) is used)."New value: +"The maximum delay for a default admin transfer (in case Roles (Default Admin Rules) is used). Default is \"30 days\"." - changed
Input schema / properties / access / requiredPrevious value: -[ - "type", - "darInitialDelay", - "darDefaultDelayIncrease", - "darMaxTransferDelay" -]New value: +[ + "type" +] - changed
Input schema / requiredPrevious value: -[ - "name", - "symbol", - "access" -]New value: +[ + "name", + "symbol" +]
- Changed
cairo-vesting1 field changed- changed
Input schema / properties / startDate / descriptionPrevious value: -"The timestamp marking the beginning of the vesting period. In HTML input datetime-local format"New value: +"The timestamp marking the beginning of the vesting period. In HTML input datetime-local format, e.g. \"2026-03-15T14:30\"."
8 tool updates
- First observed
cairo-account - First observed
cairo-custom - First observed
cairo-erc1155 - First observed
cairo-erc20 - First observed
cairo-erc721 - First observed
cairo-governor - First observed
cairo-multisig - First observed
cairo-vesting
Related MCP Connectors
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.
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.
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.
MCP server for secureFlows: token-free URL builders and integration-linting tools for AI agents.
Related MCP Servers
- 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
- 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.-
- AlicenseAqualityBmaintenanceAn 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
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.