Skip to main content
Glama
Sign In
OpenZeppelin Contracts MCP Server

OpenZeppelin Contracts MCP Server

Official
by OpenZeppelin
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

Stellar Stablecoin

stellar-stablecoin

Make a stablecoin that uses Fungible Token Standard, compatible with SEP-41.

Instructions

Make a stablecoin that uses Fungible Token Standard, compatible with SEP-41.

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

Input Schema

NameRequiredDescriptionDefault
capNoThe maximum total supply of the token, in number of tokens. Leave empty for an uncapped token. Requires total supply tracking, which is then enabled automatically. Cannot be used with votes.
infoNoMetadata about the contract and author
nameYesThe name of the contract
votesNoWhether to enable vote checkpoints and delegation for governance. Cannot be used with total supply tracking or a cap.
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
premintNoThe number of tokens to premint for the deployer.
burnableNoWhether token holders will be able to destroy their tokens
decimalsNoThe number of decimals used to represent token amounts. Defaults to 7.
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.
limitationsNoWhether to restrict certain users from transferring tokens, either via allowing or blocking them.
totalSupplyNoWhether to track the total supply and expose it through a total_supply function. Every mint and burn then writes the same storage entry, which prevents them from executing in parallel. Cannot be used with votes.
upgradeableNoWhether the contract can be upgraded.
explicitImplementationsNoWhether the contract should use explicit trait implementations instead of using the default ones provided by the library.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changedv1.0.11
    • addedInput schema / properties / cap
      Added value: +{
+  "description": "The maximum total supply of the token, in number of tokens. Leave empty for an uncapped token. Requires total supply tracking, which is then enabled automatically. Cannot be used with votes.",
+  "type": "string"
+}
    • addedInput schema / properties / totalSupply
      Added value: +{
+  "description": "Whether to track the total supply and expose it through a total_supply function. Every mint and burn then writes the same storage entry, which prevents them from executing in parallel. Cannot be used with votes.",
+  "type": "boolean"
+}
    • changedInput schema / properties / votes / description
      Previous value: -"Whether to enable vote checkpoints and delegation for governance."New value: +"Whether to enable vote checkpoints and delegation for governance. Cannot be used with total supply tracking or a cap."
  2. Changed1 schema field changedv1.0.2
    • addedInput schema / properties / decimals
      Added value: +{
+  "description": "The number of decimals used to represent token amounts. Defaults to 7.",
+  "type": "string"
+}
  3. 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"
+}
  4. 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
    • changedInput schema / properties / limitations / anyOf
      Previous value: -[
-  {
-    "enum": [
-      false,
-      "allowlist"
-    ],
-    "type": [
-      "boolean",
-      "string"
-    ]
-  },
-  {
-    "const": "blocklist",
-    "type": "string"
-  }
-]New value: +[
+  {
+    "anyOf": [
+      {
+        "const": false,
+        "type": "boolean"
+      },
+      {
+        "const": "allowlist",
+        "type": "string"
+      }
+    ]
+  },
+  {
+    "const": "blocklist",
+    "type": "string"
+  }
+]
  5. First observed

TDQS

B3.2/5.0
Behavior3/5

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

With no annotations, the description usefully discloses the output form (source code in a Markdown block) and the key side-effect fact that nothing is written to disk, which is genuinely additive. It says nothing, though, about the mutually exclusive option combinations (cap vs votes vs totalSupply) or about defaults that materially change the generated contract.

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

Conciseness4/5

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

Two tight sentences with zero waste, and the return-value and no-disk-write facts are front-loaded. Slightly more could have been said about option compatibility without bloat.

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?

For a 15-parameter contract generator with no output schema, describing the return value is valuable and the description does it. However, the cross-parameter constraints and default behavior that most affect the generated artifact are left entirely to the schema, so the description is adequate rather than complete.

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 15 parameters, including the nested info object and the enum-like access/limitations values, are already documented in the schema. The description adds no parameter meaning beyond that, which is the baseline case for full coverage.

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: generate a stablecoin contract using the Fungible Token Standard, SEP-41 compatible. That distinguishes it from the ERC/TRC/Cairo siblings, but it does not say how it differs from its closest sibling, stellar-fungible, which an agent must infer.

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 guidance on when to pick this over stellar-fungible or stellar-non-fungible, and no mention of prerequisites or typical workflow. The agent must infer the choice from the tool name alone.

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