A free, fully-offline MCP (Model Context Protocol) server that exposes utility tools to any MCP client — Claude, Cursor, Cline, and other coding agents. Written in Python, runs over stdio, zero dependencies, no API keys, no tracking, works offline.
Tool | What it does |
| UTF-8-safe Base64 encode |
| Base64 decode back to text |
| Generate 1–100 random UUID v4 |
| Validate JSON, pretty-print or minify |
| SHA-256/384/512 hash of text |
| Unix seconds/ms → ISO-8601 UTC |
| Percent-encode / decode |
| snake / kebab / camel / pascal / upper / lower |
| Cryptographically secure random password |
All tools are exposed via the standard MCP methods: tools/list and
tools/call (JSON-RPC 2.0 over stdio).
Related MCP server: mcp-server-devutils
Python 3.9+
python server.pyInstall as a Python package:
uvx --from git+https://github.com/vikash-b5/rookery-mcp -- rookery-mcpRegister python /path/to/server.py (or rookery-mcp) as a stdio MCP
server in your client's config (e.g. Claude Desktop, Cursor, Cline).
A Dockerfile is included for containerized / registry introspection:
FROM python:3.11-slim
WORKDIR /app
COPY pyproject.toml server.py README.md ./
CMD ["python", "-u", "server.py"]echo '{"jsonrpc":"2.0","id":1,"method":"initialize","params":{}}' | python server.py
python server.py --list-toolsThe server starts instantly and answers initialize + tools/list
requests, so it passes MCP registry checks (Glama, mcp.so, official
registry).
MIT
Decode Base64 back to text.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | base64 to decode |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral disclosure burden. It accurately describes the pure transformation from Base64 to text, but it does not disclose behavior for invalid Base64 input, character encoding, or empty strings. These gaps are minor for a simple deterministic utility but leave some ambiguity.
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 one short, front-loaded sentence that says exactly what the tool does without any filler. Every word adds meaning, and it is easy for an agent to parse quickly.
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 than one required parameter and this simple operation, the description is largely complete for an agent to select and invoke the tool. It conveys the transformation and the output format ('text') even though no output schema is present. It slightly lacks details about error cases and encoding, but those are not essential for this common utility.
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 fully documents the single 'text' parameter with the description 'base64 to decode', giving 100% schema coverage. The tool description does not add parameter-level detail beyond that, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb, 'Decode', with a clear resource, 'Base64', and states the result, 'back to text'. This makes the tool's function immediately distinguishable from siblings like base64_encode and url_encode.
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 implies when this tool should be used: whenever one has Base64 data and needs the original text. However, it does not explicitly mention alternatives or say when not to use it, such as directing users to base64_encode for the reverse operation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Encode text to Base64 (UTF-8 safe).
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | text to encode |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full behavioral burden. It explicitly discloses UTF-8 safe handling, which is valuable for non-ASCII inputs. For a simple pure encoding operation, nothing else about side effects is required.
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?
A single sentence with no filler, concise and front-loaded with the operation name and target format.
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 one-parameter utility with a clear inverse sibling and no output schma, the description is complete enough. It tells the agent what the tool produces (Base64) and why (UTF-8 safety), so an invocation can be made deterministically.
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?
Schema coverage is 100%, and the parameter description already documents 'text to encode'. The description adds no extra meaning beyond the schema because it simply restates the same concept.
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 states a specific verb ('Encode') and resource ('text to Base64'), and adds the UTF-8 safety caveat. It distinguishes the operation from the sibling base54_decode, so an agent can identify the intended operation without opening schemas."
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 implies a clear use case: whenever Base64 encoding is needed. It does not explicitly say when not to use it, mention alternative encoders like url_encode, or note that base64_decode is the inverse sibling.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Convert text casing: snake, kebab, camel, pascal, upper, lower.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | ||
| style | Yes | snake |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears the behavioral burden. It discloses the core action and supported styles but doesn't note edge-case behavior (e.g., multi-eord accent, numbers, whitespaces) nor the return type. The operation is simple, but the lack of any explicit edge-case info is a modest gap.
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 concise, front-loaded sentence that contains zero filler. Every part contributes to understanding the tool's purpose and choices.
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 two-parameter converter with no annotations and no output schema, the description is minimally adequate but omits practical details like how multi-word text is parsed and what exact transformation each case style. The tool is simple, but an agent could still have ambiguous meaning of 'camel' behavior without clarifying.
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?
With 0% schema description coverage, the description must compensate. It enumerates the 'style' values and states that 'text' is being converted, which gives meaning to both paramands. It doesn't explicitly map parameter names, but the schema names ('text','style') and the description's list make the mapping uncont amp
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 a specific verb ('Convert') and resource ('text casing'), and enumerates the relevant style options ('snake, kebab, camel, pascal, upper, lower'). This clearly distinguishes it from sibling tools such as base64_encode or sha_hash, so an agent can easily target when to select this tool.
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 context is implied: use this tool when text casing needs to be transformed. It doesn't explicitly mention alternatives or exclusions, but the sibling list shows no overlapping casing converters, so the context is unambiguous. Lacks an explicit when vs. when-not-to-use, keeping it from a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Validate JSON and pretty-print or minify it.
| Name | Required | Description | Default |
|---|---|---|---|
| json | Yes | json text | |
| format | No | output style (default pretty) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden. It conveys that the tool validates and formats, but says nothing about what happens when the input is invalid JSON—whether an error is returned, whether validation fails loudly, or how response messages look. For a validation tool, error behavior is essential context.
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?
A single, tight sentence containing both operations, with no filler. Every word earns its place and the core action is front-loaded.
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—two parameters, all documented, no nested objects—the description is nearly adequate. The notable gap is the absence of output schema and explanation of the return contract: returning formatted JSON vs. a validation status on invalid input. This leaves an agent guessing about what the tool will emit.
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?
Schema description coverage is 100%, so the schema already explains both parameters. The description barely adds param meaning beyond the enum choices ('pretty' and 'min'), which the schema also captures, 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 a specific action ('Validate JSON') and a secondary behavior (pretty-print or minify), with a clear resource (JSON). It reads as the canonical JSON tool among the encoding/formatting siblings, so an agent can identify it without needing the schema.
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?
There is no explicit when-to-use or when-not-to-use guidance. The description implies the intended use, but it never acknowledges alternative forms of JSON handling or mentions conditions that should route the agent away from this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate a cryptographically secure random password.
| Name | Required | Description | Default |
|---|---|---|---|
| length | No | length 8-256 (default 20) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden; it reveals that the output is random and cryptographically secure, and implies a stateless, nondestructive operation. It does not specify the exact character set or output framing, but for a generation action the core behavior is still communicated.
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?
One sentence, no wasted words, all relevant information front-loaded. It does not repeat schema details, annotations, or unrelated chatter.
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?
One optional parameter, no nested objects, and simple behavior make the current description + schema enough for most uses. The only minor gap is the exact return formatting is not described, but the meaning of the return value ('password') is obvious from the tool name and 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 schema already provides 100% of parameter semantics, including length range and default. The description itself adds no parameter-specific information, so it hits the baseline without exceeding it.
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 ('Generate') and a clear resource ('cryptographically secure random password'). It is not a tautology and is clearly distinct from sibling tools like base64_encode, uuid_v4, or timestamp_to_iso.
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 gives clear context: it should be used when a secure random password is needed. It does not name the sibling alternatives or explicitly exclude them, but none of the siblings is a password-generation tool, so the omission is minor.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Hash text with SHA-256, SHA-384 or SHA-512.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | text to hash | |
| algorithm | No | default sha256 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral burden. It only says 'hash text with...' and never states the output format (e.g., hex digest, base64), whether the result is deterministic, lowercase, or how errors are handled. These are meaningful gaps for a tool whose primary return value is the hash itself.
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 filler. Each word informs the core function and the supported algorithm choices.
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 two-parameter tool the description is enough to invoke the operation correctly, but because there is no output schema, the missing output format is a notable gap. Though hashing conventions may imply a hex digest, the description never states it, leaving a non-trivial assumption for callers.
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?
Schema description coverage is 100% since both parameters and their descriptions are present. The text in the description about the algorithm list merely duplicates what the enum in the schema already conveys, adding no new meaning beyond the schema.
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 a specific verb ('hash') and resource ('text') and enumerates the three supported algorithms (SHA-256, SHA-384, SHA-512). This is precise and distinguishes it unambiguously from the sibling tools like base64_encode and uuid_v4.
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 purpose is clear enough that an agent can infer when to use it, but no explicit when-to-use guidance or exclusions are provided. Sibling tools like password_generate could also mind-shares with hashing, yet no direction is given on choosing between them.
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 (seconds or ms) to an ISO-8601 UTC datetime.
| Name | Required | Description | Default |
|---|---|---|---|
| timestamp | Yes | unix seconds or milliseconds |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral disclosure burden. It discloses that the output is UTC, not local time, and that seconds or milliseconds are accepted. It lacks detail on edge cases like invalid inputs or timestamp bounds, but these are minor for a pure conversion utility.
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 one clean, front-loaded sentence with zero redundant phrases. It states the verb, input, and output immediately, which makes it easy for an agent to process.
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 single-parameter pure conversion tool with no output schema, the description is complete: it names the input unit range, target format, and timezone. No additional details are needed for an agent to reliably invoke and understand the result.
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 documents the single timestamp parameter with 100% coverage, including the note that it accepts unix seconds or milliseconds. The description adds no param-specific meaning beyond what the schema already states, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Convert') and names both the input resource ('Unix timestamp') and exact output format ('ISO-8601 UTC datetime'). It is clearly distinguishable from sibling utilities such as base64_encode or url_encode, which handle different transformations.
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 intended use is implied by the input/output pair: use when you need a Unix timestamp rendered as an ISO-8601 UTC datetime. However, the description does not explicitly state alternative tools or when not to use it, though the sibling list makes the niche fairly obvious.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Percent-encode a URL string (also decodes if asked).
| Name | Required | Description | Default |
|---|---|---|---|
| mode | No | encode | |
| text | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations available, anyway fthe description carries the burden. It discloses that the tool can both encode and decode based on what is 'asked', which is useful beyond the name. It also mentions the resource type (URL string) directly; however, it does not detail the return format. The core behavior is fully.
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 well-packed sentence with a clarifying parenthetical. There is no filler or repetition of schema names, and it front-loads the main 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?
For a simple encode/decode utility with only two primitive parameters and an obvious string output, the description is nearly complete. It does not spell out the exact return value, but that is inferable from 'percent-encode'. Its main gap is lacking guidance on edge cases or alternate tool choice.
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 has 0% description coverage, so the description must fill gaps. It does add 'URL string' for the text parameter and implies the decode via mode, but it doesn't explicitly map the two parameters or explain control values for `mode`. This is partial compensation for the missing schema-property descriptions.
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 says clearly what the tool does: percent-encode a URL string, and it mentions the decoding capability in a parenthetical. This is a specific action on a specific resource and is clearly different from the sibling tools like base64_encode/base64_decode, which are base64 operations rather than URL percent-encoding.
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 gives implied guidance: use this when you need to percent-encode or decode a URL string. However, it does not explicitly tell the agent when not to use it or point to alternative tools, such as base64_encode/decode for base64 encoding, so exclusions are missing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate one or more random UUID v4 strings.
| Name | Required | Description | Default |
|---|---|---|---|
| count | No | how many (default 1, max 100) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full burden. It discloses the key behavior: random generation of UUID v4 strings, and the 'one or more' wording hints at count support. However, it does not specify the return shape (e.g., single string vs. array when count > 1) or whether the randomness source is cryptographically secure. For a simple stateless generator, the core is clear, but there is still room to explain the output format.
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?
A single, front-loaded sentence with zero filler. Every word earns its place: 'Generate' states the action, 'random UUID v4' specifies the exact object, and 'one or more' captures the only parameter scope. There is no unnecessary detail.
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?
This is a low-complexity tool with one optional parameter, full schema coverage, no output schema, and clear sibling distinction. The description plus schema give an agent enough to call it correctly. minor gap: it does not explicitly state that output will be one string or an array of strings when count > 1, nor does it situate this versus password generation, so it is not a full 5.
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?
Schema description coverage is 100%, with the count parameter fully documented as 'how many (default 1, max 100)'. The description does not add additional parameter semantics beyond the schema, but the schema fully covers it, 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?
States a specific verb ('Generate'), a specific resource ('random UUID v4 strings'), and the count scope ('one or more'). This clearly distinguishes it from sibling tools like base64_encode, sha_hash, and password_generate, since UUID v4 generation is unique among them.
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 implies the use case — when you need a UUID v4 string — but it does not explicitly state when to prefer this over alternatives, nor does it mention any exclusions or special contexts. Sibling tools such as password_generate or url_encode are not referenced, leaving the boundary to inference.
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.
v0.1.0base64_decodebase64_encodecase_convertjson_validatepassword_generatesha_hashtimestamp_to_isourl_encodeuuid_v4Scored across 9 tools
Each tool performs a distinct, well-separated utility operation. There is no meaningful overlap between encoding, hashing, UUID generation, timestamp conversion, or case conversion.
Most names follow an object_verb or object_noun snake_case pattern (base64_encode, url_encode, password_generate). A few, like uuid_v4, sha_hash, and timestamp_to_iso, deviate by omitting a clear verb or using a different noun structure, which introduces minor inconsistency.
Nine tools is well-scoped for a general-purpose utility kit. Each tool provides a distinct standalone function without unnecessary bloat.
The set covers a solid range of common developer utilities—encoding, hashing, validation, UUID generation, timestamp conversion, and text manipulation. It lacks reverse conversions like ISO-to-Unix timestamp or additional hash algorithms, but no major dead ends exist for the stated toolset.
Remote MCP server: 10 developer utilities (base64, JWT, DNS, UUID, URL, JSON, UA, IP lookup).
Exact hashing, base64/hex/URL encoding, JWT decoding and UUIDs for AI agents. No auth required.
238+ dev tools via MCP: JSON, QR, PDF, DNS, hash, UUID, code review, JWT, SSL, WHOIS, and more
65+ free in-browser developer tools (JSON, Base64, JWT, hash, regex…) callable over MCP.
