Skip to main content
Glama
Sign In
OpenZeppelin Contracts MCP Server

OpenZeppelin Contracts MCP Server

Official
by OpenZeppelin
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

Stellar Non-Fungible

stellar-non-fungible

Make a non-fungible token per the Non-Fungible Token Standard, compatible with SEP-50, similar to ERC-721.

Instructions

Make a non-fungible token per the Non-Fungible Token Standard, compatible with SEP-50, similar to ERC-721.

Returns the source code of the generated contract, formatted in a Markdown code block. Does not write to disk.

Input Schema

NameRequiredDescriptionDefault
infoNoMetadata about the contract and author
nameYesThe name of the contract
votesNoWhether to enable vote checkpoints and delegation for governance.
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.
symbolYesThe short symbol for the token
burnableNoWhether token holders will be able to destroy their tokens
mintableNoWhether privileged accounts will be able to create more supply or emit more tokens
pausableNoWhether privileged accounts will be able to pause specifically marked functionality. Useful for emergency response.
tokenUriNoThe metadata URI returned by the token contract for every NFT.
royaltiesNoWhether to provide royalty information for sales of the NFTs, following ERC-2981. Privileged accounts can set the default royalty and per-token royalties.
enumerableNoWhether the NFTs are enumerable (can be iterated over).
sequentialNoWhether the IDs of the minted NFTs will be sequential.
consecutiveNoTo batch mint NFTs instead of minting them individually (sequential minting is mandatory).
upgradeableNoWhether the contract can be upgraded.
explicitImplementationsNoWhether the contract should use explicit trait implementations instead of using the default ones provided by the library.
defaultRoyaltyBasisPointsNoThe default royalty for the collection in basis points (100 = 1%, maximum 10000), paid to a receiver set at deployment. 0 sets no default royalty.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv1.0.11
    • addedInput schema / properties / defaultRoyaltyBasisPoints
      Added value: +{
+  "description": "The default royalty for the collection in basis points (100 = 1%, maximum 10000), paid to a receiver set at deployment. 0 sets no default royalty.",
+  "type": "string"
+}
    • addedInput schema / properties / royalties
      Added value: +{
+  "description": "Whether to provide royalty information for sales of the NFTs, following ERC-2981. Privileged accounts can set the default royalty and per-token royalties.",
+  "type": "boolean"
+}
  2. Changed2 schema fields changedv1.0.1
    • addedInput schema / properties / explicitImplementations
      Added value: +{
+  "description": "Whether the contract should use explicit trait implementations instead of using the default ones provided by the library.",
+  "type": "boolean"
+}
    • addedInput schema / properties / votes
      Added value: +{
+  "description": "Whether to enable vote checkpoints and delegation for governance.",
+  "type": "boolean"
+}
  3. Changed6 schema fields changedv1.0.0
    • removedInput schema / additionalProperties
      Removed value: -false
    • addedInput schema / properties / access / anyOf
      Added value: +[
+  {
+    "const": "ownable",
+    "type": "string"
+  },
+  {
+    "const": "roles",
+    "type": "string"
+  }
+]
    • removedInput schema / properties / access / enum
      Removed value: -[
-  "ownable",
-  "roles"
-]
    • removedInput schema / properties / access / type
      Removed value: -"string"
    • removedInput schema / properties / info / additionalProperties
      Removed value: -false
    • addedInput schema / properties / tokenUri
      Added value: +{
+  "description": "The metadata URI returned by the token contract for every NFT.",
+  "type": "string"
+}
  4. First observed

TDQS

A3.6/5.0
Behavior4/5

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

With no annotations, the description carries the full burden and does well: it discloses that the tool returns source code in a Markdown code block and does not write to disk, which tells the agent this is a non-mutating generation step. It leaves auth, rate limits, and whether output is deterministic unstated, but the key behavioral trait is covered.

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

Conciseness5/5

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

Two short sentences, front-loaded with purpose and followed immediately by the return behavior. Every sentence earns its place with no repetition of schema details.

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

Completeness4/5

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

For a 16-parameter code-generation tool with full schema coverage and no output schema, the description explains the return format and non-writing behavior, which is the main missing piece. It is nearly complete, though it could say more about when this generator is preferred over sibling generators.

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 all 16 parameters including nested 'info' fields and enums-like access are already documented. The description adds no parameter-level meaning beyond referencing the standard, so baseline 3 is appropriate.

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

Purpose4/5

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

States a specific verb and resource ('Make a non-fungible token') plus the relevant standard (SEP-50, ERC-721 analogue). It implies distinction from 'stellar-fungible' by the non-fungible label, but does not explicitly route against siblings like solidity-erc721 or cairo-erc721.

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

Usage Guidelines2/5

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

No explicit when-to-use or when-not-to-use guidance, and no mention of alternatives such as stellar-fungible for fungible tokens or other chain-specific NFT generators. Usage is only lightly implied by the 'make a token on Stellar' framing.

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

Deploy Server

Other Tools