Skip to main content
Glama

Generar ID estilo Nano ID

nanoid
Read-only

Genera IDs aleatorios compactos y seguros para URL (21 caracteres por defecto) o con alfabeto propio. Cuándo: hay que generar un identificador en este formato o leer los campos que lleva dentro. No para: generar un token aleatorio de 1 a 256 bytes en hex, base64url o base58 (random-token). Efectos secundarios: ninguno (solo lectura, sin red, sin estado guardado). No determinista: aleatorio salvo que se dé seed. Límites: entrada JSON de hasta 64 KB, 1 s por llamada, resultado de hasta 1 MB.

EN: Generates compact URL-safe random IDs (default 21 chars from A-Za-z0-9_-) or with a custom alphabet of 2-256 unique characters, without modulo bias. When: an identifier has to be generated in this format or its embedded fields decoded. Not for: generating a random token of 1-256 bytes encoded as hex, base64url or base58, e.g. for API keys or nonces (random-token). Side effects: none (read-only, no network access, no stored state). [EN completo / full EN: inputSchema.description]

Input Schema

NameRequiredDescriptionDefault
seedNoOptional seed. With a seed the output is reproducible; without one, cryptographically random bytes are used (string; optional; up to 256 chars).
sizeNoLength (integer; optional; default 21; min 2; max 256).
countNoHow many to generate (integer; optional; default 1; min 1; max 100).
alphabetNoCustom alphabet (string; optional; at least 2 chars; up to 256 chars).

Output Schema

NameRequiredDescriptionDefault
idsNo
avisoNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedOutput schema / properties / aviso
      Added value: +{
      +  "type": [
      +    "null",
      +    "string"
      +  ]
      +}
  2. Changed1 schema field changed
    • addedInput schema / description
      Added value: +"EN: Generates compact URL-safe random IDs (default 21 chars from A-Za-z0-9_-) or with a custom alphabet of 2-256 unique characters, without modulo bias. When: an identifier has to be generated in this format or its embedded fields decoded. Not for: generating a random token of 1-256 bytes encoded as hex, base64url or base58, e.g. for API keys or nonces (random-token). Side effects: none (read-only, no network access, no stored state). Not deterministic: random unless seed is given. Limits: JSON input up to 64 KB, 1 s per call, result up to 1 MB."
  3. First observed

TDQS

A4.2/5.0
Behavior4/5

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

Adds real value beyond the annotations: no network, no stored state, non-determinism that is removed when seed is supplied, and hard limits (64 KB input, 1 s per call, 1 MB result). The safety profile itself (readOnlyHint true, openWorldHint false) is already carried by annotations, so this is supplementary rather than essential; return-value shape is left to the existing output schema.

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

Conciseness4/5

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

Front-loaded with purpose, then when/not-for, side effects and limits – a sound order. The Spanish and English versions duplicate the same content verbatim, and the trailing pointer '[EN completo / full EN: inputSchema.description]' is redundant noise, inflating length without adding information.

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?

For a 4-param generator with an output schema and full annotation coverage, the description supplies everything needed to call it correctly: determinism via seed, alphabet constraints, batch size, and resource limits. The only gap is the confusing 'embedded fields' phrasing, which could send an agent looking for a decode capability this tool does not expose.

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%, so the baseline is 3, but the description adds semantics the schema lacks: the default alphabet charset A-Za-z0-9_- and the requirement that custom alphabet characters be unique (schema only states length bounds). It does not explain how seed interacts with count or alphabet, which is the one remaining ambiguity.

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

Purpose4/5

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

States a concrete verb and resource ('Genera IDs aleatorios compactos y seguros para URL'), names the default format (21 chars, A-Za-z0-9_-) and the custom-alphabet variant, which cleanly separates it from token/ID siblings. The clause 'o leer los campos que lleva dentro' ('or read the fields it contains') is misleading, since a random Nano ID has no embedded fields to decode, and it muddies an otherwise precise statement.

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?

Gives an explicit When ('hay que generar un identificador en este formato') and an explicit Not-for with the named alternative ('random-token' for hex/base64url/base58 tokens of 1-256 bytes) plus the motivating use cases (API keys, nonces). An agent can route between nanoid and random-token without opening either schema.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources