How do I use devkit-mcp?

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., "@devkit-mcp What's the SHA-256 of 'hunter2'?" 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.

devkit-mcp

by lllNuggetslll

Overview Schema Related Servers Score Discussions

TypeScript

Local

devkit-mcp

A Model Context Protocol server that gives an AI assistant seven everyday developer utilities: sending HTTP requests, inspecting JWTs, hashing, generating UUIDs, testing regular expressions, explaining cron schedules, and encoding text.

No API keys, no accounts, no configuration. Clone it, build it, point a client at it.

┌────────────┐   MCP over stdio   ┌──────────────┐
│  AI client │ ◄────────────────► │  devkit-mcp  │
│  (Claude)  │    JSON-RPC 2.0    │   7 tools    │
└────────────┘                    └──────────────┘

Why this exists

Language models are bad at exactly the things these tools are good at: computing a SHA-256 by hand, predicting when 0 9 * * 1-5 next fires in America/New_York, or deciding whether a base64 string round-trips. Each tool here replaces a plausible-sounding guess with a real answer.

Related MCP server: mcp-dev-utils

Tools

Tool	What it does
`http_request`	Sends an HTTP request and returns status, headers, timing, and body. Parses JSON bodies automatically. Redirects are followed manually and re-checked at every hop.
`decode_jwt`	Decodes a JWT header and payload, and reports `iat`/`nbf`/`exp` in epoch and ISO form with expiry status. Does not verify signatures — and says so in every response.
`hash_text`	MD5, SHA-1, SHA-256, SHA-384, SHA-512 digests or keyed HMACs, in hex, base64, or base64url. Optionally verifies against an expected digest in constant time.
`generate_uuid`	UUIDv4 (random) or UUIDv7 (time-ordered, RFC 9562) from a cryptographically secure source.
`regex_test`	Runs a regex and returns every match with its offset, positional groups, and named groups. Can preview a replacement.
`cron_explain`	Translates a cron expression to plain English and lists its next runs in a given timezone. Handles 5-field and 6-field syntax.
`transform_text`	base64, base64url, hex, and URL encoding in both directions, plus JSON formatting and minification. Decoders reject bad input instead of returning garbage.

Install

Requires Node.js 20 or newer.

git clone https://github.com/lllNuggetslll/devkit-mcp.git
cd devkit-mcp
npm install
npm run build

Connect it to a client

Claude Code

claude mcp add devkit -- node /absolute/path/to/devkit-mcp/dist/index.js

Claude Desktop

Add this to claude_desktop_config.json:

macOS — ~/Library/Application Support/Claude/claude_desktop_config.json
Windows — %APPDATA%\Claude\claude_desktop_config.json

{
  "mcpServers": {
    "devkit": {
      "command": "node",
      "args": ["/absolute/path/to/devkit-mcp/dist/index.js"]
    }
  }
}

Restart the client, and the seven tools appear.

Anything else

The server speaks MCP over stdio, so any compliant client works:

node dist/index.js

Try it

Once connected, these all work in plain language:

"What's the SHA-256 of hunter2?"
"When does 0 */4 * * * next run in Tokyo time?"
"Decode this JWT and tell me if it's expired."
"Does ^\d{3}-\d{4}$ match 555-1234?"
"Generate 5 UUIDv7s for my database seeds."
"GET https://api.github.com/repos/anthropics/claude-code and show me the star count."

Network access and SSRF

http_request refuses requests to loopback, link-local, and RFC 1918 addresses by default.

This matters more for an MCP server than for an ordinary HTTP client. The server takes its instructions from a model, and a model can be steered by whatever text it just read — a web page, an issue comment, a log file. An unrestricted fetch tool is therefore a server-side request forgery primitive aimed at everything the host machine can reach, including cloud metadata endpoints like 169.254.169.254.

The guard resolves hostnames before deciding, so a DNS record pointing at 127.0.0.1 does not get through, and it re-checks every redirect hop rather than trusting the first URL.

Testing a local API is the legitimate case for this, so it is one variable away:

{
  "mcpServers": {
    "devkit": {
      "command": "node",
      "args": ["/absolute/path/to/devkit-mcp/dist/index.js"],
      "env": { "DEVKIT_ALLOW_PRIVATE_HOSTS": "1" }
    }
  }
}

Other limits: responses are capped at 256 KB, redirects at 5 hops, and requests time out after 15 seconds by default (60 seconds maximum).

Development

npm test          # run the suite
npm run test:watch
npm run typecheck
npm run dev       # tsc --watch

The suite has 38 tests in two layers. tests/tools.test.ts covers the pure functions, including published test vectors — the RFC 4231 HMAC-SHA256 vector, the known SHA-256 of the empty string — plus the edge cases worth pinning down: zero-length regex matches that would otherwise loop forever, IPv4-mapped IPv6 addresses like ::ffff:127.0.0.1 that would slip past a naive private-range check, and encodings that must round-trip exactly.

tests/server.test.ts runs the real server against a real MCP client over an in-memory transport, so tool registration, schema generation, defaults, and error results are verified through the protocol rather than around it.

How it is put together

src/
  index.ts          entry point; stdio transport and signal handling
  server.ts         builds the McpServer and registers every tool
  tools/
    types.ts        ToolDefinition contract and result helpers
    index.ts        the tool registry
    http.ts         http_request, plus the SSRF host policy
    jwt.ts  hash.ts  uuid.ts  regex.ts  cron.ts  text.ts

Every tool is a ToolDefinition: a name, a description, a Zod input schema, MCP annotations, and a handler. server.ts iterates the registry and registers each one, so adding a tool means writing a module and adding a line to tools/index.ts — nothing else changes.

Two conventions are worth calling out:

The logic is separate from the protocol. Each module exports a plain function — hashText, decodeJwt, explainCron — that knows nothing about MCP. The tool wrapper handles argument parsing and result formatting. That is what lets the unit tests call the real logic directly, with no transport in the way.

Failures are results, not exceptions. MCP models a tool failure as an ordinary response with isError: true, which lets the model read the message and correct itself. A thrown protocol error would just look like a broken server. Every handler catches and returns fail(message) instead.

Tools also declare their side effects through MCP annotations, so a host can decide what needs approval: everything is readOnlyHint: true except http_request, which is the only one marked openWorldHint: true.

License

MIT

Available Tools

7 tools

cron_explainExplain a cron expressionA

Read-only

Translates a cron expression into plain English and lists its next scheduled runs in a given timezone. Handles both 5-field and 6-field (seconds) syntax, and reports the interval between runs so an accidentally too-frequent schedule is obvious.

ParametersJSON Schema

Name	Required	Description	Default
`count`	No	How many upcoming runs to list.
`timezone`	No	IANA timezone name used to resolve the schedule, e.g. "America/New_York".	UTC
`expression`	Yes	A cron expression, either 5-field or 6-field with a leading seconds field.

TDQS

A4.4/5.0

Behavior4/5

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

Annotations already mark the tool as read-only (readOnlyHint=true). The description adds value by disclosing that the output includes both a plain English translation and a list of upcoming runs, and that the interval is explicitly reported to highlight potentially problematic schedules. No contradictions with annotations.

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?

Two sentences, each serving a distinct purpose: first sentence states the core function, second sentence adds technical scope and a practical benefit. No redundant or filler content.

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

Completeness4/5

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

The description covers the tool's purpose, parameters, and output features (plain English, next runs, interval). Given the absence of an output schema, it adequately communicates what the user will receive. A minor gap is the lack of error handling information (e.g., invalid expression), but for a tool of this simplicity, the description is largely complete.

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 schema covers all three parameters with descriptions (100% coverage). The description adds context beyond the schema by explaining that the expression can be 5 or 6 fields, and that the timezone uses IANA names. It also adds the output feature of reporting the interval, which is not in 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 that the tool translates a cron expression into plain English and lists next scheduled runs, specifying it handles both 5-field and 6-field syntax. This specific verb+resource description distinguishes it from all sibling tools, which cover different domains like HTTP requests, JWT decoding, hashing, etc.

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 when a cron expression needs interpretation, and notes an additional use case: reporting the interval to catch accidentally too-frequent schedules. While no explicit when-not-to-use or alternatives are provided, the sibling tools are sufficiently distinct that no further guidance is needed.

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

decode_jwtDecode a JWTA

Read-onlyIdempotent

Decodes the header and payload of a JSON Web Token and reports the timing claims (iat, nbf, exp) in both epoch and ISO form, along with whether the token is expired. The signature is returned but NOT verified — this tool inspects tokens, it does not validate them, and the result always says so.

ParametersJSON Schema

Name	Required	Description	Default
`token`	Yes	The JWT to decode, with or without a "Bearer " prefix.

TDQS

A4.5/5.0

Behavior5/5

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

Annotations already indicate readOnlyHint and idempotentHint. The description adds crucial behavioral details: the signature is returned but not verified, and the result always states this. No contradictions.

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?

Two sentences, front-loaded with the core action, followed by important caveats. Every sentence adds value with no redundancy.

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

Completeness5/5

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

For a single-parameter tool with no output schema, the description fully covers what the tool does, what it returns, and what it omits. No gaps remain.

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 already describes the token parameter with full coverage. The description does not add new semantic detail beyond mentioning the tool accepts a JWT, which is already implied by the parameter name and schema description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it decodes the header and payload of a JWT, reports specific claims and expiry, and notes it does not verify. This distinguishes it from a validation tool, and siblings like hash_text or generate_uuid are unrelated.

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 explicitly states the tool inspects but does not validate tokens, guiding the agent not to use it for verification. It does not name an alternative tool, but the context is clear enough for proper usage.

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

generate_uuidGenerate UUIDsA

Read-only

Generates one or more UUIDs using a cryptographically secure random source. Version 4 is fully random; version 7 (RFC 9562) embeds a millisecond timestamp so the values sort chronologically, which makes them well suited to database primary keys.

ParametersJSON Schema

Name	Required	Description	Default
`count`	No	How many to generate (1-256).
`version`	No	4 for random UUIDs, 7 for time-ordered UUIDs that sort chronologically.

TDQS

A4.2/5.0

Behavior4/5

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

Adds value beyond annotations (readOnlyHint) by specifying cryptographically secure random source and time-embedding for version 7. No contradictions.

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?

Two sentences, no redundant words. First sentence states action and security, second explains version differences and use case.

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?

Covers input parameters and version implications. Lacks explicit mention of return type (array of strings), but given simplicity and no output schema, it is mostly 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 detailed parameter descriptions. The main description adds context about version 7's suitability for DB keys but does not add new parameter-level details beyond 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 it generates one or more UUIDs with a cryptographically secure random source, and distinguishes between version 4 and version 7, which are unique from sibling tools like http_request or decode_jwt.

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?

Explains when to use each version: version 4 for fully random, version 7 for time-sorted database keys. Does not explicitly state when not to use or list alternatives, but sibling tools are very different so this is sufficient.

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

hash_textHash textA

Read-onlyIdempotent

Computes a cryptographic digest (or keyed HMAC) of a string. Supports md5, sha1, sha256, sha384, and sha512 with hex, base64, or base64url output. Can also verify the result against an expected digest using a constant-time comparison.

ParametersJSON Schema

Name	Required	Description	Default
`key`	No	If provided, computes an HMAC keyed by this secret instead of a plain digest.
`text`	Yes	The text to hash, interpreted as UTF-8.
`encoding`	No	How to encode the digest bytes.	hex
`expected`	No	An expected digest to compare against, using a constant-time comparison.
`algorithm`	No	Digest algorithm. md5 and sha1 are provided for interoperability only.	sha256

TDQS

A4/5.0

Behavior5/5

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

Annotations already indicate read-only and idempotent behavior. The description adds important behavioral details: constant-time comparison for verification, and a caveat that md5/sha1 are for interoperability only. This fully discloses key behaviors beyond annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two concise sentences with no fluff. The first sentence covers purpose and options, the second adds the verification feature. It is front-loaded and every sentence adds value.

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?

The description lacks information about the return value or output format, which is critical since no output schema exists. It does not explain what the tool returns (e.g., hex string, boolean for verification). This gap makes it incomplete for an agent to interpret results.

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 schema already describes each parameter. The description does not add significant new meaning beyond what is in parameter descriptions, such as the HMAC computation when key is provided, which is already stated in the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it computes a cryptographic digest or HMAC of a string, specifies supported algorithms and encodings, and distinguishes itself from sibling tools which do not perform hashing. This provides a specific verb+resource combination.

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 does not explicitly state when to use this tool versus alternatives or when not to use it. While it's implied for hashing tasks, no comparisons or exclusions are given. It is adequate but lacks guidance on selection relative to siblings.

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

http_requestSend an HTTP requestA

Sends an HTTP request and returns the status, headers, timing, and body, parsing the body as JSON when the content type says so. Redirects are followed manually so each hop can be re-checked. Responses are capped at 256 KB. Requests to private and loopback addresses are refused unless DEVKIT_ALLOW_PRIVATE_HOSTS=1 is set.

ParametersJSON Schema

Name	Required	Description	Default
`url`	Yes	The absolute http or https URL to request.
`body`	No	Request body. Ignored for GET and HEAD.
`method`	No	HTTP method.	GET
`headers`	No	Request headers as a name-to-value object.
`timeoutMs`	No	Abort the request after this many milliseconds.
`followRedirects`	No	Follow 3xx responses. Every hop is re-checked against the host policy.

TDQS

A4.4/5.0

Behavior5/5

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

The description discloses key behaviors: JSON parsing based on content type, manual redirect following (allowing re-check), 256 KB response cap, and refusal to private/loopback addresses unless env var set. Annotations provide readOnlyHint=false and openWorldHint=true, which are consistent and the description adds significant value beyond them.

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 three sentences, front-loaded with purpose, then technical details. Every sentence adds value with no wasted 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?

Given the tool's complexity (6 params, no output schema, nested objects), the description covers return format, JSON parsing, redirect behavior, size limit, and host restrictions. It could mention error handling or what happens when response exceeds the cap, but overall quite 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 description coverage is 100%, so the schema already documents all parameters. The description adds minimal extra parameter detail (e.g., mentioning JSON parsing but not linking to a specific param). 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 uses a specific verb ('Sends') and resource ('HTTP request'), and clearly states what is returned (status, headers, timing, body). It implicitly distinguishes from sibling tools which are unrelated (text/crypto utilities).

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 for making HTTP requests via the web, and siblings are clearly different tools, so context is clear. However, it does not explicitly state when to use or not use this tool versus alternatives.

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

regex_testTest a regular expressionA

Read-onlyIdempotent

Runs a JavaScript regular expression against a string and returns every match with its character offset, positional capture groups, and named capture groups. Optionally performs a replacement so you can preview the substituted output.

ParametersJSON Schema

Name	Required	Description
`flags`	No	Regex flags such as "i" or "im". The g flag is always applied.
`input`	Yes	The text to match against.
`pattern`	Yes	The regular expression source, without delimiting slashes.
`replacement`	No	If provided, also returns the input with each match replaced by this string. Supports $1, $<name>, and the other standard String.replace patterns.

TDQS

A4/5.0

Behavior4/5

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

Annotations already indicate readOnlyHint=true and idempotentHint=true, so the description adds detail about the return structure (matches with offsets, positional and named capture groups) and optional replacement behavior. This provides useful insight into the tool's output and mutation-free nature.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences long, efficient, and front-loaded with the primary action. Every sentence adds value, and there is no redundancy or fluff.

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 no output schema, the description adequately describes return values: matches with offsets and capture groups, plus optional replacement output. Parameter coverage is complete. It could mention error handling or flag validation but is sufficient for an agent to understand the tool.

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 describes all 4 parameters with 100% coverage. The description adds no parameter-specific details beyond what the schema already provides, such as clarifying flag patterns or replacement syntax. The baseline of 3 is appropriate given schema coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool runs a JavaScript regex against a string and returns matches with character offsets and capture groups. It also mentions an optional replacement feature. This differentiates it from sibling tools like transform_text, which may perform general text transformations.

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 explains the tool's functionality but does not provide explicit guidance on when to use it versus alternatives, nor does it mention any exclusions. The optional replacement feature is shown, but no comparison to sibling tools like transform_text is given.

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

transform_textEncode, decode, or reformat textA

Read-onlyIdempotent

Applies a reversible text transformation: base64 and base64url, hex, and URL percent encoding in both directions, plus JSON pretty-printing and minification. Decoding operations validate their input and report an error rather than returning garbage.

ParametersJSON Schema

Name	Required	Description
`input`	Yes	The text to transform.
`indent`	No	Indent width for json-format. Ignored by every other operation.
`operation`	Yes	Which transformation to apply.

TDQS

A4.2/5.0

Behavior4/5

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

Annotations already set readOnlyHint and idempotentHint to true, so the description doesn't need to repeat those. However, it adds valuable behavioral context: decoding validates input and reports errors rather than returning garbage, and that the indent parameter is ignored by non-json operations. This goes beyond what annotations provide.

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?

Two sentences, front-loaded with the main purpose and operation list. Every sentence adds essential information: first covers all operations, second covers validation behavior. No redundancy or fluff.

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 moderate complexity (multiple transformation types), the description is fairly complete. No output schema exists, but for a transformation tool the return value is self-evident. Parameters are fully described in schema. The only minor gap is no mention of size limits or performance, which is acceptable for a simple transformation tool.

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 coverage is 100% (all three parameters have descriptions). The description adds extra semantics: it clarifies that the indent parameter is ignored by every operation except json-format. This adds value beyond the schema's description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it applies reversible text transformations, listing specific operations (base64, base64url, hex, URL encoding/decoding, JSON formatting/minification). It directly distinguishes itself from sibling tools like hash_text (irreversible) or decode_jwt (specific JWT only).

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 lists what the tool does but does not explicitly say when to use it versus alternative tools (e.g., for encoding/decoding this is appropriate, but no direct comparison with siblings or exclusions). Usage context is implied by the operation list, but no when-not or alternative guidance is provided.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

7 tool updatesv1.0.0Jul 28, 2026
- First observedcron_explain
- First observeddecode_jwt
- First observedgenerate_uuid
- First observedhash_text
- First observedhttp_request
- First observedregex_test
- First observedtransform_text

Install Server

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

TDQS

A4.3/5.0

Disambiguation5/5

Each tool has a clearly distinct purpose: HTTP requests, JWT decoding, hashing, UUID generation, regex testing, cron explanation, and text transformations. No overlap or ambiguity exists.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern in snake_case (e.g., decode_jwt, hash_text, generate_uuid). The pattern is predictable and easy to understand.

Tool Count5/5

Seven tools is well-scoped for a general developer utility kit. Each tool covers a fundamental, non-overlapping function without being excessive or insufficient.

Completeness4/5

The tool set covers key developer needs: networking, crypto, identifiers, text processing, regex, and cron. Minor gaps like JSONPath or data format conversion are not critical for the stated purpose.

Maintenance

ActivitySlowing

ResponsivenessSyncing

Resources

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

drwho.me developer tools A
me.drwho
Remote MCP server: 10 developer utilities (base64, JWT, DNS, UUID, URL, JSON, UA, IP lookup).
Developer Tools
2221
botoi-mcp A
io.github.XogZ3
49 developer tools via MCP: DNS, WHOIS, IP lookup, JWT, hashing, QR, and more.
Developer Tools Networking & Infrastructure
492
ToolPipe MCP Server
io.github.COSAI-Labs
238+ dev tools via MCP: JSON, QR, PDF, DNS, hash, UUID, code review, JWT, SSL, WHOIS, and more
Developer Tools Code Analysis App Automation
26
developer-tools B
net.programmes
65+ free in-browser developer tools (JSON, Base64, JWT, hash, regex…) callable over MCP.
Developer Tools Code Analysis
2

Related MCP Servers

mcp-server-devutils
Developer Tools Command Line
ofershap
A
license
A
quality
D
maintenance
Zero-auth MCP server with everyday developer utilities: base64, UUID, hash, JWT decode, cron, timestamps, JSON, regex.
Updated 6 months ago (2026-03-10 09:22 UTC)
17
88
4
MIT
mcp-dev-utils
Developer Tools
jegor377
F
license
A
quality
C
maintenance
A lightweight MCP server providing everyday developer utilities such as JSON formatting, UUID generation, Base64 conversion, HTTP status lookup, and Unix timestamp conversion as tools and resources.
Updated 3 months ago (2026-06-19 10:43 UTC)
5
-
bmobot-mcp
Developer Tools Code Analysis
RockaRhymeLLC
F
license
B
quality
D
maintenance
MCP server providing 37 developer tools for hashing, encoding, regex, JSON, SQL, cron, QR codes, UUID, JWT, and more, all powered by bmobot.ai APIs.
Updated 7 months ago (2026-02-15 07:15 UTC)
37
-
toolkit-mcp
Developer Tools
pyofart
A
license
Not graded
quality
B
maintenance
An MCP server offering developer utilities including JSON validation, base64 encoding, timestamp conversion, and hashing, built with a clean architecture for easy extensibility.
Updated 2 months ago (2026-06-28 00:55 UTC)
MIT

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/lllNuggetslll/devkit-mcp'

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