IDs-LE

[IDs-LE Logo]

IDs-LE: The ID That Only Looks Like One

Find every identifier in a document, decode the time inside it, and refuse the ones that cannot be named
UUID · ULID · NanoID · MongoDB ObjectId · Snowflake

[Install from VS Code Marketplace] [Open VSX downloads] [ids-le-mcp on npm] [ids-le on crates.io] [LE Tools]

Useful? A star or rating is how other developers find it — ★ GitHub · ★ Open VSX · ★ Marketplace

What it does

A support ticket quotes 6a7bb780a1b2c3d4e5f60718 and asks when the record was made. A regex says ObjectId, minted 2026-08-12. It is the front of a git commit hash, and the date is noise that happens to land in a plausible year.

Open a document, press Ctrl+Alt+I (Cmd+Alt+I on Mac), and every identifier in it is listed by kind with its line and column, the document's own key path for it, whether it is valid, and — for the six schemes that carry a clock — the instant it was minted, as ISO-8601 UTC. The report opens beside the editor. Works in VS Code and in VS Code–based editors like Cursor and VSCodium (installable from Open VSX).

• Reading a log or a dump — which of these are UUID v7s, and when was each minted?
• Reviewing a config — the placeholder nil UUID that escaped into production
• Before trusting a hex string — whether the document actually says it is an identifier

A run it cannot name honestly is reported with the reason, never dropped. It rewrites nothing.

Install

It refuses rather than guesses

A tool that answers confidently and wrongly is worse than one that stops and names what it needs. So every run this crate will not name is a row in the report with a reason — never a dropped row, never a silent guess.

Some are worth spelling out, because they are the cases a regex gets confidently wrong:

• 5d41402abc4b2a76b9719d911017c592 is an unhyphenated UUID and an MD5 digest. Nothing in a document separates them, so nothing here picks.
• 6a7bb780a1b2c3d4e5f60718 is 24 hex characters. Under _id it is an ObjectId minted on 2026-08-12. Under checksum, or in prose, it is refused — an ObjectId's whole specification is 24 hex characters, so a truncated SHA-1 fits it exactly and only the document can tell them apart.
• 1536886938009600000 under channel_id is a Discord Snowflake at 2026-08-12. Under a bare user_id it is refused, because the Twitter epoch fits too and the document does not say which. Under population it is not a finding at all.

The full table, and the boundaries the tool holds itself to, are in crate/SPEC.md.

The kinds

Two of those kinds need the document's permission. An ObjectId is 24 hex characters and a Snowflake is a large integer; neither carries a version, a variant, a checksum or a restricted alphabet, so neither run can say on its own what it is — a truncated git hash is a structurally perfect ObjectId, and a byte count is a structurally perfect Snowflake. Both are named only where the field's own name ends in id (_id, userId, USER-ID, $oid), and refused as ambiguous_kind otherwise. In a plain-text file, which has no keys at all, neither is ever named.

All eight UUID versions RFC 9562 defines are recognised, and all four variants — ncs, rfc4122, microsoft, future — are reported. A version is only reported under the RFC variant, because in any other layout those four bits are not a version field.

The timestamps

This is the part nobody wants to write twice. Six of these carry a clock, in six unrelated bit layouts, over four different epochs — one of which starts in 1582:

Every one comes back as the same ISO-8601 UTC string, milliseconds always present. UUID v2 is named and not decoded: its clock has its low 32 bits overwritten by a POSIX uid, so it resolves to roughly seven minutes and is not the same claim.

A decode that lands before 1990 or more than a year from now is refused as timestamp_implausible — and the decode is on the row next to the flag, because a refusal that hides its evidence is a verdict a reader cannot check.

Formats

JSON (and JSONC), YAML, TOML, INI (.properties), dotenv, CSV and TSV give each finding a key path — service.requestId, documents.[0]._id, discord.channel_id. Everything else is read as text: the same runs, in the same places, without the key.

The key path is evidence, not decoration. ObjectId and Snowflake are named only under a field the document calls an id, so a run that is named in the .json comes back ambiguous_kind in the .md beside it — same row, same position, same decode, and a reason instead of a name.

Use it from an AI agent

The same engine runs as an MCP server, so an agent can call it directly instead of guessing which hex string is which.

extract_ids(content, format?, filename?, kind?, maxResults?)

It returns the rows the editor renders, refusals included, as data — capped at 500 by default with meta.truncated. It reads no files and makes no network requests. Published as ids-le-mcp on npm and as io.github.nolindnaidoo/ids-le in the MCP registry. It answers exactly as the Rust CLI's server does: one corpus runs against both, and a differential test feeds both thousands of generated documents in every format and compares every answer.

{  "mcpServers": {    "ids-le": {      "command": "npx",      "args": ["-y", "ids-le-mcp"]    }  }}

echo '{"jsonrpc":"2.0","id":1,"method":"tools/list"}' | npx -y ids-le-mcp

The CLI

The same extraction runs over a whole tree from a terminal or a CI step: a Rust CLI in crate/, sharing one corpus with the extension — crate/fixtures/ — so the two can never read an identifier differently.

[ids-le in a terminal]

ids-le src/                    # a tree, one JSON line per fileids-le --kind uuid src/        # one scheme; refusals still reportedids-le --strict src/           # exit 2 on anything that could not be namedids-le --hidden src/           # include .envids-le mcp                     # extract_ids and ids_le_scan over MCP on stdio

Exit codes follow grep — 0 identifiers found, 1 none found, 2 the question was malformed. A refusal does not move the exit code; --strict is how a pipeline turns one into a failure.

Commands

Settings

Languages

Twelve languages besides English:

German · Spanish · French · Indonesian · Italian · Japanese · Korean · Portuguese (Brazil) · Russian · Ukrainian · Vietnamese · Chinese (Simplified)

Both halves are covered — the manifest (command titles, setting names and descriptions) and everything shown while the extension runs (notifications, the status bar and the report's headings). A refusal's detail is the engine's English, identical to the CLI's.

Privacy & security

• No network access. The extension never sends data anywhere, and it verifies nothing against a database or an API. The telemetryEnabled setting only writes events to a local Output Channel you can inspect (IDs-LE).
• The MCP server holds the same line. It takes content as an argument and returns data: no filesystem access, no network calls, no telemetry.
• Error notifications redact home directories and credential-shaped fragments.

Documentation

Performance

Median of 7 runs after warmup, on Apple M5 Pro, 24 GB RAM, Node 24.3.0. Inputs are generated by scripts/benchmark.ts rather than checked in, so the sizes above are exactly what was measured. Reproduce with bun run benchmark.

These are machine-specific and are not asserted in CI — a benchmark that gates a build only tells you how busy the runner was.

Testing

97 test cases across 11 files, plus an integration suite that runs in a real VS Code extension host and an end-to-end test that installs the built .vsix into a clean profile.

Generated from a real run — coverage/coverage-summary.json and coverage/test-results.json — by scripts/coverage-readme.js; CI fails if this section drifts. Reproduce with bun run test:coverage, and the case count is the one vitest prints.

More from the LE family

Sixteen single-purpose tools for the work in front of every model. Each ships a Rust CLI and an MCP server. One page: letools.dev

Get it out

• String-LE — Extract every string in a codebase, with its position, so a person can read them
• Numbers-LE — Extract every hardcoded number in a codebase, so a person can check them
• Units-LE — Extract every quantity with its unit, normalized, and refuse the ambiguous ones by name
• Dates-LE — Extract every date and timestamp, and the exact instant each one resolves to
• IDs-LE — Extract every UUID, ULID, NanoID, ObjectId and Snowflake, and decode the time inside
• IPs-LE — Extract every IP address, CIDR block and MAC, normalized and classified by scope
• URLs-LE — Extract every URL in a codebase, with its protocol and exact position
• Paths-LE — Extract every file path in a codebase, and say whether it still points at anything
• Colors-LE — Extract every color in a codebase, and say which ones are not in your palette

Check it

• Regex-LE — Find every regex in a codebase, and report which can be driven into catastrophic backtracking
• Versions-LE — Find where one dependency is constrained differently across a repository's manifests
• i18n-LE — Identify the i18n library a project uses, then audit its catalogs by that library's rules
• Scrape-LE — Check whether a page is scrapeable before the scraper is written, and say when it cannot tell

Guard it

• Secrets-LE — Find hardcoded credentials in a codebase, and never print one into the report
• EnvSync-LE — Compare the dotenv files in a tree, and say which keys are missing from which
• Unicode-LE — Find the Unicode that hides meaning — bidi controls, invisibles, homoglyphs, mixed scripts

Each stands on its own: no shared crate, no published core. Where two of them agree, it is because the same answer was right twice.

Contact — nolindnaidoo.com · GitHub · LinkedIn

Also by nolindnaidoo

Rust — pixelcoords and pixelactions are one loop: pixelcoords answers where, pixelactions acts there. Their own tools, their own voice — not part of the LE family.

• pixelcoords — Freeze your screen, mark regions, get pixel-exact coordinates and crops pixelcoords.dev · crates.io · docs.rs
• pixelactions — Consume human-verified coordinates, perform the interaction, confirm it landed pixelactions.dev · crates.io · docs.rs

License

MIT © nolindnaidoo