How do I use Uranium MCP Server?

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., "@Uranium MCP Server upload my artwork as an NFT to the 'Digital Gallery' collection" 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.

Uranium MCP Server

by xkelxmc

Overview Schema Related Servers Score Discussions

TypeScript

Remote

Uranium MCP Server

🚀 Quick Install

A Model Context Protocol (MCP) server for working with portal.uranium.pro - creating and managing NFT collections and assets. This server enables LLMs to interact with blockchain NFTs through a simple, structured interface.

Key Features

Fast and efficient NFT management. Direct integration with Uranium API for instant operations.
Multi-collection support. Manage ERC721 and ERC1155 NFT collections seamlessly.
File-based asset creation. Upload images, videos, audio, and documents directly as NFTs.
Bulk operations. List and filter assets across multiple collections with pagination.

Requirements

Node.js 18 or newer
Uranium API key from portal.uranium.pro
VS Code, Cursor, Windsurf, Claude Desktop, Goose or any other MCP client

Getting Started

First, install the Uranium MCP server with your client.

Standard config works in most of the tools:

{
  "mcpServers": {
    "uranium": {
      "command": "npx",
      "args": ["uranium-tools-mcp@latest"],
      "env": {
        "URANIUM_API_KEY": "your_api_key_here"
      }
    }
  }
}

Use the Claude Code CLI to add the Uranium MCP server:

claude mcp add uranium npx uranium-tools-mcp@latest

Then set your URANIUM_API_KEY when prompted.

Add to your Claude Desktop configuration file:

macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%\Claude\claude_desktop_config.json
Linux: ~/.config/Claude/claude_desktop_config.json

{
  "mcpServers": {
    "uranium": {
      "command": "npx",
      "args": ["uranium-tools-mcp@latest"],
      "env": {
        "URANIUM_API_KEY": "your_api_key_here"
      }
    }
  }
}

Create or edit the configuration file ~/.codex/config.toml and add:

[mcp_servers.uranium]
command = "npx"
args = ["uranium-tools-mcp@latest"]
env = { URANIUM_API_KEY = "your_api_key_here" }

For more information, see the Codex MCP documentation.

Click the button to install:

Or install manually:

Go to Cursor Settings -> MCP -> Add new MCP Server. Name it "uranium", use command type with the command npx uranium-tools-mcp@latest. Add environment variable URANIUM_API_KEY with your API key.

Follow the MCP install guide, use the standard config above with your API key.

Click the button to install:

Install in Goose

Or install manually:

Go to Advanced settings -> Extensions -> Add custom extension. Name it "uranium", use type STDIO, and set the command to npx uranium-tools-mcp@latest. Add environment variable URANIUM_API_KEY with your API key. Click "Add Extension".

Click the button to install:

Add MCP Server uranium to LM Studio

Or install manually:

Go to Program in the right sidebar -> Install -> Edit mcp.json. Use the standard config above with your API key.

Follow the MCP Servers documentation. For example in ~/.config/opencode/opencode.json:

{
  "$schema": "https://opencode.ai/config.json",
  "mcp": {
    "uranium": {
      "type": "local",
      "command": [
        "npx",
        "uranium-tools-mcp@latest"
      ],
      "env": {
        "URANIUM_API_KEY": "your_api_key_here"
      },
      "enabled": true
    }
  }
}

Open Qodo Gen chat panel in VSCode or IntelliJ → Connect more tools → + Add new MCP → Paste the standard config above with your API key.

Click Save.

Click the button to install:

Or install manually:

Follow the MCP install guide, use the standard config above. You can also install the Uranium MCP server using the VS Code CLI:

# For VS Code
code --add-mcp '{"name":"uranium","command":"npx","args":["uranium-tools-mcp@latest"],"env":{"URANIUM_API_KEY":"your_api_key_here"}}'

After installation, the Uranium MCP server will be available for use with your GitHub Copilot agent in VS Code.

Follow Windsurf MCP documentation. Use the standard config above with your API key.

Configuration

Environment Variables

URANIUM_API_KEY (required): Your Uranium API key from portal.uranium.pro
URANIUM_BASE_URL (optional): API base URL. Defaults to https://gw.urnm.pro

Example Configuration

{
  "mcpServers": {
    "uranium": {
      "command": "npx",
      "args": ["uranium-tools-mcp@latest"],
      "env": {
        "URANIUM_API_KEY": "your_api_key_here"
        // URANIUM_BASE_URL is optional, defaults to https://gw.urnm.pro
      }
    }
  }
}

Local Installation

If you prefer to install locally:

npm install -g uranium-tools-mcp
# or
pnpm add -g uranium-tools-mcp
# or
yarn global add uranium-tools-mcp

Then use uranium-tools-mcp instead of npx uranium-tools-mcp@latest in the configuration.

Tools

This MCP server provides 4 main tools for NFT management:

list_collections

Description: List all user collections (personal, common, and external)
Parameters: None

create_collection

Description: Create a new NFT collection
Parameters:
- name (string, required): Collection name (3-30 characters, letters, numbers, and [_.-] symbols) [min length: 3, max length: 30]
- symbol (string, required): Collection symbol (3-30 characters, letters, numbers, and underscores) [min length: 3, max length: 30]
- type (string, enum: ERC721, ERC1155, required): Collection type: ERC721 (single NFTs) or ERC1155 (multi-token)

list_assets

Description: List assets with optional filtering by collection, search, and pagination
Parameters:
- contractId (string, optional): Filter assets by collection ID
- page (number, optional): Page number (default: 1) [min: 1, default: 1]
- pageSize (number, optional): Number of assets per page (default: 20, max: 100) [min: 1, max: 100, default: 20]
- sortBy (string, optional): Sort field (default: createdAt) [default: "createdAt"]
- order (string, enum: asc, desc, optional): Sort order (default: asc) [default: "asc"]
- quickFilter (string, optional): Search text to filter assets by title

create_asset

Description: Create a new NFT asset from a local file or base64 data
Parameters:
- filePath (string, optional): Absolute path to the media file (for local files)
- fileData (string, optional): Base64 encoded file data (for Claude Desktop)
- fileName (string, optional): Original filename (required when using fileData)
- mimeType (string, optional): MIME type of the file (required when using fileData, e.g., 'image/png')
- contractId (string, required): ID of the collection to mint the asset in
- title (string, required): Asset title (3-120 characters) [min length: 3, max length: 120]
- description (string, optional): Asset description (optional, max 255 characters) [max length: 255]
- location (string, optional): Location where the asset was created (optional, max 100 characters) [max length: 100]
- editions (number, optional): Number of editions (for ERC1155 collections only, 1-1000) [min: 1, max: 1000]
- shareWithCommunity (boolean, optional): Make the asset discoverable by the community (optional, default: false) [default: false]

Supported File Formats

Images: JPG, JPEG, PNG, GIF, WebP, SVG
Video: MP4, WebM, MOV, AVI
Audio: MP3, WAV, OGG
Documents: PDF, TXT

Development

Building from Source

Clone the repository:

git clone https://github.com/xkelxmc/uranium-mcp.git
cd uranium-mcp

Install dependencies:

npm install

Build the project:

npm run build

Development Commands

# Compile in watch mode
npm run dev

# Build for production
npm run build

# Start server locally
npm start

# Clean build directory
npm run clean

Testing

Using MCP Inspector

Test your MCP server with the MCP Inspector:

# For installed version
npx @modelcontextprotocol/inspector uranium-tools-mcp

# For local development
npm run build:dev
npx @modelcontextprotocol/inspector node build/index.js

Development Testing

# Test with stdio transport
npm run dev:stdio

# Test with HTTP transport
npm run dev:http

# Inspect with HTTP transport
npm run mcp:inspect

Troubleshooting

Common Issues

API Key not working: Make sure your API key is valid and has the necessary permissions at portal.uranium.pro
Connection errors: Check that the URANIUM_BASE_URL is correct (defaults to https://gw.urnm.pro)
File upload issues: Ensure the file path is absolute and the file exists
Collection creation fails: Verify that collection names and symbols follow the required format (3-30 characters, alphanumeric and underscore)

Project Structure

src/
├── api/           # Complete copy of Uranium API from Raycast
├── utils/         # Utilities for validation, formatting, etc.
├── models/        # Upload primitives for working with files
├── tools/         # MCP tools
├── server.ts      # MCP server configuration
├── index.ts       # Entry point
└── config.ts      # API and MCP configuration

License

todo

Support

For issues and questions:

Contact support at uranium.pro

Available Tools

4 tools

create_assetB

Create a new NFT asset from a local file or base64 data

ParametersJSON Schema

Name	Required	Description
`filePath`	No	Absolute path to the media file (for local files)
`fileData`	No	Base64 encoded file data (for Claude Desktop)
`fileName`	No	Original filename (required when using fileData)
`mimeType`	No	MIME type of the file (required when using fileData, e.g., 'image/png')
`contractId`	Yes	ID of the collection to mint the asset in
`title`	Yes	Asset title (3-120 characters)
`description`	No	Asset description (optional, max 255 characters)
`location`	No	Location where the asset was created (optional, max 100 characters)
`editions`	No	Number of editions (for ERC1155 collections only, 1-1000)
`shareWithCommunity`	No	Make the asset discoverable by the community (optional, default: false)

TDQS

B3.2/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 the full burden of behavioral disclosure. While 'Create a new NFT asset' implies a write/mutation operation, the description doesn't address critical behavioral aspects like authentication requirements, rate limits, side effects (e.g., minting on-chain), error handling, or what happens upon success (e.g., returns an asset ID). For a creation tool with zero annotation coverage, this is a significant gap.

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 that directly states the tool's purpose without unnecessary words. It's front-loaded with the core action and resource, making it easy to understand at a glance. Every part of the sentence earns its place by specifying the creation target and input methods.

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 the complexity of a 10-parameter creation tool with no annotations and no output schema, the description is insufficiently complete. It doesn't explain what the tool returns (e.g., asset ID, transaction hash), behavioral traits like permissions or costs, or how it interacts with the blockchain. For a tool that likely involves minting and on-chain operations, more context is needed to guide effective use.

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%, meaning all parameters are documented in the input schema. The description adds minimal value beyond the schema by mentioning the two input sources (local file or base64 data), which loosely maps to filePath and fileData parameters. However, it doesn't provide additional context, constraints, or examples beyond what's already in the schema descriptions, so the baseline score of 3 is appropriate.

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 specific action ('Create a new NFT asset') and the resource involved ('from a local file or base64 data'), distinguishing it from sibling tools like create_collection (which creates collections) and list_assets/list_collections (which are read operations). It precisely communicates what the tool does without being vague or tautological.

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?

The description provides no guidance on when to use this tool versus alternatives like create_collection or list_assets. It mentions the input sources (local file or base64 data) but doesn't specify prerequisites, dependencies, or contextual scenarios for choosing this tool over others. There's no explicit when/when-not or alternative tool references.

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

create_collectionC

Create a new NFT collection

ParametersJSON Schema

Name	Required	Description
`name`	Yes	Collection name (3-30 characters, letters, numbers, and [_.-] symbols)
`symbol`	Yes	Collection symbol (3-30 characters, letters, numbers, and underscores)
`type`	Yes	Collection type: ERC721 (single NFTs) or ERC1155 (multi-token)

TDQS

C2.9/5.0

Behavior2/5

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

With no annotations provided, the description carries full burden for behavioral disclosure. It states 'Create' implies a write/mutation operation, but fails to mention permissions, costs, network effects, or response behavior. This is a significant gap for a creation tool with zero annotation coverage.

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 with zero wasted words. It's appropriately sized and front-loaded, clearly stating the core action without unnecessary elaboration.

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 the complexity of creating an NFT collection (a write operation with potential costs and permissions), no annotations, and no output schema, the description is incomplete. It lacks critical behavioral and contextual details needed for safe and effective tool invocation.

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 three parameters. The description adds no additional parameter semantics beyond what's in the schema, meeting the baseline for high coverage but not enhancing understanding.

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 verb ('Create') and resource ('new NFT collection'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'create_asset' or 'list_collections' beyond the resource type, so it's not fully specific to sibling context.

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?

The description provides no guidance on when to use this tool versus alternatives like 'create_asset' or 'list_collections'. It lacks context about prerequisites, typical scenarios, or exclusions, leaving the agent with minimal usage direction.

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

list_assetsC

List assets with optional filtering by collection, search, and pagination

ParametersJSON Schema

Name	Required	Description	Default
`contractId`	No	Filter assets by collection ID
`page`	No	Page number (default: 1)
`pageSize`	No	Number of assets per page (default: 20, max: 100)
`sortBy`	No	Sort field (default: createdAt)	createdAt
`order`	No	Sort order (default: asc)	asc
`quickFilter`	No	Search text to filter assets by title

TDQS

C2.9/5.0

Behavior2/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions 'optional filtering by collection, search, and pagination' which gives some context about capabilities, but doesn't disclose important behavioral traits like whether this is a read-only operation, potential rate limits, authentication requirements, or what the response format looks like. For a tool with 6 parameters and no annotations, this is insufficient.

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 - a single sentence that efficiently communicates the core functionality and key filtering options. Every word earns its place with no wasted verbiage. The structure is front-loaded with the main purpose followed by key capabilities.

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 the tool has 6 parameters, no annotations, and no output schema, the description is incomplete. It doesn't explain what an 'asset' represents in this context, what fields are returned, or provide any context about the data model. For a list operation with filtering capabilities, more context about the return format and data structure would be helpful.

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 parameters are well-documented in the schema. The description mentions 'optional filtering by collection, search, and pagination' which maps to contractId, quickFilter, page, and pageSize parameters, but doesn't add meaningful semantic context beyond what the schema already provides. The baseline of 3 is appropriate given the comprehensive schema documentation.

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 verb 'List' and resource 'assets', and mentions optional filtering capabilities. It distinguishes from siblings like create_asset and create_collection by being a read operation, though it doesn't explicitly contrast with list_collections. The purpose is specific but could be more differentiated from list_collections.

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?

The description provides no guidance on when to use this tool versus alternatives like list_collections or create_asset. It mentions filtering options but doesn't specify scenarios where filtering is appropriate or when other tools might be better suited. No explicit when/when-not instructions are provided.

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

list_collectionsB

List all user collections (personal, common, and external)

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

B3.1/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 the full burden of behavioral disclosure. It states the tool lists collections but does not describe any behavioral traits such as permissions needed, rate limits, pagination, or output format. The description is minimal and lacks essential context for safe and effective use.

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 that front-loads the core action ('List all user collections') and specifies the scope. There is no wasted language, and it is appropriately sized for a simple listing tool with no parameters.

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 the lack of annotations and output schema, the description is incomplete. It does not explain what the return values look like (e.g., format, structure) or any behavioral aspects like error handling. For a tool with no structured fields to rely on, the description should provide more context to be fully helpful.

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?

The input schema has 0 parameters with 100% coverage, so the schema fully documents the lack of inputs. The description adds no parameter information, which is appropriate since there are no parameters. A baseline of 4 is applied for tools with zero parameters, as the description need not compensate for missing schema details.

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 verb ('List') and resource ('user collections'), specifying the scope includes personal, common, and external collections. It distinguishes the tool from siblings like 'create_collection' (creation vs. listing) and 'list_assets' (collections vs. assets), though it doesn't explicitly contrast with 'create_asset'. The purpose is specific but not fully differentiated from all siblings.

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?

The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites, context for usage, or exclusions. While the tool name and description imply it's for listing collections, there is no explicit comparison to sibling tools like 'list_assets' or advice on when to choose one over the other.

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

B3.4/5.0

Disambiguation5/5

Each tool has a clearly distinct purpose: create_asset and create_collection handle creation of different resource types, while list_assets and list_collections handle listing of those same resource types. There is no overlap in functionality - assets and collections are separate entities with no ambiguity between tools.

Naming Consistency5/5

All tools follow a perfect verb_noun pattern: create_asset, create_collection, list_assets, list_collections. The naming is completely consistent with 'create' for creation operations and 'list' for listing operations, all using snake_case throughout.

Tool Count4/5

Four tools is reasonable for an NFT management server, though slightly minimal. The server covers creation and listing for both assets and collections, which represents a solid foundation, but additional operations like updating or deleting resources would typically be expected for a complete CRUD surface.

Completeness3/5

The server provides create and list operations for both assets and collections, but lacks update and delete functionality. While the core creation and listing workflows are covered, agents cannot modify or remove existing resources, which represents a notable gap in the CRUD lifecycle for this domain.

Maintenance

ActivityInactive

ResponsivenessSyncing

Resources

Need Help?

Reddit Discussion

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

uploadcare A
io.usefulapi
Manage Uploadcare files, groups and webhooks; upload and store files.
Cloud Storage Developer Tools
112
Morphed
app.morphed
Create AI images and videos, manage projects and credits, and use workspace campaign context.
AI & Machine Learning Image & Video Processing
1
Cloudinary Asset Management
io.github.cloudinary
Upload, organize, search, and transform images, videos, and files with AI-powered tools.
Cloud Storage Image & Video Processing Multimedia Processing
2
mistral A
io.usefulapi
Manage your Mistral platform — models, files, batch jobs, agents and RAG document libraries.
AI & Machine Learning RAG Systems
152

Related MCP Servers

Story SDK MCP Server
Blockchain Web3 & Decentralized Tech Developer Tools
piplabs
A
license
Not graded
quality
F
maintenance
Provides tools for managing IP assets and licenses, interacting with the Story Python SDK, and handling operations like minting tokens, registering IP, and uploading metadata to IPFS.
Updated a year ago (2025-10-17 01:24 UTC)
16
MIT
NFTGo MCP Serverofficial
Web3 & Decentralized Tech Blockchain Cryptocurrency
NFTGo
A
license
Not graded
quality
D
maintenance
Provides access to NFTGo's Developer API for retrieving NFT collection details, asset information, market data, wallet information, and search capabilities on the Ethereum blockchain.
Updated a year ago (2025-04-24 14:09 UTC)
17
5
MIT
Uranium MCP Server
Blockchain Web3 & Decentralized Tech Multimedia Processing
urnm
-
license
Not graded
quality
Not graded
maintenance
Enables LLMs to create and manage NFT collections and assets through the Uranium platform. Supports uploading media files, minting NFTs, and managing ERC721/ERC1155 collections on the blockchain.
Updated a year ago (2025-09-12 04:53 UTC)
OriginForge NFT Generator
Blockchain Web3 & Decentralized Tech File Systems
jutalik
F
license
B
quality
D
maintenance
Enables fetching, viewing, and saving NFT data from the Origin Forge API, including retrieving random NFTs, accessing their attributes, color palettes, images, and saving SVG/JSON files locally.
Updated a year ago (2025-07-19 11:21 UTC)
7
1

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/xkelxmc/uranium-mcp'

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

Uranium MCP Server

🚀 Quick Install

Key Features

Requirements

Getting Started

Click the button to install:

Or install manually:

Click the button to install:

Or install manually:

Click the button to install:

Or install manually:

Click the button to install:

Or install manually:

Configuration

Environment Variables

Example Configuration

Local Installation

Tools

list_collections

create_collection

list_assets

create_asset

Supported File Formats

Development

Building from Source

Development Commands

Testing

Using MCP Inspector

Development Testing

Troubleshooting

Common Issues

Project Structure

License

Support

Available Tools

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

NFTGo MCP Serverofficial

Latest Blog Posts

MCP directory API