OpenZeppelin Stellar Contracts

Stellar Vault

stellar-vault

Make a tokenized vault that issues Fungible Token shares for an underlying asset, similar to ERC-4626.

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

Input Schema

TableJSON Schema

Name	Required	Description
`info`	No	Metadata about the contract and author
`name`	Yes	The name of the contract
`access`	No	The 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.
`symbol`	Yes	The short symbol for the token
`pausable`	No	Whether privileged accounts will be able to pause specifically marked functionality. Useful for emergency response.
`upgradeable`	No	Whether the contract can be upgraded.
`decimalsOffset`	No	Virtual decimals offset added to the underlying asset decimals to derive the vault share decimals, used to mitigate inflation (donation) attacks via virtual shares. The default of 0 is already safe: it makes such attacks non-profitable. Higher values make attacks orders of magnitude more costly, at the cost of virtual shares absorbing a tiny portion of the value accrued to the vault. Must be between 0 and 10.
`explicitImplementations`	No	Whether the contract should use explicit trait implementations instead of using the default ones provided by the library.

TDQS

A4.2/5.0

Behavior4/5

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

With no annotations provided, the description carries the transparency burden. It clearly discloses that the tool returns source code and does not write to disk, which is essential behavioral context. It does not mention any other side effects or limitations, but for a code generator this disclosure is substantial.

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 two sentences: the first states the core purpose, the second specifies the output format and side-effect. It is concise, front-loaded, and every sentence earns its place.

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 complex generator with 8 parameters and no output schema, the description covers the essential context: what the tool creates, its output format, and that it does not persist files. It leaves parameter details to the schema, which is fully described. Minor gap: no guidance on how parameter choices affect the generated contract, but this is not critical given schema coverage.

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 8 parameters. The description adds no additional parameter-level semantics, which aligns with the baseline of 3 for high coverage.

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

Purpose5/5

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

The description uses a specific verb 'Make' and a specific resource 'tokenized vault' that issues Fungible Token shares, clearly distinguishing it from sibling tools like stellar-fungible or stellar-governor. It also clarifies the output (source code in Markdown) and side-effect-free nature, leaving no ambiguity about what the tool does.

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

Usage Guidelines4/5

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

The description provides clear context by comparing to ERC-4626, implying it is for vault-style tokenized assets rather than simple tokens. However, it does not explicitly name alternatives or state when not to use this tool, so it falls short of full exclusionary guidance.

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

All OpenZeppelin Stellar Contracts tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.2/5.0

Disambiguation5/5

Each tool generates a distinct type of smart contract (fungible, non-fungible, governor, stablecoin, vault) with no overlap in purpose. The descriptions clearly differentiate them.

Naming Consistency5/5

All tool names follow a consistent pattern: stellar-<type> using lowercase and hyphens. The naming is uniform and predictable.

Tool Count5/5

With 5 tools covering the most common Stellar contract types, the count is well-scoped for a code generator. Neither too sparse nor excessive.

Completeness4/5

The set covers major contract standards (fungible, non-fungible, governance, stablecoin, vault), but lacks some advanced types like access control or upgradeability, which are minor gaps.

Resources

Need Help?