A
licenseA
qualityA
maintenanceA Model Context Protocol (MCP) server that allows AI agents to generate smart contracts using OpenZeppelin Contracts libraries.
33
56 npm
294
AGPL 3.0
OpenZeppelin Stellar Contracts
Server Details
The OpenZeppelin Stellar Contracts MCP server generates secure smart contracts for the Stellar blockchain based on OpenZeppelin templates. It integrates with AI assistants to automatically enforce OpenZeppelin's security best practices, style rules, and standards at every prompt, enabling developers to create production-ready Fungible Token, Non-Fungible Token, and Stablecoin contracts through AI-driven workflows.
If you are the author of this connector, you can claim ownership with GitHub, an HTTP challenge, or a DNS record. Claimed connector authors can inspect health checks, view analytics, and manage their listing.
- Status
- Healthy
- Uptime
- 99.9% over 38 days
- Last Tested
- Transport
- Streamable HTTP · MCP 2025-11-25
- URL
TDQS
A3.9/5.0
Scored across 6 tools
Disambiguation4/5
Each tool generates a distinct contract type (account, fungible, governor, non-fungible, stablecoin, vault). The only potential overlap is between stellar-fungible and stellar-stablecoin, since a stablecoin is a fungible token, but the descriptions clarify stablecoin as a specialized subtype.
Naming Consistency4/5
All tools follow a 'stellar-<contract-type>' pattern using kebab-case, which is consistent and predictable. The action prefix is omitted (all generate code), so the pattern is noun-based rather than verb_noun, but it is uniformly applied.
Tool Count4/5
Six tools cover the core OpenZeppelin Stellar contract templates, which is a reasonable scope for a code generation server. The count is slightly narrow but appropriate for the specialized domain.
Completeness3/5
The server covers several major contract standards but lacks tools for common auxiliary contracts like access control, upgradeability, or pausable mechanisms that are part of OpenZeppelin's ecosystem. No lifecycle operations (writing, testing, deploying) are included, though the generation-only purpose is stated.
Available Tools
6 toolsstellar-accountStellar AccountAInspect
Make a smart account contract that authorizes operations through configurable signers and policies, for example a multisig with passkey, Ed25519 and delegated signers.
Returns the source code of the generated contract, formatted in a Markdown code block. Does not write to disk.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| info | No | Metadata about the contract and author | |
| name | Yes | The name of the contract | |
| policy | No | How authorization is decided. False requires every configured signer to sign (n-of-n). Simple threshold requires any m of the n signers (a standard multisig). Weighted threshold gives each signer a weight and requires the authorized weights to reach a threshold. Both threshold policies need the address of a deployed policy contract at deployment. | |
| upgradeable | No | Whether the account can be upgraded. The upgrade is authorized by the account itself through its context rules, not by an access control role. | |
| ed25519Signers | No | Whether the account accepts raw Ed25519 public keys, verified by an Ed25519 verifier contract supplied at deployment. | |
| webauthnSigners | No | Whether the account accepts WebAuthn (passkey) keys, verified by a WebAuthn verifier contract supplied at deployment. | |
| delegatedSigners | No | Whether the account accepts delegated signers, meaning Stellar addresses whose signatures the host verifies. Enabled by default. | |
| executionEntryPoint | No | Whether the account can call other contracts on its own behalf. Needed to manage contracts the account owns, such as its own policies, and enabled by default. |
TDQS
A4.2/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of disclosing side effects. It explicitly states that the tool 'Returns the source code of the generated contract, formatted in a Markdown code block' and 'Does not write to disk', which are critical behavioral traits. It does not mention permissions, network access, or potential errors, but for a code generator, these are less relevant. The description adequately signals that no persistent changes are made.
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 extremely concise, consisting of only two short paragraphs. It front-loads the primary purpose, then immediately discloses the output format and lack of disk write. Every sentence contributes essential information without redundant phrases. This is an ideal example of efficient writing.
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?
Given the tool's complexity (8 parameters, nested objects, no output schema), the description covers the core purpose and output format. Since the schema already documents all parameters in detail (100% coverage), the description does not need to repeat those. It provides a use-case example and side-effect transparency, which are the missing pieces. It could be more complete by mentioning that policy contracts are required for threshold policies, but that is already in the schema. Overall, it is adequate for an agent to invoke correctly.
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 baseline is 3. The description adds a meaningful example ('multisig with passkey, Ed25519 and delegated signers') that illustrates how parameters like webauthnSigners, ed25519Signers, and delegatedSigners interact, but it does not provide additional semantics beyond what the schema already documents. This is sufficient, but not above the baseline.
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 clearly states the tool's purpose: to generate a smart account contract on Stellar with configurable signers and policies. It provides a concrete example (multisig with passkey, Ed25519, and delegated signers) and distinguishes it from sibling tools like stellar-fungible or stellar-governor by its focus on account contracts. The verb 'Make' combined with the resource 'smart account contract' is specific.
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 implies when to use the tool: when you need a Stellar smart account with specific authorization logic. It gives an example of multisig use cases, which suggests typical scenarios. However, it does not explicitly mention when NOT to use it or compare it to alternatives (e.g., 'for a simpler account, use X'). Still, the context from sibling names and the description's clarity provide sufficient guidance for most cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
stellar-fungibleStellar FungibleAInspect
Make a fungible token per the Fungible Token Standard, compatible with SEP-41, similar to ERC-20.
Returns the source code of the generated contract, formatted in a Markdown code block. Does not write to disk.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| info | No | Metadata about the contract and author | |
| name | Yes | The name of the contract | |
| votes | No | Whether to enable vote checkpoints and delegation for governance. | |
| 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 | |
| premint | No | The number of tokens to premint for the deployer. | |
| burnable | No | Whether token holders will be able to destroy their tokens | |
| decimals | No | The number of decimals used to represent token amounts. Defaults to 7. | |
| mintable | No | Whether privileged accounts will be able to create more supply or emit more tokens | |
| 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. | |
| explicitImplementations | No | Whether the contract should use explicit trait implementations instead of using the default ones provided by the library. |
TDQS
A4/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. It discloses key behaviors: 'Returns the source code of the generated contract, formatted in a Markdown code block' and 'Does not write to disk.' This explains the output format and side-effect absence, which is critical for a generator. However, it does not mention validation, error handling, or whether parameters have constraints beyond the schema, so some transparency is still missing.
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 extremely concise, two sentences long, with the purpose front-loaded. Every sentence serves a distinct function: the first states what the tool creates, and the second explains the output format and side-effect. There is no wasted wording or 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?
Given the tool's complexity (12 parameters, no output schema), the description covers the essential context: it generates a contract, returns source code, and does not write to disk. It does not explain the meaning of specific parameter combinations or error conditions, but the rich schema descriptions compensate. The description is sufficient for an agent to understand the tool's role and primary behavior.
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 coverage is 100%, with every parameter having a description in the input schema. The tool description does not add additional meaning beyond what the schema provides; it only mentions the fungible token standard, which is already implied. The description neither clarifies ambiguous parameters nor provides usage examples, so it adds marginal value over the schema.
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 clearly states it 'Make a fungible token per the Fungible Token Standard, compatible with SEP-41', which is a specific verb and resource. It distinguishes from siblings by explicitly naming the token standard and noting it is 'similar to ERC-20'. The addition that it returns source code and does not write to disk further clarifies its role as a code generator.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage through its focus on fungible tokens and SEP-41 compatibility, but it does not explicitly mention when to use this tool versus alternatives like stellar-non-fungible or stellar-stablecoin. No exclusions or alternative tool references are provided. The context is clear but guidance is only implied, not stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
stellar-governorStellar GovernorAInspect
Make a governor contract for on-chain governance using token-based voting.
Returns the source code of the generated contract, formatted in a Markdown code block. Does not write to disk.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| 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. | |
| quorum | No | Minimum number of votes required for a proposal to pass, default is 500. | |
| version | No | The semantic version label returned by the governor contract. | |
| timelock | No | Whether to add a timelock mechanism that enforces a delay between proposal queuing and execution. | |
| upgradeable | No | Whether the contract can be upgraded. | |
| votingDelay | No | Number of ledgers between proposal creation and voting start (17,000 ledgers are approx. 1 day). | |
| votingPeriod | No | Number of ledgers during which voting remains open (120,000 ledgers are approx. 1 week). | |
| proposalThreshold | No | Minimum voting power required for creating a proposal, default is 100. | |
| explicitImplementations | No | Whether the contract should use explicit trait implementations instead of using the default ones provided by the library. |
TDQS
A3.8/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 of behavioral disclosure. It explicitly states that the tool returns source code in a Markdown block and does not write to disk, which are key safety and behavior clarifications. However, it does not mention other potential side effects, required permissions, or failure modes, so it falls short of a perfect score.
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 clear sentences, front-loaded with the core purpose and ending with essential output/behavior info. Every word earns its place with no redundancy or filler.
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?
The description covers the tool's primary function and output format. Although there is no output schema, the description explains the return format. It does not discuss parameter interactions or edge cases, but the schema provides parameter-level detail. Given the complexity (11 params, nested objects), slightly more context about the generated contract could be beneficial, but the description is still largely 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?
The input schema provides complete descriptions (100% coverage) for all 11 parameters, so baseline is 3. The description does not add any additional parameter semantics, but given the strong schema, this is acceptable.
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 clearly identifies the action ('Make'), the resource ('governor contract'), and the specific domain ('on-chain governance using token-based voting'). This distinguishes it from sibling tools that generate other contract types (fungible, non-fungible, stablecoin, vault).
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 is provided on when to use this tool versus alternatives. It does not mention that it should be chosen when creating a governance contract, nor does it exclude other scenarios. Sibling names imply different contract types, but the description itself lacks explicit usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
stellar-non-fungibleStellar Non-FungibleAInspect
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.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| info | No | Metadata about the contract and author | |
| name | Yes | The name of the contract | |
| votes | No | Whether to enable vote checkpoints and delegation for governance. | |
| 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 | |
| burnable | No | Whether token holders will be able to destroy their tokens | |
| mintable | No | Whether privileged accounts will be able to create more supply or emit more tokens | |
| pausable | No | Whether privileged accounts will be able to pause specifically marked functionality. Useful for emergency response. | |
| tokenUri | No | The metadata URI returned by the token contract for every NFT. | |
| enumerable | No | Whether the NFTs are enumerable (can be iterated over). | |
| sequential | No | Whether the IDs of the minted NFTs will be sequential. | |
| consecutive | No | To batch mint NFTs instead of minting them individually (sequential minting is mandatory). | |
| upgradeable | No | Whether the contract can be upgraded. | |
| 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, the description carries the burden of behavioral disclosure. It explicitly states the output format ('source code... in a Markdown code block') and the action of not writing to disk, which informs the agent that this is a non-persistent generation operation. This goes beyond mere purpose and adds safety-relevant context.
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 long, with the first stating the purpose and the second covering return format and side-effect. Every sentence is informative with no redundancy.
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?
Given the absence of an output schema, the description usefully specifies that the return is a Markdown code block containing source code. It also orients the user with the 'similar to ERC-721' analogy, which helps set expectations for the contract structure. However, it doesn't address error conditions or prerequisites beyond schema requirements.
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?
The input schema has 100% description coverage for all 14 parameters, so the baseline is 3. The description does not add any extra meaning to parameters beyond what the schema already provides.
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 clearly states the tool's function with a specific verb ('Make') and resource ('non-fungible token'), further defined by the Non-Fungible Token Standard and SEP-50 compatibility. This distinguishes it from sibling tools like stellar-fungible, satisfying the specificity requirement.
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 implies its use case by specifying 'non-fungible token' and the standard, but it does not explicitly mention when to use it over alternatives or provide exclusions. The sibling tool names provide context, but the description itself offers no comparative guidance, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
stellar-stablecoinStellar StablecoinAInspect
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.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| info | No | Metadata about the contract and author | |
| name | Yes | The name of the contract | |
| votes | No | Whether to enable vote checkpoints and delegation for governance. | |
| 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 | |
| premint | No | The number of tokens to premint for the deployer. | |
| burnable | No | Whether token holders will be able to destroy their tokens | |
| decimals | No | The number of decimals used to represent token amounts. Defaults to 7. | |
| mintable | No | Whether privileged accounts will be able to create more supply or emit more tokens | |
| pausable | No | Whether privileged accounts will be able to pause specifically marked functionality. Useful for emergency response. | |
| limitations | No | Whether to restrict certain users from transferring tokens, either via allowing or blocking them. | |
| upgradeable | No | Whether the contract can be upgraded. | |
| explicitImplementations | No | Whether the contract should use explicit trait implementations instead of using the default ones provided by the library. |
TDQS
A4/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 of behavioral disclosure. It clearly states that the tool returns source code as a Markdown block and does not write to disk, which sets expectations about side effects. However, it does not disclose any other behaviors such as network calls or permissions, but for a code generator this is sufficient.
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 exceptionally concise: three short sentences that lead with the purpose and then detail the output format and side-effect behavior. Every sentence earns its place, and there is no redundant information.
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?
The description covers the key contextual aspects: what the tool does, what it returns, and that it is non-persistent. While the tool has 13 parameters, the schema provides full descriptions, so the description does not need to elaborate on each. It adequately equips an agent to decide whether to invoke this tool within the given context.
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 coverage is 100%, so the baseline is 3. The description does not add parameter-level meaning beyond what the schema already provides for each of the 13 parameters. It neither compensates for gaps nor adds special context, but it does not need to.
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 clearly states the tool's purpose: to create a stablecoin using the Fungible Token Standard and SEP-41. The verb 'Make' combined with the specific resource 'stablecoin' leaves no ambiguity. It differentiates from sibling tools by specifying 'stablecoin' rather than generic fungible tokens, non-fungible, or governor tokens.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for generating stablecoin contracts but does not explicitly state when to use it over alternatives like stellar-fungible or stellar-governor. There is no mention of exclusions or recommended scenarios, so the usage guidance is only implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
stellar-vaultStellar VaultAInspect
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.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| 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.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
1 tool update
- Added
stellar-account
5 tool updates
- Changed
stellar-fungible2 fields changed- added
Input schema / properties / decimalsAdded value: +{ + "description": "The number of decimals used to represent token amounts. Defaults to 7.", + "type": "string" +} - added
Input schema / properties / votesAdded value: +{ + "description": "Whether to enable vote checkpoints and delegation for governance.", + "type": "boolean" +}
- Added
stellar-governor - Changed
stellar-non-fungible1 field changed- added
Input schema / properties / votesAdded value: +{ + "description": "Whether to enable vote checkpoints and delegation for governance.", + "type": "boolean" +}
- Changed
stellar-stablecoin2 fields changed- added
Input schema / properties / decimalsAdded value: +{ + "description": "The number of decimals used to represent token amounts. Defaults to 7.", + "type": "string" +} - added
Input schema / properties / votesAdded value: +{ + "description": "Whether to enable vote checkpoints and delegation for governance.", + "type": "boolean" +}
- Added
stellar-vault
3 tool updates
- Changed
stellar-fungible1 field changed- added
Input schema / properties / explicitImplementationsAdded value: +{ + "description": "Whether the contract should use explicit trait implementations instead of using the default ones provided by the library.", + "type": "boolean" +}
- Changed
stellar-non-fungible1 field changed- added
Input schema / properties / explicitImplementationsAdded value: +{ + "description": "Whether the contract should use explicit trait implementations instead of using the default ones provided by the library.", + "type": "boolean" +}
- Changed
stellar-stablecoin1 field changed- added
Input schema / properties / explicitImplementationsAdded value: +{ + "description": "Whether the contract should use explicit trait implementations instead of using the default ones provided by the library.", + "type": "boolean" +}
3 tool updates
- First observed
stellar-fungible - First observed
stellar-non-fungible - First observed
stellar-stablecoin
Related MCP Connectors
The OpenZeppelin Solidity Contracts MCP server integrates OpenZeppelin's security and style rules into AI-driven development workflows, enabling AI assistants to generate safe, correct, and production-ready smart contracts. It automatically validates generated code against OpenZeppelin standards (including imports, modifiers, naming conventions, and security checks) and supports various contract types including ERC-20, ERC-721, ERC-1155, Stablecoins, RWA, Governor, and Account contracts through prompt-driven workflows.
The OpenZeppelin Stylus Contracts MCP server generates secure smart contracts for the Arbitrum Stylus environment using OpenZeppelin templates, including ERC-20, ERC-721, and ERC-1155 standards. It automatically validates generated code against OpenZeppelin's security and style rules, enforcing best practices for imports, modifiers, naming conventions, and security checks to prevent common vulnerabilities. The server integrates with AI development tools like Cursor, Claude, Gemini, Windsurf, and VS Code to enable AI-assisted, production-ready smart contract development.
The OpenZeppelin Cairo Contracts MCP server generates secure smart contracts in the Cairo language for Starknet environments based on OpenZeppelin templates. It brings OpenZeppelin's proven security and style rules directly into AI-driven development workflows to create safe, production-ready contracts. Key capabilities include providing templates for ERC-20, ERC-721, ERC-1155, Multisig, Governor, and Vesting contracts.
MCP server for secureFlows: token-free URL builders and integration-linting tools for AI agents.
Related MCP Servers
- AlicenseNot gradedqualityDmaintenanceEnables users to generate and retrieve secure, audited smart contract templates from OpenZeppelin including ERC20, ERC721, ERC1155 tokens, access control, governance, and finance contracts through natural language prompts.MIT
- AlicenseNot gradedqualityCmaintenanceAn MCP server that provides Stellar blockchain tools for account queries, Soroban contract simulation, and boilerplate generation within compatible AI IDEs.6 npmISC
- FlicenseNot gradedqualityDmaintenanceAn MCP server that statically audits Solidity smart contracts for common vulnerabilities like reentrancy and access control, enabling developers to identify and fix security issues via natural language.-
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd
Glama MCP Gateway
Add one secure layer between your agents and this server.