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-devutils generate a new UUID"
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.
A production-ready MCP (Model Context Protocol) server providing essential utility functions for AI development workflows.
UUID v4 Generation: Generate random UUIDs
Base64 Encoding/Decoding: Encode and decode text to/from Base64 format
Timestamp Conversion: Convert between Unix timestamps and human-readable datetime strings
Hash Computation: Compute MD5 and SHA256 hashes of text strings
Related MCP server: @revxl/devtools
Python >= 3.10
pip install mcp-devutilsclaude mcp add "mcp-devutils" --command "mcp-devutils"git clone https://github.com/yourusername/mcp-devutils.git
cd mcp-devutils
pip install -e .You can run the MCP server using either the command-line script or directly with Python:
Using the command-line script:
mcp-devutilsUsing Python directly:
python -m mcp_devutils.serverRunning from source directory:
python src/mcp_devutils/server.pyTool | Description |
| Generate a random UUID v4 |
| Encode text to Base64 format |
| Decode Base64 to text |
| Convert Unix timestamp to human-readable datetime |
| Convert datetime to Unix timestamp |
| Compute MD5 hash of text |
| Compute SHA256 hash of text |
generate_uuidGenerate a random UUID v4.
Returns:
str: A UUID v4 string (e.g., 123e4567-e89b-12d3-a456-426614174000)
base64_encodeEncode text to Base64 format.
Parameters:
text (str): The text to encode
Returns:
str: The Base64 encoded string
base64_decodeDecode Base64 to text.
Parameters:
encoded_text (str): The Base64 encoded text to decode
Returns:
str: The decoded text string
timestamp_to_datetimeConvert Unix timestamp to human-readable datetime.
Parameters:
timestamp (float): Unix timestamp in seconds
Returns:
str: Datetime string in ISO 8601 format (UTC)
datetime_to_timestampConvert datetime to Unix timestamp.
Parameters:
datetime_str (str): Datetime string in ISO 8601 format (e.g., 2024-01-01T12:00:00Z)
Returns:
float: Unix timestamp in seconds
md5_hashCompute MD5 hash of text.
Parameters:
text (str): The text to hash
Returns:
str: MD5 hash as hexadecimal string
sha256_hashCompute SHA256 hash of text.
Parameters:
text (str): The text to hash
Returns:
str: SHA256 hash as hexadecimal string
Open Claude Desktop
Go to Settings → Model Context Protocol (MCP)
Click "Add Server"
Select "Command" as the connection type
Enter the command:
mcp-devutilsClick "Connect"
Open Cursor
Open Command Palette (Ctrl+Shift+P or Cmd+Shift+P)
Select "MCP: Add Server"
Choose "Command" from the dropdown
Enter the command:
mcp-devutilsClick "OK"
You can also configure MCP clients using a JSON configuration file:
{
"name": "mcp-devutils",
"command": "mcp-devutils",
"type": "stdio"
}Install build tools:
pip install build twinepython -m buildThis creates a dist/ directory with .tar.gz and .whl files.
twine upload dist/*You'll be prompted for your PyPI username and password.
twine upload --repository testpypi dist/*pip install pytest
pytestpip install mypy
mypy src/This project is licensed under the MIT License - see the LICENSE file for details.
Decode a Base64 string back to text.
| Name | Required | Description | Default |
|---|---|---|---|
| encoded_text | Yes | The Base64 encoded string to decode. |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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 only mentions the action and output type but does not address invalid input handling, whitespace tolerance, or character set assumptions, leaving the agent without critical error-handling expectations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with no redundant words. It is appropriately concise for a simple tool and front-loads the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity, one required parameter, and presence of an output schema, the description is mostly adequate. However, it omits any note about decoding failures or edge cases, which might be important for an agent to anticipate, so it is not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already documents the only parameter (encoded_text) with a description. Schema coverage is 100%, so the description adds no additional semantic meaning beyond what the schema provides. Baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action (decode) and resource (Base64 string), with the result 'back to text.' This distinguishes it from the sibling base64_encode, making its purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided. The description does not indicate when to choose this tool over alternatives or mention any prerequisites, relying solely on the tool name for context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Encode a text string to Base64 format.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | The text string to encode. |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It states the core operation but adds no extra context beyond what the name implies, such as handling of Unicode, standard Base64 padding, or edge cases. For a simple pure function, this is adequate but not enriching.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with zero wasted words. Every word earns its place by directly conveying the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and the presence of an output schema (which handles return-value documentation), the description is sufficient. It would be improved by mentioning any encoding nuances, but for a basic utility, this is adequately complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers 100% of the parameter (text) with a description that mirrors the tool description. The description adds no additional meaning beyond the schema, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Encode') and resource ('a text string to Base64 format'), clearly distinguishing it from the sibling base64_decode tool. It unambiguously states what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies its use case: encoding text to Base64. It doesn't explicitly mention when not to use it or name alternative tools, but the sibling list includes base64_decode, which intuitively signals the opposite operation. This provides clear context without explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Convert a human-readable datetime string to a Unix timestamp.
| Name | Required | Description | Default |
|---|---|---|---|
| datetime_str | Yes | The datetime string in ISO 8601 format. |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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 only states the conversion and does not mention timezone handling, default assumptions for naive datetimes, error behavior, or output precision (e.g., seconds vs milliseconds), which are important for a datetime conversion tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that front-loads the action ('Convert') and avoids any wasted words. Every word contributes to understanding the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one parameter and an output schema, and the description captures the core purpose. However, without annotations, it lacks any behavioral context such as timezone handling or error cases, leaving gaps that are important for a datetime conversion tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already fully describes the single parameter datetime_str as 'The datetime string in ISO 8601 format' (100% schema coverage). The description adds no additional parameter-level meaning, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Convert a human-readable datetime string to a Unix timestamp' – a specific verb (Convert) and resource (datetime string → Unix timestamp). It clearly distinguishes from sibling tool timestamp_to_datetime, which performs the reverse conversion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies the use case: when you have a human-readable datetime string and need a Unix timestamp. However, it does not explicitly name alternatives or exclusions, such as 'use timestamp_to_datetime for the reverse direction,' so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate a random UUID (Universally Unique Identifier) version 4.
UUID v4 is generated using random or pseudo-random numbers. It does not contain any information about the host, time, or MAC address.
Returns: str: A UUID v4 string in standard format (e.g., '123e4567-e89b-12d3-a456-426614174000').
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
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 specifies that generation uses random or pseudo-random numbers, that the UUID contains no host/time/MAC information, and it explicitly documents the return type and format. This exceeds what a basic 'Generate UUID' would convey.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded, with the core purpose in the first sentence. It includes only essential details: the generation mechanism, privacy property, and return format. Every sentence earns its place without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite being a simple tool, the description is fully complete. It explains what the tool does, how it works, and what it returns. Given that there is an output schema, the explicit return type example is a bonus but not strictly necessary. No missing information for a tool of this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4 per the rubric. The description adds no parameter information because none exists; it appropriately focuses on the output and behavior instead.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function with a specific verb and resource: 'Generate a random UUID (Universally Unique Identifier) version 4.' This immediately distinguishes it from sibling tools like base64_encode or sha256_hash, which perform different operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
While no alternatives are explicitly mentioned, the description provides clear context by explaining UUID v4 properties (random, no host/time/MAC info), making it obvious this is for generating unique identifiers, not for encoding or hashing. There are no exclusions, but the use case is unambiguous for a parameterless tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compute the MD5 hash of a text string.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | The text string to hash. |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, but it does not disclose behavioral traits such as the output format (e.g., hex string), determinism, or the fact that MD5 is not cryptographically secure. This is a minimal description that does not inform the agent about important behavioral aspects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is direct and free of unnecessary words. It effectively communicates the tool's function without verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple utility with one parameter and an output schema, the description is adequate to convey the core purpose. However, it could benefit from a brief note about output format or common use cases, but the presence of an output schema reduces the need for that.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides 100% coverage for the text parameter with a clear description ('The text string to hash'). The tool description adds no additional parameter semantics, matching the baseline of 3 for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool computes the MD5 hash of a text string, using a specific verb and resource. It distinguishes itself from siblings like sha256_hash (different algorithm) and base64_encode/decode (encoding, not hashing).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 when to prefer MD5 over SHA-256 or when to avoid MD5 due to security concerns. The description only states the operation without contextualizing its use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compute the SHA256 hash of a text string.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | The text string to hash. |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It fails to mention the output format (e.g., hexadecimal string) or character encoding assumptions, leaving important behavior undocumented.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with no filler. Every word earns its place, and it is appropriately sized for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple and an output schema exists, so the description is minimally viable. However, it lacks usage context, output format specifics, and encoding details, leaving clear gaps in completeness for a fully independent description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already describes the 'text' parameter as 'The text string to hash,' and the tool description repeats the same concept without adding encoding details or constraints. Since schema coverage is 100%, the description adds minimal extra value beyond the structured field.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the operation ('Compute') and the specific resource (SHA256 hash of a text string). It distinguishes the tool from siblings like md5_hash and base64_encode by naming the exact algorithm and operation type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 over alternatives like md5_hash or base64_encode. There are no explicit conditions or exclusions, leaving the agent without context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Convert a Unix timestamp to a human-readable datetime string.
| Name | Required | Description | Default |
|---|---|---|---|
| timestamp | Yes | The Unix timestamp (seconds since epoch). |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility for behavioral disclosure. It does not mention timezone handling (e.g., UTC vs local), output format specifics, or any edge cases. For a conversion tool, this is a notable gap, as the result may vary depending on the timezone assumed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no redundant information. Every word contributes to conveying the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, with one parameter and an output schema. The description is adequate for basic understanding, but it lacks mention of timezone assumptions and output format specifics. Since an output schema exists, it may cover format, but the timezone question remains unresolved, leaving a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully documents the single parameter (timestamp, seconds since epoch) with 100% coverage. The description adds no additional semantic detail beyond the schema, so it matches the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description uses specific verb 'Convert' and clearly states input (Unix timestamp) and output (human-readable datetime string). It distinguishes itself from the sibling tool datetime_to_timestamp, which performs the reverse conversion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies when to use this tool: when a Unix timestamp needs conversion to a readable datetime. It doesn't explicitly name alternatives, but the sibling list includes the reverse tool, providing context. However, there is no explicit when-not-to-use guidance, so it misses a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v1.0.0base64_decodebase64_encodedatetime_to_timestampgenerate_uuidmd5_hashsha256_hashtimestamp_to_datetimeEach tool provides a unique utility: UUID generation, Base64 encoding/decoding, timestamp/datetime conversion, and MD5/SHA256 hashing. The two hash functions are distinct algorithms, and the pairs are clearly inverse operations.
All tool names use lowercase snake_case and are descriptive, but they follow different syntactic patterns: 'generate_uuid' is verb-first, 'base64_encode' is object-first, and 'timestamp_to_datetime' uses a noun-to-noun structure. This slight inconsistency prevents a perfect score.
Seven tools is a well-scoped set for a utilities server, covering several common developer tasks without excessive bloat.
The set covers fundamental utilities like encoding, decoding, hashing, and time conversion, with bidirectional support for conversions. However, other common dev utilities such as URL encoding, hex encoding, or JSON formatting are absent, leaving minor gaps.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Exact hashing, base64/hex/URL encoding, JWT decoding and UUIDs for AI agents. No auth required.
Developer utilities: color conversion, WCAG contrast, timestamps, UUIDs, and hashing.
7 utility tools in here: exchange rate, UUID, hash, Base64, timestamp, calculator, unit conversion.
500+ deterministic tools for AI agents: math, conversion, validation, hashing, encoding, date/time.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/Hhh997921/mcp-devutils'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
