Skip to main content
Glama
toolkit-mcp-server

toolkit-mcp-server

by cyanheads

Server Configuration

Describes the environment variables required to run the server.

NameRequiredDescriptionDefault

No arguments

Instructions

Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.

Five tools are always available: toolkit_hash_value (digests and HMACs, and constant-time comparison against a published checksum or signature), toolkit_encode_value (base64, base64url, hex, and URL encoding), toolkit_generate_id (UUIDs and ULIDs from the platform CSPRNG), toolkit_generate_qr (QR codes), and toolkit_geolocate_ip. Geolocation is the only one that calls an outside provider, and its per-minute request budgets belong to this server process and are shared by every caller: send several addresses as one batch and reuse results already returned. The tools work on the strings you pass; none reads a file path or fetches a URL, so a path sent as a value is processed as text. Two host diagnostics, toolkit_check_network and toolkit_check_system, register only when the operator starts the server with TOOLKIT_ENABLE_NET_DIAGNOSTICS=true or TOOLKIT_ENABLE_SYSTEM_INFO=true, and they report on the machine this server runs on, not the caller's. The toolkit-guide skill (skill://toolkit-guide/SKILL.md) carries the gates for reading a digest or signature mismatch, webhook and JWT signing inputs, moving digests between encodings, who runs a network, and host diagnostics.

Capabilities

Features and capabilities supported by this server

Protocol revision2025-11-25

CapabilityDetails
tools
{
  "listChanged": true
}
logging
{}
prompts
{
  "listChanged": true
}
resources
{
  "subscribe": true,
  "listChanged": true
}
extensions
{
  "io.modelcontextprotocol/skills": {
    "directoryRead": true
  }
}

Tools

Functions exposed to the LLM to take actions

NameDescription
toolkit_hash_valueA

Generate a cryptographic digest or HMAC of a value, or verify a value against an expected digest. Set operation to "generate" for a digest, or "compare" to constant-time-check value against the expected digest — compare is timing-safe and avoids manual string equality checks. Omitting operation compares when expected is supplied and generates otherwise. Algorithm defaults to sha256; sha384 and sha512 are also secure, while md5 and sha1 are exposed ONLY for checksum and file-integrity compatibility and for verifying existing HMAC-SHA1 signatures, and must not be used for passwords, new signatures, or any other security purpose. Set secret to compute HMAC(algorithm, secret, value) instead of a plain digest, for generate and compare alike — the check behind webhook signatures such as GitHub's X-Hub-Signature-256 (pass the header value as expected) and HS256 JWT signatures; secretEncoding says how secret is written (utf8 default, hex, base64, or base64url for a JWK k), the result carries hmac: true, and the secret is never echoed back. digestEncoding selects the generated digest form: lowercase hex (default), base64, base64url (unpadded, the JWS signature form), or sri (-, the npm lockfile integrity and Subresource Integrity form, sha256/sha384/sha512 only, plain digests only). expected is recognized by its shape at the algorithm's digest length, so a published checksum can be pasted as-is: a bare hex, base64, or base64url digest; SRI, which may hold several space-separated entries as an npm integrity field can and matches when any entry for algorithm does; one checksum-file line as sha256sum, shasum, md5, or openssl dgst prints it ( , or SHA256 () = ); or a digest prefixed sha256: or sha256= (OCI and release-asset digests, webhook signature headers). A tag or prefix naming another algorithm fails rather than being ignored, and a multi-line checksum file must be cut to the one line for the file. inputEncoding controls how value is read before hashing (utf8 default, or hex/base64 for raw binary data) so binary blobs need no decode round-trip. The canonical use is matching a download against a vendor-published checksum or a lockfile integrity entry.

toolkit_generate_idA

Mint cryptographically-random identifiers using the platform CSPRNG — the correct source for IDs that must be unpredictable, unlike model-generated values. type selects the format: uuid_v4 (random, the default), uuid_v7 (time-ordered, sortable by creation), or ulid (26-char Crockford-base32, lexicographically sortable). Set count to mint a batch in one call (up to 1000); the returned ids array always contains exactly count values and is never truncated. For uuid_v7 and ulid, a batch is monotonic — strictly increasing even within the same millisecond — so the ids array stays in sorted creation order; ids minted in the same millisecond are separated by random gaps, so no id in a batch can be derived from another. IDs from this tool feed into toolkit_generate_qr (pass ids[0] as data) to create a scannable code.

toolkit_generate_qrA

Encode text or a URL into a QR code. data is the content to encode (a link, a generated identifier such as toolkit_generate_id's ids[0], or any string). format selects the output: svg returns inline SVG markup sized in pixels, png_base64 returns base64-encoded PNG bytes (with mimeType and byteLength), and terminal returns plain Unicode half-block characters (no escape codes) for a monospace display, drawn for a dark background: light modules, quiet zone included, are blocks and dark modules are spaces. errorCorrection (L/M/Q/H) trades data capacity for damage tolerance, margin sets the quiet-zone width in modules, and scale sets pixels per module for svg and png_base64, so both are (modules + 2 × margin) × scale pixels per side. The returned version (1–40) reflects how dense the encoded data is. png_base64 rejects an image past 2048 px per side with a typed raster_too_large error, so a dense symbol needs a lower scale; svg is vector markup and carries no such limit.

toolkit_encode_valueA

Encode or decode a value across base64, base64url, hex, or URL (percent) encoding, in either direction. Set operation to "encode" to transform raw UTF-8 text into the chosen encoding, or "decode" to recover the original bytes from an encoded value. Decoded bytes come back as UTF-8 text by default; set outputEncoding to "hex", "base64", or "base64url" (unpadded, the form JWK members, JWS signatures, and PKCE code challenges use) to receive them re-encoded instead, which is lossless for binary data and transcodes between encodings (a base64 digest to hex, or hex key bytes to base64url, for example). Decoding never substitutes replacement characters: bytes that are not valid UTF-8 text are reported as a recoverable error that points at outputEncoding. Whitespace in hex, base64, and base64url values is ignored, so line-wrapped MIME bodies and PEM bodies decode as-is (drop PEM's -----BEGIN/END----- lines, which are not base64). base64url uses the URL-safe alphabet (- and _ instead of + and /); url applies encodeURIComponent and percent-decoding. A value that is malformed for the chosen encoding is reported as a recoverable error, not a silent best-effort.

toolkit_geolocate_ipA

Resolve a public IP or dotted hostname to country, region, city, coordinates, ASN, AS holder and name, organization, ISP, timezone, and proxy/hosting/mobile flags. Supply target for one lookup or targets for an ordered batch, never both; blank target and empty targets are unset. Batches process the first 100 positions (duplicates retained) and disclose every remainder in unprocessedTargets; at most 1000 inputs are accepted. Each batch position reports its result or an error with recovery, so cached and local outcomes survive quota refusals. The provider is called directly, never the target. Hostnames are DNS-resolved and resolvedIp names the located address. Private/reserved addresses have no public geolocation. Results are best-effort, city-level at best; VPNs, proxies, mobile NAT, and anycast defeat IP-to-location. Read proxy, hosting, and mobile before trusting coordinates: true describes infrastructure, not the user. org can name a customer or sub-allocation rather than the network operator; read isp, asHolder, and asName for the operator. Absent metadata remains unknown. Provider-supplied names are third-party registry text; content[] escapes them so they read as literal text, never as Markdown. source names the provider. Single and batch quotas are independent; cache hits consume neither quota.

Prompts

Interactive templates invoked by user choice

NameDescription

No prompts

Resources

Contextual data attached and managed by the client

NameDescription
toolkit-guideGates for the toolkit_* tools. Use when checking a download checksum, webhook HMAC, or HS256 JWT with toolkit_hash_value; moving digest bytes between hex, base64, and base64url; or reading who runs an IP's network from toolkit_geolocate_ip. Also covers the operator-gated toolkit_check_network and toolkit_check_system. Read before reporting a mismatch, a down host, or an IP's owner, or when a task needs a host diagnostic missing from the tool list.

TDQS

A4.6/5.0

Scored across 5 tools

Disambiguation4/5

Each tool targets a clearly distinct resource: hashing, encoding, IP lookup, ID generation, and QR generation. The only mild overlap is between toolkit_hash_value and toolkit_encode_value, since both accept hex/base64/base64url forms and the hash description even mentions transcoding, so an agent might hesitate on which to call to convert a digest between encodings.

Naming Consistency5/5

All five tools share the prefix `toolkit_` followed by a consistent verb_noun pattern (hash_value, encode_value, geolocate_ip, generate_id, generate_qr). The verb choice matches the operation type (generate/hash/encode/geolocate) predictably.

Tool Count4/5

Five tools is within the healthy range and each is a self-contained, non-trivial utility with paired operations (generate/compare, encode/decode, single/batch). For a general-purpose 'toolkit' the selection feels somewhat arbitrary and sparse, but nothing is redundant.

Completeness4/5

Within each tool the surface is complete: hashing supports generate and verify, encoding supports both directions and transcoding, ID generation supports batching and multiple formats, QR supports multiple output formats, and geolocation supports single and batch. As a broad 'toolkit' there are gaps (no timestamp/date, JSON, regex, or compression utilities), but they are workable for the apparent crypto/encoding/identity focus.

Maintenance

ActivityActive
ResponsivenessLimited data