What can you do with this server?

This server enables a Sui-native minting flow for SHIT tokens, supporting standard user-funded and sponsored transaction flows, plus admin configuration and status-checking tools. * health — Verify the MCP server is alive and properly configured for the target Sui network. * quote_mint_fee — Retrieve the exact mint fee (1 SUI) and mint amount (10,000,000 SHIT) before committing. * check_mint_status — Inspect the configured Sui package and shared MintConfig objects to verify on-chain deployment health. * check_user_mint_status — Look up a user's SHIT balance, mint count, remaining mints (max 10 per wallet), and eligibility. * prepare_mint — Generate an unsigned transaction block the user signs and broadcasts themselves, paying 1 SUI to receive 10,000,000 SHIT. * prepare_sponsored_mint — Generate an unsigned transaction where the user signs as sender/recipient, while a configured sponsor wallet covers gas and the 1 SUI mint fee. * submit_sponsored_mint — Accept the user's signature for a sponsored mint, co-sign as sponsor, and broadcast the fully signed transaction to the Sui network. * prepare_config — Generate an unsigned admin transaction to initialize the shared MintConfig on-chain after the Move package is published, minting the 500,000,000 SHIT LP allocation and locking the TreasuryCap. Key constraints: All tools require an OAuth bearer token (accessToken). Maximum 10 mints per wallet address is enforced at the contract level. The contract also enforces that the recipient must equal the transaction sender, preventing mint bypasses.

Which integrations are available for this server?

Allows minting SHIT tokens on the Sui blockchain, checking user mint status, preparing and submitting mint transactions, and managing mint configuration via Sui native tools.

How do I use Sui MCP SHIT Minter?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Sui MCP SHIT Minter check my eligibility to mint SHIT on Sui testnet" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

Sui MCP SHIT Minter

by nomirizky55

Overview Schema Related Servers Score Discussions

TypeScript

Hybrid

Sui MCP SHIT Minter

MCP server prototype for a Sui-native mint flow:

Codex or another MCP client calls this server.
Each tool is gated by an OAuth bearer token value.
The server checks configured Sui package objects.
The server prepares an unsigned Sui transaction block.
In the standard flow, the user signs and broadcasts with their own Sui wallet.
In the sponsored flow, the user signs as sender and the configured sponsor signs/broadcasts as gas owner.
mint() sends 10,000,000 SHIT to the user's own Sui address and debits 1 SUI from the transaction gas coin.

This is intentionally Sui-native. It does not use EIP-7702, EOA delegation, or EVM transaction types.

Layout

move/ - Sui Move package defining the SHIT coin and mint function.
src/server.ts - MCP server with standard and sponsored mint tools.
src/sui.ts - Sui transaction builders.
src/sponsor.ts - sponsor signer loader for Sui CLI keystore or suiprivkey.
.env.example - Runtime configuration template.

Related MCP server: Sui Butler

MCP Tools

health - checks server and network config.
quote_mint_fee - returns the 1 SUI fee and 10M SHIT mint amount.
check_mint_status - checks configured package and shared mint config objects.
check_user_mint_status - checks a user's SHIT balance, mint count, remaining mints, and eligibility.
prepare_mint - returns base64 Sui transaction bytes for the user to sign and execute.
prepare_sponsored_mint - returns base64 Sui transaction bytes where the user signs and the sponsor pays gas/fee.
submit_sponsored_mint - adds the sponsor signature and broadcasts a sponsored mint signed by the user.
prepare_config - returns base64 Sui transaction bytes to create the shared MintConfig.

Every tool takes accessToken. In a production HTTP MCP deployment, replace this explicit argument with real OAuth middleware that validates the request Authorization header.

Setup

npm install
cp .env.example .env

Fill .env after publishing the Move package:

SUI_NETWORK=testnet
SUI_FULLNODE_URL=https://fullnode.testnet.sui.io:443
MCP_OAUTH_BEARER_TOKEN=replace-with-your-oauth-access-token
SUI_PACKAGE_ID=0x...
SHIT_MINT_CONFIG_ID=0x...
MINT_FEE_MIST=1000000000
FEE_RECIPIENT=0x...
LP_RECIPIENT=0x...
SPONSOR_KEYSTORE_PATH=C:\Users\you\.sui\sui_config\sui.keystore
SPONSOR_KEYSTORE_INDEX=0
# or:
# SPONSOR_PRIVATE_KEY=suiprivkey...

Deploy Move Package

From the repo root:

cd move
sui move build
sui client publish --gas-budget 100000000

Record the created package id, TreasuryCap<SHIT_COIN>, and AdminCap.

Then call prepare_config through MCP using the admin address, AdminCap id, TreasuryCap<SHIT_COIN> id, and LP recipient. Sign and execute the returned transaction bytes with the admin wallet. This mints the 500M SHIT LP allocation to LP_RECIPIENT and moves the treasury cap into the shared MintConfig, so future user mint transactions do not need to touch an admin-owned object.

Record the created shared MintConfig object id in .env as SHIT_MINT_CONFIG_ID.

Run MCP Server

npm run dev

For production:

npm run build
npm start

Run MCP HTTP Server

The HTTP entrypoint uses MCP Streamable HTTP at /mcp and a simple health endpoint at /healthz.

npm run build
npm run start:http

Default URL:

http://127.0.0.1:3000/mcp

Every /mcp request must include:

Authorization: Bearer replace-with-your-oauth-access-token

HTTP config:

MCP_HTTP_HOST=127.0.0.1
MCP_HTTP_PORT=3000
# Use this when binding to 0.0.0.0 behind a reverse proxy.
MCP_ALLOWED_HOSTS=your-domain.com,localhost

For a public deployment, run the Node process behind HTTPS, keep MCP_OAUTH_BEARER_TOKEN secret, and bind either to 127.0.0.1 behind Nginx/Caddy or to 0.0.0.0 with MCP_ALLOWED_HOSTS set to the public domain.

For permanent deployment with Docker and Caddy, see DEPLOY.md.

If you do not have a VPS or domain, use Render instead. See RENDER_DEPLOY.md.

Codex Public Mint Plugin

This repo includes a local Codex plugin scaffold at:

plugins/shit-sui-minter

It contains:

.codex-plugin/plugin.json - plugin metadata.
.mcp.json - Streamable HTTP MCP endpoint config.
skills/shit-sui-mint/SKILL.md - user-facing mint workflow for Codex.

The plugin points to the current public tunnel:

https://curvy-duck-31.loca.lt/mcp

Set MCP_OAUTH_BEARER_TOKEN in the Codex environment before using the plugin. Then a user can ask:

Use the delegated_mint tool 1 time for my Sui wallet 0x...

Codex should check eligibility, prepare a sponsored mint, ask the user to sign with their Sui wallet, submit the signature, and report the transaction digest.

Mint Flow

Call check_user_mint_status before preparing a mint:

{
  "accessToken": "replace-with-your-oauth-access-token",
  "userAddress": "0xUSER_SUI_ADDRESS"
}

The response includes the user's SHIT balance, mintCount, remainingMints, canMint, and mintBlockedReason.

Call prepare_mint with:

{
  "accessToken": "replace-with-your-oauth-access-token",
  "userAddress": "0xUSER_SUI_ADDRESS"
}

The response includes transactionBlock, a base64 Sui transaction block. The wallet should sign and execute it on the configured network. The signer and recipient are the same userAddress.

Supply Rules

Max total supply: 1,000,000,000 SHIT.
LP allocation: 500,000,000 SHIT, minted once during create_config.
Public mint allocation: 500,000,000 SHIT.
Mint size: 10,000,000 SHIT per transaction.
Max wallet mints: 10 mints per signer address.
Contract enforces recipient == tx_context::sender, so a wallet cannot mint to another recipient to bypass the wallet counter.

Important Notes

The TreasuryCap is stored inside the shared MintConfig, which lets users mint through the shared object without requiring an admin signer in the mint transaction.
The Move contract requires the payment coin to equal fee_mist, currently 1_000_000_000 MIST, or 1 SUI.
The logo URL is a placeholder in move/sources/shit_coin.move; replace it before production.

Available Tools

8 tools

check_mint_statusC

Check configured Sui package, treasury cap, and shared mint config objects.

ParametersJSON Schema

Name	Required	Description	Default
`accessToken`	Yes	OAuth bearer token issued to the MCP client.

TDQS

C2.9/5.0

Behavior2/5

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

No annotations provided, so the description must carry full burden. It says 'check,' implying read-only, but does not confirm lack of side effects, rate limits, or authentication requirements beyond the OAuth token parameter.

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?

A single sentence, no fluff, no unnecessary details. Every word is useful and conveys the core purpose efficiently.

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

Completeness2/5

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

Given no output schema and no annotations, the description lacks information about return values, error conditions, or scope (e.g., does it check a specific config or all?). A check tool should hint at what is returned (e.g., status indicators).

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% for the single parameter 'accessToken,' which is already described in the schema. The description adds no additional meaning beyond the schema, 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?

The description clearly states it checks 'configured Sui package, treasury cap, and shared mint config objects,' specifying the verb and resources. It distinguishes from sibling tool 'check_user_mint_status' by focusing on system-level objects rather than user-specific status.

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 use this tool versus alternatives like 'check_user_mint_status' or 'health.' The description only states what it does without context on prerequisites or exclusion cases.

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

check_user_mint_statusA

Check a user's SHIT balance, wallet mint count, remaining mints, and mint eligibility.

ParametersJSON Schema

Name	Required	Description	Default
`accessToken`	Yes	OAuth bearer token issued to the MCP client.
`userAddress`	Yes	Sui address to check.

TDQS

A3.8/5.0

Behavior3/5

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

No annotations are present, so the description carries the burden. It states what is checked but does not disclose whether the operation is read-only, error conditions, or authentication details beyond requiring an OAuth token.

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 a single, efficient sentence (18 words) that front-loads the action and scope with no filler or 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 simple two-parameter schema and no output schema, the description adequately covers the purpose and expected return values. It could mention what happens if the user does not exist, but overall it is sufficiently 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 coverage is 100% with descriptions for both parameters. The description does not add meaning beyond the schema for inputs, but it lists the outputs (balance, count, etc.) which provides context beyond parameters.

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 specifies the verb 'Check' and the resource 'a user's SHIT balance, wallet mint count, remaining mints, and mint eligibility', distinguishing it from the sibling `check_mint_status` which likely operates at a different scope.

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?

Usage is implied by the purpose (user-specific status), but no explicit when-to-use or when-not-to-use guidance is provided. The sibling `check_mint_status` suggests an alternative but is not mentioned.

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

healthA

Check that the MCP server is alive and configured for the selected Sui network.

ParametersJSON Schema

Name	Required	Description	Default
`accessToken`	Yes	OAuth bearer token issued to the MCP client.

TDQS

A3.8/5.0

Behavior3/5

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

No annotations are provided, so the description carries the full burden. It implies a read-only check but doesn't detail what 'alive' or 'configured' entails, nor authentication requirements.

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?

One concise sentence that efficiently conveys the tool's purpose with no unnecessary words.

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 simple one-parameter health-check tool, the description covers the main intent. However, it could mention that the accessToken is used for authentication to give full 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% and already describes the accessToken parameter. The description adds no extra meaning beyond 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 the verb 'check' and the resource 'MCP server' plus 'configured for the selected Sui network'. It ends use—it distinguishes itself from sibling tools that are all mint-related.

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 gives clear context ('check that the MCP server is alive and configured') but does not explicitly state when to use this tool versus alternatives. It could mention that this should be called first before other operations.

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

prepare_configB

Prepare an unsigned admin transaction that creates the shared mint config after publishing the Move package.

ParametersJSON Schema

Name	Required	Description
`accessToken`	Yes	OAuth bearer token issued to the MCP client.
`sender`	Yes	Admin Sui address that owns the AdminCap.
`adminCapId`	Yes	AdminCap object id created at package publish time.
`treasuryCapId`	Yes	TreasuryCap<SHIT_COIN> object id created at package publish time.
`feeRecipient`	No
`lpRecipient`	No
`feeMist`	No

TDQS

B3.4/5.0

Behavior2/5

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

No annotations are provided, so the description carries full burden. It mentions 'unsigned admin transaction' implying a signing step, but does not disclose any behavioral traits such as idempotency, side effects, or required permissions beyond being an admin.

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 a single, concise sentence that efficiently communicates the tool's purpose without extraneous words.

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

Completeness2/5

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

Given no annotations, no output schema, and only moderate parameter coverage, the description lacks sufficient detail on return values, error states, or prerequisites beyond 'after publishing the Move package'. The tool's complexity (7 parameters, admin transaction) demands more contextual information.

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 57% (4 of 7 parameters have descriptions). The description adds no parameter-specific meaning; it only gives high-level context. Some parameters like feeMist and lpRecipient lack descriptions in both schema and description, but overall the description does not significantly enhance understanding beyond 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?

Description clearly states the tool prepares an unsigned admin transaction to create the shared mint config after publishing the Move package. The verb 'prepare' and resource 'unsigned admin transaction' are specific, and the context distinguishes it from sibling tools like prepare_mint or prepare_sponsored_mint.

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?

Description implies usage context ('after publishing the Move package') but does not explicitly state when to use this tool vs alternatives, nor does it provide when-not-to-use or exclusion criteria.

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

prepare_mintA

Prepare an unsigned Sui transaction that pays 1 SUI and mints 10M SHIT to the user's own address.

ParametersJSON Schema

Name	Required	Description	Default
`accessToken`	Yes	OAuth bearer token issued to the MCP client.
`userAddress`	Yes	Sui address that signs, pays, and receives the mint.

TDQS

A3.6/5.0

Behavior3/5

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

No annotations are present, so the description carries the full disclosure burden. It states the transaction is 'unsigned' but does not explain that it requires subsequent signing or submission, or mention any side effects, permissions, or rate limits. The description is adequate but lacks depth for a mutation-like 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 a single sentence that immediately communicates the core purpose. No extraneous words or information – every part is essential.

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?

Despite no output schema or annotations, the description covers the main action for a simple tool. However, it could mention that the output is an unsigned transaction object and note the relationship to siblings like submit_sponsored_mint, which would improve completeness.

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 confirms the userAddress role but adds no new meaning beyond the schema's own descriptions. It does not elaborate on parameter formats or constraints.

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 prepares an unsigned Sui transaction that pays 1 SUI and mints 10M SHIT to the user's own address. This specific verb+resource combination distinguishes it from siblings like prepare_sponsored_mint (sponsored) and check_mint_status (status checking).

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 such as prepare_sponsored_mint or quote_mint_fee. The description only states what the tool does, without indicating context or exclusions.

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

prepare_sponsored_mintA

Prepare an unsigned Sui transaction where the user signs as sender/recipient and the configured sponsor pays gas plus the 1 SUI mint fee.

ParametersJSON Schema

Name	Required	Description	Default
`accessToken`	Yes	OAuth bearer token issued to the MCP client.
`userAddress`	Yes	Sui address that signs and receives the mint.

TDQS

A3.9/5.0

Behavior3/5

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

No annotations provided, so description carries full burden. It discloses roles (user signs, sponsor pays gas+1 SUI fee) and that it prepares an unsigned transaction. However, it omits side effects, prerequisites (e.g., configured sponsor), and lifecycle (next step: submit).

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?

Single sentence of 26 words, front-loaded with the action 'Prepare an unsigned Sui transaction'. No redundant or unnecessary information. Each word contributes meaning.

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?

With no output schema and two params, the description lacks context on the return value (unsigned transaction blob) and the relationship to sibling tools like 'submit_sponsored_mint'. It hints at sponsorship but misses the overall workflow.

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

Parameters4/5

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

Schema has 100% coverage with clear descriptions for both parameters. The description adds value by specifying that the user signs and receives the mint, complementing the schema. No enums or nested objects. Baseline 3 is exceeded.

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 'Prepare an unsigned Sui transaction' with specific roles: user signs as sender/recipient and sponsor pays gas plus fee. It distinguishes from sibling 'prepare_mint' by specifying the sponsorship arrangement.

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 for sponsored mints but does not explicitly state when to use this tool versus alternatives like 'prepare_mint' or 'submit_sponsored_mint'. No when-not-to-use or exclusions are provided.

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

quote_mint_feeB

Return the exact mint fee and amount for the SHIT mint flow.

ParametersJSON Schema

Name	Required	Description	Default
`accessToken`	Yes	OAuth bearer token issued to the MCP client.

TDQS

B3.1/5.0

Behavior2/5

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

No annotations provided, and the description only states the return type without disclosing behavioral traits like side effects (mutation vs read), authentication requirements beyond the token, or rate limits.

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?

Single sentence with no unnecessary words. Front-loaded with the core action and resource.

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 no output schema, the description could explain the return format (e.g., numeric values, units). It meets minimal viability but leaves the output structure unspecified.

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% for the single parameter (accessToken) with a description, so the description adds no new meaning. Baseline of 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?

The description clearly states the tool returns the mint fee and amount for the SHIT mint flow, using a specific verb ('Return') and resource. It distinguishes from sibling mint tools by focusing on the fee quotation step.

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 use this tool versus alternatives like prepare_mint or submit_sponsored_mint. No exclusions or prerequisites mentioned.

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

submit_sponsored_mintA

Sign a prepared sponsored mint transaction as the configured sponsor and broadcast it with the user's signature.

ParametersJSON Schema

Name	Required	Description
`accessToken`	Yes	OAuth bearer token issued to the MCP client.
`userAddress`	Yes	Sui address that signed and receives the mint.
`transactionBlock`	Yes	Base64 Sui transaction block returned by prepare_sponsored_mint.
`userSignature`	Yes	Serialized Sui transaction signature from the user wallet.

TDQS

A3.9/5.0

Behavior3/5

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

Without annotations, the description carries full burden. It discloses that the action is a write (broadcast) and involves signing. However, it does not detail success/failure behavior, side effects, or authorization requirements beyond the accessToken parameter. It lacks specificity on what happens after broadcast.

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 a single sentence that efficiently conveys the tool's purpose without extraneous information. It is front-loaded and concise.

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 tool's complexity (4 required parameters, multi-step workflow, no output schema), the description covers the basic action but omits output hints, error scenarios, and prerequisite conditions. It relies on the context from sibling tools like prepare_sponsored_mint. Without an output schema, it would benefit from mentioning what the tool returns (e.g., transaction hash).

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 schema has 100% coverage with descriptions for all parameters, so the baseline is 3. The tool description adds context by explaining the role of each parameter in the two-step signing process, but does not provide additional meaning beyond what schema descriptions already give.

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 signs a prepared sponsored mint transaction as the sponsor and broadcasts it with the user's signature. It uses a specific verb (sign and broadcast) and resource (sponsored mint transaction), which distinguishes it from sibling tools like prepare_sponsored_mint that prepare the transaction.

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 the tool is the final step after prepare_sponsored_mint by mentioning 'prepared sponsored mint transaction'. It also indicates it is for the configured sponsor. However, it does not explicitly state when not to use or provide alternatives, such as if the user is not the sponsor.

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

Install Server

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

TDQS

A3.8/5.0

Disambiguation5/5

Each tool has a unique, clearly defined purpose: checking server objects, checking user status, health, preparing config, preparing mint transactions (regular and sponsored), quoting fees, and submitting sponsored transactions. No overlap.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern with underscores (e.g., check_mint_status, prepare_mint, quote_mint_fee). No mixing of conventions.

Tool Count5/5

8 tools is appropriate for the minting domain, covering health, configuration, status checks, fee quotes, and both regular and sponsored mint flows without unnecessary bloat or missing essentials.

Completeness5/5

The tool surface covers the full lifecycle: server health, config setup, user status, fee query, regular mint, sponsored mint preparation and submission. No obvious gaps for the intended purpose.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

agentic-commerce A
io.bosonprotocol
MCP server for Boson Protocol — on-chain agentic commerce for physical & digital goods.
Blockchain E-commerce & Retail Autonomous Agents
632
mcp-klever-vm A
io.github.klever-io
MCP server for Klever blockchain smart contract development.
Blockchain Developer Tools Code Execution
16331
BittensorMCP
io.github.btmcp
Hosted MCP server for live Bittensor chain reads and self-custodial on-chain writes.
Blockchain Cryptocurrency Web3 & Decentralized Tech
1
mcp-server A
com.blockscout
MCP server for Blockscout
Blockchain Web3 & Decentralized Tech Search
16244

Related MCP Servers

sui-trader-mcp
Blockchain Agent Orchestration
kukapay
A
license
Not graded
quality
D
maintenance
An MCP server designed for AI agents to perform optimal token swaps on the Sui blockchain.
Updated a year ago (2025-05-10 08:39 UTC)
6
MIT
Sui Butler
Blockchain Web3 & Decentralized Tech Developer Tools
tamago-labs
A
license
Not graded
quality
F
maintenance
An MCP server for the Sui blockchain that enables AI agents to manage accounts, execute token swaps, and perform smart contract development using the Sui CLI. It supports over 30 tools for DeFi operations, staking, and market data via Pyth price oracles.
Updated a year ago (2025-06-16 09:04 UTC)
21
2
MIT
Sui MCP Server
Blockchain Web3 & Decentralized Tech Developer Tools
EasonC13-agent
A
license
A
quality
D
maintenance
An MCP server providing tools for Sui blockchain interaction, including wallet management and Move smart contract development. It enables users to build, test, and publish contracts, query on-chain objects, and execute transactions through Claude.
Updated 7 months ago (2026-02-15 17:50 UTC)
14
11
MIT
sui-mcp-server
Blockchain Web3 & Decentralized Tech Cryptocurrency
abhinavg6
A
license
A
quality
D
maintenance
A local-first MCP server that enables AI agents to query the Sui blockchain using gRPC, GraphQL, and Archival Service, with auto-routing and LLM-friendly responses.
Updated 4 months ago (2026-05-08 15:30 UTC)
29
79
5
Apache 2.0

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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/nomirizky55/shit-sui-mcp2'

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

Sui MCP SHIT Minter

Layout

MCP Tools

Setup

Deploy Move Package

Run MCP Server

Run MCP HTTP Server

Codex Public Mint Plugin

Mint Flow

Sponsored Mint Flow

Supply Rules

Important Notes

Available Tools

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

MCP directory API