A comprehensive MCP server providing developer tools for encoding/decoding, color conversion, cryptography, timestamp conversion, regex evaluation, and fake data generation.
The CoreKit MCP server provides 15 utility tools for encoding, color conversion, cryptographic operations, and data generation. While all tools are properly registered with names and descriptions, significant quality gaps exist across multiple dimensions. Most tool descriptions lack actionable detail and parameter descriptions are frequently missing or generic. Input schemas are present but sparse, many parameters lack proper type constraints and enums. No output schemas are documented. Error handling provides no recovery guidance. The server follows a simple, single-responsibility pattern per tool, which is good, but falls short on LLM-optimization criteria like parameter constraints, dependency hints, and structured output documentation.
Hash text using bcrypt or compare text with a bcrypt hash.
Convert a color from one format to another. Supported input formats: hex, rgb, hsl, hsv, cmyk. Output formats: hex, rgb, hsl, hsv, cmyk.
Generate a color palette from a base color and a schema. Supported schemas: triadic, quadratic, tetradic, analogous, splitcomplementary.
Generate a color scheme from a base color. Supported schemes: shades, tints, tones.
Convert a timestamp to different formats
Decode text using various methods (Base64, URL, Hex, HTML Entity).
Encode text using various methods (Base64, URL, Hex, HTML Entity).
regex_evaluator has no visible input schema and minimal description. Tool definition exists but parameter structure is completely absent from source.
convert_timestamp lacks parameter constraint documentation. Description says 'Unix timestamp or date string (RFC3339 format)' but does not explain what output formats are produced or how the LLM should choose inputs.
encode and decode tools lack enum constraints for the 'type' parameter. Descriptions mention 'base64, url, hex, html_entity' but do not use JSON Schema enum to restrict LLM choices. LLM may hallucinate invalid encoding types like 'ascii' or 'utf8'.
No output schemas are documented for any tool. LLMs cannot infer what fields to expect in responses, forcing them to parse unstructured text. Response field naming (e.g., what does hash_text return? JSON object with 'md5', 'sha1', etc.?) is invisible to the agent.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 42 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 41 | - | v1 |
Generate fake data of a specified type.
Hash text using md5, sha1, sha256, and sha512.
Generate an HMAC hash for a given text, secret, hash function, and output encoding.
Generate a number of random colors using different generators. Supported generators: pastel, warm, happy, similarhue.
Generate a random string with specified character types and length.
Evaluate a regular expression against a given text.
Generate a new ULID.
Generate a new UUID.
Color tools (color_converter, color_palette_generator, random_color_generator, color_scheme_generator) accept 'base_color' or 'color' strings but lack detailed format guidance. 'Color string to convert. Supported formats: hex, rgb, hsl, hsv, cmyk.' does not specify case sensitivity, required spacing, or error handling for malformed input.
No error recovery guidance provided. Tools like convert_timestamp and color_converter may fail on invalid input, but error responses do not guide the LLM on what to do next (e.g., 'Invalid color format. Try hex like #ff0000 or rgb like rgb(255, 0, 0)').
hash_text description does not specify output format. Returns 'md5, sha1, sha256, and sha512' hashes but does not clarify if output is a JSON object with fields like {md5: '...', sha1: '...'} or a single concatenated string.
random_string and uuid_generator descriptions do not document expected output format (number of items returned, structure, etc.). Do uuid_generator and ulid_generator return a single UUID/ULID as a string, or a JSON array when quantity > 1?
fake_data_generator's dataType parameter uses an enum in description but no explicit JSON Schema enum constraint. Enum list is very long (30+ values); LLM may guess at similar values not in the list.