OpenZeppelin Cairo Contracts

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.

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 generates source code in Markdown format and doesn't write to disk, which is useful context. However, it lacks critical behavioral details: no mention of error conditions, performance characteristics, authentication requirements, rate limits, or what happens with invalid inputs. For a complex contract generation tool, this leaves significant 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 extremely concise and well-structured in two sentences. The first sentence states the core purpose, and the second provides critical behavioral context about output format and disk behavior. Every word earns its place with zero redundancy or unnecessary elaboration.

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 (6 parameters with nested objects), lack of annotations, and no output schema, the description is incomplete. While concise, it doesn't address important contextual aspects: what constitutes a valid custom contract, how the generated code relates to input parameters, error handling, or typical workflow integration. The description leaves too many questions unanswered for such a sophisticated 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 high at 83%, establishing a baseline of 3. The description adds no parameter-specific information beyond what's in the schema. While it implies parameters are needed for custom contract creation, it doesn't explain relationships between parameters (e.g., how 'access' interacts with 'pausable') or provide usage examples. The schema does most of the work, but the description doesn't compensate for the remaining 17% coverage gap.

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' with the specific verb 'Make' and resource 'smart contract'. It distinguishes from siblings by focusing on custom contract generation rather than pre-defined templates like ERC20 or multisig. However, it doesn't explicitly contrast with all sibling tools (e.g., cairo-account).

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 indicates it's a generation-only tool, but offers no explicit when-to-use guidance versus alternatives like the sibling ERC20 or ERC721 tools. There's no mention of prerequisites, typical use cases, or when to choose custom vs. template-based contracts.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries full burden for behavioral disclosure. It mentions that the tool 'Returns the source code... Does not write to disk,' which clarifies it's a generation-only tool without file system interaction. However, it lacks critical behavioral details: no mention of error conditions, performance characteristics, authentication requirements, or what happens with invalid inputs. For a complex contract generation tool with 11 parameters, this is insufficient.

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 concise with two sentences that each serve distinct purposes: first stating the core functionality, then specifying output format and behavioral constraint. No wasted words, though it could be slightly more informative about the tool's scope or limitations. Front-loading the main purpose is effective.

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 smart contract generation tool with 11 parameters, no annotations, and no output schema, the description is incomplete. While it states the basic purpose and output format, it doesn't address important contextual aspects: what constitutes valid input combinations, how errors are handled, whether the generated code is production-ready, or what dependencies might be required. The high parameter count and complexity demand more comprehensive guidance.

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 91%, so the schema already documents most parameters thoroughly. The description adds no parameter-specific information beyond what's in the schema. It mentions generating an ERC-1155 contract, which provides context for the parameters, but doesn't explain how individual parameters like 'access.type' or 'royaltyInfo' affect the generated contract. Baseline 3 is appropriate given high schema 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 tool's purpose: 'Make a non-fungible token per the ERC-1155 standard.' This specifies the action (make), resource (non-fungible token), and standard (ERC-1155). It distinguishes from siblings like cairo-erc20 or cairo-erc721 by specifying ERC-1155, but doesn't explicitly contrast with cairo-custom 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 minimal usage guidance. It states what the tool does and the output format, but offers no advice on when to use this tool versus alternatives like cairo-erc721 or cairo-custom. There's no mention of prerequisites, typical use cases, or limitations that would help an agent choose between sibling tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries full burden. It discloses that the tool 'Returns the source code... Does not write to disk,' which clarifies it's a code generation tool without deployment or persistence. However, it lacks details about permissions needed, 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 with only two sentences that each serve clear purposes: stating the tool's function and specifying output behavior. There's zero wasted language, and it's front-loaded with the core purpose.

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 14 parameters, no annotations, and no output schema, the description is minimal. While it states the output format (Markdown code block with source code), it doesn't address the tool's scope (e.g., whether it handles validation, generates complete contracts, or requires additional steps). The high schema coverage helps, but more context about the tool's limitations or typical use cases 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 93%, so the schema already documents most parameters thoroughly. The description adds no parameter-specific information beyond what's in the schema, maintaining the baseline score. It doesn't explain relationships between parameters (e.g., how 'votes' interacts with 'appName' and 'appVersion').

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 fungible token per the ERC-20 standard' and specifies the output format. It distinguishes from siblings by focusing on ERC-20 tokens, but doesn't explicitly contrast with other token standards like ERC-721 or ERC-1155 mentioned in sibling tools.

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 guidance is provided on when to use this tool versus alternatives. The description doesn't mention sibling tools like cairo-custom or cairo-erc721, nor does it explain scenarios where ERC-20 is preferred over other standards or when to use this generator versus manual implementation.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description adds some behavioral context beyond what annotations would provide, as there are no annotations. It states 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-destructive behavior. However, it lacks details on permissions, rate limits, or error handling, which are important for a tool generating 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 extremely concise and front-loaded, consisting of only two sentences that directly state the tool's purpose and behavior. There is no wasted language or redundancy, making it easy to understand quickly. This efficiency is ideal for a tool description, as every sentence earns its place by providing essential information.

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 of the tool (15 parameters, nested objects, no output schema, and no annotations), the description is somewhat incomplete. It covers the basic purpose and output format but lacks details on parameter interactions, error cases, or examples. However, the high schema coverage mitigates some gaps, making it adequate but with clear room for improvement in guiding usage for a sophisticated 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?

The description does not mention any parameters, but the input schema has high description coverage (93%), providing detailed explanations for each parameter. Since the schema does most of the work, the baseline score is 3. The description could have added value by summarizing key parameters or usage examples, but it does not, so it meets the minimum viable standard without enhancement.

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'), resource ('non-fungible token'), and standard ('ERC-721'), which is specific. However, it does not explicitly differentiate from sibling tools like 'cairo-erc1155' or 'cairo-erc20', which handle other token standards, leaving some ambiguity in comparison.

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-721 standard but does not compare it to other token standards or tools in the sibling list, such as 'cairo-erc1155' for semi-fungible tokens or 'cairo-erc20' for fungible tokens. Without such context, users may struggle to select the appropriate tool for their needs.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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.

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.

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 value by stating the tool returns source code in a Markdown code block and does not write to disk, which clarifies output format and side effects. However, it lacks details on permissions, error handling, or rate limits, 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 front-loaded with the core purpose in the first sentence, followed by output details in the second. Both sentences earn their place by providing essential information without redundancy, making it efficient and well-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 (7 parameters, no output schema, no annotations), the description is adequate but incomplete. It covers purpose and output format but lacks guidance on usage, error handling, or prerequisites. For a tool generating smart contracts, more context on dependencies or validation 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 parameters thoroughly. The description adds no specific parameter semantics beyond what the schema provides, such as explaining how 'schedule' or 'duration' interact. Baseline 3 is appropriate 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 vesting smart contract that manages the gradual release of ERC-20 tokens to a designated beneficiary based on a predefined vesting schedule.' It specifies the verb ('Make'), resource ('vesting smart contract'), and distinguishes it from sibling tools like 'cairo-erc20' or 'cairo-multisig' by focusing on vesting functionality.

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. It mentions the output format and that it 'Does not write to disk,' which gives some context, but lacks specific when-to-use or when-not-to-use instructions compared to other tools like 'cairo-custom' or 'cairo-account'.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.