Skip to main content
Glama

toolkit-mcp-server

by io.github.cyanheads

toolkit-mcp-server: generate id

toolkit_generate_id
Read-only

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 from this tool feed into toolkit_generate_qr (pass ids[0] as data) to create a scannable code.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
typeNoIdentifier format: uuid_v4 (random), uuid_v7 (time-ordered), or ulid (sortable Crockford-base32).uuid_v4
countNoHow many identifiers to mint (1–1000). The full batch is always returned.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
idsNoThe minted identifiers — exactly count of them, in mint order; for uuid_v7 and ulid that order is strictly increasing (sorted by creation).
typeNoThe identifier format that was minted.
countNoThe number of identifiers minted (equals the requested count).
errorNoPresent when the call failed. Absent on success.

TDQS

A5/5.0
Behavior5/5

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

Adds substantial behavior beyond the readOnlyHint annotation: CSPRNG usage, strict batch semantics (exactly count, never truncated), monotonic ordering for uuid_v7 and ulid, and sortability properties. This is exactly the kind of behavioral context that helps an agent reason about results.

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?

Dense but not bloated: every sentence contributes either a purpose statement, parameter nuance, behavioral guarantee, or integration hint. The primary purpose is front-loaded before implementation details.

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?

Complete for a two-parameter tool with a readOnly annotation and an output schema. It covers identity, randomness source, format choices, batch limits, ordering guarantees, and a downstream usage example — nothing necessary for correct invocation is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Even though the schema already documents both parameters at 100% coverage, the description adds meaningful semantics: uuid_v7 is time-ordered, ulid is 26-char Crockford-base32, and count produces an exactly-sized sorted batch. It enriches the schema rather than repeating it.

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?

States a specific verb ('mint') and resource ('cryptographically-random identifiers') with an explicit correctness claim about the CSPRNG source. It clearly distinguishes the tool's scope from sibling tools and explains the type variants.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly frames the tool as the correct source for unpredictable IDs and contrasts it with model-generated values, which is a direct when-to-use/when-not-to-use signal. It also describes type selection, batch counts, and a concrete downstream use with toolkit_generate_qr.

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

All toolkit-mcp-server toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.5/5.0
Disambiguation5/5

Each tool targets a distinct function: encoding, ID generation, QR generation, IP geolocation, and hashing. No two tools could plausibly be selected for the same task, and the descriptions reinforce these boundaries.

Naming Consistency5/5

All tools follow the exact toolkit_<verb>_<noun> snake_case pattern with action verbs (encode, generate, geolocate, hash). There are no mixed conventions or vague names.

Tool Count5/5

Five tools is within the ideal 3-15 range and each tool carries substantial functionality through multiple formats, algorithms, or operations. No tool feels like filler, and the set avoids bloat.

Completeness4/5

Each individual tool is internally comprehensive—encode covers four encodings in both directions, generate_id covers common ID formats, and hash covers generate/compare. As a general 'toolkit' it omits some common utility categories, but there are no dead ends or missing operations within the five advertised functions.

Resources