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.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 3.3/5 across 8 of 8 tools scored.
Each tool has a clearly distinct purpose targeting specific contract types or standards. The solidity-account, solidity-erc1155, solidity-erc20, solidity-erc721, solidity-governor, solidity-rwa, and solidity-stablecoin tools each generate contracts for different ERC standards or use cases, while solidity-custom serves as a general-purpose fallback. There is no ambiguity about which tool to use for a given contract generation task.
All tool names follow a perfectly consistent 'solidity-' prefix pattern followed by a descriptive suffix indicating the contract type. This uniform naming convention makes it easy to understand the tool's purpose at a glance and ensures predictability across the entire toolset.
With 8 tools, this server is well-scoped for generating various types of Solidity contracts. Each tool serves a distinct purpose covering major ERC standards (ERC-20, ERC-721, ERC-1155), specialized contracts (account, governor), and experimental variants (RWA, stablecoin), plus a custom option. The count is neither too sparse nor overwhelming for the domain.
The toolset provides excellent coverage for generating contracts following major ERC standards and common use cases like governance, with a custom option for flexibility. A minor gap exists in not explicitly covering other contract types like access control or upgradeable contracts, but the solidity-custom tool can help work around this, and the core domain of standard contract generation is well-covered.
Available Tools
8 toolssolidity-accountBInspect
Make an account contract that follows the ERC-4337 standard.
Returns the source code of the generated contract, formatted in a Markdown code block. Does not write to disk.
| Name | Required | Description | Default |
|---|---|---|---|
| info | No | Metadata about the contract and author | |
| name | Yes | The name of the account contract | |
| signer | No | Defines the signature verification algorithm used by the account to verify user operations. Options: - ECDSA: Standard Ethereum signature validation using secp256k1, validates signatures against a specified owner address - EIP7702: Special ECDSA validation using account's own address as signer, enables EOAs to delegate execution rights - Multisig: ERC-7913 multisignature requiring minimum number of signatures from authorized signers - MultisigWeighted: ERC-7913 weighted multisignature where signers have different voting weights - P256: NIST P-256 curve (secp256r1) validation for integration with Passkeys and HSMs - RSA: RSA PKCS#1 v1.5 signature validation (RFC8017) for PKI systems and HSMs - WebAuthn: Web Authentication (WebAuthn) assertion validation for integration with Passkeys and HSMs on top of P256 | |
| upgradeable | No | Whether the smart contract is upgradeable. Transparent uses more complex proxy with higher overhead, requires less changes in your contract. Can also be used with beacons. UUPS uses simpler proxy with less overhead, requires including extra code in your contract. Allows flexibility for authorizing upgrades. | |
| ERC721Holder | No | Whether to implement the `onERC721Received` function to allow the account to receive ERC721 tokens. | |
| ERC1155Holder | No | Whether to implement the `onERC1155Received` function to allow the account to receive ERC1155 tokens. | |
| ERC7579Modules | No | Whether to implement the ERC-7579 compatibility to enable functionality on the account with modules. | |
| batchedExecution | No | Whether to implement a minimal batching interface for the account to allow multiple operations to be executed in a single transaction following the ERC-7821 standard. | |
| signatureValidation | No | Whether to implement the ERC-1271 standard for validating signatures. This is useful for the account to verify signatures. |
Tool Definition Quality
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 adds some useful context: it specifies that output is 'formatted in a Markdown code block' and 'Does not write to disk,' clarifying the tool's read-only nature and output format. However, it lacks details on potential limitations (e.g., rate limits, error conditions, or dependencies), which would be helpful for a tool generating complex smart contracts. No contradictions with annotations exist (since none are provided).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded, with two sentences that directly state the tool's purpose and output behavior. There's no unnecessary fluff, and each sentence adds value: the first defines the core function, and the second clarifies output format and disk interaction. It could be slightly improved by integrating usage hints, but it's efficiently structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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, no output schema, no annotations), the description is moderately complete. It covers the basic purpose and output format but lacks details on error handling, performance considerations, or integration with sibling tools. The absence of an output schema means the description doesn't explain return values beyond 'source code in a Markdown code block,' which is a gap. It's adequate for a minimal viable description but has clear room for improvement in guiding effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, meaning all parameters are well-documented in the schema itself. The description adds no parameter-specific information beyond what's in the schema (e.g., it doesn't explain default values, interactions between parameters like 'signer' and 'signatureValidation', or typical configurations). Given the high schema coverage, a baseline score of 3 is appropriate, as the description doesn't enhance parameter understanding but doesn't need to compensate for gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Make an account contract that follows the ERC-4337 standard.' It specifies the verb ('Make'), resource ('account contract'), and standard ('ERC-4337'), making the purpose unambiguous. However, it doesn't explicitly differentiate this tool from its siblings (like solidity-custom or solidity-erc20), which would be needed for a score of 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides minimal usage guidance. It mentions that the tool 'Returns the source code... Does not write to disk,' which gives some context about output behavior, but offers no explicit guidance on when to use this tool versus alternatives (e.g., solidity-custom for non-ERC-4337 contracts or other sibling tools for different contract types). There's no mention of prerequisites, typical use cases, or comparisons to other tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
solidity-customBInspect
Make a custom smart contract.
Returns the source code of the generated contract, formatted in a Markdown code block. Does not write to disk.
| Name | Required | Description | Default |
|---|---|---|---|
| info | No | Metadata about the contract and author | |
| name | Yes | The name of the contract | |
| access | No | The type of access control to provision. Ownable is a simple mechanism with a single account authorized for all privileged actions. Roles is a flexible mechanism with a separate role for each privileged action. A role can have many authorized accounts. Managed enables a central contract to define a policy that allows certain callers to access certain functions. | |
| pausable | No | Whether privileged accounts will be able to pause specifically marked functionality. Useful for emergency response. | |
| upgradeable | No | Whether the smart contract is upgradeable. Transparent uses more complex proxy with higher overhead, requires less changes in your contract. Can also be used with beacons. UUPS uses simpler proxy with less overhead, requires including extra code in your contract. Allows flexibility for authorizing upgrades. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses key behavioral traits: it 'Returns the source code... formatted in a Markdown code block' and 'Does not write to disk,' clarifying output format and non-persistent nature. However, it lacks details on permissions, rate limits, error handling, or contract validation, leaving gaps for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with two sentences that are front-loaded and waste-free. The first sentence states the core purpose, and the second adds critical behavioral details about output format and non-persistence. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (5 parameters, nested objects, no output schema) and lack of annotations, the description is minimally adequate. It covers purpose and key behaviors but misses usage context, error handling, and deeper integration details. It's complete enough to understand basics but insufficient for optimal agent decision-making.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents all 5 parameters. The description adds no parameter-specific information beyond what's in the schema. Baseline is 3 since the schema does the heavy lifting, but the description doesn't compensate with additional context like examples or constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Make a custom smart contract' specifies the verb and resource. It distinguishes from siblings by focusing on custom contracts rather than predefined templates like ERC20 or ERC721. However, it doesn't explicitly contrast with all sibling tools, keeping it at 4 instead of 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus its siblings. It mentions 'custom smart contract' but doesn't explain scenarios where custom contracts are preferred over the predefined templates listed as siblings. There's no mention of prerequisites, alternatives, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
solidity-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.
| 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 |
Tool Definition Quality
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 adds some useful context: it specifies that the tool 'Returns the source code of the generated contract, formatted in a Markdown code block' and 'Does not write to disk,' clarifying the output format and that it's a read-only generation tool (not a deployment tool). However, it doesn't mention potential side effects, error conditions, or performance considerations, which are gaps for a tool with 10 parameters and no annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is highly concise and well-structured, consisting of two sentences that efficiently convey the core functionality and output behavior. The first sentence states the purpose, and the second adds crucial behavioral details (return format and no disk writing). There is no wasted verbiage, making it easy for an AI agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (10 parameters, nested objects) and lack of annotations or output schema, the description is moderately complete. It covers the tool's purpose and key behavioral traits (output format and read-only nature), but it doesn't address error handling, validation rules, or how parameters interact (e.g., implications of choosing certain access control or upgradeable options). For a tool with significant parameter complexity, more context would be beneficial to ensure correct usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, meaning all parameters are well-documented in the input schema itself. The description adds minimal parameter semantics beyond the schema—it only implies parameters related to token creation (e.g., 'non-fungible token' hints at name and URI). Since the schema does the heavy lifting, the baseline score of 3 is appropriate, as the description doesn't significantly enhance understanding of the parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Make a non-fungible token per the ERC-1155 standard.' It specifies the verb ('Make'), resource ('non-fungible token'), and standard ('ERC-1155'), which is specific and actionable. However, it doesn't explicitly differentiate from sibling tools like solidity-erc20 or solidity-erc721, which also create tokens but for different standards, leaving some ambiguity about when to choose this specific tool over others.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It mentions the ERC-1155 standard but doesn't explain why one might choose ERC-1155 over ERC-20 or ERC-721 from the sibling tools, nor does it outline prerequisites or exclusions. This lack of contextual guidance makes it harder for an AI agent to select this tool appropriately among the available options.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
solidity-erc20AInspect
Make a fungible token per the ERC-20 standard.
Returns the source code of the generated contract, formatted in a Markdown code block. Does not write to disk.
| Name | Required | Description | Default |
|---|---|---|---|
| info | No | Metadata about the contract and author | |
| name | Yes | The name of the contract | |
| votes | No | Whether to keep track of historical balances for voting in on-chain governance. Voting durations can be expressed as block numbers or timestamps. | |
| access | No | The type of access control to provision. Ownable is a simple mechanism with a single account authorized for all privileged actions. Roles is a flexible mechanism with a separate role for each privileged action. A role can have many authorized accounts. Managed enables a central contract to define a policy that allows certain callers to access certain functions. | |
| permit | No | Whether without paying gas, token holders will be able to allow third parties to transfer from their account. | |
| symbol | Yes | The short symbol for the token | |
| premint | No | The number of tokens to premint for the deployer. | |
| burnable | No | Whether token holders will be able to destroy their tokens | |
| callback | No | Whether to include support for code execution after transfers and approvals on recipient contracts in a single transaction. | |
| mintable | No | Whether privileged accounts will be able to create more supply or emit more tokens | |
| pausable | No | Whether privileged accounts will be able to pause specifically marked functionality. Useful for emergency response. | |
| flashmint | No | Whether to include built-in flash loans to allow lending tokens without requiring collateral as long as they're returned in the same transaction. | |
| upgradeable | No | Whether the smart contract is upgradeable. Transparent uses more complex proxy with higher overhead, requires less changes in your contract. Can also be used with beacons. UUPS uses simpler proxy with less overhead, requires including extra code in your contract. Allows flexibility for authorizing upgrades. | |
| premintChainId | No | The chain ID of the network on which to premint tokens. | |
| namespacePrefix | No | The prefix for ERC-7201 namespace identifiers. It should be derived from the project name or a unique naming convention specific to the project. Used only if the contract includes storage variables and upgradeability is enabled. Default is "myProject". | |
| crossChainBridging | No | Whether to allow authorized bridge contracts to mint and burn tokens for cross-chain transfers. Options are to use custom bridges on any chain, 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". |
Tool Definition Quality
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 usefully states the output format ('Returns the source code... in a Markdown code block') and clarifies a key limitation ('Does not write to disk'), but omits other important behaviors like error handling, performance characteristics, or authentication requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with only two sentences, both of which earn their place by stating the core purpose and critical behavioral constraint. It is front-loaded with the main function and wastes no words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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, no annotations, no output schema), the description is minimal. It covers the basic purpose and output format but lacks details on error cases, performance, or integration context, making it adequate but incomplete for such a parameter-rich tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents all 17 parameters. The description adds no parameter-specific information beyond what the schema provides, maintaining the baseline score of 3 for adequate but non-enhancing coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Make a fungible token') and resource ('per the ERC-20 standard'), distinguishing it from sibling tools like solidity-erc721 (non-fungible tokens) or solidity-stablecoin (specialized token type). It precisely defines the tool's function without redundancy.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like solidity-custom or solidity-erc1155, nor does it mention prerequisites or context for generating ERC-20 tokens. It lacks explicit usage instructions or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
solidity-erc721BInspect
Make a non-fungible token per the ERC-721 standard.
Returns the source code of the generated contract, formatted in a Markdown code block. Does not write to disk.
| Name | Required | Description | Default |
|---|---|---|---|
| info | No | Metadata about the contract and author | |
| name | Yes | The name of the contract | |
| votes | No | Whether to keep track of individual units for voting in on-chain governance. Voting durations can be expressed as block numbers or timestamps (defaulting to block number if not specified). | |
| access | No | The type of access control to provision. Ownable is a simple mechanism with a single account authorized for all privileged actions. Roles is a flexible mechanism with a separate role for each privileged action. A role can have many authorized accounts. Managed enables a central contract to define a policy that allows certain callers to access certain functions. | |
| symbol | Yes | The short symbol for the token | |
| baseUri | No | A base uri for the token | |
| burnable | No | Whether token holders will be able to destroy their tokens | |
| mintable | No | Whether privileged accounts will be able to create more supply or emit more tokens | |
| pausable | No | Whether privileged accounts will be able to pause specifically marked functionality. Useful for emergency response. | |
| enumerable | No | Whether to allow on-chain enumeration of all tokens or those owned by an account. Increases gas cost of transfers. | |
| uriStorage | No | Allows updating token URIs for individual token IDs | |
| incremental | No | Whether new tokens will be automatically assigned an incremental id | |
| upgradeable | No | Whether the smart contract is upgradeable. Transparent uses more complex proxy with higher overhead, requires less changes in your contract. Can also be used with beacons. UUPS uses simpler proxy with less overhead, requires including extra code in your contract. Allows flexibility for authorizing upgrades. | |
| namespacePrefix | No | The prefix for ERC-7201 namespace identifiers. It should be derived from the project name or a unique naming convention specific to the project. Used only if the contract includes storage variables and upgradeability is enabled. Default is "myProject". |
Tool Definition Quality
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 adds some value by stating the output format ('Returns the source code... formatted in a Markdown code block') and clarifying that it 'Does not write to disk,' which indicates it's a generation tool without side effects. However, it lacks details on permissions, rate limits, error handling, or other behavioral traits, making it only moderately transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is highly concise and well-structured, consisting of only two sentences that efficiently convey the core functionality and output behavior. Every sentence earns its place by providing essential information without redundancy, making it front-loaded and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (14 parameters, no annotations, no output schema), the description is somewhat incomplete. It covers the basic purpose and output format but lacks details on when to use it, behavioral constraints, or how parameters interact. While the schema handles parameter documentation, the description doesn't fully address the tool's context, especially for a code-generation tool with many options.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, so the schema already documents all 14 parameters thoroughly. The description doesn't add any parameter-specific information beyond what's in the schema, such as explaining relationships between parameters or usage examples. Given the high schema coverage, the baseline score of 3 is appropriate, as the description doesn't compensate but also doesn't detract.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Make a non-fungible token per the ERC-721 standard.' It specifies the verb ('Make') and resource ('non-fungible token'), and mentions the standard. However, it doesn't explicitly differentiate from sibling tools like 'solidity-erc1155' or 'solidity-erc20', which are also token standards, so it doesn't fully distinguish from alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides minimal usage guidance. It mentions that the tool 'Returns the source code... Does not write to disk,' which hints at output behavior but doesn't specify when to use this tool versus alternatives like 'solidity-erc1155' or 'solidity-erc20'. No explicit context, prerequisites, or exclusions are provided, leaving the agent with little guidance on tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
solidity-governorBInspect
Make a contract to implement governance, such as for a DAO.
Returns the source code of the generated contract, formatted in a Markdown code block. Does not write to disk.
| Name | Required | Description | Default |
|---|---|---|---|
| info | No | Metadata about the contract and author | |
| name | Yes | The name of the contract | |
| delay | Yes | The delay since proposal is created until voting starts, default is "1 day" | |
| votes | No | The type of voting to use | |
| period | Yes | The length of period during which people can cast their vote, default is "1 week" | |
| storage | No | Enable storage of proposal details and enumerability of proposals | |
| decimals | No | The number of decimals to use for the contract, default is 18 for ERC20Votes and 0 for ERC721Votes (because it does not apply to ERC721Votes) | |
| settings | No | Allow governance to update voting settings (delay, period, proposal threshold) | |
| timelock | No | The type of timelock to use | |
| blockTime | No | The block time of the chain, 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. |
Tool Definition Quality
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 states the tool 'Returns the source code... Does not write to disk,' which clarifies it's a generation-only tool without side effects. However, it doesn't mention important behavioral aspects like whether it requires authentication, rate limits, error conditions, or what happens with invalid inputs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise and front-loaded with essential information in just two sentences. Every word earns its place: the first sentence states the purpose, the second describes the output format and important behavioral constraint ('Does not write to disk'). No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex tool with 16 parameters and no annotations or output schema, the description is minimal. It covers the basic purpose and output format but lacks crucial context about the governance implementation specifics, relationship between parameters, or what constitutes a valid contract configuration. The 100% schema coverage helps, but the description itself doesn't provide enough guidance for optimal tool selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so parameters are well-documented in the schema. The description adds no parameter-specific information beyond what's in the schema. It mentions the output format ('Returns the source code... formatted in a Markdown code block'), but this relates to output rather than input parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Make a contract to implement governance, such as for a DAO.' It specifies the verb ('Make'), resource ('contract'), and domain ('governance/DAO'). However, it doesn't explicitly differentiate from sibling tools like solidity-custom or solidity-account, which might also generate contracts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It mentions 'such as for a DAO' which gives some context, but offers no explicit when/when-not rules, prerequisites, or comparisons to sibling tools like solidity-custom that might also handle contract generation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
solidity-rwaBInspect
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.
| Name | Required | Description | Default |
|---|---|---|---|
| info | No | Metadata about the contract and author | |
| name | Yes | The name of the contract | |
| votes | No | Whether to keep track of historical balances for voting in on-chain governance. Voting durations can be expressed as block numbers or timestamps. | |
| access | No | The type of access control to provision. Ownable is a simple mechanism with a single account authorized for all privileged actions. Roles is a flexible mechanism with a separate role for each privileged action. A role can have many authorized accounts. Managed enables a central contract to define a policy that allows certain callers to access certain functions. | |
| permit | No | Whether without paying gas, token holders will be able to allow third parties to transfer from their account. | |
| symbol | Yes | The short symbol for the token | |
| premint | No | The number of tokens to premint for the deployer. | |
| burnable | No | Whether token holders will be able to destroy their tokens | |
| callback | No | Whether to include support for code execution after transfers and approvals on recipient contracts in a single transaction. | |
| mintable | No | Whether privileged accounts will be able to create more supply or emit more tokens | |
| pausable | No | Whether privileged accounts will be able to pause specifically marked functionality. Useful for emergency response. | |
| flashmint | No | Whether to include built-in flash loans to allow lending tokens without requiring collateral as long as they're returned in the same transaction. | |
| freezable | No | Whether authorized accounts can freeze and unfreeze accounts for regulatory or security purposes. This feature is experimental, not audited and is subject to change. | |
| restrictions | No | Whether to restrict certain users from transferring tokens, either via allowing or blocking them. This feature is experimental, not audited and is subject to change. | |
| premintChainId | No | The chain ID of the network on which to premint tokens. | |
| namespacePrefix | No | The prefix for ERC-7201 namespace identifiers. It should be derived from the project name or a unique naming convention specific to the project. Used only if the contract includes storage variables and upgradeability is enabled. Default is "myProject". | |
| crossChainBridging | No | Whether to allow authorized bridge contracts to mint and burn tokens for cross-chain transfers. Options are to use custom bridges on any chain, 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". |
Tool Definition Quality
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 adds some context: it states the tool is experimental and not fully audited, and specifies that it 'Returns the source code... Does not write to disk.' This clarifies output format and non-destructive behavior. However, it lacks details on permissions, rate limits, or error handling, leaving gaps for a tool with many parameters.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded, with three sentences that efficiently convey purpose, experimental nature, and output behavior. There is no wasted text, and each sentence adds value. However, it could be slightly more structured by explicitly separating concerns like usage warnings.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (18 parameters, no output schema, no annotations), the description is somewhat incomplete. It covers purpose and output format but lacks guidance on when to use, detailed behavioral traits, or integration with sibling tools. For a tool generating smart contracts with many options, more context on implications of features like 'experimental' would be beneficial.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all 18 parameters thoroughly. The description does not add any parameter-specific information beyond what the schema provides, such as examples or usage tips. Baseline score of 3 is appropriate as the schema handles the heavy lifting, but the description does not compensate with extra insights.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Make a real-world asset token that uses the ERC-20 standard.' It specifies the verb ('Make'), resource ('real-world asset token'), and standard ('ERC-20'). However, it does not explicitly differentiate from sibling tools like 'solidity-erc20', which might also generate ERC-20 tokens, leaving some ambiguity about uniqueness.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides minimal usage guidance. It mentions the tool is 'Experimental, some features are not audited and are subject to change,' which hints at caution but does not specify when to use this tool versus alternatives like 'solidity-erc20' or other siblings. No explicit alternatives, prerequisites, or exclusions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
solidity-stablecoinBInspect
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.
| Name | Required | Description | Default |
|---|---|---|---|
| info | No | Metadata about the contract and author | |
| name | Yes | The name of the contract | |
| votes | No | Whether to keep track of historical balances for voting in on-chain governance. Voting durations can be expressed as block numbers or timestamps. | |
| access | No | The type of access control to provision. Ownable is a simple mechanism with a single account authorized for all privileged actions. Roles is a flexible mechanism with a separate role for each privileged action. A role can have many authorized accounts. Managed enables a central contract to define a policy that allows certain callers to access certain functions. | |
| permit | No | Whether without paying gas, token holders will be able to allow third parties to transfer from their account. | |
| symbol | Yes | The short symbol for the token | |
| premint | No | The number of tokens to premint for the deployer. | |
| burnable | No | Whether token holders will be able to destroy their tokens | |
| callback | No | Whether to include support for code execution after transfers and approvals on recipient contracts in a single transaction. | |
| mintable | No | Whether privileged accounts will be able to create more supply or emit more tokens | |
| pausable | No | Whether privileged accounts will be able to pause specifically marked functionality. Useful for emergency response. | |
| flashmint | No | Whether to include built-in flash loans to allow lending tokens without requiring collateral as long as they're returned in the same transaction. | |
| freezable | No | Whether authorized accounts can freeze and unfreeze accounts for regulatory or security purposes. This feature is experimental, not audited and is subject to change. | |
| restrictions | No | Whether to restrict certain users from transferring tokens, either via allowing or blocking them. This feature is experimental, not audited and is subject to change. | |
| premintChainId | No | The chain ID of the network on which to premint tokens. | |
| namespacePrefix | No | The prefix for ERC-7201 namespace identifiers. It should be derived from the project name or a unique naming convention specific to the project. Used only if the contract includes storage variables and upgradeability is enabled. Default is "myProject". | |
| crossChainBridging | No | Whether to allow authorized bridge contracts to mint and burn tokens for cross-chain transfers. Options are to use custom bridges on any chain, 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". |
Tool Definition Quality
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 adds some context: it states the tool is 'Experimental' and that features are 'not audited and are subject to change,' which warns about reliability and stability. It also specifies that it 'Returns the source code... Does not write to disk,' clarifying the output format and non-destructive nature. However, it lacks details on permissions, rate limits, or error handling, which are important for a code-generation tool with many parameters.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded, with three sentences that efficiently convey key information: the tool's purpose, experimental nature, and output behavior. There is no wasted text, and each sentence adds value, such as the warning about features being unaudited and the clarification that it doesn't write to disk. It could be slightly improved by structuring usage hints more explicitly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (18 parameters, no output schema, and no annotations), the description is moderately complete. It covers the purpose, experimental status, and output format, but lacks guidance on when to use it versus siblings, detailed behavioral traits like error handling, and any prerequisites for use. With no output schema, it doesn't explain return values beyond 'source code in a Markdown code block,' which is minimal but sufficient for the stated output.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, so the schema already documents all 18 parameters thoroughly. The description does not add any parameter-specific information beyond what's in the schema, such as explaining how parameters interact or providing examples. Since schema coverage is high, the baseline score is 3, as the description doesn't compensate but also doesn't detract from the schema's completeness.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Make a stablecoin token that uses the ERC-20 standard.' It specifies the verb ('Make'), resource ('stablecoin token'), and standard ('ERC-20'). However, it doesn't explicitly differentiate from sibling tools like 'solidity-erc20' or 'solidity-custom', which might also generate ERC-20 tokens, leaving some ambiguity about when to choose this over others.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides minimal usage guidance. It mentions the tool is 'Experimental, some features are not audited and are subject to change,' which hints at caution but doesn't specify when to use this tool versus alternatives like 'solidity-erc20' for non-stablecoin tokens or 'solidity-custom' for other contract types. No explicit when-to-use or when-not-to-use scenarios are provided, leaving the agent with little direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!