A
licenseD
qualityD
maintenanceProvides AI assistants with capabilities to generate collision-resistant unique identifiers using UUID v4 and CUID2 algorithms.
1
18
2
MIT
MCP Rand
by turlockmike
The MCP Rand server provides various random generation tools:
Generate RFC 4122 version 4 UUIDs securely
Generate random numbers within a specified range (default 0-100)
Generate Gaussian (normal) random numbers normalized to 0-1
Generate random strings with customizable length and character sets
Generate strong passwords with mixed character types (minimum length 8, default 16)
Roll dice using standard notation (e.g., "2d6", "1d20")
Draw cards from a standard 52-card deck, maintaining deck state between draws
Allows publishing and installing the MCP-rand server as a package from the npm registry
Used to display badges showing the package's npm version and license information
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@MCP Randgenerate a secure password for my new account"
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.
MCP Rand
A Model Context Protocol (MCP) server providing various random generation utilities, including UUID, numbers, strings, passwords, Gaussian distribution, dice rolling, and card drawing.
Installation
npm install mcp-randOr install globally:
npm install -g mcp-randRelated MCP server: password-mcp
Features
UUID Generator
Generates RFC 4122 version 4 UUIDs
Uses Node's native crypto module for secure random generation
No parameters required
Random Number Generator
Generates random numbers within a specified range
Configurable minimum and maximum values (inclusive)
Defaults to range 0-100 if no parameters provided
Gaussian Random Generator
Generates random numbers following a Gaussian (normal) distribution
Normalized to range 0-1
No parameters required
Random String Generator
Generates random strings with configurable length and character sets
Supports multiple character sets:
alphanumeric (default): A-Z, a-z, 0-9
numeric: 0-9
lowercase: a-z
uppercase: A-Z
special: !@#$%^&*()_+-=[]{};'"\|,.<>/?
Configurable string length (defaults to 10)
Password Generator
Generates strong passwords with a mix of character types
Ensures at least one character from each type (uppercase, lowercase, numbers, special)
Configurable length (minimum 8, default 16)
WARNING: While passwords are generated locally, it's recommended to use a dedicated password manager
Dice Roller
Roll multiple dice using standard dice notation
Supports notation like "2d6" (two six-sided dice), "1d20" (one twenty-sided die)
Returns individual rolls and total for each set of dice
Can roll multiple different dice sets at once (e.g., "2d6", "1d20", "4d4")
Card Drawer
Draw cards from a standard 52-card deck
Maintains deck state between draws using base64 encoding
Returns drawn cards and remaining deck state
Supports drawing any number of cards up to the deck size
Properly shuffles available cards before each draw
Usage
As a CLI Tool
npx mcp-randIntegration with MCP Clients
Add to your MCP client configuration:
{
"mcpServers": {
"mcp-rand": {
"command": "node",
"args": ["path/to/mcp-rand/build/index.js"],
"disabled": false,
"alwaysAllow": []
}
}
}Example Usage
// Generate UUID
const uuid = await client.callTool('generate_uuid', {});
console.log(uuid); // e.g., "550e8400-e29b-41d4-a716-446655440000"
// Generate random number
const number = await client.callTool('generate_random_number', {
min: 1,
max: 100
});
console.log(number); // e.g., 42
// Generate Gaussian random number
const gaussian = await client.callTool('generate_gaussian', {});
console.log(gaussian); // e.g., 0.6827
// Generate random string
const string = await client.callTool('generate_string', {
length: 15,
charset: 'alphanumeric'
});
console.log(string); // e.g., "aB9cD8eF7gH6iJ5"
// Generate password
const password = await client.callTool('generate_password', {
length: 20
});
console.log(password); // e.g., "aB9#cD8$eF7@gH6*iJ5"
// Roll dice
const rolls = await client.callTool('roll_dice', {
dice: ['2d6', '1d20', '4d4']
});
console.log(rolls);
/* Output example:
[
{
"dice": "2d6",
"rolls": [3, 1],
"total": 4
},
{
"dice": "1d20",
"rolls": [4],
"total": 4
},
{
"dice": "4d4",
"rolls": [2, 3, 2, 3],
"total": 10
}
]
*/
// Draw cards
const draw1 = await client.callTool('draw_cards', {
count: 5
});
console.log(draw1);
/* Output example:
{
"drawnCards": [
{ "suit": "hearts", "value": "A" },
{ "suit": "diamonds", "value": "7" },
{ "suit": "clubs", "value": "K" },
{ "suit": "spades", "value": "2" },
{ "suit": "hearts", "value": "10" }
],
"remainingCount": 47,
"deckState": "t//+///bDw=="
}
*/
// Draw more cards using previous deck state
const draw2 = await client.callTool('draw_cards', {
count: 3,
deckState: draw1.deckState
});
console.log(draw2);
/* Output example:
{
"drawnCards": [
{ "suit": "diamonds", "value": "Q" },
{ "suit": "clubs", "value": "5" },
{ "suit": "spades", "value": "J" }
],
"remainingCount": 44,
"deckState": "l//+//zbDw=="
}
*/Contributing
Please see CONTRIBUTING.md for development setup and guidelines.
License
ISC
Available Tools
7 toolsdraw_cardsC
Draw cards from a standard deck of playing cards
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| count | Yes | Number of cards to draw | |
| deckState | No | Optional base64 encoded string representing the current deck state |
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 states what the tool does but doesn't describe how it behaves: whether it draws with or without replacement, how the deck state parameter affects behavior, what happens when the deck is exhausted, or what the output format looks like. For a tool with mutation implications (drawing changes deck state), 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 function with zero wasted words. It's appropriately sized and front-loaded, making it immediately clear what the tool does 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 a card-drawing tool with deck state management, no annotations, and no output schema, the description is incomplete. It doesn't explain the return format (e.g., card values, suits), how deck state is used or updated, or error conditions (e.g., drawing more cards than available). For a tool that likely involves state mutation and random selection, more context is needed.
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 already documents both parameters thoroughly. The description doesn't add any meaning beyond what the schema provides about count or deckState. It implies drawing from a deck but doesn't elaborate on parameter interactions or constraints beyond the schema's baseline 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 action ('draw') and resource ('cards from a standard deck of playing cards'), making the purpose immediately understandable. It doesn't explicitly differentiate from sibling tools, but since the siblings are all different generation functions (Gaussian, password, random number, string, UUID, dice), the distinction is inherent rather than explicitly stated.
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 doesn't mention prerequisites like needing a deck state for sequential draws or clarify that it's for card games versus other random generation tools. 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.
generate_gaussianA
Generate a random number following a Gaussian (normal) distribution between 0 and 1
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
TDQS
A4.2/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the tool's behavior by specifying the distribution type and range, but lacks details on randomness source, statistical parameters (e.g., mean, standard deviation), or output format. This is adequate for a simple tool but leaves gaps in behavioral 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 a single, efficient sentence that front-loads the key action and constraints without any wasted words. Every element ('Generate', 'random number', 'Gaussian distribution', 'between 0 and 1') contributes directly to understanding the tool's purpose.
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 simplicity (0 parameters, no output schema, no annotations), the description is nearly complete. It specifies the distribution and range, but lacks output details (e.g., numeric format, precision) and doesn't mention if the range is inclusive or exclusive, leaving minor gaps for a fully informed agent.
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 tool has 0 parameters with 100% schema description coverage, so no parameter documentation is needed. The description compensates by implicitly explaining the lack of parameters through its self-contained specification, earning a baseline score above 3 for clarity in a parameterless context.
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 ('Generate a random number') and the statistical distribution ('following a Gaussian (normal) distribution'), with explicit range constraints ('between 0 and 1'). It distinguishes itself from sibling tools like 'generate_random_number' by specifying the distribution type and range.
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 usage context through the range specification ('between 0 and 1'), which suggests when this tool is appropriate versus alternatives. However, it doesn't explicitly state when not to use it or name specific alternatives among siblings like 'generate_random_number' for uniform distributions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
generate_passwordB
Generate a strong password with a mix of character types. WARNING: While this password is generated locally on your machine, it is recommended to use a dedicated password manager for generating and storing passwords securely.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| length | No | Password length (minimum 8, default 16) |
TDQS
B3.2/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that the password is 'generated locally on your machine,' which adds useful context about the tool's behavior and security implications. However, it doesn't cover other behavioral aspects like performance, error handling, or the specific character types used in the mix.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized with two sentences. The first sentence states the purpose clearly, and the second provides a security warning. While the warning is useful, it could be more front-loaded with tool-specific details, but overall it's efficient with minimal waste.
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 low complexity (one parameter, no output schema, no annotations), the description is somewhat complete but has gaps. It covers the basic purpose and a security note, but lacks details on output format (e.g., what the generated password looks like) and doesn't fully address behavioral context beyond the local generation aspect.
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, with the 'length' parameter documented as 'Password length (minimum 8, default 16).' The description adds no additional parameter information beyond what's in the schema, so it meets the baseline of 3 for high schema coverage without compensating value.
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's purpose: 'Generate a strong password with a mix of character types.' It specifies the verb ('generate') and resource ('password'), though it doesn't explicitly differentiate from sibling tools like 'generate_string' or 'generate_random_number' beyond the password-specific 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. It includes a security warning about using a password manager, but this doesn't help the agent choose between this tool and siblings like 'generate_string' or 'generate_random_number' for password generation scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
generate_random_numberB
Generate a random number within a specified range
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| max | No | Maximum value (inclusive). Defaults to 100. | |
| min | No | Minimum value (inclusive). Defaults to 0. |
TDQS
B3.1/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 mentions the range constraint but doesn't describe distribution (uniform vs other), whether the number is integer or float, what happens with invalid inputs, or any performance/rate limit considerations. For a random number generator with zero annotation coverage, this leaves significant behavioral questions unanswered.
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 for a simple tool and front-loads the essential information. Every word earns its place in conveying the core functionality.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 2-parameter tool with 100% schema coverage but no annotations and no output schema, the description provides basic context but leaves gaps. It doesn't explain the return value format (integer vs float, precision), doesn't address distribution characteristics, and doesn't help differentiate from similar sibling tools. The description is minimally adequate but could be more complete given the tool's 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 description coverage is 100%, with both parameters (min and max) fully documented in the schema. The description adds the concept of 'range' which is already implied by having min and max parameters. It doesn't provide additional syntax, format, or constraint details beyond what the schema already specifies. Baseline 3 is appropriate when schema does the heavy lifting.
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 action ('generate') and resource ('random number') with scope ('within a specified range'). It distinguishes from some siblings like generate_password or generate_uuid but doesn't explicitly differentiate from generate_gaussian or roll_dice which also produce random numbers. The purpose is specific but sibling differentiation is incomplete.
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 about when to use this tool versus alternatives like generate_gaussian (for normal distribution), roll_dice (for discrete integer outcomes), or other random generation siblings. The description only states what it does, not when it's appropriate compared to other tools in the server.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
generate_stringA
Generate a random string with specified length and character set
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| charset | No | Character set to use (alphanumeric, numeric, lowercase, uppercase, special). Defaults to alphanumeric. | |
| length | No | Length of the string to generate. Defaults to 10. |
TDQS
A3.8/5.0
Behavior3/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 states the tool generates random strings, which implies non-destructive behavior, but doesn't mention any rate limits, performance characteristics, randomness quality, or what happens with invalid inputs. The description adds basic context but lacks depth about operational behavior.
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 immediately states the tool's purpose and key parameters. Every word earns its place with zero waste or redundancy. It's appropriately sized for a simple generation tool.
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 random string generator with 2 well-documented parameters and no output schema, the description is reasonably complete. It covers the core purpose and parameters, though it could benefit from mentioning the randomness source or quality. Given the tool's low complexity and good schema coverage, the description is mostly adequate.
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 already fully documents both parameters (charset with enum values and defaults, length with defaults). The description mentions 'specified length and character set' but adds no additional meaning beyond what's in the schema. Baseline 3 is appropriate when schema does the heavy lifting.
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 ('Generate a random string') and specifies the key resources ('with specified length and character set'). It distinguishes from siblings like generate_password, generate_uuid, and generate_random_number by focusing specifically on customizable string generation rather than passwords, UUIDs, or numbers.
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 generating random strings with customizable parameters, but doesn't explicitly state when to use this tool versus alternatives like generate_password (which might have different security characteristics) or generate_uuid (for unique identifiers). No explicit exclusions or comparisons to sibling tools are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
generate_uuidA
Generate a random UUID v4
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
TDQS
A3.9/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It clearly indicates a generation operation (not read-only or destructive) and specifies the UUID version (v4), but lacks details on randomness quality, potential collisions, or output format. It provides basic behavioral context but misses deeper operational traits.
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 waste—'Generate a random UUID v4'—that immediately conveys the core functionality. It's appropriately sized and front-loaded, making every word count.
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 simplicity (0 parameters, no output schema, no annotations), the description is complete enough for basic understanding but lacks depth. It doesn't explain the return value (e.g., format of the UUID) or potential use cases, which could enhance contextual completeness for an AI agent.
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 tool has 0 parameters with 100% schema description coverage, so the schema already fully documents the lack of inputs. The description doesn't need to add parameter information, and it appropriately focuses on the tool's purpose without redundant details, meeting the baseline for parameterless tools.
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 'Generate a random UUID v4' clearly states the specific action (generate) and resource (UUID v4), distinguishing it from sibling tools like generate_password or generate_random_number. It precisely identifies the type of UUID (v4) being generated.
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 context (when a random UUID is needed) but doesn't explicitly state when to use this tool versus alternatives like generate_string or generate_random_number. No exclusions or specific scenarios are mentioned, leaving usage guidance at an implied level.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
roll_diceB
Roll a set of dice using standard dice notation (e.g., "2d6" for two six-sided dice, "3d6+5" for three six-sided dice plus 5)
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| dice | Yes | Array of dice to roll |
TDQS
B3.4/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 explains the input format but does not describe output behavior (e.g., return format, whether results are summed or listed, error handling for invalid notation). This leaves gaps in understanding how the tool behaves beyond basic input.
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 purpose and provides essential examples without unnecessary details. Every part earns its place by clarifying the tool's function and input format concisely.
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 dice-rolling tool with no annotations and no output schema, the description is incomplete. It adequately covers the input but fails to explain the output (e.g., what is returned, format of results), which is critical for an agent to use the tool correctly. More context on behavior is needed.
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 already documents the 'dice' parameter with examples. The description adds marginal value by reinforcing the notation with examples like '2d6' and '3d6+5', but does not provide additional semantics beyond what the schema specifies, such as constraints or advanced usage.
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 ('Roll a set of dice') and the resource ('using standard dice notation'), with explicit examples that distinguish it from sibling tools like generate_random_number or generate_gaussian. It precisely defines what the tool does without ambiguity.
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 dice-rolling scenarios by providing notation examples, but it does not explicitly state when to use this tool versus alternatives like generate_random_number for non-dice random numbers or other sibling tools. No guidance on exclusions or prerequisites is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
TDQS
A3.7/5.0
Disambiguation5/5
Each tool has a clearly distinct purpose with no overlap: drawing cards, generating Gaussian numbers, generating passwords, generating random numbers in a range, generating random strings, generating UUIDs, and rolling dice. The descriptions are specific enough that an agent would never confuse one tool for another.
Naming Consistency5/5
All tools follow a consistent verb_noun pattern with 'generate_' or action-based prefixes like 'draw_' and 'roll_'. The naming is uniform, predictable, and enhances readability across the entire set.
Tool Count5/5
With 7 tools, the server is well-scoped for random generation tasks. Each tool serves a unique function in the domain of randomness, making the count appropriate without being too sparse or overwhelming.
Completeness4/5
The toolset covers a broad range of random generation needs (numbers, strings, UUIDs, passwords, cards, dice) with clear operations. A minor gap is the lack of tools for generating other distributions beyond Gaussian or more specialized random data types, but core workflows are well-supported.
Maintenance
ActivityInactive
ResponsivenessSyncing
Resources
Unclaimed servers have limited discoverability.
Looking for Admin?
If you are the server author, to access and configure the admin panel.
Related MCP Connectors
Generate random values and probability distribution samples.
Developer utilities: color conversion, WCAG contrast, timestamps, UUIDs, and hashing.
Generate IDs, QR codes, and hashes, encode values, geolocate IPs, plus gated host diagnostics.
Exact hashing, base64/hex/URL encoding, JWT decoding and UUIDs for AI agents. No auth required.
Related MCP Servers
- AlicenseAqualityCmaintenanceGenerates strong passwords and evaluates password strength using zxcvbn, with uniform random sampling via Node's crypto.29MIT
- FlicenseNot gradedqualityDmaintenanceCryptographically secure random number generation and randomized resources, including tools for numbers, strings, dice rolls, UUIDs, and passphrases.4
- FlicenseNot gradedqualityCmaintenanceGenerates cryptographically secure, compliant UUIDs (v4, v5, v7) to prevent AI-hallucinated identifiers that would cause database collisions.153
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
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/turlockmike/mcp-rand'
If you have feedback or need assistance with the MCP directory API, please join our Discord server