Skip to main content
Glama
OpenZeppelin

OpenZeppelin Contracts MCP Server

Official
by OpenZeppelin

cairo-erc1155

Generate ERC-1155 token contracts with configurable features like burnable, pausable, mintable, royalty, and access control options.

Instructions

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.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameYesThe name of the contract
baseUriYesThe location of the metadata for the token. Clients will replace any instance of {id} in this string with the tokenId.
burnableNoWhether token holders will be able to destroy their tokens
pausableNoWhether privileged accounts will be able to pause specifically marked functionality. Useful for emergency response.
mintableNoWhether privileged accounts will be able to create more supply or emit more tokens
updatableUriNoWhether privileged accounts will be able to set a new URI for all token types.
royaltyInfoNoProvides information for how much royalty is owed and to whom, based on a sale price. Follows ERC-2981 standard.
accessNoThe 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.
upgradeableNoWhether the smart contract is upgradeable.
infoNoMetadata about the contract and author

Implementation Reference

  • Function that registers the 'cairo-erc1155' tool on the MCP server, specifying name, prompt, schema, and handler.
    export function registerCairoERC1155(server: McpServer): RegisteredTool {
      return server.tool(
        'cairo-erc1155',
        makeDetailedPrompt(cairoPrompts.ERC1155),
        erc1155Schema,
        async ({ name, baseUri, burnable, pausable, mintable, updatableUri, royaltyInfo, access, upgradeable, info }) => {
          const opts: ERC1155Options = {
            name,
            baseUri,
            burnable,
            pausable,
            mintable,
            updatableUri,
            royaltyInfo,
            access,
            upgradeable,
            info,
          };
          return {
            content: [
              {
                type: 'text',
                text: safePrintCairoCodeBlock(() => erc1155.print(opts)),
              },
            ],
          };
        },
      );
    }
  • Handler function that constructs ERC1155Options from input params and generates Cairo code using erc1155.print from OpenZeppelin wizard-cairo.
    async ({ name, baseUri, burnable, pausable, mintable, updatableUri, royaltyInfo, access, upgradeable, info }) => {
      const opts: ERC1155Options = {
        name,
        baseUri,
        burnable,
        pausable,
        mintable,
        updatableUri,
        royaltyInfo,
        access,
        upgradeable,
        info,
      };
      return {
        content: [
          {
            type: 'text',
            text: safePrintCairoCodeBlock(() => erc1155.print(opts)),
          },
        ],
      };
    },
  • Zod schema defining the input parameters for the cairo-erc1155 tool, including name, baseUri, flags for features like burnable, pausable, etc.
    export const erc1155Schema = {
      name: z.string().describe(commonDescriptions.name),
      baseUri: z.string().describe(cairoERC1155Descriptions.baseUri),
      burnable: z.boolean().optional().describe(commonDescriptions.burnable),
      pausable: z.boolean().optional().describe(commonDescriptions.pausable),
      mintable: z.boolean().optional().describe(commonDescriptions.mintable),
      updatableUri: z.boolean().optional().describe(cairoERC1155Descriptions.updatableUri),
      royaltyInfo: z
        .object({
          enabled: z.boolean().describe(cairoRoyaltyInfoDescriptions.enabled),
          defaultRoyaltyFraction: z.string().describe(cairoRoyaltyInfoDescriptions.defaultRoyaltyFraction),
          feeDenominator: z.string().describe(cairoRoyaltyInfoDescriptions.feeDenominator),
        })
        .optional()
        .describe(cairoCommonDescriptions.royaltyInfo),
      ...commonSchema,
    } as const satisfies z.ZodRawShape;
Behavior3/5

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 generates source code (not just a token), returns formatted Markdown, and doesn't write to disk. However, it misses important details like whether this is a read-only operation (implied by 'Does not write to disk'), error conditions, rate limits, or authentication requirements for a contract generation tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is perfectly concise and well-structured in two sentences. The first sentence states the core purpose, the second clarifies the output format and important behavioral constraint ('Does not write to disk'). Every word earns its place with zero redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity (10 parameters, nested objects, no output schema, no annotations), the description is minimally adequate. It covers what the tool does and output format, but lacks guidance on usage context, error handling, or detailed behavioral expectations. The 100% schema coverage helps, but for a contract generation tool with many parameters, more contextual information would be beneficial.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema fully documents all 10 parameters. The description adds no parameter-specific information beyond what's in the schema. According to scoring rules, when schema coverage is high (>80%), the baseline is 3 even with no param info in description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: 'Make a non-fungible token per the ERC-1155 standard.' This specifies the verb ('Make'), resource ('non-fungible token'), and standard ('ERC-1155'). However, it doesn't explicitly differentiate from siblings like 'cairo-erc721' or 'solidity-erc1155', which would require mentioning Cairo language specificity or contract generation focus.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'cairo-erc721' for different token standards, 'solidity-erc1155' for different languages, or 'cairo-custom' for more flexibility. There's no context about prerequisites, target use cases, or exclusions.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/OpenZeppelin/contracts-wizard'

If you have feedback or need assistance with the MCP directory API, please join our Discord server