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.
- 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.8/5 across 8 of 8 tools scored. Lowest: 3.2/5.
Each tool generates a distinct contract type (account, ERC20, ERC721, etc.) with no functional overlap. An agent can easily select the correct tool for the desired contract.
All tools follow the 'cairo-{type}' naming convention uniformly, making the tool set predictable and easy to navigate for both agents and humans.
8 tools cover the most common smart contract patterns without being excessive. The count is well-scoped for a generative server focused on OpenZeppelin Cairo contracts.
Covers major contract types (tokens, governance, multisig, vesting) but lacks some common ones like access control or upgradeable contracts. Minor gap but core functionality is present.
Available Tools
8 toolscairo-accountBInspect
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.
| 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. |
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 specifies that the tool 'Returns the source code of the generated contract, formatted in a Markdown code block' and 'Does not write to disk,' which clarifies output format and non-destructive behavior. However, it lacks details on permissions, rate limits, error handling, or deployment implications, leaving gaps for a tool that generates deployable smart contracts.
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 appropriately sized and front-loaded, with the core purpose stated first. The two sentences are efficient: the first defines the tool's function, and the second clarifies output format and non-destructive behavior. There's minimal waste, though it could be slightly more structured (e.g., separating usage notes).
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 behavior but lacks depth on when to use it, how parameters interact, or what the generated contract entails. Without annotations or output schema, more guidance on behavioral traits and expected outcomes would improve completeness for a smart contract generation 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 already documents all 9 parameters thoroughly. The description adds no parameter-specific information beyond what the schema provides (e.g., it doesn't explain how 'type' affects contract behavior or what 'deploy' entails). Baseline 3 is appropriate as the schema does the heavy lifting, but the description doesn't compensate with additional semantic 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 custom smart contract that represents an account that can be deployed and interacted with other contracts, and can be extended to implement custom logic.' It specifies the verb ('Make'), resource ('custom smart contract'), and type ('account'), distinguishing it from sibling tools like erc20 or erc721. However, it doesn't explicitly differentiate from 'cairo-custom' or 'cairo-multisig', which might also involve account-like 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 minimal usage guidance. It mentions that the account 'can be deployed and interacted with other contracts' and 'can be extended to implement custom logic,' but offers no explicit when-to-use criteria, prerequisites, or alternatives. For example, it doesn't clarify when to choose this over 'cairo-multisig' or 'cairo-custom,' or what scenarios warrant its use versus other account types.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
cairo-customAInspect
Make a custom smart contract.
Returns the source code of the generated contract, formatted in a Markdown code block. Does not write to disk.
| Name | Required | Description | Default |
|---|---|---|---|
| info | No | Metadata about the contract and author | |
| name | Yes | The name of the contract | |
| access | No | ||
| 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. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It clearly states the tool does not write to disk, indicating it is a read-only generation. It specifies the output format (Markdown code block). However, it does not mention any potential side effects or required permissions, though for a generation tool 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of two short sentences that front-load the purpose. It contains no extraneous words and is highly efficient. Every sentence adds value: the first defines the action and the second clarifies the output and safety.
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 lack of an output schema, the description explains the return format (Markdown code block) and notes it does not write to disk, covering key behavioral aspects. It does not discuss error scenarios or validation, but for a code generation tool this is adequate. Sibling names provide context that this is for custom contracts.
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 83%, so the schema provides detailed descriptions for most parameters. The tool description does not add additional context beyond what is in the schema. For example, it could explain that the 'access' parameter affects the generated code's security model, but it relies on the schema. Therefore, a score of 3 (baseline) is appropriate.
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 uses the verb 'make' which is somewhat generic, but it clearly states that it generates a custom smart contract and returns the source code in a Markdown code block. It distinguishes from sibling tools (specific contract types like erc20, account) by implying this is for custom contracts not covered by those templates.
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?
No explicit guidance on when to use this tool versus alternatives. The sibling tools cover specific contract types (e.g., cairo-erc20), but the description does not mention that this tool is for cases where none of those templates fit. No exclusions or prerequisites are described.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
cairo-erc1155AInspect
Make a non-fungible token per the ERC-1155 standard.
Returns the source code of the generated contract, formatted in a Markdown code block. Does not write to disk.
| Name | Required | Description | Default |
|---|---|---|---|
| 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. | |
| 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. | |
| 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. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses two key behaviors: returns source code in a Markdown code block and does not write to disk. With no annotations available, it effectively communicates the non-destructive, output-only nature. However, it leaves out details about any prerequisites, authentication, or side effects, 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no filler. The first sentence states the core purpose, and the second adds crucial behavioral details (returns code, no disk write). Every sentence adds value.
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 (11 parameters, nested objects, no output schema), the description adequately explains the output format and side-effect-free behavior. It could mention that parameters customize the contract, but the schema provides that detail, so the description is reasonably complete.
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 coverage is high (91%), so the description does not need to add much parameter detail. It adds no independent meaning beyond what the schema already provides, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Make' and clearly identifies the resource as a non-fungible token per the ERC-1155 standard. It distinguishes this tool from siblings like cairo-erc20 and cairo-erc721 by specifying the standard, and additionally states that it returns source code and does not write to disk, providing precise scope.
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?
While the description does not explicitly state when to use this tool vs. alternatives, the name and mention of the ERC-1155 standard make the intended use case clear. It implies usage for generating ERC-1155 tokens but lacks explicit 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-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, 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. | |
| 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. | |
| 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. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses that the tool returns source code in a Markdown code block and does not write to disk. This is good transparency for a code generation tool. However, it could mention that it's purely generative (no side effects).
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?
Two sentences: first states purpose, second explains return format and side-effect. Front-loaded and efficient. 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?
Given the complexity (14 parameters, nested objects, no output schema), the description is minimal. It doesn't explain the expected output structure further or give guidance on prerequisites (e.g., Cairo toolchain). Adequate but leaves gaps for an agent.
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 93%, meaning the schema already documents most parameters well. The description does not add significant new meaning beyond what's in the schema. Baseline of 3 is correct.
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 verb 'Make' (generate) and the resource 'fungible token per ERC-20 standard'. It distinguishes from sibling tools like cairo-erc721 (NFT) and cairo-erc1155 (multi-token) by specifying the standard. Returns source code in Markdown.
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?
Implied usage is clear: use for generating ERC-20 fungible tokens. Sibling tool names (e.g., cairo-erc721) provide context for alternatives. However, no explicit when-not or exclusions are stated, so a 4 is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
cairo-erc721AInspect
Make a non-fungible token per the ERC-721 standard.
Returns the source code of the generated contract, formatted in a Markdown code block. Does not write to disk.
| Name | Required | Description | Default |
|---|---|---|---|
| info | No | Metadata about the contract and author | |
| name | Yes | The name of the contract | |
| votes | No | Whether to keep track of individual units for voting in on-chain governance. Voting durations can be expressed as block numbers or timestamps. | |
| 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. | |
| 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. | |
| 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. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose behavior. It states the tool returns source code in a Markdown code block and does not write to disk. This covers the core behavior and safety (no side effects). Additional context like network requests or prerequisites is absent but not critical 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: three short sentences that state purpose, output format, and a key behavioral constraint. No redundant or unnecessary words. The most important information is front-loaded.
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 (15 parameters, nested objects, no output schema, no annotations), the description covers the essential aspects: what it generates, the format of output, and that it does not persist. It could mention integration with sibling tools or deployment, but current completeness is sufficient for most agents.
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 93%, so the schema already documents most parameter meanings. The description adds no new parameter-specific information, but it does not need to. It focuses on the tool's purpose and output, which is appropriate. Score reflects the high schema coverage baseline.
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 creates an ERC-721 non-fungible token, which is a specific verb and resource. It distinguishes from sibling tools like cairo-erc20 (fungible) and cairo-erc1155 (multi-token) by referencing the standard. The output behavior is also clarified.
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 implies use when an ERC-721 token is needed but does not explicitly state when to use this tool versus alternatives (e.g., cairo-erc20, cairo-erc1155). No exclusions or comparative guidance are provided, leaving the agent to infer based on the tool name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
cairo-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, 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. |
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 returns source code in a Markdown code block and does not write to disk, clarifying output format and side effects. However, it lacks details on permissions, rate limits, error handling, or other behavioral traits like whether the contract is deployed or just generated. The description compensates partially but leaves gaps for a tool with 17 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 appropriately sized with two sentences that are front-loaded: the first states the purpose, and the second clarifies output behavior. There is no wasted text, and it efficiently conveys key information without redundancy. However, it could be slightly more structured by explicitly separating purpose from constraints.
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 output schema, no annotations), the description is minimally adequate. It covers the core purpose and output format but lacks details on usage context, behavioral nuances, or integration with other tools. Without annotations or output schema, the description should provide more guidance on how the generated contract is used or what to expect, but it falls short of being complete for such a multifaceted 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 does not add any parameter-specific semantics beyond what the schema provides—it mentions no parameters explicitly. According to the rules, with high schema coverage (>80%), the baseline score is 3 even with no param info in the description, as the schema does the heavy lifting.
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 a contract') and resource ('governance'), distinguishing it from sibling tools like cairo-erc20 or cairo-multisig that handle different contract types. The description is specific about what the tool generates.
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' but does not specify prerequisites, constraints, or compare it to other governance-related tools (none listed in siblings). There is no explicit when/when-not usage advice or named alternatives, leaving the agent with minimal context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
cairo-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.
| 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. |
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 valuable context beyond the input schema: 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 output format and non-persistent behavior. However, it doesn't mention potential side effects, error conditions, or performance aspects, leaving some gaps.
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: two sentences that front-load the core purpose and follow with critical behavioral details (output format and non-persistence). Every sentence adds essential value without redundancy, making it efficient for an AI agent to parse and understand.
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 (5 parameters, nested objects, no output schema, and no annotations), the description is reasonably complete. It covers the tool's purpose, output behavior, and non-persistence, which are crucial for a code-generation tool. However, it lacks details on error handling or example usage, which could enhance completeness for the agent's context.
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 documented in the schema itself. The description does not add any parameter-specific details beyond what's in the schema (e.g., it doesn't explain 'quorum' further or provide examples). Given the high 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 multi-signature smart contract, requiring a quorum of registered signers to approve and collectively execute transactions.' This specifies the verb ('Make'), resource ('multi-signature smart contract'), and key functionality (quorum-based approval). It effectively distinguishes this from sibling tools like cairo-account or cairo-erc20 by focusing on multi-signature capabilities.
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 implies usage context by mentioning 'multi-signature smart contract' and 'quorum,' suggesting it's for scenarios requiring collective transaction approval. However, it lacks explicit guidance on when to use this tool versus alternatives (e.g., cairo-custom for other contract types) or any prerequisites. The context is clear but not detailed enough for optimal agent decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
cairo-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.
| 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?$/ |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It states that the tool 'does not write to disk' and returns a Markdown code block, disclosing non-destructive behavior. However, it lacks details about input validation, error handling, or any side effects beyond generation.
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?
Two sentences: the first captures the core purpose, the second clarifies output format and side-effects. No extraneous information—every sentence adds value.
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 has 7 parameters (5 required) with nested objects and no output schema, the description explains the output format and overall behavior. It could be more complete by hinting at return structure or validation, but it covers the essential context.
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 coverage is 100% with detailed parameter descriptions (e.g., date formats, duration regex). The description adds no additional meaning beyond the schema, so baseline 3 is appropriate.
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 vesting smart contract that manages the gradual release of ERC-20 tokens...' and specifies the output ('Returns the source code...'). It distinguishes itself from sibling tools like cairo-erc20 or cairo-account by focusing on vesting 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 implies usage for creating vesting contracts but provides no explicit guidance on when to use this tool versus alternatives, nor does it mention prerequisites, exclusions, or when not to use it.
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!